Use this evidence-backed 2026 SEO checklist to review 111 controls across technical SEO, content, search appearance, performance, international SEO, ecommerce, and measurement. Open any item to see what to check, how to check it, why it matters, and the primary reference. Priority 5 is critical. Priority 1 is optional.

Has the complete URL inventory been reconciled across a site crawl, XML sitemaps, server logs, analytics landing pages, and Search Console?

What: Build one inventory that exposes discovered, indexed, visited, orphaned, and stale URLs.
How: Join normalized canonical URLs from each source and investigate gaps by template and status.
Why: No single tool sees every URL, so reconciliation reveals discovery and indexation blind spots.
Reference: Google Page Indexing report

Is every business-critical canonical URL indexed or intentionally excluded for a documented reason?

What: Confirm that priority pages are eligible for indexing and that every exclusion is expected.
How: Review Page Indexing groups and inspect representative indexed and excluded URLs.
Why: An intentional inventory distinguishes technical defects from valid exclusions.
Reference: Google URL Inspection

Can every important page be discovered through at least one crawlable HTML link?

What: Important pages need a resolvable anchor link from another discoverable page.
How: Crawl the site, compare the result with the URL inventory, and inspect orphan candidates manually.
Why: Sitemaps can assist discovery, but they do not replace a connected site structure.
Reference: Google crawlable links guidance

Do indexable pages meet Google's basic technical eligibility requirements?

What: A page must be accessible to Googlebot, return a successful response, and contain indexable content.
How: Test representative templates with URL Inspection and verify status, robots controls, and rendered content.
Why: Ranking improvements cannot compensate for a page that is technically ineligible for Search.
Reference: Google Search technical requirements

Are only useful canonical pages intended for indexing?

What: Search, filter, print, session, empty, duplicate, and low-value URL families need an explicit indexation decision.
How: Classify each URL pattern as index, consolidate, noindex, block crawl, authenticate, or remove.
Why: Intentional indexation protects quality signals and prevents uncontrolled URL growth.
Reference: Google Search spam policies

Are staging, preview, and mirror environments protected from public indexing?

What: Non-production copies should normally require authentication rather than rely on robots.txt.
How: Test anonymous access. If noindex is used temporarily, ensure crawlers can fetch and see it.
Why: Public copies can leak unfinished content and create competing duplicate URLs.
Reference: Google block indexing guidance

Are site search operators used only as samples rather than as an index count or ranking test?

What: The site operator is useful for spot checks but is not exhaustive and is not normally ranked.
How: Use Page Indexing and URL Inspection for diagnosis, then use site queries only to sample visible results.
Why: Treating an approximate operator as a database produces false indexation conclusions.
Reference: Google site search operator

Is crawl-budget work limited to sites whose scale, change rate, or discovered URL waste justifies it?

What: Crawl budget is usually a concern for large sites or sites that change rapidly. It is not a universal optimization project.
How: Review verified server logs, Crawl Stats, host capacity, and low-value URL spaces before prioritizing it.
Why: Smaller sites usually gain more from fixing discovery, quality, and response problems.
Reference: Google crawl budget guide

Is each hostname's robots.txt reachable, valid, correctly scoped, and served as UTF-8 text?

What: Every crawlable host needs a predictable robots file at the root path.
How: Fetch the file without redirects or authentication and validate groups, paths, wildcards, and encoding.
Why: A malformed or unavailable policy can unintentionally change crawling across the host.
Reference: Google robots.txt specification

Have robots.txt allow and disallow rules been tested for unintended blocks?

What: Production HTML, CSS, JavaScript, APIs, images, and locale paths needed for rendering must remain crawlable.
How: Test representative URLs against the relevant user-agent group and inspect blocked resources in URL Inspection.
Why: Blocking required resources prevents Google from understanding the page as users receive it.
Reference: Google robots.txt introduction

Is robots.txt used only to control crawling rather than as the sole index-removal method?

What: A disallowed URL can still appear in search if Google discovers it elsewhere.
How: Use crawl-visible noindex, authentication, removal, or an appropriate status code for index control.
Why: Crawl blocking can hide the very directive Google needs to remove a URL.
Reference: Google robots.txt limitations

Are noindex and X-Robots-Tag directives intentional, consistent, and visible to crawlers?

What: HTML and non-HTML exclusions need the correct directive without contradictory headers or robots blocks.
How: Inspect raw responses and rendered HTML for representative URLs, including PDFs and generated pages.
Why: Conflicting or unreachable directives create persistent and hard-to-debug index states.
Reference: Google robots meta and X-Robots-Tag

Are XML sitemaps used where they materially improve discovery?

What: Sitemaps are most useful for large, new, media-heavy, or weakly linked sites.
How: Decide by site shape, then generate sitemaps from canonical production records rather than a blind crawl.
Why: A sitemap is a discovery hint. It does not guarantee indexing or replace internal links.
Reference: Google sitemap overview

Do sitemaps contain only absolute, canonical, indexable URLs with the intended successful response?

What: Exclude redirects, errors, duplicates, blocked pages, and noindex URLs from canonical sitemaps.
How: Crawl every submitted sitemap URL and compare response, robots, canonical, and locale signals.
Why: Clean sitemaps give search engines and monitoring tools an unambiguous preferred inventory.
Reference: Google build and submit a sitemap

Does every sitemap stay within 50,000 URLs and 50 MB uncompressed?

What: Oversized files must be split and referenced through one or more sitemap indexes.
How: Validate URL counts and uncompressed bytes in the generated artifact before publication.
Why: Files beyond protocol limits may not be processed completely.
Reference: Sitemaps protocol

Are sitemap discovery, lastmod values, extensions, and processing reports maintained correctly?

What: Declare or submit sitemap locations, use accurate significant lastmod dates, and add media extensions only when relevant.
How: Monitor Search Console errors. Remove retired pinging and do not rely on ignored priority or changefreq fields.
Why: Accurate signals support recrawling, while stale metadata and obsolete submission methods create noise.
Reference: Google sitemap lastmod guidance

Does each indexable HTML URL expose one valid absolute self-referencing canonical in the head?

What: The canonical should identify the preferred public URL and appear in valid head markup.
How: Compare raw and rendered HTML, and use HTTP Link canonicals where appropriate for non-HTML files.
Why: Missing, relative, multiple, or body-injected canonicals weaken consolidation signals.
Reference: Google canonicalization guidance

Do redirects, canonicals, internal links, sitemaps, and hreflang agree on the same preferred URL?

What: Every strong canonicalization signal should point to the same indexable destination.
How: Test each signal across representative duplicate clusters and localized equivalents.
Why: Consistent signals help search engines consolidate indexing and reporting predictably.
Reference: Google canonical signal best practices

Are protocol, host, case, slash, parameter, session, print, and tracking variants deliberately consolidated?

What: Every duplicate-generating URL convention needs one stable preferred form.
How: Inventory variants, select canonicals, and align redirects, links, templates, and sitemaps.
Why: Uncontrolled variants split signals and expand crawling without adding user value.
Reference: Google duplicate URL consolidation

Are canonical and robots directives stable between server HTML and rendered HTML?

What: JavaScript must not remove or replace correct server signals with conflicting values.
How: Diff raw and rendered head markup on representative routes and navigation states.
Why: Late mutations can make canonical and indexation decisions unreliable.
Reference: Google JavaScript SEO basics

Do valid pages return 200 while removed pages return 404 or 410 without soft-404 behavior?

What: Response semantics must match the visible content and actual resource state.
How: Test templates, empty results, invalid IDs, and client-rendered error routes in raw responses.
Why: A misleading 200 wastes crawling and can index empty or error experiences.
Reference: Google HTTP status code guidance

Do redirect status codes match whether a move is permanent or temporary?

What: Use 301 or 308 for permanent moves and 302, 303, or 307 only for genuinely temporary behavior.
How: Verify response codes, destination intent, and request-method handling with an HTTP client.
Why: Correct semantics guide canonicalization, caching, and safe client behavior.
Reference: Google redirects and Search

Do redirects reach the final relevant URL directly without loops or avoidable chains?

What: Each legacy or variant URL should resolve through the shortest maintainable path.
How: Crawl redirects from every known source and inspect both server and client-side hops.
Why: Chains add latency, failure points, and unnecessary crawl work.
Reference: Google redirect best practices

Are removed URLs redirected only when a genuinely equivalent replacement exists?

What: Unrelated removals should return 404 or 410 instead of being mass-redirected to the homepage.
How: Review redirect maps by user intent and test destination relevance.
Why: Irrelevant redirects confuse users and are often treated as soft 404s.
Reference: Google site move guidance

Are 429 and 5xx responses temporary, monitored, and paired with appropriate recovery behavior?

What: Capacity, maintenance, and rate-limit failures must not persist on crawl-critical URLs.
How: Alert on status trends, inspect Retry-After where suitable, and retest recovery from outside the origin.
Why: Prolonged server errors suppress crawling and can eventually remove URLs from Search.
Reference: Google HTTP and network errors

Do initial HTML and rendered HTML expose the same critical SEO content and signals?

What: Titles, directives, canonicals, primary copy, structured data, and links must survive rendering.
How: Compare raw source with URL Inspection rendered HTML across core templates.
Why: Content absent from the rendered result cannot reliably be indexed or understood.
Reference: Google JavaScript SEO basics

Is primary content available without clicks, scrolling, consent state, or local storage?

What: Crawlers should receive important copy and media without a user interaction trigger.
How: Inspect rendered output before interaction and test lazy-loaded content with crawler-compatible loading.
Why: Search crawlers do not reproduce every interaction needed by an application.
Reference: Google lazy-loading guidance

Do navigation and application routes use resolvable anchor URLs and the History API?

What: Important destinations need real anchor href values rather than fragments or script-only controls.
How: Inspect rendered anchors and navigate copied URLs in a fresh browser session.
Why: Stable URLs allow discovery, sharing, history, and independent crawling.
Reference: Google crawlable links guidance

Can Googlebot retrieve required scripts, styles, APIs, and media without authentication or runtime errors?

What: Dependencies needed to understand the page must be publicly fetchable and crawler-compatible.
How: Review URL Inspection resources, response codes, console errors, robots rules, and server logs.
Why: A successful document response can still render as incomplete or empty.
Reference: Google JavaScript troubleshooting

Do client-rendered routes expose meaningful HTTP states and recoverable rendered content?

What: SPAs must distinguish valid, redirected, removed, and error routes beyond an in-app message.
How: Request deep links directly, disable warm caches, and compare HTTP status with rendered state.
Why: Soft errors and fragile rendering make discovery and indexation unreliable.
Reference: Google JavaScript SEO status codes

Is critical HTML available within Google's first 2 MB fetched for an individual URL?

What: Metadata and content needed for indexing should precede oversized inline data or assets in the document.
How: Measure response headers plus HTML bytes and inspect what is lost after the 2 MB boundary.
Why: Bytes beyond the current fetch limit are not fetched, rendered, or indexed.
Reference: Googlebot fetch size limits

Does the mobile-rendered version preserve desktop-equivalent content and SEO signals?

What: Primary copy, links, metadata, structured data, images, video, and crawl permissions must remain equivalent.
How: Compare mobile and desktop rendered outputs across every important template.
Why: Google predominantly uses the mobile version for indexing and ranking.
Reference: Google mobile-first indexing guidance

Is responsive same-URL delivery the default, with legacy mobile configurations handled correctly?

What: Prefer responsive delivery. Retain Vary, redirects, parity, and canonical-alternate checks only for separate or dynamic mobile sites.
How: Test phones, tablets, desktops, and crawler user agents against the same content intent.
Why: Responsive URLs reduce duplication and configuration failure while legacy models remain conditionally supported.
Reference: Google mobile site configurations

Does the information architecture reflect user tasks, content relationships, and business priorities?

What: Categories and page types should form a predictable hierarchy rather than mirror internal organization.
How: Map key journeys and topics to navigation, hubs, detail pages, and URL patterns.
Why: Clear architecture helps people and crawlers understand scope and relationships.
Reference: Google SEO Starter Guide

Do crawl depth and internal-link prominence reflect page importance without proprietary scores?

What: Priority pages should be easy to reach and linked from relevant high-visibility contexts.
How: Review click depth and inlink sources by template, then compare them with business priority.
Why: Useful prominence is more meaningful than a mythical ideal link count or vendor metric.
Reference: Google site hierarchy guidance

Is primary navigation present as crawlable HTML links?

What: Menus, category paths, and footer links needed for discovery require resolvable anchor destinations.
How: Inspect server and rendered markup, including collapsed mobile navigation.
Why: Script-only navigation can leave entire sections undiscovered.
Reference: Google crawlable links guidance

Is internal anchor text descriptive, concise, and free from forced repetition?

What: Link text should explain the destination in its surrounding context.
How: Sample recurring templates and flag generic, misleading, stuffed, or empty anchors.
Why: Descriptive anchors improve navigation, accessibility, and page relationship signals.
Reference: Google link best practices

Are orphaned and weakly linked important pages detected from multiple inventories?

What: A page in analytics, a sitemap, a CMS, or the index but absent from the crawl needs investigation.
How: Compare normalized URL sets and add relevant links or retire the page deliberately.
Why: Orphans are hard to discover and often signal broken publishing workflows.
Reference: Google links and discovery

Do internal links point directly to canonical successful destinations?

What: Templates should avoid linking through redirects, errors, blocked URLs, or duplicate variants.
How: Crawl all internal outlinks and prioritize recurring template-level defects.
Why: Direct canonical links reduce latency, waste, and conflicting signals.
Reference: Google canonicalization best practices

Does every faceted, filtered, sorted, search, and parameter URL family have an indexation strategy?

What: Valuable landing states and low-value combinations need different crawl and index treatment.
How: Inventory parameter patterns, stabilize ordering, and return non-success states for impossible combinations.
Why: Unbounded combinations can create infinite crawl spaces and duplicate indexes.
Reference: Google faceted navigation guidance

Does pagination use unique URLs, self-canonicals, and sequential crawlable links?

What: Each page in a sequence must be independently reachable without fragment-only identifiers.
How: Test next-page discovery and filtered states without relying on rel next or rel prev for Google.
Why: Crawlers do not click load-more controls and Google no longer uses those link relations.
Reference: Google pagination guidance

Does every indexable page have a unique descriptive title in the page's language?

What: The title should accurately summarize the specific page without a fixed character target.
How: Audit missing, duplicate, vague, and mismatched titles by template and search appearance.
Why: Google uses multiple page signals to generate the title link users see.
Reference: Google title link guidance

Do titles avoid keyword stuffing, repeated boilerplate, obsolete dates, and excessive brand text?

What: Titles should be concise and useful rather than repeat every possible modifier.
How: Review recurring templates and compare visible titles with generated search title links.
Why: Low-quality patterns can be rewritten and reduce result clarity.
Reference: Google title link best practices

Is the main visible title clearly identifiable and aligned with the title element?

What: Users and search systems should agree on the page's primary subject.
How: Compare the title element, main heading, hero text, and prominent visual labels.
Why: Conflicting prominent headings make title generation and comprehension less predictable.
Reference: Google title link sources

Do priority pages have useful page-specific meta descriptions without fixed length rules?

What: Describe the page's value accurately for people rather than targeting 155 characters or keyword lists.
How: Audit missing, duplicated, generic, misleading, and programmatically weak descriptions.
Why: Google may use a strong description when it better explains the result for a query.
Reference: Google snippet guidance

Are search-result preview controls applied intentionally?

What: nosnippet, data-nosnippet, max-snippet, image-preview, and video-preview affect eligible previews.
How: Inspect meta and X-Robots directives where legal, paywalled, or sensitive text needs restriction.
Why: Preview controls can also affect eligibility and presentation in AI search experiences.
Reference: Google robots preview controls

Does each page serve a clearly defined audience need or task?

What: Content should help an intended visitor accomplish something meaningful.
How: State the audience and task, then test whether the page answers it without forcing another search.
Why: People-first usefulness is a more durable standard than writing primarily for ranking systems.
Reference: Google people-first content guidance

Does the content add original evidence, experience, analysis, or perspective?

What: Priority pages should contribute value beyond summaries of existing search results.
How: Identify first-hand examples, data, methods, comparisons, or expert interpretation on the page.
Why: Easily replicated content gives users and search systems little reason to prefer the page.
Reference: Google helpful content self-assessment

Is the topic covered deeply enough for the user task without an arbitrary word count?

What: Include the information needed to make a decision or complete the task, then stop.
How: Compare user questions and journey gaps instead of relying on word totals or competitor averages alone.
Why: There is no preferred Google word count and padding reduces clarity.
Reference: Google SEO Starter Guide

Are factual claims accurate, supported, and reviewed by relevant expertise?

What: High-impact claims need trustworthy evidence, context, and a responsible reviewer.
How: Check sources, dates, calculations, conflicts of interest, and expert review for sensitive topics.
Why: Users need reliable content, especially when it can affect health, money, or safety.
Reference: Google helpful and reliable content

Are authorship, contribution, and editorial responsibility clear where users expect them?

What: Pages should explain who created or reviewed the content and why they are credible.
How: Connect bylines and review notes to substantive profile and editorial-policy pages.
Why: Transparent provenance helps users assess trust and accountability.
Reference: Google Who How Why guidance

Is content readable, well structured, and genuinely maintained?

What: Use meaningful sections and headings, remove obsolete claims, and change dates only after substantive updates.
How: Review headings, language, accessibility, broken references, stale facts, and update history.
Why: Clear current content serves people better without treating heading count or freshness as ranking formulas.
Reference: Google helpful content questions

Do AI-assisted and programmatic pages provide distinct value and receive accuracy review?

What: Automation should support useful content rather than mass-produce pages for ranking manipulation.
How: Sample outputs by template, verify claims and sources, and require an accountable editorial owner.
Why: Scaled-content abuse depends on purpose and value, regardless of whether humans or AI produced it.
Reference: Google generative AI content guidance

Is the site free from scraped, spun, stitched, and low-value auto-translated pages?

What: Republishing or transforming other sources must add substantial original usefulness.
How: Compare sampled pages with source material and review translation quality and local relevance.
Why: Publishing low-value copies across many pages can violate spam policies and erode user trust.
Reference: Google spam policies

Are doorway pages, keyword blocks, expired-domain abuse, and site-reputation abuse prevented?

What: Pages and third-party sections need a genuine audience purpose beyond exploiting ranking signals.
How: Review templated location/query pages, hosted partner content, acquired domains, and unnatural repetition.
Why: Manipulative patterns can trigger algorithmic demotion or manual action.
Reference: Google web spam policies

Are pages intended for Google's AI features indexed and eligible for snippets?

What: AI Overviews and AI Mode use the same foundational Search eligibility rather than a special submission path.
How: Verify indexation, preview controls, rendered content, internal links, and ordinary Search quality.
Why: Accidental noindex or snippet restrictions can also prevent AI-feature presentation.
Reference: Google AI features and website guidance

Has the team rejected unsupported AI-only SEO requirements?

What: Google does not require llms.txt, special AI schema, forced chunking, or a special page length.
How: Remove these as pass-fail gates and invest in crawlability, usefulness, media, and structured data instead.
Why: Unsupported files and formulas create work without improving Google eligibility.
Reference: Google AI optimization guide

Does content avoid creating a separate page for every query or query-fan-out variation?

What: One strong resource should cover coherent user needs instead of manufacturing near-duplicate permutations.
How: Cluster overlapping pages, inspect generated inventories, and consolidate thin variants.
Why: Query-scale page production often creates low-value duplication and weak user journeys.
Reference: Google AI optimization guide

Is AI-search visibility measured with the limits of the available reports documented?

What: Use Search Console Web performance and the dedicated Generative AI report only where that limited report is available.
How: Record report scope, impression-only fields, rollout status, and release annotations before interpreting changes.
Why: Incomplete reporting should not be mistaken for complete AI referral measurement.
Reference: Search Console Generative AI report

Does each structured-data type map to a currently supported Google Search feature?

What: Use the live Search Gallery rather than an inherited list of old rich-result types.
How: Match each implementation to its current feature guide and eligibility requirements.
Why: Unsupported or retired display types add maintenance without Search appearance value.
Reference: Google Search Gallery

Are required structured-data properties complete and consistent with visible page content?

What: Markup must be relevant, current, original, and represented to users on the page.
How: Compare required and recommended properties with rendered content and source records.
Why: Hidden, misleading, or stale markup can lose eligibility or violate policies.
Reference: Google structured data policies

Is structured data valid in raw and rendered output?

What: Syntax, nesting, identifiers, URLs, and generated values must survive the production render.
How: Use the Rich Results Test before release and URL Inspection after publication.
Why: Build-time validity does not prove the crawler receives the same markup in production.
Reference: Google structured data introduction

Is structured data treated as eligibility rather than a display guarantee?

What: Valid markup qualifies a page for consideration but does not approve or guarantee a rich result.
How: Set stakeholder expectations and monitor Search Console enhancements and manual actions.
Why: Search appearance varies by query, device, country, quality, and system decisions.
Reference: Google structured data policies

Is review markup limited to supported types and genuine visible ratings?

What: Exclude self-serving Organization or LocalBusiness ratings controlled by the reviewed business.
How: Trace every aggregate and review to visible first-party content and the supported parent type.
Why: Invalid or self-serving review markup is ineligible for the star review feature.
Reference: Google review snippet guidance

Do Organization and WebSite signals consistently identify the site and brand?

What: Name, URL, logo, contact details, and authoritative profiles should agree across visible and structured sources.
How: Audit homepage Organization and WebSite data alongside canonical brand pages and profiles.
Why: Consistent identity helps Search understand and present the organization and site name.
Reference: Google Organization structured data

Do breadcrumb markup and visible navigation describe the same hierarchy?

What: BreadcrumbList positions and URLs should represent a useful user-facing path.
How: Compare rendered breadcrumbs, canonical URLs, and structured items across nested templates.
Why: Accurate breadcrumbs can clarify page context in Search and on the site.
Reference: Google breadcrumb structured data

Is the favicon crawlable, stable, square, and representative of the brand?

What: The homepage should declare one supported favicon that remains available to Google.
How: Verify the link element, URL stability, image format, square dimensions, and a size above 48 pixels where practical.
Why: A clear favicon improves recognition in eligible search results.
Reference: Google favicon guidance

Are important images exposed through crawlable img or picture markup?

What: Search-relevant images should not exist only as CSS backgrounds or interaction-created assets.
How: Inspect rendered HTML and confirm that Google can fetch the image URLs.
Why: Google Images discovers supported HTML image elements but does not index CSS images.
Reference: Google Images best practices

Do images have context-appropriate text alternatives?

What: Informative images need meaningful alt text, decorative images need empty alt text, and linked images should describe the destination.
How: Review purpose in context rather than requiring a keyword-filled alt value on every image.
Why: Correct alternatives support accessibility and help systems understand image content and function.
Reference: W3C image alt decision tree

Are key images high quality, responsive, and efficiently delivered?

What: Provide dimensions, responsive candidates, suitable formats, compression, and intentional loading behavior.
How: Audit rendered size, transfer cost, device variants, layout stability, and whether the LCP image is delayed.
Why: Outcome-based delivery improves discovery and experience without an arbitrary 20 KB rule.
Reference: web.dev image performance guidance

Is an image sitemap used only when important images are otherwise hard to discover?

What: Image sitemap extensions are optional discovery aids for eligible image URLs.
How: Compare rendered discovery with the media inventory before adding or retaining the extension.
Why: Conditional use keeps sitemaps useful without duplicating already crawlable assets.
Reference: Google image sitemap guidance

Does each video intended for Search visibility have an indexable watch page?

What: The video should be the main visible content on a page with a unique title and description.
How: Test prominence, playback, canonical status, and page eligibility on each video template.
Why: Google primarily indexes videos from dedicated watch pages where the video is central.
Reference: Google video SEO best practices

Are video and thumbnail URLs stable, crawlable, and loadable without user interaction?

What: Google must be able to fetch the supported media and thumbnail resources directly.
How: Test URLs anonymously, inspect robots and expiry behavior, and verify rendered discovery before playback.
Why: Unavailable or ephemeral assets prevent video indexing and preview generation.
Reference: Google video indexing requirements

Are VideoObject, video sitemap, and Open Graph data consistent where relevant?

What: Metadata should describe the same visible video, thumbnail, dates, duration, and content URL.
How: Validate rendered markup and use a video sitemap or key moments only when the format and inventory justify them.
Why: Consistent optional signals help Google understand and present eligible videos.
Reference: Google VideoObject structured data

Do videos provide accurate captions and useful transcripts?

What: Spoken information and visual details needed for understanding should be available in accessible text.
How: Review caption timing and accuracy, and publish a transcript appropriate to the media and audience.
Why: Accessible alternatives help more users understand the content without keyword-stuffed companion copy.
Reference: W3C transcripts guidance

Do key templates meet Core Web Vitals at the field 75th percentile on mobile and desktop?

What: Target LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1.
How: Measure real users by template and device, then confirm the 75th percentile for each metric.
Why: Field metrics represent the experience of actual visits and support page-experience evaluation.
Reference: web.dev Core Web Vitals

Are poor Search Console Core Web Vitals groups prioritized by visibility and business importance?

What: Grouped mobile and desktop issues need owners, affected templates, and a validation plan.
How: Combine Search Console groups with impressions and revenue, then follow the rolling 28-day validation cycle.
Why: Template fixes can improve many URLs, while validation requires enough new field data.
Reference: Search Console Core Web Vitals report

Is field evidence used for acceptance and lab testing used for diagnosis?

What: Real-user data and controlled lab traces answer different questions.
How: Investigate differences in devices, networks, cache state, traffic mix, and interaction patterns.
Why: A single Lighthouse run cannot prove the experience of the user population.
Reference: web.dev lab and field data differences

Are LCP, INP, and CLS root causes diagnosed separately by template?

What: Find the specific resource chain, main-thread interaction, or layout-shift source behind each failure.
How: Use traces and field attribution rather than optimizing a composite score.
Why: Each metric measures a different experience and requires a different corrective action.
Reference: web.dev diagnose performance in the field

Are performance regressions segmented and correlated with releases?

What: Device, geography, browser, network, URL group, CDN, and traffic changes can explain regressions.
How: Maintain release annotations and compare affected cohorts before and after each change.
Why: Segmentation prevents broad fixes based on an unrelated aggregate movement.
Reference: web.dev performance monitoring

Is page experience reviewed as a set of user outcomes rather than one SEO score?

What: Include secure delivery, usable mobile presentation, unobstructed content, and strong performance.
How: Test HTTPS, intrusive interstitials, accessibility basics, and CWV without inventing one pass-fail total.
Why: Google explicitly states that page experience has no single signal.
Reference: Google page experience guidance

Does every localized version have a distinct stable URL?

What: Language and regional content should be addressable without relying only on cookies or browser settings.
How: Open every locale URL directly in a fresh session and verify its content and status.
Why: Separate URLs let users and crawlers discover, share, and index each version.
Reference: Google multi-regional site guidance

Are hreflang annotations fully qualified, self-referencing, reciprocal, and valid?

What: Each language cluster needs matching URL sets with supported language and optional region codes.
How: Compare HTML, HTTP headers, or sitemap annotations across every member of the cluster.
Why: Missing return links or invalid codes can cause the annotations to be ignored.
Reference: Google hreflang guidance

Do localized pages canonicalize within the equivalent same-language cluster?

What: Each translated page should normally be canonical in its own language rather than point to another language.
How: Cross-check canonical and hreflang destinations for every locale template.
Why: Conflicting signals can suppress the intended localized URL.
Reference: Google localized versions guidance

Is x-default reserved for a genuine fallback or language selector?

What: Use x-default for the neutral destination shown when no listed locale is the best match.
How: Verify its user experience, canonical, redirects, and reciprocal annotations.
Why: A deliberate fallback helps Google choose an appropriate destination for unmatched users.
Reference: Google x-default guidance

Can users and crawlers change locale through ordinary links without forced IP redirects?

What: Locale selection should remain accessible even when geolocation or Accept-Language suggests a default.
How: Test from different regions and language settings, and preserve the requested URL.
Why: Forced adaptation can hide versions from crawlers and frustrate multilingual users.
Reference: Google locale-adaptive pages guidance

Do localized pages preserve content, metadata, structured data, and language quality?

What: Each version should serve its audience fully rather than expose a thin or unreviewed machine translation.
How: Compare template parity, declared page language, translated assets, and native editorial review.
Why: Hreflang cannot compensate for incomplete, inaccessible, or low-value localized content.
Reference: Google managing international sites

Do product pages use the structured-data model that matches their purchase experience?

What: Purchasable pages use merchant-listing Product data while editorial pages use the appropriate product-snippet model.
How: Match page purpose and required properties to the current Product feature documentation.
Why: The correct model determines eligibility and which offer details Search can understand.
Reference: Google Product structured data

Do price, currency, availability, condition, and identifiers agree everywhere?

What: Visible product data, structured data, checkout, and Merchant Center must describe the same current offer.
How: Compare sampled SKUs across page source, rendered output, feed diagnostics, and transaction flow.
Why: Conflicting commerce data can cause disapprovals, stale results, and user distrust.
Reference: Google product data specification

Is Merchant Center data complete and monitored where Shopping visibility matters?

What: A current feed and account diagnostics complement on-page structured data.
How: Supply required attributes, schedule updates, and resolve item and account-level warnings.
Why: Using both sources improves Google's understanding and supports additional surfaces.
Reference: Google sharing product data

Do product variants use crawlable preselectable URLs and the correct canonical model?

What: Variant URLs should show the matching image, price, availability, identifier, and cart state.
How: Choose the documented single-page ProductGroup or multi-page model and test every canonical relationship.
Why: Incorrect consolidation can hide important variants or create duplicate inventory.
Reference: Google product variant structured data

Do product descriptions and reviews add first-hand evidence?

What: Include measurements, comparisons, original media, pros, cons, and experience beyond manufacturer copy.
How: Review priority pages against the actual testing or evaluation process.
Why: Original evidence helps shoppers make decisions and distinguishes the page from replicated listings.
Reference: Google high-quality review guidance

Are shipping and return policies visible and consistent across supported systems?

What: Users and Google should receive the same current policy terms on the site and in applicable data.
How: Compare policy pages, checkout, Merchant Center, and Organization or Product markup.
Why: Accurate policy information supports purchase decisions and eligible commerce presentations.
Reference: Google organization return policy markup

Does each Google Business Profile represent the real business accurately?

What: Use the real-world name, address or service area, hours, and fewest precise categories with one eligible profile per business.
How: Compare the profile with storefront evidence, official pages, and operational records.
Why: Accurate profiles protect local discovery and prevent misleading customer experiences.
Reference: Google Business Profile guidelines

Does each physical location have a crawlable page with accurate LocalBusiness data?

What: Location pages should expose unique useful content, contact details, hours, and the most specific applicable type.
How: Reconcile visible facts, canonicals, internal links, structured data, and Business Profile destinations.
Why: Consistent location evidence helps users and Search understand each real-world entity.
Reference: Google LocalBusiness structured data

Is site measurement based on GA4 with no Universal Analytics dependency?

What: Critical templates should use the intended GA4 web stream and G-prefixed Measurement ID.
How: Inventory tags, dashboards, integrations, and documentation for retired UA properties or fields.
Why: Universal Analytics stopped processing and became unavailable in 2024.
Reference: Google Universal Analytics sunset

Does tag coverage confirm collection on every critical template?

What: Missing, duplicate, or misplaced tags need verification rather than assumptions from page source.
How: Use Tag Coverage and Tag Diagnostics, then confirm suspected gaps with Tag Assistant.
Why: Collection gaps can make SEO and business performance conclusions false.
Reference: Google Tag Coverage

Is there a deliberate GA4 event map validated in Realtime and DebugView?

What: Distinguish automatically collected, enhanced-measurement, recommended, and custom events.
How: Trigger representative journeys and inspect names, parameters, counts, and duplicates.
Why: GA4 is event-based, so a clean measurement model is the foundation of useful reporting.
Reference: Google Analytics events

Are critical business actions marked as key events with recommended names?

What: Replace legacy goals and category-action-label conventions with meaningful GA4 events.
How: Map each business outcome to a recommended event when available and mark the correct event as key.
Why: Consistent semantics make the intended reporting possible and reduce fragmented implementations.
Reference: Google Analytics key events

Are ecommerce purchase and refund events complete and deduplicated?

What: Required items, value, currency, and a unique transaction ID must describe the real transaction.
How: Test funnel, purchase, cancellation, and refund paths in DebugView and reports.
Why: Missing parameters and duplicate purchases corrupt revenue and SEO landing-page analysis.
Reference: Google Analytics ecommerce measurement

Is internal search measured with view_search_results and the actual search term?

What: Site search should record valid query parameters without exposing sensitive input.
How: Test searches, no-result states, rewritten URLs, and duplicate page-view behavior.
Why: Internal demand reveals content gaps and navigation problems relevant to organic journeys.
Reference: Google Analytics enhanced measurement

Does cross-domain measurement preserve the user journey?

What: Domains, subdomains, forms, and payment providers need the same Measurement ID and intact linker parameters.
How: Follow real journeys and verify configured domains, the gl parameter, sessions, and self-referrals.
Why: Broken linking splits one visitor into multiple sessions and misattributes conversions.
Reference: Google Analytics cross-domain measurement

Are consent defaults set before measurement and updated correctly after the user's choice?

What: Consent state, including ad_user_data and ad_personalization where applicable, must precede tag behavior.
How: Inspect the event timeline for first load, accept, reject, revisit, and navigation scenarios.
Why: Incorrect sequencing creates data-quality and privacy-control failures.
Reference: Google consent mode implementation

Are Search Console and GA4 linked with explicit source-of-truth and retention rules?

What: Use Search Console for pre-click search performance and GA4 for on-site behavior.
How: Document expected discrepancies and export Search Console data when history beyond 16 months matters.
Why: The systems measure different stages and cannot be reconciled as identical datasets.
Reference: Google Analytics and Search Console comparison

Are SEO releases, collection loss, security issues, and search anomalies actively monitored?

What: Alerts and annotations should cover indexing, traffic, CWV, tags, key events, manual actions, and compromise.
How: Assign owners, annotate releases and incidents, and drive every warning or validation to a recorded outcome.
Why: Evidence and response time matter more than occasionally opening dashboards.
Reference: Search Console monitoring guidance

Is every migration backed by a complete old-to-new URL map?

What: Include URLs from crawls, analytics, sitemaps, the CMS, backlinks, media, and server logs.
How: Normalize and classify every known old URL, then assign an equivalent destination or removal state.
Why: Missing legacy URLs cause avoidable traffic loss and broken user journeys.
Reference: Google site move guidance

Are destination capacity, Search Console ownership, and a pre-launch baseline ready?

What: The new host must handle crawl demand and both old and new properties must be verifiable.
How: Load-test representative traffic and archive rankings, clicks, indexing, crawl, CWV, and conversion baselines.
Why: Readiness and baseline evidence make migration failures detectable and recoverable.
Reference: Google site move preparation

Are redirects, canonicals, hreflang, internal links, and sitemaps switched together at launch?

What: Every discovery and consolidation signal should identify the new final URLs.
How: Crawl old and new inventories and remove temporary staging noindex or robots blocks before release.
Why: Mixed signals slow consolidation and can make the new site unavailable to Search.
Reference: Google site move launch steps

Is the migration monitored after launch with redirects retained for at least one year?

What: Track old and new crawl, index, traffic, CWV, and conversion behavior through stabilization.
How: Submit Change of Address where applicable, inspect samples, and keep redirect infrastructure healthy.
Why: Search systems and users continue requesting old URLs long after launch.
Reference: Google site move monitoring

Are organic traffic drops segmented before a cause is assigned?

What: Separate page, query, device, country, search type, indexing, seasonality, and release effects.
How: Combine Search Console, URL Inspection, logs, analytics, release notes, and Google Trends.
Why: Different loss patterns require different fixes and broad totals hide the evidence.
Reference: Google debugging traffic drops

Are validation, review, and incident workflows driven to a terminal documented result?

What: Submission alone is not proof that an indexing, security, or enhancement problem is resolved.
How: Track owner, evidence, request time, final status, recurrence, and preventive action.
Why: Closed-loop operations prevent repeated failures and unsupported completion claims.
Reference: Search Console validation workflow

This list carries a date because it will go out of date. Search shifts in small ways that usually surface only when something stops working, so a line that reads fine today can quietly go stale. We haven't gated any of it, and the boxes you tick stay in your own browser. The GEO checklist does the same job for AI search.

Ask us about your site

Checklist

DISCOVERY & INDEXING