A finished design can still hide basic problems
A page may look ready while its title is missing or its canonical URL points somewhere else. It may even ask search engines not to index it. These details sit in the HTML and response headers, so they are easy to miss during a visual review. I built Web Doctor to put those public signals in one report. You enter a URL and the tool shows what it found, why a result may matter, and what to check next. It does not ask you to copy source code unless the website blocks automated access.
What the report reads
Web Doctor requests one public page. It parses that HTML once and shares the parsed result with separate checks. It also requests the origin’s robots.txt file and looks for a sitemap declared there. If none is declared, it checks /sitemap.xml and /sitemap_index.xml. It does not follow every link or crawl the whole website. The report covers the title, meta description, canonical, robots instructions, headings, social metadata, image alt text, links, structured data, document language, viewport, charset, icons, page landmarks, and selected response headers.
How the checks are grouped
The report separates findings into discoverability, metadata, page structure, social sharing, accessibility basics, and technical basics. Security headers appear in their own informational area because they should not be presented as a search ranking score. Each check returns a visible status and plain explanation. A missing description can be important and easy to fix. A missing touch icon is much less urgent. The interface keeps those differences visible so a small site-identity detail does not look as serious as a noindex instruction.
What the score means
The score comes from weights stored in code. Discoverability, metadata, and page structure each have twenty available points. Social sharing has fifteen, accessibility basics has fifteen, and technical basics has ten. A pass receives the configured weight, a warning receives half, and an error receives none. Some findings are neutral when they do not apply or cannot be checked. The total is a quick summary of the checks shown in that report. It is not a Google score, a ranking prediction, or proof that a page will be indexed.
How the server fetch is limited
The browser does not request the target website directly. A protected server route accepts HTTP and HTTPS URLs on the normal web ports. Before each request, the server resolves the hostname and rejects private, loopback, link-local, reserved, multicast, and internal addresses. It repeats that validation for every redirect. The fetch has a ten-second total timeout, a shorter connection timeout, a five-redirect limit, and an HTML limit of about 3 MB. Supporting files have smaller limits. The response must identify itself as HTML before the page is parsed.
Why one failed check does not remove the report
Each diagnostic module runs inside its own error boundary. If sitemap fetching fails, title and heading checks can still finish. The same parsed page is reused, so the analyser does not download the HTML for every check. Independent checks run together where that is safe. Recommendation text also comes from typed, reusable rules. No AI writes the diagnosis at runtime. Given the same fetched document and rule configuration, the tool follows the same scoring and recommendation path.
When to investigate by hand
Web Doctor reads the initial HTML response. It does not run the page in a browser, so metadata added only after JavaScript executes may not appear. It cannot tell whether Google has indexed a URL, whether a structured-data feature meets every current search requirement, or how real visitors experience performance. It also avoids fetching every external link. Use the report to identify a concrete lead. Then inspect the delivered source, deployment settings, Search Console, a platform sharing debugger, or browser accessibility tools when the question goes beyond the public HTML.