A technical SEO audit that finds
every issue on your site.

Faults that shipped on a template, not a page

The expensive errors are rarely on a page somebody wrote carelessly. They arrive in a shared template and apply everywhere it renders: a noindex directive that was correct on staging, a canonical tag pointing at a URL that no longer exists, a title pattern that emits the same string for a whole section.

Each of these looks fine when you open a single page, and each affects every page in its section at once. A crawl finds them because it compares pages against each other rather than reading them one at a time.

Faults in the shape of the site, not its pages

A site is a graph of pages linking to pages, and that graph has failure modes no single page reveals. Orphan pages sit outside it entirely, receiving no internal link equity because nothing points at them. Broken internal links spend crawl budget on URLs that return nothing. Redirect chains add hops between a link and its destination. Hreflang clusters break the moment one locale is added without updating the others. You cannot see any of this from a page; you can only see it from the whole set.

Faults that appeared without anyone changing anything

Technical health decays on its own. Outbound links rot as other sites reorganise. Sitemaps drift out of step with what actually exists. A CMS upgrade changes how a tag is emitted. A page that ranked for two years quietly stops being indexable after a plugin update.

None of these announce themselves, and none corresponds to a decision anybody made. That is why comparing one crawl against the previous one finds problems a single audit in isolation cannot: the signal is the change, not the state.

Why the order of fixes decides the outcome

Indexability comes first because it is a gate rather than a scale. If a page is blocked, noindexed, or canonicalised away, no amount of content work will make it rank, and effort spent there is simply lost.

Template-level fixes come second, because one edit clears the same fault everywhere it renders. Structural work follows, and page-level content last, once the pages can actually be reached and understood.

An audit that hands you four thousand rows sorted by page is unusable. The same findings grouped by cause are usually fifteen or twenty real fixes.

What does a technical SEO audit report look like?

A useful one is a list of specific faults, each naming the URL it was found on, what was expected, and what was found instead. "Improve your meta descriptions" is not a finding. "These 43 pages return the string from the category template instead of a description, because the product template does not map the field" is, because someone can act on it without doing the diagnosis again.

The structure that makes a report usable is grouping by cause rather than by page. A four-thousand-row export sorted by URL is unreadable; the same findings grouped by what produced them are usually fifteen or twenty real fixes, most of them template edits that clear hundreds of pages at once. A report that hands you the raw rows has moved the hard part back to you.

Treat the score at the top as a prompt rather than a verdict. It is a weighted sum chosen by whoever built the tool, so the same site legitimately scores differently across two products. It is useful for watching one site over time and close to meaningless for comparing two.

Do you need a paid tool to start?

No, and it is worth knowing what the free options cover before paying for anything. Google Search Console is free and shows what Google actually did with your pages. PageSpeed Insights covers Core Web Vitals per URL. Between them you can diagnose a great deal without spending anything.

Where free tools stop is site-wide crawling with history: comparing one crawl to the last is what turns a list of problems into evidence that your fixes worked. We keep an honest breakdown of the free SEO audit tools worth using, including where each one runs out, and our own tool is listed there on the same terms as the rest.