Most technical SEO audits produce a hundred-item report in which the genuinely important findings are buried among cosmetic ones. This checklist is ordered by what actually costs traffic, so you can stop partway down and still have done the work that matters.
1. Is the site indexable at all?
Start here, because everything else is irrelevant if the answer is no.
- robots.txt — fetch it and read it. A stray
Disallow: /left over from a staging deployment is the single most damaging and most common technical SEO fault. - Meta robots and X-Robots-Tag — check a sample of important pages for
noindex. Content management systems apply it by default more often than people expect. - Search console coverage — look at what is excluded and why. “Discovered — currently not indexed” at scale usually means quality or crawl budget; “Crawled — currently not indexed” usually means the content is thin or duplicated.
- HTTP status codes — important pages returning anything other than 200, and soft 404s returning 200 with an error page.
2. Canonical and duplicate handling
Duplicate content splits ranking signals between URLs that should be one.
Check that one version of the site is canonical and the rest redirect: HTTP to HTTPS, www to non-www or the reverse, trailing slash consistency, and uppercase variants. Four URLs serving the same homepage is still common.
Then check that self-referencing canonical tags are present and correct on template pages, and that parameterised URLs — filters, sorting, tracking parameters — canonicalise to the clean version rather than being indexed separately.
Pagination deserves a specific look: page two of a listing should be indexable but canonical to itself, not to page one, which is a mistake that hides a lot of content.
3. Redirects
Redirect chains waste crawl budget and lose a little signal at each hop. Crawl the site and look for any chain longer than one hop, then point the first URL directly at the final destination.
Also check for redirect loops, redirects to 404s, and internal links pointing at URLs that redirect. Internal links should point at the final URL; there is no reason to make a crawler follow a hop you control.
4. Sitemaps
An XML sitemap should contain only canonical, indexable, 200-status URLs. The common failures are including redirects, noindexed pages, and URLs that no longer exist.
Check that it is referenced in robots.txt, submitted in search console, and split into logical sections if large, so you can see indexation rates by content type rather than as one blended number.
5. Core Web Vitals and real speed
Use field data rather than lab scores where it is available, because it reflects actual users on actual devices. The three measures are largest contentful paint, interaction to next paint and cumulative layout shift.
The common causes are consistent across sites: unoptimised hero images, render-blocking scripts in the head, web fonts loading without a fallback, third-party tags, and ads or embeds inserted without reserved space. Our piece on Core Web Vitals covers the fixes in detail.
A caution on priorities: a perfect score is not the goal. Moving from poor to good matters; moving from good to excellent rarely changes rankings.
6. Mobile rendering
Indexing is mobile-first, so what the mobile crawler sees is what counts.
Check that content is identical between mobile and desktop — hidden-on-mobile content is content you have deprioritised. Check that structured data and internal links are present in the mobile version. And view a few pages on an actual narrow viewport rather than trusting a responsive-design claim.
7. JavaScript rendering
If content is rendered client-side, test what a crawler receives. Fetch a page with JavaScript disabled, and use the URL inspection tool to see the rendered HTML.
Links generated by JavaScript without real href attributes are frequently not followed. Content loaded on scroll or on click is frequently not seen. Where this matters, server-side rendering or static generation for the important pages is the reliable fix.
8. Internal linking
Check for orphan pages with no internal links, important pages more than three clicks from the homepage, and navigation that relies on JavaScript. Our piece on internal linking strategy covers how to structure this deliberately rather than reactively.
9. Structured data
Validate the markup you have and check it matches what is on the page. Invalid markup produces no rich results; markup that contradicts the visible content risks a manual action. See schema markup types for which types are worth adding.
10. International and hreflang, if relevant
If the site serves multiple languages or regions, check hreflang tags are reciprocal, use correct codes, include a self-reference and an x-default, and point at canonical URLs. Hreflang is error-prone and errors are silent.
Tools and the order to use them
A crawler for the site-wide picture, search console for what Google actually sees, a field-data source for speed, and a browser’s developer tools for individual pages. Crawl first to find the patterns, then investigate specific pages.
Export the crawl and sort by status code, then by indexability, then by title duplication. That sequence surfaces most of the significant problems in about twenty minutes.
Writing the output
An audit that lists everything gets nothing fixed. Group findings into three buckets: things costing traffic now, things limiting growth, and things that are merely untidy. Give each a specific action, an owner and an effort estimate.
Then put the top five in a separate section at the front. In practice that is the only part most stakeholders will read, and if those five get done the audit has succeeded.
Monitoring instead of auditing
A twice-yearly audit finds problems up to six months after they appeared. Four checks running continuously catch most of them within days, and they are cheap to set up.
- Indexed page count. A sudden drop is the earliest signal of an accidental noindex or robots.txt change. Alert on any change over 10%.
- Status codes on key URLs. A scheduled check of your top fifty pages, alerting on anything other than 200.
- robots.txt and sitemap content. Diff them daily. Changes should be deliberate and should be noticed.
- Core Web Vitals field data by template. Monthly, so a regression from a new feature is caught before it affects a quarter of traffic.
Most of this can be assembled from search console, a scheduled crawl and a simple alerting rule. The work is a day; the saving is finding out in two days rather than five months.
Audits after a migration
Site migrations are where technical SEO problems cluster, and they warrant their own pass within 48 hours of launch.
Check that every old URL redirects to its direct equivalent with a 301, not to the homepage in bulk, which loses nearly all the value. Check the new robots.txt, since staging configurations travel more often than anyone expects. Confirm the new sitemap is submitted and that canonical tags point at new URLs rather than old ones. Verify analytics and search console are recording the new property. And crawl the whole site looking for internal links still pointing at old URLs.
Then watch indexed page count and impressions daily for a fortnight. A migration that loses traffic usually shows it within the first ten days, and recovering quickly depends on noticing quickly.
Auditing a large, generated site
Sites with thousands of templated pages need an additional pass that the checklist above does not cover. Check the indexation rate across the generated set specifically, since partial indexation is normal and a very low rate indicates a quality judgement rather than a crawl problem.
Check also that thin pages in the set are noindexed and absent from the sitemap, and that the internal linking connects the set to the rest of the site rather than leaving it isolated. Our piece on programmatic SEO covers the quality thresholds that determine whether such a set helps or harms.
Frequently asked questions
How often should a technical audit run?
A full audit twice a year, plus automated monitoring of indexation, status codes and Core Web Vitals continuously. Also run one after any significant site change.
Does page speed affect rankings directly?
It is a ranking signal, and a comparatively light one. Its larger effect is on conversion and on crawl efficiency. Fix genuinely slow pages; do not chase a perfect score.
Should every page be indexed?
No. Thin pages, internal search results, tag archives with one item and duplicate variants all dilute quality signals. Deliberate noindexing is part of a healthy site.
What is crawl budget and should I care?
The number of pages a search engine will crawl in a period. It matters for very large sites and for sites with many low-value URLs. Below a few thousand pages it is rarely the limiting factor.
