A technical SEO audit should direct decisions

A long audit report can make a site look thoroughly examined while leaving the ranking problem untouched. A useful technical SEO audit is not a catalogue of tool warnings. It is a decision system: it shows which obstacles prevent valuable pages from being found, understood, indexed or efficiently reached, and it ties each obstacle to a practical change.

That distinction matters because the same warning can mean very different things. A blocked thank-you page may be intentional. A parameterised product page may be harmless until it competes with a category page. Conversely, one missing internal path to a revenue-driving page can matter more than dozens of low-value metadata notices. The goal of SEO and organic search work is to create conditions in which the right pages can earn visibility, not to make a crawler dashboard entirely green.

Establish evidence before drawing conclusions

Start with a baseline that can be revisited after a release: an HTML crawl, a JavaScript-rendered crawl where relevant, XML sitemaps, server log samples, Google Search Console coverage and performance views, and a shortlist of commercially important URLs. For each suspected issue, record the affected template or URL pattern, the number and importance of pages involved, the current response, the canonical target, robots directives, internal-link sources and observed search behaviour. This separates a real pattern from a one-off crawl artefact.

Crawlability and indexation are different questions

Crawlability asks whether a bot can request and process a URL. Indexation asks whether a search engine should keep that URL in its index. A page can be crawlable yet excluded because it is duplicated, thin, noindexed or judged less useful than another version. It can also be indexable in principle but undiscoverable because no meaningful link or sitemap points to it. Treating every excluded URL as a robots problem leads to counterproductive fixes. Inspect the response, page directives, canonical relationship, sitemap inclusion and Search Console status together before changing anything.

Make important URLs easy to discover

Crawl budget becomes operational when a site offers more URLs than its useful pages justify, or when essential URLs are repeatedly buried behind low-value variants. The practical question is not whether every URL receives a crawl. It is whether search engines can consistently discover the pages that serve real search demand. Duplicate filters, calendar states, internal search results and legacy routes can distract crawlers from that work.

Compare the URLs found in navigation, category hubs, XML sitemaps, analytics landing-page data and server logs. Look for valuable pages that appear in only one source, as well as URLs that consume requests without being pages anyone should find. Log data is especially useful because it shows requests actually made, rather than a crawler’s prediction. A sitemap is a declaration of preferred URLs, not a substitute for a connected architecture.

Begin with real URL sources

Build a single inventory from the crawl, sitemap exports, CMS routes and log files. Flag orphaned priority URLs, URLs linked only through forms or scripts, and non-canonical URLs included in the sitemap. Then fix discovery at the source: add descriptive HTML links from relevant hubs, expose essential category paths, keep only canonical 200-status URLs in sitemaps, and restrict generation of valueless parameter combinations. Do not block a URL merely to reduce a count if people or systems still need it; decide first whether it should exist, redirect, be noindexed or remain available.

Resolve canonicalisation and duplicate paths

Duplicate content is usually a URL-management problem, not a request to rewrite every similar sentence. The same content may be available through protocol or host variants, trailing-slash versions, uppercase paths, filtered listings, sort parameters, pagination, print views and old campaign routes. When internal links, sitemaps, canonicals and redirects disagree, search engines must choose between signals instead of concentrating them on the preferred URL.

Gather a sample of each duplicate pattern and compare status code, final destination, canonical tag, robots directive, sitemap presence and internal-link targets. Check which URL Search Console reports as the selected canonical, but also trace why the alternative exists. International sites need one additional check: language and regional alternatives must refer to equivalent, indexable pages; our guide to international SEO and hreflang explains how those relationships differ from canonicalisation.

A canonical tag is a signal, not clean-up

Choose one preferred URL for each equivalent page, then make every controllable signal agree. Self-reference the canonical page, point internal links and XML sitemaps to it, and use a single permanent redirect for versions that should disappear. Remove campaign or filter parameters from navigational links where they add no value. Do not use canonical tags to hide substantially different products, useful paginated content or pages that require their own intent. In those cases, the fix may be a clearer URL strategy, controlled faceting, a redirect decision or genuinely distinct content.

Test JavaScript as a rendering problem

A browser can make a JavaScript-heavy page feel complete even when the initial document contains little meaningful content or no crawlable navigation. Search systems can render JavaScript, but rendering adds dependency, delay and failure points. The audit must therefore test what arrives in the initial response as well as what appears after scripts run. A fast visual load alone does not prove that essential content is available to crawlers.

Compare raw source and rendered DOM for a homepage, a major listing, a detail page and a parameterised route. Record the title, meta robots, canonical, main copy, headings, links, status code and any console or resource failures in both states. Use URL inspection and a rendered crawl as supporting evidence, then check whether blocked scripts, client-side errors or user-state conditions change the output. Performance symptoms belong in the same investigation, but need their own remedy; see our Core Web Vitals and site speed guide for that workstream.

Put essential signals in reliable HTML

The fix is rarely “add more JavaScript.” Server-render or pre-render primary content, metadata, canonical tags, robots directives and critical navigation wherever the platform allows. Ensure links are actual anchor elements with usable href values rather than click-only controls. Keep error states visible to crawlers and return appropriate HTTP statuses from the server, not only a friendly client-side message. Retest representative templates after deployment, because a solution that works on one route can fail on another data state.

Shorten paths and clean up status codes

Internal link depth is not a ranking metric on its own, but it reveals whether important pages sit naturally within the site’s information architecture. A priority service or category that requires several obscure steps to reach has fewer discovery routes and receives weaker contextual reinforcement than one linked from a relevant hub. Measure depth from meaningful entry points, incoming-link counts, orphan status and anchor context—not simply from the homepage.

Use links to explain the hierarchy

Fix depth by connecting priority pages from the pages that genuinely introduce their topic. Add editorial links where a reader needs the next step, strengthen hub and category routes, and repair navigation that hides useful sections behind interactions. Avoid manufacturing hundreds of sitewide keyword links; repetition is not the same as a coherent architecture. This is especially important during a migration or redesign, when preserving redirects and internal paths should be planned alongside the build. Our website redesign SEO guide covers the transition controls in more detail.

Redirects should finish in one useful destination

A redirect audit should follow the whole chain, not stop at the first 3xx code. Export redirecting URLs from a crawl, logs, sitemap validation and internal-link reports; then check for chains, loops, temporary redirects that have become permanent, redirects to irrelevant pages and internal links still pointing at retired addresses. Replace chains with one direct permanent redirect when the move is lasting, update links and sitemaps to the final 200 URL, and return a real 404 or 410 when no relevant replacement exists. That keeps signals clear and avoids spending requests on detours.

Use structured data and sequence fixes by impact

Structured data helps search engines interpret defined entities and may support eligible search appearances, but it does not rescue a page that is undiscoverable, duplicate or poorly aligned to intent. Audit the markup against visible content and the page’s actual type. Gather a rendered-page sample, the detected entities and properties, validation results, and any warnings that affect required fields. Then correct the source template so that markup represents real, current information rather than adding markup solely to satisfy a testing tool. For the underlying concepts, read our schema markup beginner’s guide.

Build the fix queue from consequences, not colours

Audit-tool severity colours are useful for triage, not strategy. First resolve failures that stop high-value pages from being discovered, rendered, crawled or indexed. Next consolidate duplicate signals and broken migration paths that divide visibility. Then improve architecture, status-code hygiene and structured data where the affected templates support meaningful demand. Estimate impact from the value of the affected pages, the reach of the template, the evidence that the problem is live, implementation risk and the ability to verify the result. A focused technical SEO programme turns that sequence into owned changes, retests and measured outcomes rather than an impressive but inert report.