The technical checks look at whether search engines can reach your pages, understand which version to keep, and render what’s on them. Most serious SEO problems I find are here rather than in the content, and they’re usually invisible from the front end.
Built in-house. It is my own tooling rather than a reseller’s dashboard, which is why it checks the things I act on rather than everything a generic tool can measure.
What it does
The technical checks crawl the site and compare what’s found against what’s in Search Console, then report the things actively preventing pages from ranking: blocked or noindexed pages, canonicals pointing somewhere unexpected, redirect chains, duplicate URL trees, broken internal links and status codes that don’t match what the site intends.
The output is a list of problems with the pages they affect, ordered by what’s costing the most.
What it checks
| Area | What it looks at |
|---|---|
| Crawl access | robots.txt rules, blocked resources, and whether anything important is unreachable |
| Indexability | noindex directives, canonicals, and whether pages Google should have are missing |
| Status codes | 404s, 5xx errors, soft 404s, and whether redirects resolve in one hop |
| Duplication | Parallel URL trees, parameter versions and near-identical pages competing with each other |
| Internal linking | Orphan pages, pages with no sitewide link, and how deep key pages sit |
| Sitemaps | Whether sitemaps match what’s actually indexable |
| Rendering | Whether content and links exist in the HTML or only after JavaScript |
| Site speed | Core Web Vitals field data where it’s available, and the obvious build causes |
Two things I always verify before reporting
A 4xx in a crawl isn’t always a broken page. Crawlers get rate limited, and a server under load returns errors to a tool that a browser never sees. I recheck anything reported as 4xx before it goes in a document, because a list of imaginary broken links wastes a developer’s week.
A redirect reads as a canonical if you follow it. If a crawl is set to follow redirects, a page that 301s elsewhere can be reported as having a canonical pointing to the destination. Those are different problems with different fixes, so the check has to distinguish them.
The same care applies to parameter URLs. Before flagging them as a duplication problem, it’s worth confirming whether they’re already canonicalised or noindexed, because very often they are and the finding is noise.
Example output
FINDING: 11 live duplicate page sets, including two parallel URL trees for the same service, three pages covering one scheme, and four URLs for one product type. EFFECT: Ranking signals split across versions. None of the competing pages reaches page one for the main search. ACTION: Choose one URL per topic, redirect the others, and update internal links to point at the survivor.
What I review
Every finding is checked against the live URL. Crawl data is a starting point and it’s wrong often enough that reporting it unverified damages trust the first time a developer checks one and finds nothing there.
Findings are also ordered by commercial impact rather than by count. A hundred missing alt tags on blog images matter less than one noindexed service page, and a report sorted by volume gets that backwards.
Limitations
- A crawl is a snapshot. Sites change, and a problem found on Tuesday may be a deployment from Monday.
- Search Console data has caps. Query and page reports truncate, so some figures are a floor rather than a total.
- Access matters. Some checks need Search Console or server access, which depends on the client granting it.
Services it powers
The technical checks power SEO, XML sitemaps and indexing and site speed and Core Web Vitals, and run over every site migration. See the rest of the tools on the tech stack page.
FAQ
What are technical SEO checks?
They’re checks on whether search engines can reach your pages, understand which version to keep, and render what’s on them. That covers robots rules, canonicals, redirects, status codes, duplicate URLs, internal linking and sitemaps, rather than anything about the writing itself.
Why do crawl tools report errors that aren’t real?
Because a crawler hits a site faster than a person does, and servers under load return errors to tools that a browser never sees. Anything reported as broken gets rechecked against the live URL before it reaches you, since a list of imaginary problems wastes developer time.
How often should technical checks be run?
A full check before and after any significant site change, and a lighter run monthly to catch new 404s, indexing flags and redirect chains as they appear. Sites break gradually, so the value is in spotting things early rather than in an annual audit.
See the whole toolkit
The tech stack page lists every tool, and the free assessment includes a technical review of your site.