The Technical SEO Checklist I Run Before Any Campaign
In short
Crawl budget, Core Web Vitals, structured data — the audit steps that come first.
Technical SEO is the set of site-health fixes — crawlability, speed, structured data, and indexing — that let search engines find, render, and trust a page before content or links can help it rank. I run the same checklist before starting any SEO engagement, in this order, because fixing content on a site Google can't crawl properly is wasted effort.
1. Crawlability and indexing first
Before touching content, I confirm Google can actually reach the pages that matter. That means checking robots.txt for accidental disallows, reviewing the XML sitemap for stale or missing URLs, and scanning Google Search Console's Page Indexing report for pages marked "Crawled – currently not indexed" or "Discovered – currently not indexed."
A site with hundreds of thin, near-duplicate, or orphaned pages burns crawl budget on pages that will never rank, which slows discovery of the pages that should.
2. Core Web Vitals
I pull real-user data from the Chrome UX Report (via Search Console or PageSpeed Insights) rather than relying only on lab scores, since field data reflects what actual visitors experience.
The three metrics I prioritise, in order of typical impact: Largest Contentful Paint (LCP) — usually fixed by optimising the hero image or font-loading strategy; Interaction to Next Paint (INP) — usually a JavaScript-execution problem; and Cumulative Layout Shift (CLS) — almost always fixed by reserving space for images, ads, and embeds before they load.
3. Structured data
Schema.org markup doesn't directly boost rankings, but it's how you make a page's facts machine-readable — for rich results in classic search, and increasingly for citation by AI answer engines (see my note on GEO below).
For most sites I implement Organization/Person schema sitewide, then layer in page-specific types: Article for blog posts, Product for e-commerce, LocalBusiness for location pages, and FAQPage for any page with a genuine Q&A section.
- Validate every schema block with Google's Rich Results Test before shipping
- Keep schema in sync with visible page content — mismatched schema can trigger manual actions
- Don't mark up content that isn't visible to users
4. Internal linking and site architecture
Once crawling, speed, and markup are sound, I map the internal link graph. Pages that are one or two clicks from the homepage tend to get crawled and refreshed more often than pages buried six levels deep.
For content sites, this usually means building topic hub pages that link out to supporting articles, and making sure every new post links back to at least one relevant hub — closing the loop rather than leaving pages orphaned.
5. Canonicals, redirects and one preferred host
Duplicate URLs split signals. The same page reachable at http and https, with and without www, or with tracking parameters, should resolve to one canonical version. I check that redirects, canonical tags, the XML sitemap and internal links all agree on the same host — a canonical pointing to a URL that redirects elsewhere is a mixed signal that can slow indexing.
Redirect chains are the other common leak: each old URL should redirect straight to its final destination, with a permanent redirect.
- Pick www or non-www and redirect the other permanently
- Self-referencing canonical on every indexable page
- No canonicals pointing at redirected or noindexed URLs
- Sitemap contains only final, canonical, indexable URLs
6. JavaScript rendering
Google crawls, renders and then indexes JavaScript pages, and rendering can be delayed. Other crawlers — including many AI search bots — may not render JavaScript at all. I check the raw HTML the server sends: if the main content, links or headings only appear after scripts run, I move them to server rendering.
7. Monitoring after the fixes
Technical SEO isn't a one-time job. After the audit, Search Console's page indexing report, Core Web Vitals report and crawl stats show whether fixes held — and warn early when a deployment breaks something. I review them monthly, and immediately after any release that touches templates, routing or redirects.
8. Mobile-first checks
Google indexes the mobile version of pages, so the mobile site must contain the same important content, headings, structured data and links as desktop. I check that nothing important is hidden behind tabs that never load on mobile, that images have the same alt text, and that tap targets and font sizes are usable. A page that looks complete on desktop but thin on mobile is, for Google, a thin page.
How I prioritise the findings
An audit usually produces a long list. I sort it by impact and effort: issues that block indexing of important pages come first, whatever the effort; then quick wins such as fixing titles, broken internal links and missing canonicals; then larger projects such as performance work or restructuring navigation. Each item gets an owner and a date, and I re-check Search Console after each batch of fixes to confirm the effect.
- Blockers: important pages not indexed, noindex or robots.txt mistakes, broken redirects
- Quick wins: titles, descriptions, canonicals, internal links, missing alt text
- Projects: Core Web Vitals, site architecture, JavaScript rendering
- Ongoing: monitoring, content quality and new pages
Tools I use for the audit
Search Console for indexing, performance and Core Web Vitals; PageSpeed Insights for page-level speed; a site crawler to list every URL, status code, title, canonical and internal link; the Rich Results Test for structured data; and the browser's page source view to confirm what the server actually sends. Most of these are free — the value is in knowing what to look for and in what order.
Where to start today
Open Search Console's page indexing report and look at why important pages aren't indexed. That single report usually points to the first fix.
Frequently Asked Questions
How often should a technical SEO audit be repeated?
Quarterly for an active site, or immediately after a platform migration, redesign, or major content push — those are the events most likely to introduce crawl or indexing regressions.
Does technical SEO matter if the content is already strong?
Yes — strong content on a page Google can't crawl, render, or trust simply won't rank. Technical SEO is the foundation content strategy sits on top of, not a separate track.
What's the single highest-impact technical fix for most sites?
Fixing pages stuck in "Discovered – currently not indexed" almost always has the fastest, most measurable impact, since it means Google knows the page exists but hasn't allocated crawl budget to render it.
What does 'Discovered – currently not indexed' mean?
Google knows the URL exists but hasn't crawled it yet. Common causes are low perceived value (thin or duplicate pages), weak internal linking, and mixed canonical or redirect signals.
Should my site use www or not?
Either is fine. What matters is choosing one and making redirects, canonical tags, sitemaps and internal links all use it consistently.
Does Google index the mobile or desktop version of my site?
Google primarily uses the mobile version for indexing, so important content must be present on mobile.
Key Takeaways
- Fix crawlability and indexing before optimising content — Google has to find a page before it can rank it.
- Use field data (CrUX) for Core Web Vitals, not just lab scores.
- Validate every schema block and keep it in sync with visible content.
- Internal links closer to the homepage get crawled and refreshed more often.
Sources & further reading
- Page indexing report — Search Console Help
- What is URL canonicalization — Google Search Central
- Redirects and Google Search — Google Search Central
- Understand JavaScript SEO basics — Google Search Central
- Web Vitals — web.dev
- What is a sitemap — Google Search Central
- Rich Results Test — Google
Keep reading
Have a project that touches seo? See SEO, AEO & GEO services.
Get in touch