Here is the uncomfortable truth about technical SEO checklists: they are mostly lists of things Google has already told you matter. Crawlability, indexation, site speed, mobile-friendliness — every guide covers these. And yet, sites with completed checklists still flatline in search.
Why? Because the checklist industry has optimised for completion, not for outcome. Ticking boxes feels productive.
Ranking in competitive positions requires something different: a systems view of how technical signals compound, conflict, and interact across your entire site architecture. When we started working with sites at the foundation level, the pattern that emerged again and again was not that teams had skipped the checklist. It was that they had completed the checklist in isolation — fixing individual items without understanding the chain reaction that connects crawl budget to indexation, indexation to authority signal distribution, and authority distribution to ranking velocity.
This guide is built around that systems view. You will still get a comprehensive checklist — every item you need, with the depth to implement it properly. But you will also get two proprietary frameworks we use internally: the quarterly calibration using the CRAWL CHAIN framework for diagnosing technical SEO at a systems level, and the Signal Stack method for connecting your technical fixes to measurable organic growth.
If you have been running technical audits that produce reports nobody acts on, this guide is specifically for you.
Why? Because the checklist industry has optimised for completion, not for outcome. Ticking boxes feels productive.
Ranking in competitive positions requires something different: a systems view of how technical signals compound, conflict, and interact across your entire site architecture. When we started working with sites at the foundation level, the pattern that emerged again and again was not that teams had skipped the checklist. It was that they had completed the checklist in isolation — fixing individual items without understanding the chain reaction that connects crawl budget to indexation, indexation to authority signal distribution, and authority distribution to ranking velocity.
This guide is built around that systems view. You will still get a comprehensive checklist — every item you need, with the depth to implement it properly. But you will also get two proprietary frameworks we use internally: the quarterly calibration using the CRAWL CHAIN framework for diagnosing technical SEO at a systems level, and the Signal Stack method for connecting your technical fixes to measurable organic growth.
If you have been running technical audits that produce reports nobody acts on, this guide is specifically for you.
Key Takeaways
- 1Technical SEO is not a one-time audit — it's a living system that needs quarterly calibration using the CRAWL CHAIN framework
- 2Most sites leak crawl budget silently; the 'Crawl Drain Audit' method reveals exactly where Google wastes its visits
- 3Canonical confusion is the single most common reason well-optimised pages fail to rank — and most checklists skim over it
- 4Core Web Vitals are a ranking signal, but the real damage is in user abandonment before Google even measures you
- 5Structured data is not optional decoration — it's how you speak to AI-driven search features like SGE and rich results
- 6The 'Signal Stack' framework connects your technical fixes to actual organic revenue, not just crawl stats
- 7Internal linking architecture is a technical SEO issue, not just a content strategy issue — treat it as infrastructure
- 8Log file analysis is the most underused diagnostic tool available to any SEO practitioner — start using it within 30 days
- 9Hreflang errors compound silently across international sites; a monthly hreflang sweep prevents ranking collapse in secondary markets
- 10Technical SEO without a prioritisation matrix means you fix the easy things first, not the high-impact things first
1The CRAWL CHAIN Framework: Why Technical SEO Is a System, Not a Checklist
Before you touch a single technical element, you need a mental model for how they connect. The CRAWL CHAIN framework is the internal system we use to diagnose technical SEO at a site-wide level. It treats each technical layer as a link in a chain — and recognises that a weak link anywhere breaks the entire sequence.
The six links in the CRAWL CHAIN are: Crawlability, Rendering, Authority signal flow, Waste elimination, Link architecture, and Content-signal alignment. In that order, because that is the order in which they compound.
Crawlability determines whether Googlebot can access your pages at all. Rendering determines whether it can read them. Authority signal flow determines whether the pages it can read receive enough equity to compete. Waste elimination determines whether crawl budget is being spent on pages that matter. Link architecture determines how equity and context move through your site. Content-signal alignment determines whether the technical signals you have built match the topical intent your content targets.
Most checklists address each of these in isolation. The CRAWL CHAIN model treats them sequentially because fixing waste elimination before authority signal flow means you are optimising crawl budget for pages that still have no equity behind them. Order matters.
How to apply this in practice: Before your next technical audit, map your site against each CRAWL CHAIN link. Score each one from one to five. Any link scoring below three becomes your priority — because until that link is strong, the links downstream from it cannot function at full capacity. This takes about two hours for a site under 500 pages and is the most valuable diagnostic work you can do before writing a single recommendation.
The six links in the CRAWL CHAIN are: Crawlability, Rendering, Authority signal flow, Waste elimination, Link architecture, and Content-signal alignment. In that order, because that is the order in which they compound.
Crawlability determines whether Googlebot can access your pages at all. Rendering determines whether it can read them. Authority signal flow determines whether the pages it can read receive enough equity to compete. Waste elimination determines whether crawl budget is being spent on pages that matter. Link architecture determines how equity and context move through your site. Content-signal alignment determines whether the technical signals you have built match the topical intent your content targets.
Most checklists address each of these in isolation. The CRAWL CHAIN model treats them sequentially because fixing waste elimination before authority signal flow means you are optimising crawl budget for pages that still have no equity behind them. Order matters.
How to apply this in practice: Before your next technical audit, map your site against each CRAWL CHAIN link. Score each one from one to five. Any link scoring below three becomes your priority — because until that link is strong, the links downstream from it cannot function at full capacity. This takes about two hours for a site under 500 pages and is the most valuable diagnostic work you can do before writing a single recommendation.
CRAWL CHAIN links: Crawlability → Rendering → Authority flow → Waste elimination → Link architecture → Content-signal alignment
Fix links in order — downstream optimisation is wasted effort if upstream links are broken
Score each link 1-5 before writing any recommendations; anything below 3 is a priority
This framework applies to sites of any size, from 50-page service sites to 500,000-page e-commerce builds
The framework also works as a communication tool — it helps non-technical stakeholders understand why you are doing what you are doing
Revisit the CRAWL CHAIN score quarterly, not just after initial implementation
2Crawlability and Indexation: The Unglamorous Foundation Everything Else Depends On
Crawlability is the entry point. If Googlebot cannot access a page, nothing else you do for that page matters. And yet, crawlability issues are often invisible to the humans managing a site — because the pages still load perfectly fine in a browser.
Start with your robots.txt file. Verify it is not accidentally blocking critical paths. This sounds obvious, but a misplaced disallow rule on a JavaScript asset, a CSS file, or a canonical parameter can prevent pages from rendering correctly — causing Google to index a stripped, unstyled version of your content and miss key signals.
Next, audit your XML sitemap. Your sitemap should only contain pages you actively want indexed: canonical, indexable, returning a 200 status code. Every non-canonical URL in your sitemap sends a conflicting signal. Every redirect in your sitemap wastes a crawl slot. Every 404 in your sitemap erodes trust in the sitemap as a navigation tool. Run a sitemap audit using any major crawl tool and filter for status codes other than 200 — then remove or update every offending URL.
Indexation control via meta robots tags deserves careful management. The noindex directive is a powerful tool, but it requires maintenance. Over time, sites accumulate noindexed pages that were meant to be temporary — staging parameters, old campaign landing pages, faceted navigation variants — and these quietly drain crawl budget without appearing in your index report.
A tactic most guides skip: pull your Google Search Console coverage report and examine the 'Crawled but not indexed' category in depth. Google will often annotate the reason. 'Duplicate without user-selected canonical' and 'Alternate page with proper canonical tag' are both worth investigating — the first suggests canonical confusion, the second suggests you may have a signal dilution problem where equity is being split across URL variants.
The Crawl Drain Audit: This is a specific diagnostic process we run on every new site engagement. Export your full crawl log data from server logs (not just crawl tool estimates) and segment Googlebot visits by URL type: indexable target pages, redirect chains, parameterised URLs, and error pages. Calculate the percentage of crawl budget being consumed by each category. In our experience, most established sites waste a meaningful portion of their crawl budget on non-canonical and error-state URLs — budget that should be directed to their highest-value content.
Start with your robots.txt file. Verify it is not accidentally blocking critical paths. This sounds obvious, but a misplaced disallow rule on a JavaScript asset, a CSS file, or a canonical parameter can prevent pages from rendering correctly — causing Google to index a stripped, unstyled version of your content and miss key signals.
Next, audit your XML sitemap. Your sitemap should only contain pages you actively want indexed: canonical, indexable, returning a 200 status code. Every non-canonical URL in your sitemap sends a conflicting signal. Every redirect in your sitemap wastes a crawl slot. Every 404 in your sitemap erodes trust in the sitemap as a navigation tool. Run a sitemap audit using any major crawl tool and filter for status codes other than 200 — then remove or update every offending URL.
Indexation control via meta robots tags deserves careful management. The noindex directive is a powerful tool, but it requires maintenance. Over time, sites accumulate noindexed pages that were meant to be temporary — staging parameters, old campaign landing pages, faceted navigation variants — and these quietly drain crawl budget without appearing in your index report.
A tactic most guides skip: pull your Google Search Console coverage report and examine the 'Crawled but not indexed' category in depth. Google will often annotate the reason. 'Duplicate without user-selected canonical' and 'Alternate page with proper canonical tag' are both worth investigating — the first suggests canonical confusion, the second suggests you may have a signal dilution problem where equity is being split across URL variants.
The Crawl Drain Audit: This is a specific diagnostic process we run on every new site engagement. Export your full crawl log data from server logs (not just crawl tool estimates) and segment Googlebot visits by URL type: indexable target pages, redirect chains, parameterised URLs, and error pages. Calculate the percentage of crawl budget being consumed by each category. In our experience, most established sites waste a meaningful portion of their crawl budget on non-canonical and error-state URLs — budget that should be directed to their highest-value content.
Audit robots.txt for accidental blocks on JavaScript, CSS, and canonicalised parameters
Sitemap should only include 200-status, canonical, indexable URLs — audit and clean quarterly
Review 'Crawled but not indexed' in Search Console and investigate every annotation Google provides
Log file analysis (real server logs) reveals crawl budget waste that tool-based crawls cannot show you
Run the Crawl Drain Audit: segment Googlebot visits by URL type and identify waste categories
Maintain a 'noindex register' — a living document tracking every intentionally noindexed URL and the reason why
3Rendering and JavaScript SEO: The Hidden Indexation Killer
Rendering is where technical SEO gets genuinely complicated, and where most non-specialist practitioners lose confidence. The core issue: modern websites frequently rely on JavaScript to render content, navigation, and internal links. Google can execute JavaScript, but it does so in a deferred, resource-constrained second wave of indexing — which means content that depends on JavaScript to appear may be invisible to Google for days, weeks, or sometimes indefinitely.
The first diagnostic step is to fetch your most important pages using Google Search Console's URL Inspection tool and compare the rendered HTML with the source HTML. If key content — headings, body copy, internal links, structured data — appears in the rendered version but not the source, you have a JavaScript dependency that could be causing indexation lag.
Server-side rendering (SSR) or static site generation (SSG) resolves this most cleanly: your server delivers fully rendered HTML that Google can parse immediately without executing JavaScript. If a full rendering architecture change is off the table, dynamic rendering — serving a pre-rendered HTML version to bots while serving the JavaScript-driven version to users — is a practical middle-ground solution.
But here is the nuance that most guides skip: JavaScript execution also affects internal link discovery. If your navigation, related content modules, or pagination controls are rendered via JavaScript, Google may not discover and follow those links in its first crawl pass — meaning link equity does not flow through them as efficiently as it would through static HTML links. For large sites, this can mean entire content clusters being under-linked from Google's perspective, even when the user experience looks fully connected.
Audit your internal links specifically for JavaScript dependency: are any of your primary navigation links, breadcrumb links, or content hub links only available after JavaScript executes? If so, prioritise migrating those to static HTML. The link equity impact alone justifies the development effort.
Core Web Vitals connect back to rendering here. Largest Contentful Paint (LCP) is directly affected by render-blocking resources — JavaScript and CSS that delay the browser's ability to paint the main content. Interaction to Next Paint (INP) measures responsiveness to user interactions and is heavily influenced by JavaScript execution overhead. Cumulative Layout Shift (CLS) is often caused by late-loading elements (ads, fonts, dynamic content) that push existing content around after initial render.
The first diagnostic step is to fetch your most important pages using Google Search Console's URL Inspection tool and compare the rendered HTML with the source HTML. If key content — headings, body copy, internal links, structured data — appears in the rendered version but not the source, you have a JavaScript dependency that could be causing indexation lag.
Server-side rendering (SSR) or static site generation (SSG) resolves this most cleanly: your server delivers fully rendered HTML that Google can parse immediately without executing JavaScript. If a full rendering architecture change is off the table, dynamic rendering — serving a pre-rendered HTML version to bots while serving the JavaScript-driven version to users — is a practical middle-ground solution.
But here is the nuance that most guides skip: JavaScript execution also affects internal link discovery. If your navigation, related content modules, or pagination controls are rendered via JavaScript, Google may not discover and follow those links in its first crawl pass — meaning link equity does not flow through them as efficiently as it would through static HTML links. For large sites, this can mean entire content clusters being under-linked from Google's perspective, even when the user experience looks fully connected.
Audit your internal links specifically for JavaScript dependency: are any of your primary navigation links, breadcrumb links, or content hub links only available after JavaScript executes? If so, prioritise migrating those to static HTML. The link equity impact alone justifies the development effort.
Core Web Vitals connect back to rendering here. Largest Contentful Paint (LCP) is directly affected by render-blocking resources — JavaScript and CSS that delay the browser's ability to paint the main content. Interaction to Next Paint (INP) measures responsiveness to user interactions and is heavily influenced by JavaScript execution overhead. Cumulative Layout Shift (CLS) is often caused by late-loading elements (ads, fonts, dynamic content) that push existing content around after initial render.
Use URL Inspection in Search Console to compare source HTML vs rendered HTML for key pages
JavaScript-dependent content faces indexation delays — server-side rendering is the cleanest fix
Internal links rendered via JavaScript may not be discovered in first-pass crawls, affecting equity flow
Core Web Vitals (LCP, INP, CLS) are all affected by rendering decisions — treat them as rendering metrics, not just UX metrics
Dynamic rendering is a practical interim solution when full SSR/SSG is not immediately feasible
Audit navigation, breadcrumbs, and content hub links specifically for JavaScript dependency
4Canonical Tags and Duplicate Content: The Signal Dilution Problem Nobody Talks About
Canonical tags are the most widely misunderstood technical SEO element we encounter. Most practitioners know that canonicals tell Google which version of a page is the 'preferred' version. What most guides fail to explain is that Google treats canonical directives as signals, not commands — and conflicting signals cause Google to make its own choice, which may not be the choice you intended.
Canonical confusion happens in several common patterns. The first: a page has a self-referencing canonical, but is also included in a sitemap under a different URL variant (with or without trailing slash, with or without www). The sitemap URL and the canonical URL conflict, and Google must choose one to honour.
The second: a page is canonicalised to a second page, but that second page is itself canonicalised to a third — creating a canonical chain. Google typically resolves canonical chains, but each hop introduces uncertainty. The third: faceted navigation or filter parameters generate unique URLs that self-canonicalise when they should canonicalise to the base category page — causing hundreds or thousands of thin URL variants to compete with your primary category.
The protocol for a canonical audit: crawl your full site and export every canonical tag. Cross-reference against your sitemap URLs. Identify mismatches, chains, and self-referencing canonicals on pages you actually want consolidated. Then cross-reference against your Search Console index coverage to find any 'Alternate page with proper canonical tag' URLs — these are pages where Google has acknowledged your canonical but chosen not to follow it, which often signals that the canonical relationship is not supported by the internal link structure or that the canonicalised-from page has more perceived authority than the destination.
That last point is the non-obvious insight: if the page you are canonicalising away has more inbound links than the page you are canonicalising to, Google may override your canonical. Canonical implementation must be paired with link equity consolidation — ensure your preferred URL is the one that receives the majority of internal links.
Canonical confusion happens in several common patterns. The first: a page has a self-referencing canonical, but is also included in a sitemap under a different URL variant (with or without trailing slash, with or without www). The sitemap URL and the canonical URL conflict, and Google must choose one to honour.
The second: a page is canonicalised to a second page, but that second page is itself canonicalised to a third — creating a canonical chain. Google typically resolves canonical chains, but each hop introduces uncertainty. The third: faceted navigation or filter parameters generate unique URLs that self-canonicalise when they should canonicalise to the base category page — causing hundreds or thousands of thin URL variants to compete with your primary category.
The protocol for a canonical audit: crawl your full site and export every canonical tag. Cross-reference against your sitemap URLs. Identify mismatches, chains, and self-referencing canonicals on pages you actually want consolidated. Then cross-reference against your Search Console index coverage to find any 'Alternate page with proper canonical tag' URLs — these are pages where Google has acknowledged your canonical but chosen not to follow it, which often signals that the canonical relationship is not supported by the internal link structure or that the canonicalised-from page has more perceived authority than the destination.
That last point is the non-obvious insight: if the page you are canonicalising away has more inbound links than the page you are canonicalising to, Google may override your canonical. Canonical implementation must be paired with link equity consolidation — ensure your preferred URL is the one that receives the majority of internal links.
Google treats canonicals as signals, not commands — conflicting signals cause Google to override your preference
Canonical chains (A→B→C) introduce uncertainty; resolve all chains to direct canonical relationships
Faceted navigation requires careful canonical strategy to prevent thin URL proliferation
Canonical audit: crawl all canonical tags, cross-reference sitemap URLs, identify every mismatch
If 'Alternate page with proper canonical tag' appears in GSC, check whether the canonicalised-from page has more link equity than the destination
Internal link structure must support your canonical choices — preferred URLs should receive more internal links
5Structured Data: Not Optional in an AI-First Search Landscape
Structured data has gone from a nice-to-have to a critical ranking and visibility signal in an era of AI-generated search overviews and rich result features. When search surfaces present answers rather than links, structured data is the mechanism by which your content gets interpreted, attributed, and featured.
Start with the foundational schema types for your site category: Article or BlogPosting for content sites, Product for e-commerce, LocalBusiness for service-area businesses, FAQPage for content with explicit question-and-answer structure, and HowTo for instructional content. These are not decorative additions — they are the vocabulary Google uses to understand what type of entity your page represents and what information it should extract.
Beyond the basics, implement BreadcrumbList schema on every page that has a logical breadcrumb structure. This reinforces your site architecture signal and increases the likelihood of breadcrumb display in search results, which improves click-through by clarifying page context at a glance.
For knowledge-panel and EEAT purposes, implement Organisation schema on your homepage with your official name, logo, sameAs links to verified social profiles, and contactPoint data. If you have authors publishing content, implement Person schema for each author with their credentials and professional profile links. These signals feed directly into Google's entity understanding — which is foundational to EEAT (Experience, Expertise, Authoritativeness, Trustworthiness) assessment.
A non-obvious structured data tactic: implement SpeakableSpecification markup on your most authoritative summary paragraphs. Originally designed for voice search, this schema type now signals to AI summary systems that these specific passages are the authoritative, quotable version of your content — increasing the likelihood of attribution in AI-generated overviews.
Validate all structured data using Google's AI-driven search features like SGE and rich results Test and Schema Markup Validator. More importantly, monitor your Search Console Enhancements report monthly — schema errors and warnings here directly affect your eligibility for rich results.
Start with the foundational schema types for your site category: Article or BlogPosting for content sites, Product for e-commerce, LocalBusiness for service-area businesses, FAQPage for content with explicit question-and-answer structure, and HowTo for instructional content. These are not decorative additions — they are the vocabulary Google uses to understand what type of entity your page represents and what information it should extract.
Beyond the basics, implement BreadcrumbList schema on every page that has a logical breadcrumb structure. This reinforces your site architecture signal and increases the likelihood of breadcrumb display in search results, which improves click-through by clarifying page context at a glance.
For knowledge-panel and EEAT purposes, implement Organisation schema on your homepage with your official name, logo, sameAs links to verified social profiles, and contactPoint data. If you have authors publishing content, implement Person schema for each author with their credentials and professional profile links. These signals feed directly into Google's entity understanding — which is foundational to EEAT (Experience, Expertise, Authoritativeness, Trustworthiness) assessment.
A non-obvious structured data tactic: implement SpeakableSpecification markup on your most authoritative summary paragraphs. Originally designed for voice search, this schema type now signals to AI summary systems that these specific passages are the authoritative, quotable version of your content — increasing the likelihood of attribution in AI-generated overviews.
Validate all structured data using Google's AI-driven search features like SGE and rich results Test and Schema Markup Validator. More importantly, monitor your Search Console Enhancements report monthly — schema errors and warnings here directly affect your eligibility for rich results.
Structured data is how AI-first search features identify, attribute, and cite your content
Implement entity-appropriate schema: Article, Product, LocalBusiness, FAQPage, HowTo as relevant
BreadcrumbList schema reinforces site architecture and improves click-through rate in results
Organisation and Person schema feed EEAT signals — implement these for every publishing entity
SpeakableSpecification markup signals to AI systems which passages are the authoritative, quotable version
Monitor Search Console Enhancements report monthly for schema errors that revoke rich result eligibility
6Internal Linking as Infrastructure: The Signal Stack Method
Internal linking is consistently categorised as a content strategy concern. It is not. It is technical infrastructure — the system through which authority, context, and crawl priority flow through your site. Treating it as content strategy means it gets managed inconsistently by whoever publishes content that week. Treating it as infrastructure means it gets designed, audited, and maintained like your URL structure or your sitemap.
The Signal Stack method is the framework we use to design internal link architecture. The principle: every page in your site belongs to one of three tiers based on its commercial or strategic value. Tier 1 pages are your highest-value targets — your primary service pages, pillar content, or top-category pages.
Tier 2 pages are supporting content that reinforces Tier 1 topical authority — subtopic articles, comparison pages, supporting guides. Tier 3 pages are peripheral content — blog posts, news items, supplementary resources — that earns links and generates long-tail traffic but is not itself a primary ranking target.
The Signal Stack rule: Tier 3 pages must link to Tier 2 pages. Tier 2 pages must link to Tier 1 pages. Tier 1 pages link to each other only when the relationship is genuinely contextual. This creates a directional flow of authority from content that earns links (Tier 3) through topical authority builders (Tier 2) to the pages you most need to rank (Tier 1).
Audit your current internal link structure by pulling a crawl report that includes inbound internal link counts for every page. Sort by Tier 1 pages first. If any Tier 1 page has fewer inbound internal links than your Tier 3 content, you have an inverted signal stack — and it is almost certainly suppressing your most important page rankings.
Orphan pages — pages with zero internal inbound links — are a crawl and authority issue. Google discovers them only through sitemaps or external links, meaning they receive no equity through your internal architecture. Every orphan page is either dead weight or a missed opportunity, depending on whether it has inherent value.
The Signal Stack method is the framework we use to design internal link architecture. The principle: every page in your site belongs to one of three tiers based on its commercial or strategic value. Tier 1 pages are your highest-value targets — your primary service pages, pillar content, or top-category pages.
Tier 2 pages are supporting content that reinforces Tier 1 topical authority — subtopic articles, comparison pages, supporting guides. Tier 3 pages are peripheral content — blog posts, news items, supplementary resources — that earns links and generates long-tail traffic but is not itself a primary ranking target.
The Signal Stack rule: Tier 3 pages must link to Tier 2 pages. Tier 2 pages must link to Tier 1 pages. Tier 1 pages link to each other only when the relationship is genuinely contextual. This creates a directional flow of authority from content that earns links (Tier 3) through topical authority builders (Tier 2) to the pages you most need to rank (Tier 1).
Audit your current internal link structure by pulling a crawl report that includes inbound internal link counts for every page. Sort by Tier 1 pages first. If any Tier 1 page has fewer inbound internal links than your Tier 3 content, you have an inverted signal stack — and it is almost certainly suppressing your most important page rankings.
Orphan pages — pages with zero internal inbound links — are a crawl and authority issue. Google discovers them only through sitemaps or external links, meaning they receive no equity through your internal architecture. Every orphan page is either dead weight or a missed opportunity, depending on whether it has inherent value.
Internal linking is technical infrastructure, not content strategy — design and audit it systematically
Signal Stack tiers: Tier 1 (primary targets) ← Tier 2 (topical support) ← Tier 3 (peripheral content)
Audit inbound internal link counts for all pages; Tier 1 pages should always have the most
An inverted signal stack (Tier 3 pages receiving more internal links than Tier 1) suppresses priority page rankings
Orphan pages receive no equity from internal architecture — either integrate or deprecate them
Anchor text in internal links carries significant contextual signal — use descriptive, keyword-relevant anchor text
7Core Web Vitals and Site Speed: Performance as a Business Decision
Site speed and Core Web Vitals are often presented as a ranking factor story. They are also a revenue story — and framing them as a revenue story is often what gets performance work prioritised and funded by stakeholders who are unmoved by ranking discussions.
The business case is straightforward: pages that load slowly lose users before they convert. In a high-intent search context — someone actively looking for your product or service — a slow page does not just cost you a conversion. It costs you a visitor who was already motivated to engage. The ranking signal is secondary to the user behaviour impact.
For Core Web Vitals specifically, focus on the three current metrics in order of typical impact:
Largest Contentful Paint (LCP) should be under 2.5 seconds. The most common causes of poor LCP are unoptimised hero images, render-blocking JavaScript, slow server response times (TTFB), and missing resource hints. Fix in that order. For images: serve WebP or AVIF formats, use explicit width and height attributes to prevent layout shifts, and implement lazy loading below the fold — but critically, do not lazy load your hero image. Preload it instead.
Interaction to Next Paint (INP) replaced First Input Delay as the interactivity metric and is significantly harder to optimise. INP measures the full input delay, processing time, and presentation delay of user interactions. Long JavaScript tasks are the primary culprit. Audit your JavaScript execution with browser DevTools Performance panel and identify any tasks exceeding 50ms — these are blocking interaction responsiveness.
Cumulative Layout Shift (CLS) should be under 0.1. The most common causes are images or embeds without declared dimensions, dynamically injected content, and web fonts causing text reflow. Solving CLS is often the quickest performance win available — declare dimensions on all images and media embeds, and use font-display: swap with a font size fallback to minimise layout shift from font loading.
Measure using real-world data from Search Console's Core Web Vitals report (which reflects the Chrome User Experience Report, or CrUX) rather than lab tools alone. Lab tools measure ideal conditions; CrUX measures what real users on real devices and connections actually experience.
The business case is straightforward: pages that load slowly lose users before they convert. In a high-intent search context — someone actively looking for your product or service — a slow page does not just cost you a conversion. It costs you a visitor who was already motivated to engage. The ranking signal is secondary to the user behaviour impact.
For Core Web Vitals specifically, focus on the three current metrics in order of typical impact:
Largest Contentful Paint (LCP) should be under 2.5 seconds. The most common causes of poor LCP are unoptimised hero images, render-blocking JavaScript, slow server response times (TTFB), and missing resource hints. Fix in that order. For images: serve WebP or AVIF formats, use explicit width and height attributes to prevent layout shifts, and implement lazy loading below the fold — but critically, do not lazy load your hero image. Preload it instead.
Interaction to Next Paint (INP) replaced First Input Delay as the interactivity metric and is significantly harder to optimise. INP measures the full input delay, processing time, and presentation delay of user interactions. Long JavaScript tasks are the primary culprit. Audit your JavaScript execution with browser DevTools Performance panel and identify any tasks exceeding 50ms — these are blocking interaction responsiveness.
Cumulative Layout Shift (CLS) should be under 0.1. The most common causes are images or embeds without declared dimensions, dynamically injected content, and web fonts causing text reflow. Solving CLS is often the quickest performance win available — declare dimensions on all images and media embeds, and use font-display: swap with a font size fallback to minimise layout shift from font loading.
Measure using real-world data from Search Console's Core Web Vitals report (which reflects the Chrome User Experience Report, or CrUX) rather than lab tools alone. Lab tools measure ideal conditions; CrUX measures what real users on real devices and connections actually experience.
Frame Core Web Vitals as a revenue issue, not just a ranking issue — slow pages lose motivated buyers
LCP target: under 2.5 seconds; prioritise hero image optimisation, TTFB, and render-blocking resources
INP replaced FID — audit long JavaScript tasks using DevTools Performance panel
CLS target: under 0.1; declare explicit dimensions on all images and media, use font-display: swap
Use Search Console CrUX data, not just lab tools — real-world performance is what Google measures
Do not lazy load your hero image — preload it to improve LCP
8Site Migrations: The Technical SEO Event That Can Erase Years of Authority
Site migrations — domain changes, HTTP to HTTPS transitions, URL restructures, CMS platforms switches, or any combination — are the highest-risk technical SEO events most sites will ever face. Done correctly, they are invisible to rankings. Done incorrectly, they can erase years of accumulated authority in weeks.
The migration checklist works differently from standard ongoing technical SEO — it is a time-bounded, sequenced process where errors compound if not caught at the right moment.
Pre-migration: Crawl your current site completely and export a full URL inventory. Document every URL, its canonical, its inbound internal links, and its external link count (from your link data tools). This is your baseline. Without it, you cannot verify post-migration integrity. Also document your current Search Console performance metrics by page — you will need this to identify post-migration drops quickly.
Redirect mapping: Every URL that will change requires a 301 redirect from its old location to its new location. Redirect chains must be resolved — if old URL A redirected to old URL B, and B becomes new URL C, the redirect should go A→C directly, not A→B→C. Build your redirect map in a spreadsheet, QA it before launch, and implement it as a batch — do not rely on redirect plugins to handle migration-scale volumes reliably.
Post-migration: Re-crawl the entire site within 48 hours of launch. Compare the new crawl against your pre-migration inventory and flag every URL where the response code, canonical, or title tag has changed unexpectedly. Verify that all intended redirects are returning 301 (not 302) and are resolving to the correct destination. Update your XML sitemap to reflect the new URL structure and resubmit to Search Console. Request re-indexing of your priority pages via URL Inspection.
Monitor Search Console daily for the first four weeks post-migration. Look for spikes in 404 errors, drops in indexed page count, and ranking changes by page cluster. A well-executed migration may show a temporary dip in impressions lasting two to four weeks as Google recrawls and reprocesses — this is normal. A sustained drop beyond six weeks signals a migration error that needs investigation.
The migration checklist works differently from standard ongoing technical SEO — it is a time-bounded, sequenced process where errors compound if not caught at the right moment.
Pre-migration: Crawl your current site completely and export a full URL inventory. Document every URL, its canonical, its inbound internal links, and its external link count (from your link data tools). This is your baseline. Without it, you cannot verify post-migration integrity. Also document your current Search Console performance metrics by page — you will need this to identify post-migration drops quickly.
Redirect mapping: Every URL that will change requires a 301 redirect from its old location to its new location. Redirect chains must be resolved — if old URL A redirected to old URL B, and B becomes new URL C, the redirect should go A→C directly, not A→B→C. Build your redirect map in a spreadsheet, QA it before launch, and implement it as a batch — do not rely on redirect plugins to handle migration-scale volumes reliably.
Post-migration: Re-crawl the entire site within 48 hours of launch. Compare the new crawl against your pre-migration inventory and flag every URL where the response code, canonical, or title tag has changed unexpectedly. Verify that all intended redirects are returning 301 (not 302) and are resolving to the correct destination. Update your XML sitemap to reflect the new URL structure and resubmit to Search Console. Request re-indexing of your priority pages via URL Inspection.
Monitor Search Console daily for the first four weeks post-migration. Look for spikes in 404 errors, drops in indexed page count, and ranking changes by page cluster. A well-executed migration may show a temporary dip in impressions lasting two to four weeks as Google recrawls and reprocesses — this is normal. A sustained drop beyond six weeks signals a migration error that needs investigation.
Pre-migration URL inventory is non-negotiable — without it you cannot verify post-migration integrity
Redirect chains from previous migrations must be resolved in the new redirect map
Implement all redirects as 301 (permanent) not 302 (temporary) — 302 redirects do not pass full equity
Re-crawl within 48 hours of launch and compare against pre-migration baseline
Monitor Search Console daily for four weeks post-launch — early error detection prevents compounding loss
A two-to-four week impression dip is normal; sustained drops beyond six weeks indicate unresolved migration errors