The technical SEO audit checklist we run on every new client

Start every audit by running a full crawl using a tool that renders JavaScript by default. Screaming Frog with JavaScript rendering enabled, Sitebulb, or a headless Chrome based crawler will show you the site as Googlebot experiences it, not as a browser experiences it. Compare the rendered DOM against the initial HTML for your top twenty templates. If key on page content, canonical tags or internal links only appear after JavaScript execution, you have a rendering risk that will limit crawl efficiency. Set your crawler to obey robots.txt so you see what Google is allowed to see, then run a second crawl ignoring robots.txt to see what would be discoverable if you removed disallow rules. The delta between the two crawls tells you what your rules are actually blocking. Save both crawls; you will reference them throughout the audit. A crawl that stops early because of resource limits will produce a misleading audit, so on large sites give the crawler enough memory and let it run overnight. Auditing without a proper crawl is like diagnosing a car without opening the bonnet; you will identify symptoms and miss root causes.

A crawler tells you what is technically discoverable. Search Console tells you what Google actually cares about. Cross reference the two datasets to find the interesting gaps. Pages that appear in the crawl but not in the coverage report are either not being crawled at all or are being crawled and discarded. Pages that appear in the coverage report but not in the crawl are either orphan pages, pages behind authentication, or pages the crawler is missing due to configuration. The most valuable finding is usually the reverse: pages that are indexed but shouldn't be. Faceted search variants, staging URLs that leaked, printer friendly duplicates, sort parameters, and old campaign landing pages routinely accumulate in the index and waste crawl budget. Export the full index coverage report, join it against the crawl and against organic traffic data, and produce a single sheet that shows every URL with its crawl status, index status, canonical target and organic clicks. That sheet is the single most useful artefact of any technical audit. Every subsequent finding in the audit refers back to it.

Nothing else in the audit matters if the wrong pages are indexed. Walk the sheet from the previous section and classify every URL into one of four buckets. Index and rank as is, index but improve, keep but noindex, or remove. Bloated sites often discover that thirty to fifty percent of indexed URLs fall into the last two buckets. Removing or noindexing them is not a scary act. It clarifies what your site is actually about, both for Google and for humans reading your analytics. Use response codes precisely. Permanent removals become 410 gone. Temporary removals become 503 service unavailable. URLs that consolidate into others become 301 redirects, mapped one to one where possible. Never mass 301 unrelated URLs to your homepage; Google increasingly treats those as soft 404s and the redirects lose all equity. After clean up, submit a fresh sitemap containing only the URLs you want indexed, and monitor the coverage report weekly for four to six weeks. It is normal to see impressions dip briefly before recovering higher; do not panic revert on the first weekly drop.

Once indexation is clean, look at architecture. A healthy site keeps every important page within three clicks of the homepage, uses descriptive anchor text on internal links, and clusters related content into topic hubs. Run the crawler's internal link report and look for orphan pages, pages that receive only footer or sitewide links, and pages whose only inbound anchor text is 'read more' or 'click here'. These are silent losers; they cannot rank for the terms they deserve because the site itself does not tell Google what they are about. Rebuild your hub structure by choosing five to fifteen commercial priority topics and mapping every existing page against them. Each hub gets a pillar page, three to ten cluster pages, and a set of internal links flowing bidirectionally between them. Where two pages compete for the same keyword, choose one canonical target and either merge, redirect or noindex the other. Fixing internal linking often produces bigger short term ranking gains than any other single lever because it clarifies intent for pages that were already in the index but under supported.

Pull the Core Web Vitals report from Search Console and prioritise fixes by the total number of URLs affected in each group. Do not chase perfect scores on every page; focus on ensuring the templates that hold ninety percent of your organic traffic are in the good bucket. On most modern stacks, three fixes cover the majority of vitals problems. First, defer non critical JavaScript and eliminate render blocking third party scripts above the fold. Second, size images correctly with modern formats and explicit width and height attributes to prevent layout shift. Third, reserve space for ads, embeds and lazy loaded elements so they do not push content around when they render. If your INP metric is failing, look at heavy client side event handlers and long tasks; these are almost always due to over eager analytics or personalisation scripts firing on every interaction. Ship these fixes template by template, monitor field data for at least twenty eight days, and only then declare the vitals workstream complete. A Core Web Vitals guide is on the site if you want a deeper walkthrough of each metric.

Structured data does not directly boost rankings but it unlocks rich results and helps Google understand relationships between entities on the page. Prioritise Article schema on blog content, Product and Offer on eCommerce templates, LocalBusiness on location pages, FAQPage on pages with genuine FAQs and BreadcrumbList site wide. Validate every template against Google's rich results test and monitor the enhancements reports in Search Console for weekly errors. On canonicals, verify that every template outputs a self referential canonical unless it is deliberately consolidating variants. Mixed canonical signals, especially those set differently in HTML and HTTP headers, will produce hard to diagnose indexation problems. On international sites, audit hreflang implementation across every template and confirm bidirectional references. A one way hreflang tag is worse than no hreflang because it tells Google you know about the alternate market but do not fully trust the mapping. Every template is either fully declared or not declared at all.

The final and most important step is translation. Take every finding from the audit and score it on three axes. Estimated impact on organic revenue over the next twelve months, engineering effort in days, and risk of regression if shipped without careful QA. Multiply impact by an inverse of effort and risk to produce a rough priority score. Sort descending and cut off at the top twenty items. Everything else goes into a backlog you may or may not revisit next quarter. Rewrite each of the top twenty into a proper engineering ticket with acceptance criteria, test cases and rollback plans. Present the list to your engineering lead as a quarterly roadmap, not as an SEO wishlist. Good engineering teams will happily prioritise SEO tickets if they are written in the same language as product tickets and if you commit to measurable outcomes. Bad engineering teams will ignore any SEO document that reads like a plea rather than a plan. The audit is not the deliverable; the ranked, ready to ship ticket queue is. If your audit stops before this step, it is unfinished.