SEO Glossary 2026

SEO spans content, site architecture, technical accessibility, and off-site reputation — it isn't a fee paid to Google for placement, and finishing a checklist doesn't guarantee a position. The discipline is really three overlapping jobs: make the site crawlable and indexable, make individual pages genuinely useful for a specific intent, and build enough credibility (links, mentions, consistent entity signals) that Google and, increasingly, AI systems trust the site as a source.

A SERP's composition changes with the query and context, so a numeric ranking alone doesn't describe what a searcher actually sees — a #1 organic position can sit below ads, a knowledge panel, and an AI Overview, especially on mobile. Record the query, country, device, and visible feature set alongside any ranking you track; a position tracked without that context is close to meaningless by 2026's standards.

"Unpaid" describes the placement mechanism, not the cost of the work behind it — ranking organically can require substantial content, technical, and link-building investment. An organic click is also a different event from a conversion; someone finding a guide in search and later buying a product are two separately measurable steps, not one.

A search query is what a user actually enters; a target keyword is the phrase a publisher plans content around, and one well-built page can answer many related queries without needing a separate page for each phrasing. Keyword research is really query-intent research wearing an old name — the useful output is a cluster of real user questions, not a list of strings to insert into a page a set number of times.

Long-tail queries collectively make up a large share of all searches even though no single one gets much volume, and they're frequently the easiest wins for a newer site because competition for an ultra-specific question is usually thinner than for a broad head term. A precise question about a narrow, CMS-specific problem is a textbook long-tail example — small audience, well-defined need, genuinely winnable.

Different tools pull from different data sources, group related queries differently, and average out seasonal swings, so two tools can report meaningfully different volume for the identical phrase. A page targeting a query with modest reported volume can still receive far more traffic than that number implies once related and long-tail variations are counted.

Each tool defines and calculates its own KD score, typically from the backlink profiles of currently-ranking pages, which means a low score can still hide a format mismatch — searchers want a working tool or calculator, and your planned page is an article, so no realistic amount of link building closes that gap. Treat KD as a screening aid for prioritization, not a reliable predictor of actual ranking difficulty.

On-page work is about clarity and structure, not keyword density — a page with a vague heading like "More information" forces both readers and crawlers to work harder than one with "When should you use noindex?" that answers the implied question directly underneath it. Good on-page SEO is largely an editing discipline: can someone unfamiliar with the topic find the answer, its limitations, and the next step without leaving the page?

Technical SEO removes obstacles; it doesn't by itself make a page deserve to rank. An excellent, well-researched guide that happens to ship with an accidental noindex tag in production will never be found no matter how good the writing is — the technical layer is a precondition, not a ranking strategy on its own.

Not every mention is a backlink, and not every backlink moves rankings — off-page SEO is broader than link building alone, and includes brand mentions, reviews, and the kind of reference-worthy original work other publishers choose to cite on their own. The throughline across all of it is reputation built by being genuinely useful to someone else's audience, not just acquired by request.

robots.txt is a request, not an enforcement mechanism — well-behaved crawlers (Googlebot, Bingbot) honor it, but it can't stop a page from being indexed if other sites link to it; for that you need `noindex` instead. Rules are evaluated by longest-match-wins, not first-match, so a broad `Disallow: /` followed by a narrower `Allow: /blog/` still blocks everything except `/blog/`. Case matters, and a trailing slash changes what a rule catches.

A sitemap doesn't guarantee indexing or reserve crawl capacity — it's a discovery hint, not a promise. Google Search Console's Page indexing report (formerly called Coverage) will show you the gap between URLs submitted and URLs actually indexed, which is usually where the real diagnosis starts. Large sites should split sitemaps by type (products, blog, categories) and use a sitemap index file, since a single sitemap is capped at 50,000 URLs / 50MB uncompressed — unchanged going into 2026. Google also ignores the `priority` and `changefreq` fields entirely.

Google must be able to crawl a page to see its `noindex` tag — if robots.txt blocks the page first, Google may never discover the `noindex` directive and could still index the URL (with no snippet) based on external links pointing to it. That's the opposite of what most people intend. Use `noindex` alone for pages you want deindexed; combine it with `nofollow` only if you also don't want link equity flowing through it.

Canonical tags are a strong hint, not a directive — Google can and does ignore them if other signals (internal links, sitemap entries, actual content differences) point elsewhere. Every page should self-canonicalize by default, including the canonical version itself. Parameter-driven URLs (`?sort=price`, `?utm_source=...`) remain, as of 2026, the most common source of accidental duplicate content that canonical tags exist to consolidate.

Google detects soft 404s heuristically — mostly-empty content, "sorry, nothing here" language, or a page pattern that matches known error templates. It's flagged separately from true 404s in Search Console's Page Indexing report and is treated just as harshly for crawl budget purposes. E-commerce sites hit this constantly with out-of-stock or discontinued product pages that stay live at 200 with no content.

These are field metrics measured from real Chrome users (via CrUX data), not lab scores — a page can look fast in Lighthouse and still fail Core Web Vitals in Search Console if real users on slow connections or older devices experience it differently. INP replaced FID (First Input Delay) in 2024 and, still the current metric in 2026, measures responsiveness across the entire page visit rather than just the first interaction — which made a lot of previously "passing" sites suddenly fail.

Crawl budget is mostly a concern for very large or rapidly changing sites — small sites rarely exhaust it. Google's own rough illustrative scale is roughly a million-plus pages for a site updating weekly, or around 10,000+ for a site updating daily; these are examples, not a universal size threshold that diagnoses a problem. It's shaped by two factors Google controls independently: crawl rate limit (how fast your server can handle requests without breaking) and crawl demand (how much Google actually wants to recrawl your content based on popularity and freshness). Faceted navigation, infinite parameter combinations, and calendar-style URLs remain the classic budget killers in 2026.

Googlebot renders JavaScript in a separate queue after initial crawling, using a headless Chromium, which means there can be a real delay — sometimes days — between a JS-heavy page being crawled and its rendered content being indexed. Other crawlers (many AI bots included) render JavaScript far less reliably or not at all, so client-side-only content can be invisible to them even when Google eventually sees it.

Thin content isn't purely about word count; a 200-word page can be substantive and a 2,000-word page can be thin if it's padded, templated, or says nothing a reader couldn't get elsewhere. Programmatic SEO pages (city+service combinations, auto-generated product variants) remain the most common large-scale source in 2026, and Google's Helpful Content system evaluates this at the site level, not just per-page.

Google has gotten better at treating 302s like 301s if the redirect persists over time, but that's a heuristic recovery, not a guarantee — using the correct status code from the start avoids relying on Google to correct your mistake. Redirects also don't transfer 100% of ranking signal instantly; there's typically a settling period of days to weeks as Google re-crawls and re-evaluates the destination.

Google doesn't apply a direct 'duplicate content penalty' in the way many assume — it simply has to choose one version to show for a query, and if it picks the wrong URL (or splits authority evenly across several), your intended page ranks worse than it should. Internal duplication is usually caused by URL parameters, HTTP/HTTPS or www/non-www variants, or printer-friendly versions all being crawlable and indexable separately.

Not all 404s need fixing — a genuinely removed product or expired event page returning a real 404 is the correct behavior, and Google handles isolated 404s without penalty. The actual risk is at scale: a spike in 404s from a broken migration, or high-value pages returning 404 because of a bug, both waste crawl budget and lose whatever link equity and rankings those URLs had built up.

Google states it can follow multiple redirect hops, but each additional hop increases the chance of signal loss and definitely increases page load latency, which matters for Core Web Vitals. Chains accumulate silently over time as sites migrate repeatedly (URL A → B during one redesign, then B → C during the next) without anyone updating the original A → C mapping directly.

Internal links are the most controllable ranking lever most sites underuse — unlike backlinks, you have complete control over anchor text, placement, and quantity, and Google explicitly uses internal link structure to understand which pages you consider most important. A page linked from dozens of relevant internal pages signals importance far more clearly than the same page sitting three clicks deep with one footer link.

Orphan pages can still get indexed and perform if Google finds them another way — a sitemap entry, an external backlink, or a known direct URL — but they receive no internal PageRank flow and are invisible to users actually navigating the site, which is a real usability and discoverability problem even when the page isn't doing badly in search. They accumulate naturally as sites redesign navigation, retire category pages, or migrate CMS platforms without auditing what used to link where — a very live risk for any site that's replatformed on its way into 2026.

A crawler can discover a URL through a link or a sitemap without having fetched it yet — in Search Console that shows up as "discovered" rather than crawled. A fetch doesn't guarantee indexing either; crawling, indexing, and ranking are three separate questions, and conflating them is the single most common misdiagnosis in indexing troubleshooting.

An excluded duplicate or an intentionally noindexed page can represent exactly the intended outcome, not a failure — the useful question for any important URL isn't "is my total indexed count as high as possible," it's "are my specific, intended canonical pages indexed." Review important URLs individually rather than chasing a total that includes URLs you never wanted in the index anyway.

A CMS setting or a page's visible HTML source won't necessarily reveal a server-level X-Robots-Tag header — it's set at the response level, so the only reliable way to check it is inspecting the actual GET response headers for the resource. A downloadable file can accidentally inherit a sitewide noindex header even though its HTML landing page is fully indexable.

A 200 response doesn't by itself mean the content is useful or indexable, and a page that visually reads "not found" while still returning 200 creates exactly the mismatch Google classifies as a soft 404. Inspect the final status after any redirects, not just the URL you originally requested — the two can tell very different stories.

Automated link checkers can also report a false positive when they hit an access control or a timeout, so a flagged link deserves a human check before you conclude the destination is genuinely gone. A public resource that redirects to a sign-in screen instead of the expected content is just as broken for a reader as a 404, even though a crawler might record it differently.

Not every filter combination deserves independent search visibility; the practical task is inventorying the actual parameter patterns a catalogue produces and deciding, deliberately, which filtered views are genuinely useful standalone destinations versus which exist purely to help on-site browsing. Google's current guidance favors purpose-built crawl controls over relying on canonical tags alone to manage unbounded combinations.

Language and regional alternatives generally need to reference each other reciprocally for the relationship to be understood correctly, and each version still needs its own accurate, complete content — hreflang pointing at a page is not a substitute for actually localizing it. Genuine translations of main content shouldn't be treated as ordinary same-language duplicates; same-language regional variants are a separate, narrower decision that needs to be reviewed alongside canonicalization.

Important content, links, metadata, and structured data all need to actually be present on the mobile version, since that's the version Google evaluates — a design pattern that hides explanatory content behind a tap on mobile, while showing it by default on desktop, can genuinely harm discovery even if the desktop experience looks complete.

The LCP element can be a block of text just as easily as an image — assuming it's always the hero image and reaching straight for image compression skips the step that actually matters: identifying the real element and which phase of its loading path (server response, resource discovery, transfer, or render) is dominating the delay. A smaller image file won't help if the real bottleneck is that the element stays hidden behind JavaScript until late in the page lifecycle.

INP reflects a near-worst interaction across the entire visit, not just the first one — which is exactly why sites that comfortably passed the old FID metric (measuring only initial input delay) can fail INP once later-visit interactions are counted. Long main-thread tasks — often from third-party scripts, large synchronous calculations, or excessive re-renders — are the usual cause, and diagnosing it needs an actual interaction trace in DevTools, not a load-time lab score.

CLS isn't just a loading-phase metric — a burst groups shifts within a short window and can happen well after initial load, when an ad refreshes, a widget opens, or a user scrolls into a late-loading embed. Movement that follows deliberate user input within a documented window is generally excluded from the score, but it can still be a bad experience worth fixing even when it doesn't count against the metric.

There's no fixed character count that guarantees a title will display in full — preview-tool pixel widths are layout guidance, not a ranking rule, and Google rewrites title links from on-page signals often enough that treating the `<title>` tag as the final, unchangeable word is a mistake. What does matter is giving each important page a descriptive title aligned with its actual visible heading.

Google frequently selects page text instead of the written meta description, depending on the query, so a meta description is best thought of as a strong suggestion rather than a guaranteed traffic lever. What it should actually do is describe what the page delivers specifically enough that a searcher can self-select — a generic description repeated across many pages wastes the opportunity entirely.

A clear, descriptive heading does more work than a keyword-stuffed one — repeating a target phrase in every heading isn't a substitute for an outline that actually makes sense when read on its own. The practical test: strip away all the body text and read just the headings in order; if they don't form a coherent outline, the underlying structure needs work before more content gets added.

Alt text should describe an image's purpose, not function as a place to stuff extra keywords — a purely decorative image generally warrants an empty alt attribute rather than a forced description. If an image carries essential instructions (an annotated screenshot in a tutorial, for instance), that information also needs to exist in the surrounding page text — the alt attribute shouldn't be asked to carry an entire explanation on its own.

Not all backlinks pass equal value: relevance to your topic, the linking domain's own authority, the link's placement (in-content vs. footer/sidebar), and whether it's followed or nofollowed all shape how much a link actually contributes. A single link from a topically relevant, trusted site regularly outperforms dozens of low-quality directory links combined.

100 links from a single domain carry a fraction of the weight of 10 links from 10 unique domains, because Google's algorithms discount repeated links from the same source to prevent easy manipulation. This is why link-building reports lead with referring domain growth, not raw backlink counts — a site can have 50,000 backlinks from 200 domains and be weaker than a site with 2,000 backlinks from 800 domains.

DA is not a Google ranking factor — Google has repeatedly confirmed it doesn't use any third-party authority score. It's a comparative, industry-standard proxy used for competitive benchmarking and prospecting, calculated via machine learning against Moz's own link index, which is a different (and smaller) index than Google's. Ahrefs' equivalent, still widely used in 2026, is Domain Rating (DR); the two scores are not directly comparable to each other.

The disavow tool is a last resort, not a routine maintenance task — Google's own algorithmic spam systems already discount most obviously toxic links automatically, so disavowing everything that looks spammy often does nothing except waste effort. Google's guidance frames it as appropriate when you have a substantial, genuinely problematic set of links AND an existing or likely manual action tied to them — after you've tried to get the links removed directly. Suspected sabotage alone, without that combination, isn't Google's documented bar for using it.

Manual actions require an active reconsideration request after cleanup — they do not lift on their own, unlike most algorithmic demotions, which can recover automatically once the underlying issue is fixed and Google recrawls. The reconsideration request needs to document what was found, what was done about it (removal outreach, disavow, or both), and prove the pattern won't recur.

True negative SEO is rarer than most site owners assume — a sudden ranking drop is far more often caused by an algorithm update, a technical regression, or a real (self-inflicted) link-quality issue. A spike in low-quality referring domains with spammy, unrelated anchor text is a lead worth investigating, not proof of an attack or evidence that damage occurred — plenty of sites get scraper-generated links with no measurable effect at all.

There's no universal 'safe' number of links per week — velocity is evaluated relative to a site's own history and its topical niche, so a viral piece of content earning 200 links in a day is normal for a large publisher and a red flag for a brand-new site with zero prior link history. Sudden drops in velocity matter too, often signaling a paid link scheme that got shut off.

Natural anchor text profiles are dominated by branded terms ("SEOdisaster"), naked URLs, and generic phrases ("click here", "this guide") — exact-match keyword anchors ("buy cheap running shoes") should be a small minority of a healthy link profile, not the majority. Google's Penguin algorithm, still enforced as part of the core ranking system in 2026, specifically targets over-optimized anchor text distributions as a spam signal.

PBNs work by exploiting an expired domain's residual backlink profile and trust — the buyer republishes content on it and links out to their target site, hoping the old domain's authority passes through. Google actively hunts for PBN footprints: shared hosting IPs, identical WHOIS/registration patterns, matching CMS templates, and thin or repurposed content across the 'network' are the classic tells.

Google's algorithmic systems already discount the vast majority of toxic links automatically — they simply don't count, rather than actively hurting you, in most cases. Toxic links become a real problem specifically when they're part of a pattern severe enough to trigger a manual action, or when a link-quality tool's 'toxicity score' is used as a blunt, non-contextual filter for the disavow tool.

DR reflects link-profile strength specifically, not overall content quality or a promise that every page on the domain will rank — a site with a high DR can still have a thin, poorly maintained page that has no chance of ranking for its target query. If you use DR, compare similar sites within the same tool and record the measurement date rather than treating the number as a fixed, portable score.

Current page-level PageRank values aren't publicly available as a toolbar score the way they once were, which is part of why "link equity" gets used loosely — it's a useful mental model for why internal and external linking matter, not a number you can audit directly. Treat it as a reason to maintain sensible URL relationships during migrations and to link generously to pages that deserve it, not as a precise currency to budget.

Google treats link qualification attributes as hints, not absolute commands — nofollow doesn't guarantee a destination won't be found or indexed through another route entirely. It's most appropriate for links to sources you're discussing but not vouching for; Google's guidance also accepts it as one valid option for paid or user-generated links alongside the more specific `sponsored` and `ugc` attributes.

The attribute addresses the relationship with search engines; it's separate from (and doesn't replace) a visible disclosure to your actual human readers that a placement is paid, which may also be a legal requirement depending on jurisdiction. Review paid banners, affiliate placements, and compensated articles specifically for whether the link relationship is correctly qualified.

The ugc attribute tells Google the link came from a user, not the publisher, which is useful context for a comments section or forum where moderation can't catch everything instantly. It doesn't replace moderation, and it doesn't make a spam link to a malicious destination any less of a problem for the people who click it — the attribute is about signaling provenance to search engines, not safety to readers.

Schema markup doesn't directly improve rankings — it improves eligibility for supported rich results and gives search engines (and increasingly, LLMs doing retrieval) an unambiguous, machine-readable description of page content instead of forcing them to infer it from prose. Google's Rich Results Test validates syntax and feature-specific requirements, but valid markup never guarantees display — Google discontinued the FAQ rich result entirely as of May 2026, which is a useful reminder that feature support changes and markup for a retired feature won't bring it back.

Google has understood entities separately from keywords since the 2012 Knowledge Graph launch — 'Paris' the city and 'Paris' the person are different entities with different attributes, and Google resolves ambiguous queries by matching context to the correct entity, not just the string. Entity SEO means building clear, consistent, structured signals — schema markup, Wikidata/Wikipedia presence, consistent naming — that help Google resolve your brand or topic to a specific, well-defined entity, a discipline that's only grown more central heading into 2026.

Topical authority compounds at the site level, not the page level — a single excellent article rarely outranks a mediocre article on a site that has demonstrated deep, sustained coverage of the surrounding topic space through internal linking and breadth of related content. This is why content strategists build 'pillar + cluster' structures deliberately, rather than publishing isolated posts chasing individual keywords.

The Knowledge Graph is populated from structured sources (Wikidata, Wikipedia, verified business data) combined with Google's own web-scale entity extraction — there's no direct submission form for most entity types. A knowledge panel appearing for your brand name is a strong trust signal, since Google is confident enough in the entity resolution to surface it directly in the SERP rather than just linking to your site.

E-E-A-T is not a single score Google's algorithm directly assigns to a page — it's a framework in Google's Search Quality Rater Guidelines that human raters use to evaluate search result quality, which in turn helps evaluate and validate the ranking systems rather than ranking any individual page itself. The 'Experience' component, added in 2022, specifically asks whether content reflects first-hand, demonstrated experience — a product review from someone who actually used the product reads as more credible than a rewritten spec sheet, all else equal.

The pillar page covers a broad topic comprehensively and links out to narrower cluster pages, which link back to the pillar and often to each other — this reciprocal linking structure is what distinguishes a real cluster from a random collection of related posts. Done well, it also directly serves user needs: someone reading the pillar can drill into exactly the sub-topic they care about without leaving the site's information architecture.

Start the diagnosis in Search Console by checking if multiple URLs from your own site rank (even alternately) for the same query — that's a clue worth investigating, not proof of harm on its own; the two pages might simply serve different sub-intents and both be earning useful traffic. Confirm overlapping purpose and an actual detrimental outcome (split clicks, inconsistent ranking, conflicting content) before treating it as a problem. Where it's real, it's resolved either by merging the weaker page into the stronger one (301 redirect) or clearly differentiating their intents if both genuinely deserve to exist.

Search intent is the single strongest predictor of ranking content format: Google's own SERP is the fastest way to reverse-engineer it — if a query returns product pages, write a product page; if it returns comparison articles, a product page won't outrank them no matter how well-optimized it is. In 2026, with AI Overviews now occupying part of many SERPs, intent-matching also has to account for whether a query gets fully answered on-page or genuinely needs a click-through.

Schema.org recognizing a given type doesn't mean Google offers a search feature for it, and Google can discontinue support for a previously available rich result without warning — it retired the FAQ rich result entirely as of May 2026. Confirm current feature documentation before investing implementation effort chasing a specific visual benefit.

GSC is not interchangeable with an analytics platform that measures what happens after a visitor arrives — it answers "how does Google see and treat my site," while an analytics tool answers "what did visitors do once they got here." Combining query-level GSC evidence with on-site outcome data is usually necessary to tell a complete story; neither tool alone gives the full picture.

CTR depends heavily on context — query type, ranking position, which SERP features are present, and device — so a single sitewide CTR target can be actively misleading when applied uniformly. Before concluding that a title or description change hurt CTR, check whether the page's impressions simply expanded into new, broader queries that naturally click less often; that's a different story from the page itself getting less appealing.

Different search features get counted under different rules, so comparing impression totals across reports requires confirming they're measuring the same thing — feature, aggregation level (property vs. page), and date range all need to match before a comparison is meaningful. A page can gain impressions across many new queries without gaining a proportional share of clicks, which on its own isn't a failure.

A page newly appearing for many less-established queries can show a worse average position even while its total visibility is genuinely growing — the metric blends everything together, so a single sitewide number can mask real, positive movement happening underneath it. Segment by query, page, device, and country, and check actual results and conversions, before declaring success or failure from this one number.

The indexed view and the live test answer two different questions — one describes what Google has stored from an earlier crawl, the other checks the page right now. Removing an accidental noindex tag today and immediately running a live test will show the fix working, while the stored indexed view can still reflect the prior crawl until Google processes the page again; that gap isn't evidence the fix failed.

AI Overviews are generated via a retrieval-then-synthesis process — Google retrieves and grounds the answer in a set of web sources (often several, not just the #1 result), then writes a synthesized summary citing them. Being cited in the AIO is a trust signal but frequently reduces click-through, since a well-written overview answers the query directly without requiring a visit — this is the core tension GEO exists to address, and by 2026 it's arguably the single biggest shift in how SERP real estate works.

GEO shares foundations with classic SEO (crawlability, authority, relevance) but adds a distinct layer: content needs to be extractable as a clean, self-contained, directly quotable answer, since generative engines lift and synthesize passages rather than sending users to browse a full page. Clear headings that mirror actual questions, direct-answer-first paragraphs, and unambiguous entity references all measurably improve citation likelihood — and heading into 2026, this is no longer an experimental discipline, it's table stakes.

Zero-click rates vary enormously by query type — simple factual and definitional queries ('what is X') are answered on-SERP at very high rates, while complex, comparative, or transactional queries still drive real click-throughs because no on-page summary can substitute for the actual decision-making content. Treat any specific sitewide zero-click percentage you read with skepticism unless it's dated and tied to a disclosed methodology — the behavior predates generative AI and varies by niche, device, and query type far more than any single headline number suggests.

Citation happens through two distinct mechanisms that require different strategies: presence in a model's training data (static, hard to influence directly, tied to historical content quality and reach) and live retrieval at query time (dynamic, tied to current crawlability, structured data, and how well content matches the query's sub-questions). Most consumer-facing AI search products in 2026 rely primarily on live retrieval, not training-data recall.

Unlike traditional rank tracking, AI share of voice has to be measured by running a representative sample of real queries against each AI platform (Google AIO, ChatGPT, Perplexity, Gemini) and logging whether and how your brand appears — there's no single API that reports this the way Search Console reports rankings, even in 2026. Results also vary by platform, since each uses different retrieval sources and training cutoffs.

BOFU content resists zero-click and AI summarization better because the value isn't purely informational — it's judgment, comparison, and a path to conversion that a generic AI summary can't fully replace. A 'how to fix X' query is easily and completely answered in three AI-generated sentences; 'which tool is best for X, and should I buy it' requires nuance, current pricing, and trust that pushes users to click through.

Featured snippets are pulled from pages already ranking in the top 10, extracted algorithmically from content structured as a direct, self-contained answer — usually a concise paragraph, a numbered/bulleted list, or a table immediately following the matching question as a heading. Winning one can increase visibility even at position 2 or 3, since the snippet effectively promotes that result above position 1 visually — though in 2026 it increasingly competes for the same screen space as AI Overviews rather than standing alone.

AEO and GEO overlap heavily and are often used interchangeably, but the emerging distinction is scope: GEO is typically framed around optimizing individual content for citation within generative search results, while AEO is framed more broadly around brand-level presence and mentions across the whole AI answer ecosystem — chatbots, voice assistants, and search all included. Both require the same underlying work: clear entity signals, extractable direct answers, and structured data.

Rather than treating a prompt as one keyword lookup, systems like Google's AI Mode explicitly issue several parallel, more specific searches — a query about 'best running shoes for flat feet' might fan out into sub-searches on arch support, pronation, specific shoe models, and injury prevention — then ground the synthesized answer across all of those retrieved results. Content that anticipates and directly answers those implicit sub-questions is more likely to be pulled into the final synthesis.

AI Mode can use related searches and a multi-step reasoning process to build an answer, and its responses and cited sources need not match either an AI Overview or the regular organic results for the same question. Visibility here is harder to track than conventional rankings precisely because the output isn't a stable, repeatable list — the same question can surface different sources depending on phrasing and session context.

Google's own current guidance states that Search does not use llms.txt files to improve or reduce a site's rankings — publishing one is about curating a resource list for whichever specific systems actually consume it, and that set of consumers is still narrow and evolving. Identify an actual consumer before investing meaningful effort; a well-maintained sitemap and genuinely crawlable content matter far more right now.

OpenAI, for instance, documents separate bots for different roles: OAI-SearchBot for search, GPTBot for potential training use, and ChatGPT-User for certain user-triggered visits — disallowing one in robots.txt does not automatically disallow the others. Treat each provider's documentation and your actual access logs (including any CDN-level rules) as the source of truth, rather than assuming every AI-associated bot behaves the same way or serves the same purpose.

Retrieval lets a system incorporate recent or specialized information without requiring it to be baked into model parameters, but it doesn't guarantee perfect interpretation of the retrieved source or eliminate unsupported claims in the generated answer — grounding reduces certain kinds of error, it doesn't remove the need to verify output. Keeping source pages clear, accurate, and genuinely verifiable is what makes a page useful to a RAG system in the first place.

The report groups impressions by dimensions like page, country, device, and date, giving a site-specific view of which URLs gain visibility inside Google's own generative features specifically — it says nothing about ChatGPT, Perplexity, or other platforms, which need to be measured separately if you care about them. Confirm there's enough data for the report's counting rules to be meaningful before drawing conclusions from a small sample.

The current documented scope includes AI Overviews, AI Mode, and generative features in Discover, with inclusion as the default, subject to property-level inheritance rules. This is a narrower, more specific lever than noindex — an owner can exclude a property from these particular generative features without removing its pages from ordinary Search results altogether.