Questions
How to check the technical SEO of a website
Checking a site's technical SEO means verifying, in order, that search engines can reach the pages, that they are allowed to index them, and that each page describes itself clearly. Those three questions have a dependency: a page that cannot be crawled will never be indexed however good its title is, so working through them out of order wastes effort on pages that are not in the running.
1. Can it be reached?
Read `robots.txt` at the root. A `Disallow` covering a section stops crawling of that section entirely — and a blocked page never sees its own noindex tag, which is how URLs get indexed without their content.
Read the XML sitemap. Compare it with the pages that internal links actually reach: URLs in the sitemap that no link points to, and pages reachable by link that the sitemap omits, are both findings.
Check status codes. A page returning 404 or 5xx is not a candidate for indexing.
2. Is it allowed to be indexed?
Look for `<meta name="robots" content="noindex">` and for the `X-Robots-Tag` response header, which does the same thing and is easier to miss because it is not in the HTML.
A noindex left over from a staging environment is one of the most common and most expensive single faults on a site, and it produces no visible symptom.
Check canonical tags: a page canonicalising to another URL is asking not to be indexed on its own.
3. Does the page describe itself?
A `<title>` that is present, unique across the site, and identifies the page.
A meta description, or a deliberate decision not to have one.
One `<h1>`, and a heading structure that does not skip levels.
A declared language on `<html lang>`, and hreflang if the site is multilingual.
Structured data matching what is actually on the page.
What to measure across the site, not per page
Distinct titles against total pages. A ratio far below one is a template applying a constant.
Pages with no meta description, grouped by template rather than listed individually.
Internal links pointing at 404s or at redirects.
The gap between sitemap URLs and crawlable URLs.
These are the findings that turn into one task instead of four hundred.
The tools that cost nothing
Google Search Console, if the site is verified: the Page indexing report says which URLs Google knows about and why any are excluded. Nothing else gives you Google's own view.
`curl -I <url>` for status codes and the `X-Robots-Tag` header.
The browser's view-source for title, description, canonical and robots meta.
These answer the question for one page. Answering it for a whole site is where a crawler earns its place.
How VeriFixScan helps
It crawls the site and applies the checks above uniformly: `seo.robots_txt`, `seo.sitemap`, `seo.noindex`, `seo.canonical`, `seo.title`, `seo.duplicate_titles`, `seo.meta_description`, `seo.h1`, `seo.lang` and `seo.open_graph`, with the URL behind every finding.
It also reports what it could not reach and why, which is the part that makes a clean result trustworthy.
What it does not do is track rankings or estimate search volume. It answers whether a site is technically sound, not how it performs commercially.
The JavaScript question, which changes the method
One distinction decides whether any of the checks above are being applied to the right document: whether the page's content is in the server's response or is assembled by the browser afterwards.
Google does render JavaScript, in a second pass after the initial crawl. So a client-rendered page is not invisible — it is delayed, and it is subject to whatever fails during that second pass. Other crawlers, and most generative-engine fetchers, do considerably less.
The test is `curl -s <url>` and reading what comes back. If the title, the headings and the body text are in that response, the site is server-rendered and everything above applies directly. If the response is an empty container and a script bundle, they apply to whatever the render produces, which is not the same document.
That is also why view-source and the browser's element inspector disagree so often. The inspector shows the DOM after scripts have run; view-source shows what was actually sent. For this purpose the second is the one that matters.
The consequences to check when the page is client-rendered: whether the title and description are in the initial HTML or set after mount, whether internal links are real `<a href>` elements a crawler can follow rather than click handlers, and whether the route returns a real 404 status or a 200 with a not-found view.
None of this makes a JavaScript application unindexable. It makes indexing conditional on a rendering step, and the failures it produces are invisible in a browser — which is the whole reason to read the raw response.
Frequently asked questions
- How often should technical SEO be checked?
- The useful trigger is change: after a redesign, a migration, a CMS or plugin upgrade, or a bulk import — those are when template-level faults appear across many pages at once.
- Is a technical SEO audit the same as an SEO audit?
- No. Technical SEO covers crawling, indexing and how pages describe themselves. A full SEO audit also covers content, keyword targeting and links, which are editorial and commercial questions.
- What single fault costs the most?
- A noindex or a robots.txt Disallow left in place from a staging environment. It removes pages from search entirely and produces no visible symptom on the site itself.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website