Ali Demirbaş

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

Editorial illustration of an SEO checklist with web pages, a crawler, and a search magnifier
Ali DemirbaşMobile App Growth Lead, Aksigorta

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.

SEO checklist: evidence and acceptance criteria
  • 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

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.

Discovery and indexing flow between a web page, crawler, and search index
Verify crawling and indexing as separate steps.

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.

Visual checklist for SEO reviews and prioritized improvements
Track priority findings with evidence and acceptance criteria.

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:

  1. Save the original evidence, affected URL or template, and expected behavior.
  2. Assign an owner and identify any dependencies that must be resolved first.
  3. Recheck the published change using the method that exposed the problem.
  4. Monitor subsequent crawling, indexing, and performance without promising a recovery date.
  5. 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.

Ali Demirbaş

Written by

Ali Demirbaş

Mobile App Growth Lead, Aksigorta

Ali Demirbaş is the Mobile App Growth Lead at Aksigorta. He writes about growth, lifecycle marketing and the metrics behind them.

Related tools

What to read next

If this work overlaps with yours, let's talk.

Send me a note about growth, CRM, measurement or one of the projects here. A question, a counterpoint or a simple hello all work.