The Practical GEO Checklist: 30 Things Worth Reviewing

Most GEO checklists mix a robots.txt syntax error with "add an llms.txt file" and present both as tasks. One of those is a defect against a published standard; the other is an untested idea. Sorting them is the entire value of a checklist, so this one is ordered by evidence tier and says out loud which items are not fixes at all. Sixteen of the thirty rest on a published specification or on current first-party provider documentation. Four of them should never be counted as failures.

The uncomfortable finding, stated up front: the top tier is mostly conventional technical SEO and honest publishing. Google states it directly — "There are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary", and "You don't need to create new machine readable files, AI text files, or markup to appear in these features." Any checklist whose top tier is full of AI-specific novelties is not reporting evidence; it is selling a category.

How to use this

Work top down. An item in the first section is a defect with a documented consequence and belongs in a defect queue. An item in the second is well-supported and belongs in a work queue. An item in the third is a reasonable practice with a plausible mechanism and no confirmation. An item in the fourth is something you may try and must not measure yourself against.

The distinctions that survive every item here: crawled ≠ retrieved ≠ cited ≠ recommended. robots.txt access ≠ citation. llms.txt presence ≠ ingestion. Schema ≠ citation. An API response ≠ what a person sees in a chat product. One query ≠ a ranking.

---

Section A — Established standard and official provider guidance (items 1–16)

These are compliance checks. A failure has a consequence documented by a specification author or by the provider itself, and can legitimately be reported as a defect.

1. robots.txt exists at the host root and returns HTTP 200

Check: Request https://yourdomain/robots.txt over HTTP and read the status code, not the file on disk. Why: RFC 9309 places the file at scheme:[//authority]/robots.txt, requires UTF-8 and text/plain, and separates unavailable from unreachable: on 4xx a crawler "MAY access any resources on the server", while on 5xx it "MUST assume complete disallow" until the file is reachable again or 30 days pass. A misconfigured server returning 5xx for robots.txt can therefore suppress crawling site-wide. Google similarly treats 4xx as if no robots.txt existed and stops crawling for 12 hours on 5xx before falling back to a cached copy for up to 30 days. Evidence: ESTABLISHED STANDARD (RFC 9309) and OFFICIAL PROVIDER GUIDANCE (Google).

2. No unintended Disallow on content you want retrieved

Check: Parse the effective file and resolve the rule that applies to each crawler group. Google uses the most specific rule by path length and, on ties, "the least restrictive rule"; RFC 9309 puts it as "the most specific match found MUST be used. The most specific match is the match that has the most octets." Why: A disallowed URL cannot be fetched by a compliant crawler, so nothing downstream — indexing, retrieval, citation — can happen. This is the single highest-consequence line in the file. Evidence: ESTABLISHED STANDARD.

3. Rules exist on every host, protocol and port you publish from

Check: Fetch robots.txt for every subdomain and for both http and https. Why: Google states robots.txt rules apply only to "the host, protocol, and port number where the robots.txt file is hosted". Anthropic makes the same point operationally: apply your rule "for every subdomain that you wish to opt out from". A rule on example.com governs nothing on docs.example.com. Evidence: ESTABLISHED STANDARD and OFFICIAL PROVIDER GUIDANCE.

4. A Sitemap: line is present and the sitemap is valid

Check: Confirm the Sitemap: directive resolves, then validate the file: <urlset> with the correct namespace, a <loc> per URL, no more than 50,000 URLs and no larger than 50MB uncompressed, and an index file if you exceed either. Why: Google supports the sitemap field with no limit on the number of lines. The sitemaps protocol also constrains scope by location — a sitemap at /catalog/sitemap.xml may only list URLs under /catalog/ — and all URLs must share the sitemap's protocol and host. Evidence: ESTABLISHED STANDARD (sitemaps.org) and OFFICIAL PROVIDER GUIDANCE (Google).

5. Sitemap lastmod is honest, and changefreq/priority are not being relied on

Check: Compare <lastmod> values against actual modification history. Look for a corpus where every URL shares the build date. Why: The protocol defines <lastmod> as "the date of last modification of the page". <changefreq> is documented as "a hint and not a command", and <priority> "does not affect how your pages are compared to pages on other sites". A generator stamping today's date everywhere is emitting noise, not a freshness signal. Evidence: ESTABLISHED STANDARD.

6. No unintended noindex, in meta or in X-Robots-Tag

Check: Read both the <meta name="robots"> tag and the HTTP response headers for every template. Headers are the ones people miss, because they are invisible in the page source. Why: Google documents noindex as "do not show this page, media, or resource in search results". Google's AI features documentation states that pages must be indexed and eligible for snippets to appear as supporting links, so a stray noindex removes a page from both conventional results and AI feature links at once. Evidence: OFFICIAL PROVIDER GUIDANCE.

7. Disallow and noindex are not applied to the same URL

Check: Cross-reference disallowed paths against pages carrying noindex. Why: A crawler must be allowed to fetch a page to see its meta directive. Disallowing the URL guarantees the directive is never read, so the combination is self-defeating — and Google's canonicalisation guidance separately advises against using robots.txt for de-duplication at all. Evidence: OFFICIAL PROVIDER GUIDANCE.

8. Snippet controls are not suppressing eligibility unintentionally

Check: Look for nosnippet, max-snippet:[n] with a small value, data-nosnippet wrapping the main content, and max-image-preview:none. Why: Google documents nosnippet as "do not show a text snippet or video preview in the search results for this page", and names nosnippet, data-nosnippet, max-snippet and noindex as the controls that govern how content is used in AI features. These are legitimate choices, but they are frequently inherited from a theme or plugin default rather than chosen. Note that noarchive and nocache are documented as no longer used by Google Search. Evidence: OFFICIAL PROVIDER GUIDANCE.

9. Canonical URLs are absolute, self-referencing where appropriate, and not contradicted

Check: For each template, confirm one rel="canonical" per page, an absolute URL, no fragment, and no conflict between the HTML element, an HTTP header, and the sitemap. Why: Google describes rel="canonical" as indicating "that another page is representative of the content on the page" and treats canonicalisation methods as preferences rather than commands, ranked by strength: redirects strongest, rel="canonical" strong, sitemap inclusion weak. Documented mistakes to avoid include conflicting techniques on the same page, fragment canonicals and relative paths. Evidence: OFFICIAL PROVIDER GUIDANCE.

10. One hostname and one protocol, consolidated by redirect

Check: Request the site as http and https, with and without www, and confirm each variant redirects to the single canonical form. Why: Redirects are the strongest consolidation signal Google documents, and it separately notes it prefers HTTPS over HTTP absent conflicting signals. Splitting the same content across four addressable variants splits every signal that depends on the URL. Evidence: OFFICIAL PROVIDER GUIDANCE.

11. Structured data describes content that is actually visible on the page

Check: Extract every JSON-LD block and compare each property to the rendered page. Why: Google's structured data policies are explicit: "Don't mark up content that is not visible to readers of the page." Irrelevant or misleading markup, content "not representative of the main content of the page", and impersonation are all named. Violations can trigger a manual action costing rich result eligibility. Evidence: OFFICIAL PROVIDER GUIDANCE.

12. Structured data is complete for the type you have chosen, and not duplicated

Check: Validate each type's required properties, and look for two plugins emitting competing Organization or Article graphs on the same page. Why: Google notes that "items that are missing required properties are not eligible for rich results", and that even correct markup carries no guarantee: "Google does not guarantee that your structured data will show up in search results, even if your page is marked up correctly." For Article specifically there are no required properties — "add the properties that apply to your content". Evidence: OFFICIAL PROVIDER GUIDANCE.

13. Dates are present, consistent, and not in the future

Check: Compare the visible date, datePublished and dateModified. Confirm ISO 8601 format with a timezone, and that no date is ahead of today. Why: Google recommends both a prominent user-facing date labelled "Posted", "Published" or "Last updated" and structured-data dates, states that "the date is required; the time is not", instructs you to "make your dates and times consistent", warns against future dates and against dates that describe events on the page rather than the page itself, and notes it "doesn't depend on a single date factor". Evidence: OFFICIAL PROVIDER GUIDANCE. Detail in content freshness.

14. Author markup uses the right type and a clean name

Check: Confirm Person for people and Organization for organisations, with name and either url or sameAs. Why: Google's Article guidance recommends exactly that split, and specifically advises against putting publisher names, job titles or honorifics inside the name field. Author information is one of the few identity signals a retrieval system can parse without inference. Evidence: OFFICIAL PROVIDER GUIDANCE.

15. AI crawler access has been decided per operator, deliberately

Check: Resolve the effective rule for each documented agent — OpenAI's GPTBot, OAI-SearchBot, OAI-AdsBot and ChatGPT-User; Anthropic's ClaudeBot, Claude-SearchBot and Claude-User; Google's Googlebot and Google-Extended; CCBot — and confirm each matches an intention. Why: OpenAI states "each setting is independent of the others", and Google states "Google-Extended does not impact a site's inclusion in Google Search nor is it used as a ranking signal in Google Search." A single blanket rule usually blocks the agent that would have cited you and leaves the training crawler untouched. Evidence: OFFICIAL PROVIDER GUIDANCE for every documented consequence. This item is never scored as a deficiency. Access is a licensing and bandwidth decision — see should you block AI training crawlers?.

16. No spam-policy violations anywhere in the corpus

Check: Look for mass-generated pages, near-duplicate location or keyword variants, text served differently to crawlers than to users, keyword-dense blocks, and third-party content hosted purely to borrow your domain's standing. Why: Google defines scaled content abuse as "when many pages are generated for the primary purpose of manipulating search rankings and not helping users"; doorway abuse as pages "created to rank for specific, similar search queries"; cloaking as "presenting different content to users and search engines with the intent to manipulate search rankings and mislead users"; and keyword stuffing as "filling a web page with keywords or numbers in an attempt to manipulate rankings". Evidence: OFFICIAL PROVIDER GUIDANCE. AI-assisted content production makes the first of these very easy to commit by accident.

---

Section B — Strong evidence (items 17–21)

Well-supported by long-standing, reproducible practice and consistent with Google's own guidance, though the specific effect size is not published by anyone. Legitimate work-queue items.

17. No orphan pages; important pages are reachable by internal links

Check: Build the internal link graph and list pages with zero inbound internal links, plus pages more than three or four clicks from an entry point. Why: A page reachable only from a sitemap is discoverable but unsupported: nothing on the site indicates what it is about or how important it is. Retrieval systems, like search crawlers, work from what is connected. Evidence: STRONG EVIDENCE. See internal linking for SEO, retrieval and AI.

18. No broken, redirected-in-chain, or insecure internal links

Check: Resolve every internal link and record the final status. Flag 4xx, 5xx, chains longer than one hop, and http:// links on an HTTPS site. Why: Broken internal links waste the crawl and strand content. Mixed-content links are a correctness defect regardless of any search consideration. Evidence: STRONG EVIDENCE.

19. Titles and meta descriptions are unique and descriptive

Check: Group the corpus by exact and near-duplicate title. Any cluster larger than one is a candidate defect. Why: Duplicate titles across a site usually indicate a template problem or genuine content duplication, and a title is the strongest single-line description a machine has of a page. Evidence: STRONG EVIDENCE.

20. Thin and near-duplicate pages are consolidated, not multiplied

Check: Flag documents below a sensible word-count floor for their type, and near-duplicate clusters by lexical similarity. Be careful with page-builder pages, where extracted word counts are unreliable and a thin-content flag is a serious false positive. Why: Several weak pages on one subject compete with each other and dilute the internal links that should have pointed at one good page. Consolidation is usually the higher-value move. Evidence: STRONG EVIDENCE.

21. Pages contain original information, not a restatement of other pages

Check: For your top pages, ask whether anything on them could only have come from you — your data, your testing, your experience. Why: Google's self-assessment asks whether content "provides original information, reporting, research, or analysis" and whether it offers "substantial, complete, or comprehensive" coverage, and asks directly: "Is this the sort of page you'd want to bookmark, share with a friend, or recommend?" Evidence: OFFICIAL PROVIDER GUIDANCE for the questions; STRONG EVIDENCE for the practice of auditing against them. See citation-worthy content for AI systems.

---

Section C — Emerging practice (items 22–26)

Widely adopted, with a plausible mechanism, and not confirmed by any provider as affecting AI answer systems. Worth doing; worth reporting with a light hand.

22. Primary content is present in the server-rendered HTML

Check: Fetch the page with a plain HTTP client — no JavaScript — and confirm the main text is there. Why: None of the crawler documentation we verified on 9 September 2026 states whether a given AI crawler executes JavaScript, and we are not going to assert it either way. The asymmetry decides it: if content is in the initial HTML it is available to every consumer; if it is not, availability depends on an undocumented capability. Server-rendering costs nothing and removes the question. Evidence: EMERGING PRACTICE, on an explicit absence of provider documentation.

23. Sections are self-contained and headings describe their content

Check: Take a ## section at random, read it without the rest of the page, and see whether it answers something on its own. Check that headings are descriptive rather than clever. Why: Retrieval systems generally operate on passages rather than whole documents, so the unit that gets retrieved is the section, not the article. A section that depends on three paragraphs above it to make sense is a poor retrieval unit. Evidence: EMERGING PRACTICE. See passage-level content structure.

24. The organisation is named consistently and identified unambiguously

Check: Confirm the same legal or trading name across the site, an Organization block with name, url and sameAs links to profiles you control, and real About and Contact pages. Why: A model resolving "who is X" needs a consistent surface form and corroborating identifiers. Inconsistent naming produces ambiguous entity resolution, and there is no mechanism by which ambiguity helps. Evidence: EMERGING PRACTICE as a GEO practice; the schema itself is ESTABLISHED STANDARD. See entity clarity.

25. Authorship and review are transparent

Check: Named author on substantive pages, a bio establishing why they can speak on it, and a review date where the subject warrants it. Why: Google emphasises trust as the most important element of E-E-A-T, particularly for health, financial and safety topics, and asks whether content is "written or reviewed by an expert or enthusiast who demonstrably knows the topic well". Its effect on AI retrieval specifically is not documented. Evidence: OFFICIAL PROVIDER GUIDANCE for the underlying quality guidance; EMERGING PRACTICE for the GEO claim. Never invent an author, a credential, or a review. An empty field stays empty.

26. Factual claims are consistent across the site

Check: Pick three claims that appear on multiple pages — founding year, pricing model, product capability — and confirm they agree. Why: A retrieval system may surface any of your pages. Contradictions between them give it no way to choose, and give a reader a reason to distrust all of them. Evidence: EMERGING PRACTICE, and plain editorial hygiene regardless.

---

Section D — Experimental and hypothesis (items 27–30) — these are not fixes

Everything in this section is an idea, not a defect. None of it is scored, none of it contributes to a status band, and none of it should be phrased to a client as something that is wrong with their site. Google's position on its own AI features is that no new files or markup are needed to appear in them, and nothing below contradicts that.

27. /llms.txt, if you want one

Check: If present, confirm it parses against the proposal: an H1 with the project or site name — "the only required section" — an optional blockquote summary, and file lists delimited by H2 headings containing links with optional notes. Why anyone does it: The proposal, authored by Jeremy Howard and first published in September 2024, describes "a proposal to standardise on using an /llms.txt file to provide information to help agents use a website", offering LLM-friendly content instead of HTML parsing. The site itself describes the current text as "v2 of the proposal", still "open for community input". What is not true: No major provider documents consuming it, and presence is not ingestion. Google says explicitly that you do not need to create AI text files to appear in its AI features. Evidence: EXPERIMENTAL. See what is llms.txt.

28. Quotable statistics and primary-source citations

Check: Does the page contain a specific, attributable number or a cited primary source that another writer would want to quote? Why anyone does it: The reasoning is that a specific figure is easier for a generative system to lift and attribute than a general claim, and that verifiable sourcing raises the probability a summariser keeps the attribution. What is not true: No provider documents this, and the mechanism is inferred from output rather than from documentation. Evidence: EXPERIMENTAL. Never fabricate a statistic to satisfy this item. If you did not measure it, you do not have it.

29. Explicit question-and-answer blocks aligned to conversational phrasing

Check: Do headings phrase real questions in the words people use, with the answer immediately beneath? Why anyone does it: Prompts are questions; a heading that matches a question is a plausible passage-level match. What is not true: This is indistinguishable in practice from ordinary good headings, and no provider has confirmed any additional effect. Note also that stuffing pages with FAQPage markup for content not visible to users violates the structured data policies in item 11. Evidence: EXPERIMENTAL.

30. A short machine-readable summary at the top of long pages

Check: Does a long page open with a two-or-three-sentence statement of what it concludes? Why anyone does it: First-principles reasoning — if a retrieval system chunks a document, an early chunk that states the conclusion is more likely to be a usable answer than an early chunk of throat-clearing. What is not true: There is no evidence for this at all beyond the reasoning itself. It is included because it is harmless and helps human readers, which is a sufficient justification on its own. Evidence: HYPOTHESIS.

---

What not to assume

• That completing all thirty produces citations. The chain is crawled → retrieved → cited → recommended, and every arrow is a separate step that no provider fully documents. This checklist removes obstacles at the first arrow and improves the odds at the second. It does not buy the third.
• That Section D failures are failures. They are not scored here and must not be scored in any audit you run.
• That a single AI answer tells you anything. One query is not a ranking, and a generative answer has no position. Measurement is a separate discipline — see how LLM visibility monitoring works.
• That vendor documentation is stable. Every claim above was verified against a live page on 9 September 2026. Crawler rosters and directive support change; re-read before you write a rule.
• That a score summarises this. SiteRank AI reports status bands with the counts behind them and excludes the bottom two evidence tiers from that calculation in the query itself, so an experimental idea cannot leak into a number. The rules are in the measurement methodology.

Key takeaways

• Sixteen of thirty items rest on a published standard or current provider documentation. That is where the defect queue comes from.
• The top tier is overwhelmingly conventional technical SEO and honest publishing, which is consistent with Google's own statement that no special optimisations are needed for its AI features.
• Crawler access policy is a business decision and appears in the list only as "decide it deliberately" — never as a deficiency.
• Four items are explicitly not fixes. Presenting llms.txt, statistic density, FAQ phrasing or TL;DR blocks as required work is the most common dishonesty in this field.
• Verify vendor claims against the live page before writing a rule, and record the date you checked.

Official sources & further reading

• AI features and your website — Google Search Central
• Google robots.txt specification — Google Search Central
• Robots meta tag, data-nosnippet, and X-Robots-Tag specifications — Google Search Central
• Consolidate duplicate URLs with canonicals — Google Search Central
• Structured data general guidelines — Google Search Central
• Article structured data — Google Search Central
• Article dates in Google Search results — Google Search Central
• Creating helpful, reliable, people-first content — Google Search Central
• Google Search spam policies — Google Search Central
• Google's common crawlers — Google Search Central
• Overview of OpenAI crawlers — OpenAI
• Does Anthropic crawl data from the web, and how can site owners block the crawler? — Anthropic
• CCBot — Common Crawl
• RFC 9309: Robots Exclusion Protocol — IETF
• Sitemaps XML format — sitemaps.org
• The /llms.txt file — Jeremy Howard

Related reading

• What is generative engine optimization?
• SEO vs GEO
• Passage-level content structure
• Entity clarity
• SiteRank AI's GEO readiness audit