In plain English
Check that every important page returns a successful response, is accessible to Googlebot, contains indexable text and has the intended canonical URL. Then verify crawlable internal links, sitemap entries, unique titles, mobile usability, accurate structured data and Search Console coverage. Record evidence, owners and retest dates instead of treating a plugin score as proof.
Can Google access, load and index each important page?
Pass this gate only when an important URL is public, returns HTTP 200, does not block Googlebot and contains indexable text that communicates the service. Google's minimum technical requirements identify those three conditions for index eligibility while making clear that eligibility does not guarantee indexing. Test representative service, area, contact and insight pages rather than assuming the home page proves the whole site works.
Use Search Console URL Inspection and Page Indexing reports to compare the declared URL, Google's selected canonical, last crawl and index status. Check robots rules and noindex directives in the rendered response, not only inside a content-management dashboard. Record the affected URL and observed evidence before changing anything, because an excluded utility page may be intentional while an excluded revenue page may be urgent. Keep a separate record for intentional exclusions and their business owner.
Sources for this section: Google Search technical requirements, How to use Search Console.
Are discovery, internal links, canonicals and sitemaps coherent?
Every important page should be reachable through standard crawlable links from a logical service, location or content hierarchy. Remove orphan pages and repair broken links, loops and irrelevant redirect chains. Navigation labels should describe the destination for customers. A sitemap helps Google discover preferred URLs, but Google calls it a hint rather than an indexing or ranking guarantee, so it cannot compensate for poor site structure.
Choose one preferred URL for each piece of content and align redirects, internal links, canonical annotations and sitemap entries with it. Investigate protocol, hostname, trailing-slash, parameter and duplicate-location variants. Google explains that it may choose a different canonical despite a declared preference, so validate the selected result in Search Console instead of checking only whether a canonical tag exists in source code. Retest a sample of old and new URLs after every structural release.
Sources for this section: Build and submit a sitemap, What is canonicalization?.
Do page metadata, visible content and structured data agree?
Give each indexable page a concise, descriptive title and a useful main heading that match its actual purpose. Write a unique summary, direct answer and visible service details; do not rely on meta keywords or repeated hidden terms. Ensure important text, links and images work in the rendered mobile experience, with descriptive alternative text where an image communicates meaning.
Structured data must describe content that users can see and must not invent ratings, addresses, prices, services or organisation facts. Use the most specific supported type that fits the page, keep stable identifiers consistent and validate the output. Google's structured-data guidelines stress that valid markup only establishes eligibility for supported search features; display is not guaranteed and markup cannot replace indexable, trustworthy content. Compare the rendered page and markup together during acceptance, including mobile output and error states.
Sources for this section: SEO Starter Guide, General structured data guidelines.
How should the checklist be monitored after release?
Save a release baseline containing important URLs, status codes, index directives, canonicals, sitemap membership, structured-data validation and representative rendered checks. After a migration, template change or domain configuration update, rerun the affected checks and inspect Search Console for new coverage patterns. Assign each failure an owner, severity, evidence link and next verification step rather than closing it when code merely changes.
Monitor search queries, pages, countries and devices alongside real enquiry quality, but keep platform metrics distinct from sales outcomes. Expect crawlers and reports to update on their own schedules. A clean technical checklist removes preventable access and interpretation problems; it does not prove that a page is useful, guarantee inclusion or promise rankings in Pretoria, Johannesburg, Cape Town or anywhere else. Retain dated prior baselines so regressions are distinguishable from known existing gaps and intentional exclusions.
Sources for this section: How to use Search Console, Using Search Console and Google Analytics data for SEO, Google Search technical requirements.
Official references
- Google Search technical requirements (Google Search Central)
- How to use Search Console (Google Search Central)
- Build and submit a sitemap (Google Search Central)
- What is canonicalization? (Google Search Central)
- SEO Starter Guide (Google Search Central)
- General structured data guidelines (Google Search Central)
- Using Search Console and Google Analytics data for SEO (Google Search Central)