SEO checklist: What to check and how to verify it
Use this SEO checklist to review indexing, content, links, and performance. Set priorities, verify fixes, and connect your audit to business outcomes.
October 4, 202611 min read

An SEO checklist should help you decide what to fix, how to verify it, and when to check again. Start with pages that search engines cannot access or index, then review search intent, content, links, and the visitor experience. Give each finding an owner and an acceptance criterion so the audit produces work that somebody can actually complete.
A long report can hide a small number of underlying problems. One broken template might affect an entire product catalog, while a single inaccessible landing page could interrupt an important source of leads. The order of work should reflect that difference. Use the checklist below to connect technical findings with the pages and customer actions that matter to your site.
Define the audit before choosing tools
Write down the purpose of organic search for the business. An online store may care about product discovery and purchases; a software company may focus on qualified trials; a support site may help customers solve problems independently. This decision shapes the audit. Without it, improving a crawler score can become the objective even when important customer journeys remain broken.
Build an inventory from your content management system, XML sitemap, and Search Console. Group URLs by template, language, and business purpose. Start with representative pages, plus any pages that have lost traffic or support important conversions. Sampling makes repeated issues easier to identify, but it does not prove that every URL is healthy. Expand the review when a finding suggests a wider problem.
Record the date, device, page version, and tool used for each check. Keep “not tested” separate from “passed.” If you cannot inspect Search Console or server responses, say so in the audit. Missing access is a limit on the evidence, not evidence that a problem is absent. This distinction becomes particularly useful when several teams share responsibility for the site.
Use a checklist with acceptance criteria
Use this table to turn findings into tasks. Priority depends on affected pages, business importance, and whether the issue blocks other work.
Area: Access
- Evidence to collect
- HTTP response and URL Inspection
- Typical finding
- Important page is unavailable
- Acceptance criterion
- Expected content can be retrieved
- Starting priority
- Critical
Area: Indexability
- Evidence to collect
- Robots meta and response headers
- Typical finding
- Accidental noindex directive
- Acceptance criterion
- Rules match the intended indexing state
- Starting priority
- Critical
Area: Canonicalization
- Evidence to collect
- Declared canonical and indexing evidence
- Typical finding
- Conflicting preferred URLs
- Acceptance criterion
- Relevant signals support the intended URL
- Starting priority
- High
Area: Discovery
- Evidence to collect
- Sitemap and internal link inventory
- Typical finding
- Important page has no useful incoming links
- Acceptance criterion
- Page is linked from relevant content
- Starting priority
- High
Area: Search intent
- Evidence to collect
- Query and result-page review
- Typical finding
- Wrong content format or incomplete answer
- Acceptance criterion
- Page addresses the intended need
- Starting priority
- High
Area: Page metadata
- Evidence to collect
- Title, description, and visible content
- Typical finding
- Misleading or repeated page promise
- Acceptance criterion
- Metadata accurately describes the page
- Starting priority
- Medium
Area: Mobile experience
- Evidence to collect
- Device testing and field measurements
- Typical finding
- Important task cannot be completed
- Acceptance criterion
- Task works on supported devices
- Starting priority
- Impact dependent
Area: Structured data
- Evidence to collect
- Validator and visible content
- Typical finding
- Unsupported or inaccurate claims
- Acceptance criterion
- Markup represents the actual page
- Starting priority
- Medium
Area: Measurement
- Evidence to collect
- Test conversion and reporting checks
- Typical finding
- Missing or duplicated events
- Acceptance criterion
- Defined action is recorded correctly
- Starting priority
- High
| Area | Evidence to collect | Typical finding | Acceptance criterion | Starting priority |
|---|---|---|---|---|
| Access | HTTP response and URL Inspection | Important page is unavailable | Expected content can be retrieved | Critical |
| Indexability | Robots meta and response headers | Accidental noindex directive | Rules match the intended indexing state | Critical |
| Canonicalization | Declared canonical and indexing evidence | Conflicting preferred URLs | Relevant signals support the intended URL | High |
| Discovery | Sitemap and internal link inventory | Important page has no useful incoming links | Page is linked from relevant content | High |
| Search intent | Query and result-page review | Wrong content format or incomplete answer | Page addresses the intended need | High |
| Page metadata | Title, description, and visible content | Misleading or repeated page promise | Metadata accurately describes the page | Medium |
| Mobile experience | Device testing and field measurements | Important task cannot be completed | Task works on supported devices | Impact dependent |
| Structured data | Validator and visible content | Unsupported or inaccurate claims | Markup represents the actual page | Medium |
| Measurement | Test conversion and reporting checks | Missing or duplicated events | Defined action is recorded correctly | High |
Treat these priorities as a starting point. A metadata problem affecting every product can deserve more attention than an isolated technical warning on an unimportant page. Add the affected template, a reproducible example, and the expected behavior to each task. That gives the person implementing the fix enough information to judge scope and confirm whether the change worked.
Remove access and indexing blockers
Separate crawling from indexing
Robots.txt controls crawling, while noindex tells a search engine not to include an accessible page in its index. They serve different purposes. Google’s noindex documentation explains that Google must crawl a page to discover the directive. Blocking the same URL in robots.txt can prevent that discovery, so combining the two is not a reliable removal strategy.

Check both HTML robots tags and the X-Robots-Tag response header. A page can look normal in a browser while carrying an unintended indexing directive. In Search Console, distinguish the indexed information from the live test. A successful live test helps establish current accessibility; it does not mean the page is already indexed or guarantee that it will appear in search results.
Align canonical URLs, redirects, and sitemaps
A canonical identifies the preferred version among duplicate or very similar pages. Google treats canonical declarations as signals, and may choose a different URL. Compare the declaration with internal links, redirects, and sitemap entries. If these disagree, investigate the reason. Do not use canonical tags to collapse genuinely different pages simply because maintaining them is inconvenient.
Check alternate domain and protocol versions, including HTTP, HTTPS, www, and non-www. When a page moves permanently, use an appropriate permanent redirect to its relevant replacement. Avoid sending every removed URL to the homepage. A page without a suitable replacement may need a proper 404 or 410 response. Verify the destination content as well as the status code.
Your sitemap should contain the canonical URLs you want discovered and indexed. Compare it with the inventory instead of assuming that successful submission proves coverage. Google describes sitemap submission as a hint, not a crawling or indexing guarantee. If you provide lastmod values, make them reflect meaningful page changes rather than resetting every date whenever the website is deployed.
Inspect rendered content and language alternatives
For JavaScript sites, compare the initial response with the rendered page. Confirm that important text, links, and metadata become available without depending on an interaction that a crawler may never perform. Google’s JavaScript SEO guidance separates crawling from rendering. Use inspection evidence to investigate missing content instead of assuming that a page working in your browser settles the question.
Multilingual sites need an additional check. Hreflang annotations should identify the corresponding language versions, include the page itself, and provide reciprocal links using complete URLs. Check the language selector too. Correct annotations will not help a visitor who switches languages and lands on an unrelated homepage. Keep canonical choices consistent with the purpose of each localized page.
Match each page to a search need
Review the results for a target query before rewriting the page. Are people being offered product categories, tutorials, comparison pages, or tools? This gives you evidence about the likely task behind the query. Search volume alone cannot make that decision. A buying query and a troubleshooting query may mention the same product while requiring very different information and next steps.
Map related queries to existing pages before creating more content. Similar wording does not automatically mean two pages compete for the same need. Compare their purpose, query patterns, and usefulness. Consolidation may help when both pages answer substantially the same question, but distinct use cases may justify keeping both. Plan redirects and internal link updates whenever consolidation changes the URL structure.
Make the page promise accurate
Check the title, main heading, and meta description against the actual content. They should describe the same offer or answer without overstating it. Google can generate title links from several sources and snippets from page content or descriptions. Your preferred wording may therefore change in search. Evaluate differences in the context of the query rather than treating every rewrite as an error.
Use headings to organize the reader’s questions. Put the main answer near the beginning, then provide the details needed to act on it. Remove sections that repeat the introduction or define terms the intended reader already understands. A useful editing test is to read only the headings: the sequence should reveal what the page covers and how its sections connect.
Check evidence, authorship, and maintenance
Verify statistics, comparisons, and product claims against their original sources. State who wrote the page and provide relevant author information without inventing experience. Google’s helpful content guidance encourages reviewing originality, usefulness, and trust. Apply those standards to AI-assisted drafts as well. A confident explanation can still contain an unsupported claim, an outdated instruction, or a source that says something different.
Update content when something meaningful changes: a product condition, a recommended process, an unavailable tool, or a broken example. Moving the displayed date forward does not make an unchanged page more useful. Keep a record of substantive revisions so readers and editors can understand what was updated. For a checklist, removing obsolete steps can be as valuable as adding new ones.
Review links as part of the reader’s next step
Important pages should receive links from relevant parts of the site. Inspect those links in context, including their anchor text and destination. Google recommends crawlable links and descriptive anchors. A useful internal link helps someone continue a task, such as moving from a comparison guide to a relevant product category, without requiring them to start again from the navigation menu.
Fix broken destinations and avoid unnecessary redirect chains. Check external references too: a page can remain online while its information changes. For earning links, consider useful research, practical tools, and contributions that deserve a reference. Google’s spam policies cover manipulative link practices, including buying or selling links for ranking purposes. Raw link count is a poor substitute for reviewing why those links exist.
Test the mobile experience and performance
Choose important tasks and perform them on a real mobile device. Read an article, open the menu, select a product, and complete a form. Check whether overlays obscure content or moving elements cause mistakes. Record the device and steps needed to reproduce each issue. A responsive layout can still contain a form that is difficult or impossible to use.
Core Web Vitals define good thresholds of 2.5 seconds or less for LCP, 200 milliseconds or less for INP, and 0.1 or less for CLS. Assess these at the 75th percentile, separating mobile and desktop. Laboratory tests help diagnose problems, but they are not the same as real-user measurements. A strong lab score cannot establish that every visitor receives a good experience.
When field data is unavailable, record that limitation and combine laboratory testing with device checks and your own measurements where possible. Investigate the cause before choosing a fix: a large image, expensive JavaScript, and a third-party widget require different work. Repeat the diagnostic test after the change, then monitor field measurements separately as new user experiences become available.
Validate structured data and AI search assumptions
Structured data should describe what visitors can actually see on the page. Check the type, required fields, and consistency with visible information. Do not invent ratings, prices, or author credentials to complete a template. Google’s structured data guidelines distinguish technical validity from eligibility and appearance. Passing a validator does not guarantee a rich result, and content updates can create new inconsistencies.
Google’s AI features guidance says there are no additional special optimizations required for AI Overviews or AI Mode. Start with accessible, indexable, useful content. For a broader review across AI search systems, use the GEO checklist. Keep platform-specific requirements separate; a statement about Google’s features does not establish how every other assistant selects or cites sources.
Measure outcomes and verify the work
Review impressions, clicks, click-through rate, and average position by meaningful page and query groups. Separate branded demand where possible, then connect organic visits with useful customer actions in analytics. The marketing calculators can support conversion-rate and customer-value calculations. Keep the definitions of visits, users, and completed actions consistent so changes in reporting do not masquerade as changes in performance.

A rise after a fix does not prove that the fix caused the entire improvement. Seasonality, campaigns, and other website changes can affect the same period. Record what changed and compare suitable periods, devices, and page groups. Technical acceptance and business evaluation answer different questions: you can verify a corrected directive promptly, while its search impact may take longer to assess.
Close each task using a consistent sequence:
- Save the original evidence, affected URL or template, and expected behavior.
- Assign an owner and identify any dependencies that must be resolved first.
- Recheck the published change using the method that exposed the problem.
- Monitor subsequent crawling, indexing, and performance without promising a recovery date.
- Reopen relevant checks when templates, domains, content, or measurement settings change.
Use the type of change to decide the next review’s scope. Publishing one article calls for different checks from replacing a product template or moving a domain. Keep previous findings and their verification evidence available to the team. That makes the checklist a reusable record of decisions and remaining work, with enough context to catch recurring problems before another full audit is needed.


