# SEO Madman - full corpus > Technical SEO news, original research, studies and free tools for search and AI answer engines, by Adam Hafez. Generated: 2026-09-12T17:06:06.768Z Entries: 116 --- --- title: "Google documents its EEA-only aggregator and supplier units" url: https://seomadman.com/news/search-central-eea-aggregator-features section: news published: 2026-09-12T00:00:00.000Z modified: 2026-09-12T00:00:00.000Z author: Adam Hafez topics: ["Structured data", "Technical SEO"] --- # Google documents its EEA-only aggregator and supplier units ## The short answer Google's Search Central changelog logged one entry for September 2026, dated 8 September: new documentation for regional search features called aggregator units, supplier units and structured data carousels. Aggregator and supplier units are EEA-only and cover hotels, flights, ground transportation and products. Carousels also run in South Africa and Turkiye and require structured data markup to qualify. ## Key takeaways - The September 2026 Search Central changelog contains exactly one entry, published 8 September, documenting regional search features. - Aggregator units and supplier units appear only in the European Economic Area, across hotel, flight, ground transportation and product queries. - Structured data carousels run in the EEA, South Africa and Turkiye, with the query types varying by region. - Google states a site must implement structured data markup to be eligible for a carousel; the page does not list which schema types satisfy that requirement. - Neither aggregator nor supplier units carry a published eligibility list beyond appearing exclusively inside the EEA. The September 2026 Search Central changelog has one entry. Dated 8 September, it adds documentation for three region-specific search result formats: aggregator units, supplier units and structured data carousels. None of them are new to Google Search; what changed is that Google now writes down where each one appears and what a page needs to show up in one. ## What the three formats are **Aggregator unit.** Google's own description: "a unit that provides visibility for ecosystem participants (aggregators) on the search results page." It appears only inside the European Economic Area, on hotel, flight, ground transportation and product queries. **Supplier unit.** The counterpart aimed at direct suppliers rather than aggregators, using the same wording pattern: "a unit that provides visibility for ecosystem participants (direct suppliers) on the search results page." Same region, same four query types. **Structured data carousel.** Google calls it "a list-like rich result that people can scroll horizontally to see entities from a given site," also known as a host carousel. This one has the widest reach: the EEA (hotels, local businesses, things to do, products, ground transportation, flights, vacation rentals), South Africa (hotels, things to do, flights, products, food delivery, car hire, vacation rentals, ground transportation) and Turkiye (hotels, local businesses, vacation rentals). ## What the documentation does not say Google states that a carousel requires structured data markup, without naming which schema types satisfy the requirement on this particular page; it links out to the general [carousel documentation](/topics/structured-data) instead of listing types inline. Aggregator and supplier units carry no published eligibility criteria at all beyond the EEA-only scope. For a publisher or aggregator trying to qualify, the practical next step is the linked carousel reference and existing [Merchant Center](/topics/technical-seo) or travel structured data guides, not this changelog entry by itself. ## Why we care This is a documentation update, not an algorithm change, and Google's own changelog treats it that way: no ranking signal, no new markup requirement, no rollout date attached. The reason it matters regardless is regulatory geography. Aggregator and supplier units exist because the EEA's Digital Markets Act pushes Google toward giving third-party aggregators comparable visibility to Google's own verticals, and a site operating in Europe, South Africa or Turkiye now has a citable Google source describing exactly which query types and regions those formats touch, something that previously lived only in scattered support threads and observation. ## Frequently asked questions ### What is an aggregator unit? Google describes it as "a unit that provides visibility for ecosystem participants (aggregators) on the search results page," shown only in the European Economic Area for hotel, flight, ground transportation and product queries. ### Is this new functionality or new documentation? The changelog entry is documentation, not a feature launch. Google is documenting result formats and eligibility criteria that were not previously written up on Search Central, not announcing something newly built. ### Do these formats apply outside the EEA? Aggregator and supplier units are EEA-only. Carousels run in the EEA plus South Africa and Turkiye, with the specific query types differing by region. ## Sources 1. [Search Central changelog: Added documentation about regional differences in Search experience](https://developers.google.com/search/updates) - Google Search Central (primary) 2. [Regional differences in Search experience](https://developers.google.com/search/docs/appearance/aggregator-features) - Google Search Central (primary) --- --- title: "JSON-LD syntax and required-field validator" url: https://seomadman.com/tools/json-ld-validator section: tools published: 2026-09-11T00:00:00.000Z modified: 2026-09-11T00:00:00.000Z author: Adam Hafez topics: ["Structured data"] --- # JSON-LD syntax and required-field validator ## The short answer This validator checks a pasted JSON-LD block for syntax errors, reporting the exact line and column where JSON.parse fails, then checks the detected @type against the required and recommended properties Google actually documents for Article, Product, FAQPage, HowTo, Organization, BreadcrumbList and Recipe, flagging the two types Google no longer rewards with a rich result. ## Key takeaways - A JSON syntax error is reported with its exact line and column instead of a generic parse failure. - Google states no properties are strictly required for Article or Organization, only recommended ones. - FAQPage and HowTo no longer earn a rich result in Google Search even when the markup is valid. - Every required and recommended property list here comes from Google's own structured data documentation, not from the schema.org specification. ## What this checks The validator runs two passes. The first is a strict `JSON.parse` of whatever is in the textarea; a syntax error is shown with the line and column `JSON.parse` reports, rather than a bare "Unexpected token" with no location. The second pass only runs on valid JSON: it looks for `@context` and warns if it is missing or not schema.org, looks for `@type`, and if that type is one of the seven this tool covers, lists which of Google's documented properties for that type are present and which are missing. The required and recommended property lists come from Google's structured data documentation pages, fetched directly for this build rather than recalled from memory or copied from the schema.org spec, which is broader than what Google actually rewards. Product, BreadcrumbList and Recipe carry genuine required properties; Article and Organization do not, by Google's own statement, so a missing recommended property is shown as a warning rather than a failure. ## What this cannot check Structural validity is not the same as search eligibility. The tool cannot see the live page, so it cannot confirm that a `headline` matches the visible heading, that a `datePublished` is accurate, or that an `aggregateRating` reflects reviews a visitor can actually find. Markup that asserts something the page does not show is a policy violation regardless of how clean the property list looks here. Two of the seven types are flagged rather than passed cleanly: Google removed the FAQ rich result from Search on 7 May 2026 and the HowTo rich result in September 2023. Both remain valid schema.org types and this tool still checks their structure, but neither produces a rich result in Google Search any more, and the validator says so directly instead of implying otherwise. ## Using the result Fix syntax errors before reading anything else; a broken parse means every downstream check is skipped. Once the JSON is valid, treat a "missing (required)" line as something to fix before shipping the block, and a "missing (recommended)" line as a judgment call tied to what the page actually contains. Confirm the final result with Google's Rich Results Test on the live URL, since that tool also checks eligibility rules this one does not attempt to replicate. ## Frequently asked questions ### Does a clean result mean the page is eligible for a rich result? It means the pasted block is syntactically valid and carries the properties Google documents for that type. Eligibility also depends on site policies, content quality and, for FAQPage and HowTo, a rich result that no longer exists at all. ### Why does Article show nothing as strictly required? Because Google's own documentation says so. Article lists headline, image, author, datePublished and dateModified as recommended, not required, so the validator marks a missing one as a warning rather than a failure. ### Which types does this check today? Article, Product, FAQPage, HowTo, Organization, BreadcrumbList and Recipe. Pasting a different @type still gets the syntax and @context checks, with a note that no property table exists for it yet. ## Sources 1. [Understand how structured data works](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data) - Google Search Central (primary) 2. [Article, NewsArticle, BlogPosting structured data](https://developers.google.com/search/docs/appearance/structured-data/article) - Google Search Central 3. [Product snippet structured data](https://developers.google.com/search/docs/appearance/structured-data/product-snippet) - Google Search Central --- --- title: "Google splits site reputation enforcement along the EEA border" url: https://seomadman.com/news/site-reputation-policy-eea-split section: news published: 2026-09-10T00:00:00.000Z modified: 2026-09-10T00:00:00.000Z author: Adam Hafez topics: ["Core updates", "Content strategy"] --- # Google splits site reputation enforcement along the EEA border ## The short answer From 30 August 2026, a manual action under Google's site reputation policy applies only to searchers outside the European Economic Area. Inside the EEA the penalty is not applied; Google says the affected section may instead be separated in its systems so that it ranks independently of the host domain over time. ## Key takeaways - Google announced on 28 August 2026 that site reputation manual actions take effect differently inside and outside the European Economic Area from 30 August. - Outside the EEA nothing changes: the manual action suppresses the affected portion of the site, and the rest of the domain is untouched. - Inside the EEA the manual action is not applied, and Google says the affected section may be separated in its systems so it ranks on its own merit rather than the host's. - Google attributes the change to discussion with the European Commission and states its concern that an overbroad reading of the DMA would block enforcement. - Search Console still reports the manual action, reconsideration requests still exist, and eligible sites can now take a dispute to mediation. Google has changed how it enforces the site reputation policy, and the change is geographic, not editorial. In a post dated 28 August 2026, the Search Quality team said that from 30 August, a manual action under the policy has one effect for searchers outside the European Economic Area and a different one for searchers inside it. ## What changed on 30 August **Outside the EEA, nothing is different.** A manual action still suppresses the portion of the site it was issued against; Google repeats that "the rest of the site won't be affected." **Inside the EEA, the penalty does not apply.** Instead, "the affected section of the site may be separated in our systems so that, over time, it ranks independently from the rest of the site." That is not the same mechanism: one is a penalty, the other removes an inherited advantage, so the subfolder stops borrowing the host domain's signal and has to earn its own position. ## Why a search policy is being drawn on a map **Google names the European Commission directly.** It attributes the split to "discussion with the European Commission" and states its own objection plainly: it remains concerned that "an overbroad application of the DMA could prevent us from addressing real threats to the integrity of our search results." **The underlying policy dates from 2024,** introduced to stop third-party content published on a trusted host purely to exploit that host's reputation: coupon subfolders on newspaper domains, casino reviews under university sites, licensed sections that exist only because the host ranks. ## What a site owner should do **Detection has not changed.** Google says site owners "will continue to be notified within Search Console when a manual action is applied," the same path you already watch. **The appeal path grew.** Reconsideration requests continue, and eligible sites now get the opportunity to bring disputes to mediation after one. **Measurement got harder for EEA-heavy sites.** Google notes "any given page might have a manual action taken on it, but that change will only affect search results shown to users outside the EEA." If your traffic concentrates in Europe, enforcement that would be obvious in a US-heavy export can be nearly invisible in yours. ## Why we care Split Search Console by country before diagnosing anything. A drop confined to non-EEA countries on a specific subfolder, with the rest of the domain flat, is this change's signature - and an EEA-only pattern is not evidence you escaped, since separation is gradual by design and shows up as a subfolder that stops outperforming its own content quality, not as a cliff. The decision this forces is editorial as much as technical: whether a section of your domain would survive on its own if it stopped inheriting the reputation of the masthead above it. ## Frequently asked questions ### Does this mean site reputation abuse is allowed in Europe now? No. The policy still applies and the manual action is still issued. What changes is the effect: for searchers inside the EEA the action is not applied to results, and Google says the affected section may instead be separated in its systems so it ranks independently of the host domain. ### Will Search Console still tell me if I am penalised? Yes. Google states that site owners continue to be notified in Search Console when a manual action is applied, regardless of which side of the border the effect lands on. ### What is new about mediation? Google says eligible sites will, following a reconsideration request, also have the opportunity to bring disputes to mediation. That is an escalation path that did not previously exist for this policy. ## Sources 1. [Update to the Site Reputation Policy](https://developers.google.com/search/blog/2026/08/update-site-reputation-policy) - Google Search Central (primary) 2. [Site reputation abuse policy](https://developers.google.com/search/docs/essentials/spam-policies) - Google Search Central (primary) --- --- title: "Every confirmed Google ranking update since December 2025" url: https://seomadman.com/reports/google-ranking-updates-2026 section: reports published: 2026-09-10T00:00:00.000Z modified: 2026-09-10T00:00:00.000Z author: Adam Hafez topics: ["Core updates", "Search Console"] --- # Every confirmed Google ranking update since December 2025 ## The short answer Google has confirmed eight ranking updates since December 2025, six of them in 2026. Core updates in that set averaged 14 days to roll out and spam updates 8 days, so a judgement made in the first week of any of them was made before the rollout that caused the movement had finished. ## Key takeaways - Google's Search Status Dashboard lists eight confirmed ranking updates between 11 December 2025 and 18 August 2026. - Core updates in that set took an average of 14 days to complete, ranging from 11 days 21 hours to 18 days 2 hours. - Spam updates were faster but far less consistent, from 19 hours 30 minutes in March 2026 to 26 days 15 hours in August 2025. - The February 2026 Discover update ran 21 days 17 hours, the longest rollout of the period, and it targeted Discover rather than web results. - No core update has been confirmed since 21 May 2026, the longest gap between core updates in this record. Most arguments about a traffic drop are arguments about dates. This is the record, as Google publishes it, with nothing added: eight confirmed ranking updates between December 2025 and September 2026. ## The confirmed record | Update | Type | Started | Google's stated duration | | --- | --- | --- | --- | | August 2026 spam update | Spam | 18 Aug 2026 | 2 days, 16 hours | | June 2026 spam update | Spam | 24 Jun 2026 | 2 days, 1 hour | | May 2026 core update | Core | 21 May 2026 | 11 days, 21 hours | | March 2026 core update | Core | 27 Mar 2026 | 12 days, 4 hours | | March 2026 spam update | Spam | 24 Mar 2026 | 19 hours, 30 minutes | | February 2026 Discover update | Discover | 5 Feb 2026 | 21 days, 17 hours | | December 2025 core update | Core | 11 Dec 2025 | 18 days, 2 hours | | August 2025 spam update | Spam | 26 Aug 2025 | 26 days, 15 hours | The same table is published as [JSON](https://seomadman.com/data/ranking-updates.json) with the durations expressed in hours, so you can join it against your own analytics export instead of retyping it. ## What the durations tell you **Core updates cluster.** The three in this record took 11 days 21 hours, 12 days 4 hours and 18 days 2 hours, an average of about 14 days. When one starts, assume a fortnight of movement rather than guessing. **Spam updates do not cluster at all.** March 2026 finished in under 20 hours; August 2025 took more than 26 days. The 8-day average describes nothing you would plan around - spam updates vary with what is being enforced, not with a fixed process. **The longest rollout is the most misread one.** February 2026's Discover update ran 21 days 17 hours and touched Discover only. A site whose Discover traffic moved that month while web rankings held steady was not experiencing a partial core update. ## The gap nobody has explained **No core update has been confirmed since 21 May 2026.** As of 10 September that is the longest interval between confirmed core updates in this record, filled with the usual industry conversation about unconfirmed volatility. **Google confirms what it confirms.** Volatility trackers measure something real, but a proxy, and attaching "unconfirmed update" to a week of movement is a hypothesis, not a finding. If your traffic changed outside every window in the table above, the first suspect is your site or your market, not an update nobody can name. ## Why we care Export daily clicks and impressions from [Search Console](/topics/search-console) for a window starting at least a week before an update began and ending a week after it completed, then check which surface moved. A shift confined to Discover, to news carousels or to a single country is evidence about that surface, and the table above tells you which updates were even capable of producing it - the difference between diagnosing [core update](/topics/core-updates) damage and assuming it. ## Frequently asked questions ### How long should I wait before judging a core update? Until the dashboard marks the rollout complete, then long enough for your own data to stabilise after it. Core updates in this record averaged 14 days end to end, so a verdict formed on day three is a verdict about a partial rollout. ### Why does this table not include the updates everyone discussed but Google never confirmed? Because the value of the table is that every row can be checked against Google's own dashboard. Unconfirmed volatility is real, but it belongs in a volatility tracker, not in a record of confirmed updates. ### Is a long rollout a sign of a bigger change? Nothing in this data supports that. The longest rollout in the period, at 21 days 17 hours, was the February 2026 Discover update, which affected a single surface rather than web ranking as a whole. ## Sources 1. [Google Search Status Dashboard](https://status.search.google.com/summary) - Google (primary) 2. [Google Search ranking updates documentation](https://developers.google.com/search/updates/ranking) - Google Search Central (primary) 3. [Dataset: confirmed ranking updates (this report)](https://seomadman.com/data/ranking-updates.json) - SEO Madman (primary) --- --- title: "Who blocks AI crawlers: 60 robots.txt files, read in full" url: https://seomadman.com/research/ai-crawler-policies-news-sites section: research published: 2026-09-10T00:00:00.000Z modified: 2026-09-10T00:00:00.000Z author: Adam Hafez topics: ["AI search", "Technical SEO", "Indexing"] --- # Who blocks AI crawlers: 60 robots.txt files, read in full ## The short answer We fetched robots.txt from 60 publishers and SEO vendors on 10 September 2026. Of 28 reachable news publishers, 24 block at least one named AI crawler. Of 15 SEO trade sites, 2 do. The industry that publishes most about AI search is the one leaving it most open. ## Key takeaways - Of 57 sites with a reachable robots.txt, 33 name at least one AI crawler and 29 block at least one outright. - News publishers block almost as a rule: 24 of 28 reachable ones disallow a named AI agent across the whole site. - SEO trade publications behave in the opposite way, with only 2 of 15 blocking any AI crawler by name. - ClaudeBot and Bytespider are the most blocked agents at 27 sites each, followed by CCBot at 25 and Applebot-Extended at 24. - Almost nobody separates training from retrieval: 9 sites block both GPTBot and OAI-SearchBot, and only Forbes blocks the training agent while leaving the search agent through. Every publisher in this sample has had two years to decide what to do about AI crawlers. On 10 September 2026 we asked all 60 of them the same question, in the only place the answer is written down: robots.txt. ## What we did **One request per site, parsed by the rules.** A single GET of `/robots.txt`, grouped the way [RFC 9309](https://www.rfc-editor.org/rfc/rfc9309.html) defines it, then one question per agent: does a group naming this crawler disallow the whole site. Fifteen agents checked, from GPTBot and ClaudeBot to Bytespider and Applebot-Extended. **Fifty-seven of sixty files were readable.** Politico (403), NPR (connection failure) and Stack Overflow (418) are excluded from the denominators, not quietly counted as open. The full per-site result is published as [JSON](https://seomadman.com/data/ai-crawler-policies.json), so every number below can be checked against the file it came from. ## What the files say **Twenty-nine of 57 sites block at least one named AI crawler site-wide.** Thirty-three name at least one, so a handful name agents only to allow them, or to restrict them to part of the site. **The most-blocked agents cluster near the top.** ClaudeBot and Bytespider are each blocked by 27 sites, CCBot by 25, Applebot-Extended by 24, PerplexityBot by 22. GPTBot, the name that gets the most attention, sits lower at 17 blocks from 24 sites that name it. **Google-Extended is the outlier.** Twenty sites name it, 16 block it - the only training-related agent with a meaningful gap between being noticed and being refused. It shares infrastructure with Search traffic, and publishers have accepted terms from Google for two decades that they refuse from anyone else. ## The finding worth arguing about **Split by who runs the site and the picture stops being a spectrum.** Of 28 reachable news publishers, 24 block at least one AI crawler, including the New York Times, the Washington Post, the Guardian, the BBC, AP, Bloomberg, the FT, CNN, Wired, Ars Technica, the Economist and Nature. **Of 15 SEO trade sites, 2 do.** Search Engine Land, Search Engine Journal, Search Engine Roundtable, Moz, Ahrefs, Semrush, Yoast, SEOPress, Screaming Frog, Sistrix, Conductor and BrightEdge all leave every named AI agent free to take the whole site. The industry that publishes the most words about AI search is the industry least likely to withhold its own text from it - a coherent strategy for a vendor selling software, and a harder one to defend from an industry advising publishers on a trade it has not made itself. ## The distinction almost nobody is drawing **OpenAI separates training from retrieval; almost no one uses that.** GPTBot collects training data, OAI-SearchBot handles search retrieval, ChatGPT-User fetches what a person asked for - a publisher can decline training while staying citable in answers. Nine sites in this sample block both anyway. One, Forbes, blocks GPTBot and lets OAI-SearchBot through. OAI-SearchBot is named by only 13 sites at all, against 24 for GPTBot. ## Why we care If your robots.txt blocks both a training agent and its matching retrieval agent, confirm that is what you meant. The cost is not paid in training corpora, already assembled either way - it is paid in the retrieval layer that decides which sources an answer cites this week, a live traffic question in [AI search](/topics/ai-search). Read your file, not your memory of it, decide the training and retrieval questions separately, and record the decision somewhere a colleague will find it two years from now. ## Frequently asked questions ### Does blocking GPTBot remove my site from ChatGPT? Not by itself. GPTBot is the crawler associated with training data collection, while OAI-SearchBot and ChatGPT-User relate to search retrieval and user-initiated fetches. In this sample 9 sites block both and only one blocks the training agent alone, which means most sites making the block are making a broader decision than they may realise. ### Why measure only site-wide blocks? Because a partial rule is a judgement call and a site-wide disallow is not. Counting "Disallow: /" under a named agent produces a number anyone can reproduce from the same file, which is the point of publishing the dataset next to the finding. ### Can I check your numbers? Yes. The full per-site dataset, including the raw decision for every agent on every host, is published as JSON at the link in this article, with the collection timestamp inside it. ## Sources 1. [Dataset: AI crawler policies across 60 sites (this study)](https://seomadman.com/data/ai-crawler-policies.json) - SEO Madman (primary) 2. [RFC 9309: Robots Exclusion Protocol](https://www.rfc-editor.org/rfc/rfc9309.html) - IETF (primary) 3. [Google-Extended and Search crawler documentation](https://developers.google.com/search/docs/crawling-indexing/overview-google-crawlers) - Google Search Central (primary) --- --- title: "llms.txt is a vendor standard, not a publisher one" url: https://seomadman.com/studies/llms-txt-adoption-2026 section: studies published: 2026-09-10T00:00:00.000Z modified: 2026-09-10T00:00:00.000Z author: Adam Hafez topics: ["AI search", "Technical SEO"] --- # llms.txt is a vendor standard, not a publisher one ## The short answer We requested /llms.txt from 60 major sites on 10 September 2026. Fourteen served a real file. Seven of those are SEO or marketing vendors and only one is a news publisher, so adoption is concentrated in the companies that sell tooling rather than the ones whose content answer engines actually quote. ## Key takeaways - Fourteen of 60 sites served a valid llms.txt, meaning a 200 response with text content rather than an HTML error page. - Seven of the 14 are SEO or marketing vendors, including Semrush, Yoast, SEOPress, Onely, Conductor, BrightEdge and HubSpot. - Only one of 30 news publishers in the sample serves one, which is Time. - Developer platforms are the other adopter group, with Cloudflare, Vercel, GitHub, Shopify and WordPress.org all serving a file. - No search engine has committed to reading llms.txt, so today the file is a publishing convention rather than a ranking or retrieval input. The llms.txt proposal asks a site to publish a plain-text map of its most useful pages for language models, in the spirit of robots.txt or sitemap.xml. Two years of conference slides later, the useful question is not whether it is a good idea. It is who actually put the file on their server. ## What we measured **One request per site, counted strictly.** `/llms.txt` on each of 60 major sites, 10 September 2026, alongside the robots.txt crawl published in our [AI crawler research](/research/ai-crawler-policies-news-sites). A file counted only if the response was 200, the content type was not HTML, and the body was not empty - a large share of sites answer any unknown path with a styled 404 under a 200 status, and counting those would have roughly doubled the result. The per-site outcome sits in the same [JSON dataset](https://seomadman.com/data/ai-crawler-policies.json). ## Who serves one **Fourteen sites of sixty.** Seven sell SEO, marketing or optimisation software: Semrush, Yoast, SEOPress, Onely, Conductor, BrightEdge and HubSpot. Five are developer or commerce platforms: Cloudflare, Vercel, GitHub, Shopify and WordPress.org. One is a trade publication, Search Engine Land. One is a news publisher, Time. **Twenty-nine of 30 news publishers serve nothing at that path**, including every outlet with a licensing deal or a lawsuit in progress. ## Why the split makes sense **The adopters share a product shape, not a sophistication level.** Every organisation on the list has documentation as a product surface - an API reference, a plugin manual, a help centre. A file that says "here are the canonical explanations, in order" costs an afternoon and matches something they already maintain. **A newspaper has no equivalent artifact.** Its corpus is thousands of dated articles with no stable hierarchy, and the commercial instinct of the last two years has been to withhold that corpus rather than index it more helpfully for machines. Our robots.txt crawl found 24 of 28 reachable news publishers blocking at least one AI crawler outright - a site trying to keep models out has no reason to hand them a table of contents. ## Why we care **If you publish documentation, llms.txt is a reasonable, cheap addition** - the companies most practised at documentation adopted it first for exactly that reason. **If you publish news, it is not the highest-value item on your list.** Nothing in this data suggests it changes how often you are cited; structured data, clean canonicals and a machine-readable version of the article itself do more, because those are surfaces search engines have actually committed to reading. **If a vendor claims llms.txt affects AI visibility, ask for the commitment they are relying on.** No major engine has published one. The file is a convention with an adoption base of fourteen sites in sixty, and saying that plainly beats treating it as settled practice in [technical SEO](/topics/technical-seo). ## Frequently asked questions ### Does llms.txt help me rank in AI answers? There is no published commitment from Google, Microsoft, OpenAI or Anthropic to read llms.txt, so nothing in this study supports a ranking or citation claim. Treat it as documentation you control, not as a retrieval input. ### How did you decide a file counted? A request to /llms.txt had to return 200 with a non-HTML content type and a non-empty body. That excludes the common case of a site returning its styled 404 page with a 200 status, which would otherwise inflate the count. ### Should I publish one anyway? If you maintain developer or product documentation, it is cheap and it is a reasonable place to point a machine reader at your canonical explanations. If you are a publisher weighing it against basic structured data and clean markup, it is not the thing to do first. ## Sources 1. [Dataset: AI crawler policies and llms.txt across 60 sites](https://seomadman.com/data/ai-crawler-policies.json) - SEO Madman (primary) 2. [The llms.txt proposal](https://llmstxt.org/) - llmstxt.org (primary) --- --- title: "Redirect chain analyzer: check hop count, loops and mixed codes" url: https://seomadman.com/tools/redirect-chain-analyzer section: tools published: 2026-09-10T00:00:00.000Z modified: 2026-09-10T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Redirect chain analyzer: check hop count, loops and mixed codes ## The short answer This tool analyzes a redirect chain you paste in as URL and status code pairs, since a client-side tool cannot reliably fetch and follow live redirects. It flags chain length against Google's documented guidance of ideally no more than 3 hops, plus loops, mixed 301/302 codes, protocol downgrades, and www inconsistency. ## Key takeaways - Google documents that Googlebot can follow up to 10 hops, but advises keeping a redirect chain to no more than 3 and fewer than 5 hops. - A redirect chain that revisits the same URL twice is a loop that no crawler or browser will finish following. - Mixing 301 and 302 codes within one chain makes the intended permanence of the move ambiguous, since Google treats the two codes as distinct signals. - A chain that drops from https to http, or switches between the www and bare host, adds an avoidable extra hop each time it happens. - This tool analyzes a chain you paste in rather than fetching URLs live, since cross-origin restrictions make client-side redirect-following unreliable in a browser. A redirect chain is easy to create by accident: a site move, then an https migration, then a www change, each adding one more hop on top of the last. None of that is visible from clicking a link, only from the sequence of status codes underneath it. ## Why this tool does not fetch URLs itself A browser will not let a page running on seomadman.com read the response headers of a request to a different origin; that restriction exists for good reason and this tool does not try to work around it. So rather than following redirects live and reporting an unreliable partial result, it analyzes a chain you already collected: your browser's dev tools Network tab, curl -IL, or a redirect-checking service all show the real hop-by-hop status codes and destinations. Paste that in, and the analysis runs entirely in your browser with nothing sent anywhere. ## Google's documented guidance on chain length Google's own site-move documentation states that Googlebot can follow up to 10 hops in a chain of multiple redirects, but adds a clear recommendation on top of that ceiling: redirect to the final destination directly where possible, and if that is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5. This tool applies that exact threshold: a chain at 3 hops or fewer passes, one above 3 gets a warning, and one at 5 or more is flagged as a hard problem, since it is both past Google's stated ideal and closer to the point where crawling and real user load time both suffer. ## 301 versus 302, and why mixing them is a problem Google's documentation on redirects draws a firm line between the two most common codes: 301 (and 308) are permanent redirects, meant for a page or site that has moved for good, while 302 (and 303, 307) are temporary, meant for a page that will return to its original location. A permanent redirect passes the intended signal that the move should stick; a temporary one keeps the source URL showing in search results rather than the target. A chain that mixes both codes sends a mixed signal about which behavior is actually intended, so this tool flags that combination as worth a second look, separate from Google's own explicit chain-length guidance. Use this tool after you have already gathered a chain from a real source, not as a substitute for gathering one: it tells you what the sequence of hops you found actually implies, not whether the destination page itself exists or responds correctly. ## Sources 1. [Redirecting an entire site or section of a site](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) - Google Search Central (primary) 2. [301 redirects and Google Search](https://developers.google.com/search/docs/crawling-indexing/301-redirects) - Google Search Central --- --- title: "Bing reports how often AI answers cite your pages" url: https://seomadman.com/news/bing-ai-performance-citations section: news published: 2026-09-09T00:00:00.000Z modified: 2026-09-09T00:00:00.000Z author: Adam Hafez topics: ["AI search", "Search Console"] --- # Bing reports how often AI answers cite your pages ## The short answer Bing Webmaster Tools has a public preview report called AI Performance. It counts how often a site is cited as a source in Copilot and AI-generated answers, shows the average number of cited pages per day, and lists the grounding queries the system used when it retrieved that content. ## Key takeaways - AI Performance entered public preview in Bing Webmaster Tools on 10 February 2026 and reports citations across Copilot, Bing AI answers and select partner integrations. - Total Citations counts how often your content appeared as a source, without saying where in the answer it appeared. - Average Cited Pages reports the mean number of unique pages from your site cited per day over the selected range. - Grounding queries show the phrases the system used to retrieve the content, which is a different question from the phrases a person typed. - Microsoft frames the report as an early step toward generative engine optimisation tooling, so treat the metrics as directional rather than as a ranking readout. Bing Webmaster Tools now answers the question paid tools used to guess at: how often does an AI answer cite your pages. The AI Performance report, in public preview since 10 February 2026, shows citations across Microsoft Copilot, Bing's AI-generated answers and, in Microsoft's words, "select partner integrations." ## What it measures **Total Citations.** How often your content was "displayed as sources in AI-generated answers" in the selected period. Microsoft is explicit this says nothing about placement: cited first or cited last count the same. **Average Cited Pages.** The mean number of unique pages from your site cited per day, a breadth measure. It tells you whether a whole section gets used as source material or one page carries everything. **Grounding queries.** The phrases the system used when it retrieved content that ended up referenced, not the question the user actually typed. Microsoft calls it a sample, not a complete list. ![The AI Performance dashboard in Bing Webmaster Tools, showing Total Citations, Average Cited Pages and a Grounding Queries list](../../../assets/editorial/bing-ai-performance-dashboard.png) *The AI Performance dashboard, from Microsoft's own announcement. The domain shown is Microsoft's placeholder example, not a real site's data. [Source: Bing Webmaster Blog](https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview).* **Robots.txt still applies.** Microsoft says the underlying retrieval "respects robots.txt and other supported control mechanisms," so a page blocked from Bing's crawlers cannot show up in this report, however often an answer would otherwise have used it. Low numbers are worth checking against your [robots.txt](/tools/robots-and-llms-txt-generator) before you read anything else into them. ## How to use it without overreading it **Compare against your own baseline.** Citations against your own impressions, not a competitor's estimate: the absolute count depends on how much AI traffic Bing serves in your market, which you do not control. **Read queries as retrieval language, not keyword research.** If the phrasing that pulls your page is consistently narrower than the topic you thought you covered, that is a content gap worth acting on in [AI search](/topics/ai-search). **Do not forecast traffic from it.** Microsoft's own framing avoids ranking language throughout, and nobody outside the engines can yet map a citation count onto sessions. ## Why we care A page can be the source an AI answer is built from and get zero clicks, a state invisible to every traffic report you already run. This is the first free, first-party number that describes it, even though it only covers Microsoft's surfaces: Google still exposes AI feature performance through Search Console impressions rather than a citation metric, and the two numbers do not add together. ## Frequently asked questions ### Does Google offer the same thing? Not in this form. Search Console reports impressions and clicks from AI features on your own property, but it does not count citations as a distinct metric or expose the query the system used to retrieve the page. Those are different measurements and they are not interchangeable. ### What is a grounding query? It is the phrase the AI system used when it retrieved supporting content, which is often a reformulation of what the person actually asked. Microsoft states the data shown is a sample, so treat it as a signal about retrieval phrasing rather than a complete query list. ### Does a citation mean traffic? No. A citation means your page was displayed as a source. Whether anyone clicked it is a separate question, and the citation metric does not answer it. ## Sources 1. [Introducing AI Performance in Bing Webmaster Tools Public Preview](https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview) - Bing Webmaster Blog (primary) 2. [Bing Webmaster Tools](https://www.bing.com/webmasters/about) - Microsoft (primary) --- --- title: "Search Console now reports impressions from Google's AI features" url: https://seomadman.com/news/search-console-generative-ai-reports section: news published: 2026-09-09T00:00:00.000Z modified: 2026-09-09T00:00:00.000Z author: Adam Hafez topics: ["Search Console", "AI search"] --- # Search Console now reports impressions from Google's AI features ## The short answer Google Search Console now includes a generative AI performance report showing how often pages appeared inside AI Overviews and AI Mode, plus a separate report for Discover. The report breaks impressions down by page, country, device and date, down to hourly granularity, and Google says it reached every website worldwide by 31 August 2026. ## Key takeaways - Search Console reports impressions from generative AI features separately from ordinary search results, so AI visibility is finally measurable in first-party data. - The Search report covers AI Overviews and AI Mode, and a second report covers generative AI features in Discover. - Available dimensions include pages, countries, devices and dates down to hourly granularity, and both the chart and the table can be exported. - As of 31 August 2026 Google says the reports reached every website worldwide, so an absent report now points at a property-level issue rather than a rollout stage. Search Console now answers "how visible are we inside AI Overviews" with a real number instead of a shrug. The generative AI performance report separates impressions inside AI features from impressions in ordinary search results, and Google says it now reaches every website worldwide. ## What the report contains **Impressions, broken four ways.** How many times links to your site were shown inside a generative AI feature on Google Search, with pages, countries, devices and date dimensions down to hourly granularity. Both the chart and the table export. ![The Generative AI features performance report in Search Console, showing total impressions and a Pages, Countries, Devices, Dates breakdown](../../../assets/editorial/search-console-generative-ai-report.png) *The report as Google shipped it, from the announcement post. The domain and numbers shown are Google's own placeholder example, not a real site's data. [Source: Google Search Central](https://developers.google.com/search/blog/2026/06/gen-ai-performance-reports).* **Discover gets its own report.** A second, separate view covers generative AI features in Discover, which matters for publishers whose Discover traffic behaves nothing like their search traffic. **The rollout question is closed.** Google's post carries a note added after launch: as of 31 August 2026, the reports reached every website worldwide, after an initial run on a subset of properties. A property still showing no data likely has no qualifying AI-feature impressions yet, not an access problem. ## Why this changes the measurement problem **Every alternative so far has been inferred.** Teams reverse-engineered AI visibility from unexplained impression growth without matching clicks, or bought a third-party panel that samples prompts and guesses which domains get cited. Neither number reconciles against Google's own reporting. **A first-party count does.** Same measurement lineage as the rest of Search Console, covers your whole property rather than a sampled prompt set, and can be exported and stored, so the trend line survives the next interface redesign. ## What it does not settle An impression is not a citation, and a citation is not a visit. The report says your pages appeared, not whether the generated answer quoted them or buried them at the bottom of a source list. Treat it as a presence metric and pair it with your own analytics before anyone in the room turns it into a revenue claim. ## Why we care Check whether the report is live on your property, then export the full window immediately - interface-bound history has a habit of disappearing when a report gets redesigned. Compare the pages that actually surface in AI features against the pages you assumed were your AI-visible set. In most audits those two lists overlap far less than people expect, and the gap is the real work. ## Frequently asked questions ### Does the report separate AI Overviews from AI Mode? Google describes a single report covering generative AI features on Search, which includes both AI Overviews and AI Mode. Discover gets its own report. Treat the Search figure as a combined generative AI number rather than a per-surface breakdown. ### What should I do if I cannot see the report yet? Google says it reached every website worldwide by 31 August 2026, so a missing report is no longer a rollout question. Check the property is verified and has recent Search traffic first; if it still does not appear, that is worth raising with Google directly rather than waiting. ### Can I export the data? Yes. The report provides an export button that downloads both the chart and the table, so you can hold your own history rather than depending on the interface window. ## Sources 1. [Introducing Search Generative AI performance reports in Search Console](https://developers.google.com/search/blog/2026/06/gen-ai-performance-reports) - Google Search Central (primary) 2. [Generative AI performance report (Search)](https://support.google.com/webmasters/answer/16984139) - Google Search Console Help (primary) 3. [Generative AI performance report (Discover)](https://support.google.com/webmasters/answer/16983858) - Google Search Console Help --- --- title: "Search Console now measures your TikTok, X and YouTube posts" url: https://seomadman.com/news/search-console-platform-properties section: news published: 2026-09-09T00:00:00.000Z modified: 2026-09-09T00:00:00.000Z author: Adam Hafez topics: ["Search Console", "Content strategy"] --- # Search Console now measures your TikTok, X and YouTube posts ## The short answer Google has introduced platform properties in Search Console, a property type that reports how a creator's Instagram, TikTok, X and YouTube content performs on Google Search and Discover. It shows clicks, impressions and the queries behind them, and it works for creators who own no website at all. ## Key takeaways - Google announced platform properties on 7 July 2026, adding a Search Console property type for Instagram, TikTok, X and YouTube accounts. - The Performance report covers clicks, impressions and the queries that led to a post, with the same filtering and export you get for a site. - An Insights report summarises traffic trends and top posts, and Achievements tracks click milestones over a rolling 28 day window. - Verification runs through the platform itself, so the property is authorised by the account rather than by a file or a DNS record. - This is the first Search Console surface that reports on content a creator does not host, which makes off-site publishing measurable rather than assumed. Search Console has spent its whole life reporting on one thing: pages you host. Platform properties break that assumption. Announced 7 July 2026 by Moshe Samet, Product Manager Lead for Search Console, the new property type reports how your Instagram, TikTok, X and YouTube content performs in Google Search and Discover. ## What a platform property reports **Performance.** Total clicks, impressions and related metrics, filterable down to the individual post and query. Google's own line: you can "track which search terms lead people to your Instagram, TikTok, X, and YouTube content on Search." **Insights.** The high-level view: recent traffic trends, top performing posts, and how people find the account through Google. ![The Insights report for a platform property in Search Console, showing overall clicks split between web search, video search, Discover and image search](../../../assets/editorial/search-console-platform-insights.png) *A platform property's Insights report, from Google's announcement post. The creator handle and numbers shown are Google's own illustrative example. [Source: Google Search Central](https://developers.google.com/search/blog/2026/07/search-console-social-video-platforms).* **Achievements.** Milestones, like passing a click threshold in the last 28 days. The lightest of the three, and the only one with no equivalent on a website property. ## Why this matters beyond social teams **Off-site publishing becomes measurable.** A brand posting explainers to TikTok can now see whether those posts earn Search impressions and for which queries, instead of assuming they only reach the in-app audience. **Query data arrives from a second direction.** The phrases that surface a video are not always the phrases that surface an article on the same subject, and until now that difference was invisible in [Search Console](/topics/search-console). **Setup runs through the platform, not a file.** Open Search Console, go to the verification page or the property selector, choose "Add property," pick one of the four platforms, then authorise through the platform itself rather than a file upload or DNS record. Google said access would arrive gradually over the following weeks. ## Why we care A platform property tells you how a post performed on Google, not that the post is yours in any durable sense: the account, the reach and the rules stay with the platform, and the report will happily document a decline you cannot fix. Read it as a distribution audit for [content strategy](/topics/content-strategy) decisions, not a reason to move work off a domain you actually control. ## Frequently asked questions ### Do I need a website to use a platform property? No. Google states the point of the property type is to give site owners and creators a consolidated view of how their content is discovered on Search, explicitly including those without their own website. ### Which platforms are supported? Instagram, TikTok, X and YouTube. You select one of the four when adding the property and then complete the platform's own authorisation flow. ### Is the data exportable? Yes. Google says the Performance report can be exported if you prefer to analyse it in another tool, the same as any other Search Console performance data. ## Sources 1. [See how content from social and video platforms performs on Google Search](https://developers.google.com/search/blog/2026/07/search-console-social-video-platforms) - Google Search Central (primary) 2. [Platform properties roll out globally, plus a new social and video performance guide](https://developers.google.com/search/blog/2026/07/platform-properties-social-video-guide) - Google Search Central (primary) --- --- title: "AI answer readiness checker for articles" url: https://seomadman.com/tools/ai-answer-readiness-checker section: tools published: 2026-09-09T00:00:00.000Z modified: 2026-09-09T00:00:00.000Z author: Adam Hafez topics: ["AI search", "Structured data"] --- # AI answer readiness checker for articles ## The short answer Paste an article and this checker scores the structural properties that decide whether an answer engine can quote it: an opening answer of the right length, question-shaped headings with stable ids, standalone list items, outbound citations, structured data and a machine-readable date. Everything runs in your browser. ## Key takeaways - An opening paragraph of 40 to 60 words that answers the headline directly is the single highest-leverage change most articles can make. - Headings that carry stable ids let a system cite one section of a page rather than the whole page. - List items written as complete sentences survive being lifted out of context; fragments do not. - Structure is necessary but never sufficient, because no amount of markup makes an unsourced claim worth citing. ## What is actually being measured Seven structural properties, each scored on its own: - **An opening answer of 40 to 60 words.** Long enough to be complete, short enough to quote whole. - **Question-shaped headings.** Headings that match how a person phrases the question they typed. - **Stable heading ids.** The difference between citing a page and citing a passage of it. - **Standalone list items.** A bullet that reads as a full sentence survives being lifted alone. - **Outbound citations.** Pages that cite verifiable sources are safer to repeat. - **Structured data.** An explicit machine reading beats an inferred one. - **A machine-readable date.** Freshness cannot be assessed if it cannot be parsed. ## What it deliberately does not score Accuracy, authority and originality, because no script can assess them. A page can score full marks here and be entirely wrong, and a page with none of this structure can be the best thing written on its subject. The score answers one narrow question: if a system wanted to quote this page, could it? ## Frequently asked questions ### Does a high score mean an answer engine will cite my page? No, and any tool claiming otherwise is guessing. This scores whether a page is structurally easy to extract and attribute. Whether a system chooses your page over another depends on authority, relevance to the specific prompt and factors none of us can observe. ### Why does it weight the opening paragraph so heavily? Because an extraction pass has to find a self-contained answer somewhere, and the top of the article is where it looks first. A page that opens with throat-clearing forces a system to synthesise an answer from fragments, which makes attribution to your page less likely. ### Is my content uploaded anywhere? No. The page loads a small script that parses the text in your browser. There is no server involved, no request carrying your content, and nothing stored. ## Sources 1. [AI features and your website](https://developers.google.com/search/docs/appearance/ai-features) - Google Search Central (primary) 2. [Google's guide to optimizing for generative AI features on Search](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide) - Google Search Central (primary) --- --- title: "Image alt text auditor" url: https://seomadman.com/tools/image-alt-text-auditor section: tools published: 2026-09-09T00:00:00.000Z modified: 2026-09-09T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Image alt text auditor ## The short answer This tool parses pasted HTML and flags every image's alt attribute: missing entirely, left empty, a generic placeholder or filename, or padded with repeated keywords. Missing and generic checks follow Google's documented image guidance. Filename-shape and keyword-stuffing detection are this tool's own heuristics, since Google has not published an exact alt-text length or repetition rule. Nothing pasted leaves your browser. ## Key takeaways - Every image needs an alt attribute, and Google's own documentation says alt text helps images be understood and found in search. - An empty alt="" is not automatically an error, since it is the documented way to mark a purely decorative image for accessibility tools. - Google names filling alt attributes with keywords as keyword stuffing in its spam policies, a manipulative practice rather than a length limit. - This tool's filename-shape and repeated-word detection are heuristics, clearly labeled as such, not official Google thresholds. - Generic placeholder text such as image123 or a raw filename fails Google's own descriptive-filename and alt-text guidance. Alt text serves two audiences at once: people using a screen reader and Google trying to understand what an image shows. This tool parses pasted HTML with the browser's own DOMParser and checks every img tag's alt attribute against Google's documented guidance, plus a couple of its own heuristics for patterns Google has flagged as spam but never reduced to a formula. ## What Google actually documents about alt text Google's own image SEO guidance says to focus on useful, information-rich alt text that uses keywords appropriately and stays in context of the page, rather than treating alt text as a keyword slot. It separately advises against generic filenames, giving `my-new-black-kitten.jpg` as a good example against `IMG00023.JPG` as a bad one, and that same logic extends to alt text that is just a filename restated. Google's spam policies go further and name keyword stuffing directly: filling an alt attribute with keywords is called out as a practice that produces a bad user experience and can get a site treated as spam. None of this amounts to a length limit or a maximum keyword count. It is guidance about writing for a reader first, not a threshold to hit. ## What this tool checks, and which parts are Google's rules versus its own guesses Two checks are direct reads of that documentation: an image with no alt attribute at all fails the basic requirement that alt text exist, and alt text that is a generic placeholder such as "image123" or a bare filename fails the descriptive-filename guidance. Both are labeled as following Google's documentation because they map to a specific documented statement. Two other checks are this tool's own heuristics, and the results table says so on every flag. Google has never published an exact character count or repetition count that defines keyword stuffing in alt text, so this tool makes a judgment call: alt text that is nothing but a filename pattern gets flagged as filename-shaped, and alt text with a single word repeated three or more times across eight or more words gets flagged as possibly stuffed. Both exist to catch obvious cases, not to define a passing score, and both can be wrong on unusual real captions. Read the flag before rewriting solely to satisfy it. Empty alt text gets its own, softer treatment. An `alt=""` is not flagged as an error here, because leaving alt text empty is the documented way to tell assistive technology that an image is purely decorative and can be skipped. Only a missing alt attribute, not an empty one, is treated as the accessibility and SEO problem. Paste a real page's markup to see where its images actually stand, then fix the missing and generic cases first since those map directly to Google's documented guidance, and treat the heuristic flags as a second read rather than a verdict. ## Sources 1. [Google Images best practices](https://developers.google.com/search/docs/appearance/google-images) - Google Search Central (primary) --- --- title: "robots.txt and llms.txt generator with an AI policy" url: https://seomadman.com/tools/robots-and-llms-txt-generator section: tools published: 2026-09-09T00:00:00.000Z modified: 2026-09-09T00:00:00.000Z author: Adam Hafez topics: ["AI search", "Technical SEO"] --- # robots.txt and llms.txt generator with an AI policy ## The short answer This tool writes a robots.txt and an llms.txt from one decision: which AI crawlers may take your content. It separates search agents from training agents from live fetchers, because blocking one does not block the others, and shows what each one actually does before you choose. ## Key takeaways - A single company usually runs several crawlers with different purposes, and refusing one of them says nothing about the others. - Blocking a training crawler does not remove you from the answer engine that shares its name, because that engine reads with a different agent. - Google-Extended controls Gemini training only, and refusing it has no effect on how the page ranks in Google Search. - robots.txt states intent, so a bot rule at your CDN can silently overrule everything the file says. ## Three kinds of crawler, three different exchanges A **search agent** indexes your page so it can be cited in an answer. You get attribution and, sometimes, a click. This is the closest thing to the traditional search bargain. A **training agent** copies your content into a model. There is no attribution and no click. The argument for allowing it is influence over what models know; the argument against is that you get nothing back that you can measure. A **live fetcher** retrieves your page because a person asked about it right now. It behaves like a visitor with a robot's user agent, and blocking it mostly means the person gets a worse answer about you. Deciding all three with one checkbox is the most common mistake in AI crawler policy, and it is usually made in the direction of blocking search agents by accident. ## robots.txt is a request, not a wall Nothing in the protocol enforces anything. Well-behaved crawlers read the file and comply; the rest do not. More importantly for most sites, your own infrastructure can overrule it: a bot management rule, an AI crawler toggle at the CDN, or a WAF rule matching on bot signatures will block an agent that robots.txt explicitly welcomes. So verify with a request rather than a file: ```bash for ua in GPTBot OAI-SearchBot ClaudeBot PerplexityBot; do curl -sA "$ua" -o /dev/null -w "$ua %{http_code}\n" https://example.com/ done ``` A 403 there means the decision is being made somewhere other than the file you just published. ## Frequently asked questions ### If I block GPTBot, do I disappear from ChatGPT? No. GPTBot collects training data. ChatGPT search results are built by OAI-SearchBot, and a page fetched because a user asked about it comes through ChatGPT-User. Blocking the training crawler leaves the other two untouched, which is usually what a publisher actually wants. ### Does refusing Google-Extended hurt my rankings? No. Google-Extended governs whether your content is used to train Gemini. It is a separate control from Googlebot, and Google documents that it does not affect Search ranking. ### Is llms.txt a standard that engines obey? It is a proposal, not a standard, and no engine is obliged to read it. It costs almost nothing to publish and it is the only place you get to state, in your own words, what a machine should read first. Treat it as a courtesy that may pay off, not as a ranking mechanism. ### My robots.txt allows these bots but they still get blocked. Why? Almost always a bot-management rule at the CDN. Cloudflare's AI crawler controls, bot fight modes and WAF rules that match on bot signatures all act before robots.txt is ever read. Test with a real request using the agent's user-agent string. ## Sources 1. [RFC 9309: Robots Exclusion Protocol](https://www.rfc-editor.org/rfc/rfc9309.html) - IETF (primary) 2. [Overview of Google crawlers and fetchers](https://developers.google.com/search/docs/crawling-indexing/overview-google-crawlers) - Google Search Central (primary) 3. [OpenAI bots and how to control them](https://platform.openai.com/docs/bots) - OpenAI (primary) 4. [The llms.txt proposal](https://llmstxt.org/) - llmstxt.org --- --- title: "Structured data generator for search and AI" url: https://seomadman.com/tools/schema-markup-generator section: tools published: 2026-09-09T00:00:00.000Z modified: 2026-09-09T00:00:00.000Z author: Adam Hafez topics: ["Structured data", "Technical SEO"] --- # Structured data generator for search and AI ## The short answer This generator builds valid JSON-LD for the page types that earn something in search: Article, NewsArticle, FAQPage, VideoObject, Organization and BreadcrumbList. It marks every required property, checks URL and date formats as you type, and hands you a block ready to paste into the page. ## Key takeaways - Structured data states what a page is in explicit terms instead of leaving it to be inferred from prose. - A missing required property does not degrade a rich result, it disqualifies the page from it entirely. - An author or publisher given as a plain string is a label; given as an entity with a URL it can be resolved and trusted. - Markup describes the page, so anything asserted here that the page does not actually show is a spam signal rather than an optimisation. ## What each type is actually for **Article and NewsArticle** describe editorial content. NewsArticle is the one that matters for Google News surfaces; use it only for genuine news reporting, since applying it to evergreen content misrepresents the page. **FAQPage** describes a page that genuinely is a set of questions and answers. Google narrowed the FAQ rich result to a small set of site types, but the markup still gives answer engines a clean question-to-answer mapping, which is why it stays worth adding on pages that really are Q and A led. **VideoObject** is the one most sites skip and should not. It is what makes a video eligible for video results, and the transcript property is what makes the content of the video readable at all. **Organization** and **BreadcrumbList** are site-level plumbing. The first resolves who publishes the site as an entity rather than a name; the second gives search a reliable path structure that does not depend on parsing your navigation. ## The two mistakes worth avoiding The first is a string where an entity belongs. `"author": "Adam Hafez"` is a label that cannot be connected to anything. An author object with a `url` pointing at a real profile page can be resolved, cross-referenced and trusted, and that difference is the whole point of the exercise. The second is markup that describes a page you did not build. Claiming a rating, a price or an FAQ that a visitor cannot see is a policy violation, and the penalty is losing rich results across the site rather than on the one page. ## Frequently asked questions ### Does structured data improve rankings? Not directly. It makes a page eligible for rich results and gives search and answer engines an unambiguous reading of what the page is. Both affect how often the page is shown and clicked, which is a different mechanism from ranking. ### Should I use JSON-LD, Microdata or RDFa? JSON-LD. Google recommends it, it lives in one block rather than being threaded through the markup, and it survives template changes that would break attribute-based formats. ### What happens if I mark up something the page does not show? It is a structured data policy violation and can cost the site its rich result eligibility. The markup has to describe the visible page, not the page you wish you had. ## Sources 1. [Intro to how structured data markup works](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data) - Google Search Central (primary) 2. [Schema.org vocabulary](https://schema.org/) - Schema.org (primary) --- --- title: "SERP snippet preview with pixel-accurate truncation" url: https://seomadman.com/tools/serp-snippet-preview section: tools published: 2026-09-09T00:00:00.000Z modified: 2026-09-09T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO", "Content strategy"] --- # SERP snippet preview with pixel-accurate truncation ## The short answer This tool previews how a title and description will render in Google's results and measures them in pixels rather than characters, because Google truncates by width. Enter a title, URL and description, switch between desktop and mobile, and see exactly where each line will be cut. ## Key takeaways - Google truncates snippets by rendered pixel width, so the familiar 60-character rule is wrong for any title made of unusually wide or narrow letters. - The same title can fit on desktop and be cut on mobile, because the two layouts allow different widths. - Google rewrites titles and descriptions when it judges its own version more useful, so a passing preview is a ceiling rather than a guarantee. - Everything is measured in your browser with a canvas text measurement, so nothing you type is sent anywhere. ## Why pixels and not characters Google composes results in a proportional font. A capital W is roughly four times the width of a lowercase l, so two titles with an identical character count can truncate in completely different places. Counting characters gives you a rule that is wrong for every title made of unusual letters, which in practice means every title containing a brand name. ## What this tool does not tell you It does not tell you whether Google will use your title at all. Title rewriting is common, and the strongest defence against it is a title tag that accurately describes the page and matches its H1, not one tuned to a pixel budget. It also cannot see the query. Descriptions are frequently replaced with a passage pulled from the page when that passage matches the search better. Treat the meta description as the version you prefer, not the version that will always appear. ## Frequently asked questions ### Why do the widths differ from other snippet tools? Most tools count characters, or measure with whatever font the page happens to load. This one measures with a canvas at the font sizes Google uses in its results, which is closer to the real truncation point but still an approximation of a layout Google changes without notice. ### Does a perfect preview mean Google will use my title? No. Google rewrites title links when it judges an alternative more useful for the query, most often by pulling from the H1 or on-page text. A well-formed title makes a rewrite less likely; nothing prevents one. ### Should I write to the maximum width? No. Write the clearest title, then check it fits. A truncated title that front-loads its meaning still works; a padded title that fits exactly rarely reads better than a short one. ## Sources 1. [Control your title links in search results](https://developers.google.com/search/docs/appearance/title-link) - Google Search Central (primary) 2. [Control your snippets in search results](https://developers.google.com/search/docs/appearance/snippet) - Google Search Central (primary) --- --- title: "The August 2026 spam update finished after three days" url: https://seomadman.com/news/august-2026-spam-update-completed section: news published: 2026-09-08T00:00:00.000Z modified: 2026-09-08T00:00:00.000Z author: Adam Hafez topics: ["Core updates", "Technical SEO"] --- # The August 2026 spam update finished after three days ## The short answer Google's August 2026 spam update ran from 18 August to 21 August, according to the Search Status Dashboard, a rollout of roughly three days. Spam updates re-apply Google's spam policies rather than re-score quality, so a drop points at a policy breach on the site, not at a content quality verdict. ## Key takeaways - The August 2026 spam update started on 18 August and completed on 21 August in US Pacific time, per Google's own status dashboard. - A spam update enforces Google's spam policies, which is a different mechanism from a core update re-scoring relevance and quality. - Recovery from a spam action requires removing the violating practice, and it does not take effect until a later spam update run. - Align the loss window against the dashboard dates before diagnosing anything, because an overlapping infrastructure change is a common false positive. Google's August 2026 spam update is finished. The Search Status Dashboard records the rollout as starting 18 August at 09:27 and completing 21 August at 01:49, US Pacific time: two days and 16 hours, applied "globally and to all languages," per Google's own incident note. Short enough that the start and end of the decline should read as clean edges in a daily Search Console export. ## Spam update or core update **A core update re-scores the index** against revised notions of relevance and quality. Nothing is flagged. A site can lose visibility having done nothing newly wrong, and the recovery path runs through the content itself. **A spam update enforces specific policies**: scaled content abuse, site reputation abuse, expired-domain abuse, cloaking, link schemes. The fix is not "improve the content" but "stop doing the specific thing," and stopping does not register until Google's systems reprocess the site on a later run. ## How to check your own data **Mark the dashboard dates on your series first.** A decline that begins two days before the rollout is not the rollout, whatever the calendar suggests. **Segment by page group, not site total.** Spam enforcement is usually concentrated: one template, one directory, one content programme. A site-wide, even decline is a weak match for a spam action. **Rule out the boring explanations before the algorithmic one.** A robots change, a `noindex` shipped by accident, a CDN rule, a migration, seasonality. In most drop investigations the cause is on this list, and the update was a coincidence that happened to be nearby. ## Why we care If it is a spam action, the audit question is whether the content programme in question would have existed at all with search traffic taken out of the equation. Identify the practice, not the page, remove or rebuild it, then accept the clock runs on Google's next spam-update schedule, not yours. There is no reconsideration request for algorithmic spam enforcement, and no way to accelerate it. ## Frequently asked questions ### How do I know whether a spam update or a core update hit me? Compare your loss window against the Search Status Dashboard dates. If the decline starts inside a spam update window and is concentrated on a specific content pattern, treat it as spam policy enforcement. A broad decline across otherwise healthy sections during a core update window is a different problem. ### How long does recovery from a spam update take? Google's documentation is explicit that changes take effect when the relevant systems next process the site, which in practice means a later spam update run. There is no reconsideration request for algorithmic spam enforcement, and no way to accelerate it. ## Sources 1. [Ranking incident details: August 2026 spam update](https://status.search.google.com/incidents/LEubPCm2octf2uMqCFKE) - Google Search Status Dashboard (primary) 2. [Google Search spam updates](https://developers.google.com/search/docs/appearance/spam-updates) - Google Search Central (primary) --- --- title: "How often Google rewrites a title tag: 61.6% to 76%" url: https://seomadman.com/studies/title-tag-rewrite-rate-study section: studies published: 2026-09-08T00:00:00.000Z modified: 2026-09-08T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # How often Google rewrites a title tag: 61.6% to 76% ## The short answer Cyrus Shepard's 2022 study of 80,959 title tags found Google rewrote 61.6% of them. John McAlpin's Q1 2025 follow-up found a 76% rewrite rate. Shepard also found that when a title matches its H1, the rewrite rate drops to 20.6%, and titles over 70 characters get rewritten 99.9% of the time. ## Key takeaways - Cyrus Shepard's 2022 Zyppy study of 80,959 title tags across 2,370 sites found Google rewrote 61.6% of them at least partially. - John McAlpin's May 2025 Search Engine Land study, covering roughly 30,000 keywords in Q1 2025, found the rewrite rate had climbed to 76%. - Shepard's study found that when a page's title tag matches its H1, the rewrite rate drops to 20.6%, far below the 61.6% baseline. - Titles between 51 and 60 characters were changed only 39% to 42% of the time, the lowest rate Shepard measured; titles over 70 characters were rewritten 99.9% of the time. - McAlpin's data shows brand-name removal accounts for 63% of rewrites, readability and clarity for 30%, with length adjustments a smaller factor. Two researchers, three years apart, asked the same question with two different datasets: how often does Google use a page's title tag as written, versus rewriting it for the results page. Cyrus Shepard's 2022 study put the rate at 61.6%. John McAlpin's 2025 follow-up put it at 76%. Both studies also isolated a specific, actionable lever: what a title tag matching its H1 does to the odds of a rewrite. ## The overall rewrite rate rose from 61.6% to 76% Shepard, an SEO consultant at Zyppy, examined 80,959 title tags across 2,370 sites in early 2022 and found Google rewrote 61.6% of them at least partially, whether by trimming, reordering, appending a brand name, or replacing the title outright with text pulled from the page. Search Engine Journal covered the study on publication and it has been cited across the industry since. McAlpin's study, published on Search Engine Land in May 2025, sampled roughly 30,000 keywords in the top 20 results during Q1 2025 and found a 76% rewrite rate, close to a 25% relative increase from Shepard's figure. McAlpin's data attributes the largest share of rewrites, 63%, to Google stripping brand names, with readability and clarity changes accounting for another 30%. Neither study names a single cause for the increase between 2022 and 2025; the two are independent measurements taken with different tools and different keyword sets, not the same dataset checked twice. ## Matching the H1 cuts the rewrite rate to 20.6% The more useful finding for anyone writing title tags sits inside Shepard's original data, not the headline number. When a page's title tag says roughly the same thing as its H1, including cases with elements Google commonly strips like pipe characters, the rewrite rate drops to 20.6%, a third of the 61.6% baseline. Shepard's study also isolated length as a factor independent of H1 alignment: titles between 51 and 60 characters were rewritten only 39% to 42% of the time, the lowest rate in the study, while titles over 70 characters were rewritten 99.9% of the time and titles of 1 to 5 characters were rewritten 96.6% of the time. Neither finding is a guarantee. A title that matches its H1 and sits in the 51 to 60 character range still gets rewritten roughly one time in five, on Shepard's numbers. What the data supports is a lever, not a lock: title and H1 agreement, and a length that avoids Google's truncation point, both measurably reduce the odds without eliminating them. ## Why we care A rewrite rate above 60%, rising toward 76%, means most title tags you write are not the title tag searchers actually see. That is a reason to write titles Google is less likely to touch, not a reason to stop writing them carefully: the two factors both studies isolate, H1 alignment and character length, are both things a site controls before publishing, unlike the query-dependent snippet rewriting Google does to meta descriptions. Check where a title actually truncates before publishing it. Our [SERP snippet preview](/tools/serp-snippet-preview/) measures rendered pixel width rather than character count, since Google truncates by width and a 50-character title in a wide typeface can cut earlier than a 60-character title in a narrow one. It will not tell you whether Google keeps your title intact, since neither this tool nor any study here can see Google's rewriting model directly, but it removes length as a guessing game before you check the one factor that is proven to matter more: whether the title agrees with the H1 underneath it. ## Frequently asked questions ### Who ran these studies, and are they independent of each other? Cyrus Shepard, an SEO consultant at Zyppy, ran the first study in early 2022 on 80,959 title tags from 2,370 sites. John McAlpin ran the follow-up published on Search Engine Land in May 2025, on roughly 30,000 keywords sampled in Q1 2025. They are two separate researchers using two separate datasets three years apart, not one study cited twice. ### Does matching my title tag to my H1 guarantee Google keeps it? No. Shepard's data shows the rewrite rate drops from 61.6% to 20.6% when title and H1 say roughly the same thing, which is a large reduction, not a guarantee. Google still rewrites about one in five matched titles. ### What length keeps a title tag safest from rewriting? Shepard's study found 51 to 60 characters had the lowest rewrite rate he measured, 39% to 42%. Titles over 70 characters were rewritten 99.9% of the time, and titles of 1 to 5 characters were rewritten 96.6% of the time. Check the actual rendered width with a pixel-based preview rather than relying on character count alone. ### Why did the rewrite rate go up between 2022 and 2025? Neither study states a cause. McAlpin's data shows brand-name removal is now the single largest reason for a rewrite, at 63% of changes, followed by readability and clarity fixes at 30%. Whether Google's rewriting model changed or the pages sampled differ is not something either study isolates. ## Sources 1. [Study: Google Rewrites Title Tags 61.6% of the Time](https://zyppy.com/seo/google-title-rewrite-study/) - Zyppy (primary) 2. [Google Changed 76% of Title Tags in Q1 2025, Here's What That Means](https://searchengineland.com/google-changed-76-of-title-tags-in-q1-2025-heres-what-that-means-454847) - Search Engine Land (primary) 3. [Google Changes More Than 61 Percent Of Title Tags](https://www.searchenginejournal.com/google-changes-more-than-61-percent-of-title-tags/435618/) - Search Engine Journal --- --- title: "Breadcrumb schema generator" url: https://seomadman.com/tools/breadcrumb-schema-generator section: tools published: 2026-09-08T00:00:00.000Z modified: 2026-09-08T00:00:00.000Z author: Adam Hafez topics: ["Structured data"] --- # Breadcrumb schema generator ## The short answer This generator builds BreadcrumbList JSON-LD from a repeatable list of page names and URLs, following Google's documented structure: each item gets a position and a name, every item but the last needs an absolute URL, and the trail needs at least two entries to mean anything. A live preview shows the trail as a reader would see it. ## Key takeaways - A BreadcrumbList needs at least two ListItem entries to represent a real parent-to-page path. - Every item except the last requires an absolute item URL; the last item may omit it because Google resolves it to the page the markup is on. - Breadcrumbs should represent a typical user path to a page rather than mirror the URL structure exactly. - Getting position numbering wrong is a common source of breadcrumb markup that validates as JSON but fails Google's structured data test. A breadcrumb trail is the one piece of structured data that describes navigation rather than content. Get the list right and Google can show the trail in place of a raw URL in search results; get the position numbering or the last-item URL wrong and the markup validates as JSON while still failing Google's structured data test. ## What Google actually requires The `itemListElement` array holds `ListItem` entries, each with a `position` (an integer starting at 1), a `name`, and an `item`, the URL of that step. The one documented exception is the last entry: its `item` is optional, because Google resolves it to the URL of the page the markup is published on. Google's own guidance also says the trail should represent a typical path a visitor takes to reach the page, not a literal mirror of the URL's folder structure, so a trail can skip a step that exists in the URL but that no reader would think of as a real waypoint. ## Why a dedicated tool instead of the generic one The site's schema markup generator handles six page types from one fixed-field form, useful when you need an Article or FAQPage block quickly. A breadcrumb trail is not a fixed set of fields, it is a list whose length depends on the page, so this tool is built around adding and removing rows instead of filling in a form. The validation is specific to what makes a BreadcrumbList useful: at least two items, so the trail actually shows a path rather than a single node, and an absolute URL on every item except the last, which is the one place Google's own documentation allows it to be skipped. Paste the result into the page you built the trail for, not a template shared across pages. A breadcrumb that does not match the navigation a visitor can actually click is the same kind of policy violation as any other structured data that describes a page you did not build. ## Frequently asked questions ### Does the last breadcrumb need a URL? No. Google's documentation states the item property is not required on the last entry in the trail, since it resolves to the URL of the page the markup sits on. ### Should the trail match my URL folder structure? Not necessarily. Google's guidance is to represent a typical user path to the page, which can differ from how the URL is nested. ### How is this different from the general schema markup generator? The schema markup generator covers six page types from a fixed field form. This tool is built around the one thing a breadcrumb trail actually is, a repeatable, reorderable list, with validation specific to BreadcrumbList's position and item rules. ## Sources 1. [Breadcrumb (BreadcrumbList) structured data](https://developers.google.com/search/docs/appearance/structured-data/breadcrumb) - Google Search Central (primary) --- --- title: "Google opens AI Mode ads to exact and phrase match keywords" url: https://seomadman.com/news/ai-mode-ads-rollout section: news published: 2026-09-07T00:00:00.000Z modified: 2026-09-07T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # Google opens AI Mode ads to exact and phrase match keywords ## The short answer Google confirmed on September 4, 2026 that exact and phrase match keywords can now serve text ads inside AI Mode, after advertisers spotted the change and Google Ads Liaison Ginny Marvin explained it. The test is capped to queries with explicit and direct user intent, a term Google has not defined, with no disclosed country or duration limits. ## Key takeaways - Google Ads Liaison Ginny Marvin confirmed on September 4, 2026 that exact and phrase match keywords can now serve text ads inside AI Mode. - Before this test, only AI Max for Search, Performance Max, or broad match paired with Smart Bidding could reach AI Mode ad placements. - Eligibility is limited to queries showing explicit and direct user intent, a phrase Google has not defined in any public documentation. - Google disclosed no country, vertical, account share, or end date for the test, and Ads reporting does not separate AI Mode delivery from standard Search delivery. Google confirmed on September 4, 2026 that exact and phrase match keywords from standard Search campaigns can now serve text ads inside AI Mode. Advertisers spotted the behavior first, and Google Ads Liaison Ginny Marvin followed up to describe it as a small, recently started experiment rather than a policy Google had pre-announced. Until this test, the only entry points into an AI Mode ad placement were AI Max for Search, Performance Max, or broad match paired with Smart Bidding. ## What actually changed The eligibility rule that has governed AI Mode advertising since ads first appeared on the surface required a campaign to use broad match with Smart Bidding, or one of Google's AI-driven formats, AI Max or Performance Max. Marvin's statement extends that list to exact and phrase match keywords, the more restrictive, advertiser-controlled match types that dominate a large share of existing Search accounts. Google frames the extension narrowly: it applies only where the query shows, in Marvin's words, "explicit and direct user intent," a threshold Google has not defined with examples or documentation. ## What Google has not disclosed Google named no country, no industry vertical, no percentage of accounts included, and no end date for the test. Advertisers who want to know whether they are in it have no dashboard flag to check; the only public confirmation so far is Marvin's own statement responding to advertisers who noticed the change themselves. Google Ads reporting also does not split AI Mode delivery from ordinary Search delivery inside a keyword's rows, so even an advertiser inside the test cannot isolate how much of their existing traffic now originates from AI Mode versus classic Search results. Separately, Google has said AI Mode ads stay labeled "Sponsored" and run alongside an independently generated AI explainer, rather than folding advertiser copy into the answer text itself, though that description predates this specific test and Google has not restated it here. ## Why we care An eligibility change that lets exact and phrase match keywords into AI Mode is a bigger deal than it first looks for anyone who assumed AI Mode's ad load was capped to advertisers running AI Max or Performance Max. It is not: a large share of Search accounts still run on exact and phrase match, and those campaigns can now compete for the same placements next to, or inside, AI Mode's conversational answers. With no reporting split and no defined intent threshold, the practical result for now is that more ads can appear in AI Mode than before, and neither advertisers nor the publishers whose citations sit alongside those ads have a way to measure how much has shifted. ## Frequently asked questions ### Does this mean Shopping ads are new to AI Mode too? No. The September change confirmed by Google is limited to text ads from standard Search campaigns using exact and phrase match keywords. Shopping and Performance Max placements inside AI Mode predate this test and are unaffected by it. ### What counts as "explicit and direct user intent"? Google has not published a definition. Ginny Marvin used the phrase to describe the eligibility bar but gave no query examples, so advertisers cannot currently predict which exact or phrase match keywords will qualify. ### Can advertisers see how much of their spend now comes from AI Mode? Not separately. Google Ads reporting does not break out AI Mode delivery from standard Search delivery at the keyword level, so there is no way to isolate the incremental reach this test adds. ## Sources 1. [Google tests traditional Search campaigns in AI Mode](https://searchengineland.com/google-tests-traditional-search-campaigns-in-ai-mode-487199) - Search Engine Land (primary) 2. [Exact and phrase match keywords gain AI Mode ads in Google test](https://ppc.land/exact-and-phrase-match-keywords-gain-ai-mode-ads-in-google-test/) - PPC Land 3. [A new generation of ads for the AI era of Search](https://blog.google/products/ads-commerce/google-marketing-live-search-ads/) - Google --- --- title: "Site migration redirect map builder" url: https://seomadman.com/tools/redirect-map-builder section: tools published: 2026-09-07T00:00:00.000Z modified: 2026-09-07T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Site migration redirect map builder ## The short answer This tool builds a 1:1 redirect map for a site migration: add old and new URL rows, then export CSV, Apache Redirect 301 directives, or Nginx permanent rewrite rules. It warns when too many old URLs point at the homepage, a pattern Google says can read as a soft 404, and flags duplicate old URLs before you ship the map. ## Key takeaways - Google's site-move documentation recommends mapping every old URL to its closest real equivalent on the new site rather than to one catch-all destination. - Redirecting many old URLs to an irrelevant single destination, such as the home page, can confuse users and may be treated as a soft 404 error by Google. - Google recommends server side permanent redirects, such as HTTP 301 or 308, for a permanent site move rather than temporary redirects. - Apache's Redirect 301 directive and Nginx's rewrite with the permanent flag both need a path, not a full URL, so this tool strips the domain before generating those two formats. A site migration succeeds or fails on the redirect map more than on almost anything else in the project. Google's own documentation on moving a site with URL changes is specific about what a good map looks like, and this tool builds one against those rules directly: enter old and new URLs, watch the warnings, then export the format your server actually reads. ## Why a 1:1 map beats redirecting everything to the homepage Google's site-move documentation says to decide, for every old URL, where it should redirect to, and it warns against the shortcut migrations reach for under deadline pressure: "don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site." Google states this can confuse users and may be treated as a soft 404 error, which means the redirect can end up carrying none of the old page's ranking signal to anywhere useful. The one documented exception is consolidation: if several old pages now live as sections of one new page, redirecting all of them to that specific page is fine, because it is still each URL's closest real equivalent, not a generic fallback. Google also recommends server side permanent redirects, HTTP 301 or 308, for a move intended to be permanent. A temporary redirect leaves the old URL in a kind of limbo where search engines keep checking whether it will return, which is the opposite of what a domain or path migration needs. ## Apache and Nginx syntax notes The Apache format this tool generates uses mod_alias's `Redirect 301 /old-path /new-path`, an argument order of status code, then old path, then new path, placed in a `.htaccess` file or the site's virtual host config. The Nginx format uses `rewrite ^/old-path$ /new-path permanent;`, where the caret and dollar anchor the match to the exact old path and `permanent` emits a 301. Both directives expect a path, not a full URL with scheme and host, which is why this tool strips the domain from any full URL you paste in before generating those two outputs; the CSV export keeps whatever you typed, full URL or path, since a spreadsheet has no directive syntax to satisfy. ## Usage note Every field here stays in your browser; nothing is sent anywhere. How much this map matters shows up in our study of 892 real domain migrations: the fastest recoveries, 19 to 23 days, all involved complete 1:1 redirect mapping validated before launch, while the slowest cases in the same dataset took over 1,000 days and never recovered at all. Build the map before the migration, not during the cleanup afterward. ## Sources 1. [Site moves with URL changes](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) - Google Search Central (primary) --- --- title: "Bing tests bolded HTTPS and snippets without site names" url: https://seomadman.com/news/bing-serp-display-tests-https-sitenames section: news published: 2026-09-06T00:00:00.000Z modified: 2026-09-06T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Bing tests bolded HTTPS and snippets without site names ## The short answer Microsoft is running two distinct Bing SERP tests spotted in September 2026: bolding just the https portion of displayed URLs, seen so far in sponsored results, and removing site names from snippets so only a favicon plus URL and breadcrumb remain. Both were surfaced by Sachin Patel and reported by Search Engine Roundtable days apart, with no stated rollout date. ## Key takeaways - Search Engine Roundtable reported the HTTPS bolding test on 4 September 2026, currently visible in Bing's sponsored results only. - The same outlet reported the site names removal test on 2 September 2026, showing a favicon and URL with breadcrumbs in place of the bolded site name line. - Both tests were first spotted by Sachin Patel and neither has been confirmed as a full or permanent rollout by Microsoft. - Microsoft has trialed other HTTPS indicators before, including lock icons, so bolding the protocol text is a variation on a recurring theme rather than a first attempt. - Google ran a comparable site name removal test in its own results in May 2025, making the Bing test a parallel experiment rather than a copy of the same test. Microsoft is testing two changes to how Bing displays result snippets, reported by Search Engine Roundtable within days of each other in September 2026: bolding the https portion of the URL, and removing the site name line so a favicon and URL with breadcrumbs stand alone. Both were spotted by Sachin Patel. Neither has a confirmed rollout date or a statement from Microsoft. ## What the HTTPS bolding test does Search Engine Roundtable reported on 4 September 2026 that Bing is bolding just the https segment of the displayed URL in search results, leaving the rest of the URL in normal weight. The treatment had only been observed in sponsored results at the time of reporting; the outlet said it could not reproduce the same bolding in organic listings, so whether it extends there is unverified. This is not Microsoft's first attempt at flagging secure connections in the results page. The company has previously tried other HTTPS indicators, including lock icons next to the URL, before arriving at this bolded-text version. Treat it as another entry in that ongoing experimentation rather than a settled design. ## What the site names removal test does Two days earlier, on 2 September 2026, Search Engine Roundtable reported a separate Bing test that removes the site name from the snippet entirely. In its place, the result shows a favicon followed by the site's URL and breadcrumb path, with no separate bolded site-name line above it. The report included before-and-after screenshots showing the change against Bing's standard snippet layout. ## How it compares to Google's test Search Engine Roundtable's report on the site name change notes that Google tried something similar about a year earlier: in May 2025, Google removed website names from some results and showed the URL instead. Bing's September 2026 test follows the same idea on its own [SERP](/topics/technical-seo), but it is a separate experiment run independently by Microsoft, not a continuation of Google's test or evidence the two companies are coordinating. ## Why we care Neither test has a confirmed rollout, and Microsoft has not published anything explaining either one. What both share is a shift in where trust signals sit in a snippet: HTTPS bolding pulls attention toward the URL's security marker, and site name removal pulls attention away from the brand label a site has spent years building recognition for and puts weight on the raw URL and favicon instead. If either ships broadly, sites that rely on a distinctive site name to stand out in results lose that line, and clean, recognizable domains and favicons become a bigger part of how a result reads at a glance. ## Frequently asked questions ### Are the HTTPS bolding and site name removal the same Bing test? No. Search Engine Roundtable reported them as two separate experiments two days apart in September 2026, one bolding the https segment of the URL and the other removing the site name line from snippets. Nothing published ties them to a single feature. ### Does the HTTPS bolding test appear in organic results? As reported on 4 September 2026, it had only been observed in Bing's sponsored results. The reporting outlet noted it could not replicate the treatment in organic listings. ### Is this the same as Google's site name test? It is a parallel, not a repeat. Google tested removing site names from some results in May 2025, showing the URL instead. Bing's September 2026 test does the same thing on its own results but is a separate experiment run by a different company. ## Sources 1. [Bing Bolds HTTPS In The URLs Of The Search Results](https://www.seroundtable.com/bing-bolded-https-urls-41939.html) - Search Engine Roundtable (primary) 2. [Bing Tests Search Snippets Without Site Names](https://www.seroundtable.com/bing-search-snippets-without-sitenames-41990.html) - Search Engine Roundtable (primary) --- --- title: "Core Web Vitals thresholds checker" url: https://seomadman.com/tools/core-web-vitals-checker section: tools published: 2026-09-06T00:00:00.000Z modified: 2026-09-06T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Core Web Vitals thresholds checker ## The short answer This tool classifies a Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift number against Google's published Core Web Vitals thresholds. Enter values you already have from PageSpeed Insights or the Chrome UX Report and see each metric's rating plus the overall pass, which requires all three to be Good. It does not measure a live page. ## Key takeaways - A page only passes Google's Core Web Vitals assessment when LCP, INP and CLS are all rated Good at once. - Google evaluates these thresholds at the 75th percentile of real user visits, not a single lab measurement. - The current Good thresholds are 2.5 seconds for LCP, 200 milliseconds for INP and 0.1 for CLS. - This tool classifies whatever number you type, so a pass here reflects your input, not a live field measurement of your site. - Everything runs in your browser, so no metric you enter is sent anywhere. This tool classifies three numbers you already have against the thresholds Google publishes for its Core Web Vitals. It does not crawl your site or run a lab test: it is a calculator for numbers pulled from PageSpeed Insights, the Chrome UX Report, or your own monitoring. ## The current thresholds Google rates each metric into Good, Needs Improvement or Poor. Largest Contentful Paint is Good at 2.5 seconds or less and Poor above 4.0 seconds. Interaction to Next Paint is Good at 200 milliseconds or less and Poor above 500 milliseconds. Cumulative Layout Shift is Good at 0.1 or less and Poor above 0.25. Anything between the Good ceiling and the Poor floor is rated Needs Improvement. These are the thresholds documented on web.dev, and Google updates them infrequently but not never: INP replaced First Input Delay as the responsiveness metric in March 2024, so a threshold set is a snapshot, not a permanent fact. ## Why one number here is not Google's real assessment Google's own methodology does not rate a page on one measurement. It rates a page at the 75th percentile of a distribution of real visits, segmented across mobile and desktop, and a page only passes the overall Core Web Vitals assessment when LCP, INP and CLS are all Good at that percentile simultaneously. A single number you paste into this tool tells you where that one measurement would land against the published thresholds, which is useful for sanity-checking a lab result or a specific page load, but it is not the field assessment Search Console and CrUX report on. Treat a pass here as a threshold check, not proof that real users are getting a Good experience. Use this tool to sanity-check numbers from a report you trust, not as a replacement for pulling real field data on the page you actually care about. ## Sources 1. [Largest Contentful Paint (LCP)](https://web.dev/articles/lcp) - web.dev, Chrome team (primary) 2. [Interaction to Next Paint (INP)](https://web.dev/articles/inp) - web.dev, Chrome team (primary) 3. [Cumulative Layout Shift (CLS)](https://web.dev/articles/cls) - web.dev, Chrome team (primary) 4. [Core Web Vitals](https://web.dev/articles/vitals) - web.dev, Chrome team (primary) --- --- title: "Publishers report Google News sitemap data stuck in Search Console" url: https://seomadman.com/news/google-news-sitemap-reporting-lag section: news published: 2026-09-05T00:00:00.000Z modified: 2026-09-05T00:00:00.000Z author: Adam Hafez topics: ["Search Console", "Indexing"] --- # Publishers report Google News sitemap data stuck in Search Console ## The short answer Publishers reported in early September 2026 that Search Console's indexed pages report for their Google News sitemap appeared frozen around August 28-29, while articles were already indexed and showing in Google News. The News source page was also updating slowly, and some articles appeared in Top Stories but not the dedicated News tab. Google has not publicly acknowledged the issue. ## Key takeaways - Publishers on WebmasterWorld reported the indexed pages report for their Google News sitemap appeared stuck around August 28-29, 2026. - The sitemap itself was still being read successfully, and new articles were confirmed indexed and visible in Google News despite the frozen report. - The publisher's Google News source page was also updating slowly, with new articles taking longer than usual to appear there. - Some publishers reported articles showing in regular search results and Top Stories carousels but missing from the dedicated Google News tab. - No public acknowledgment from Google appears in the thread; this is a publisher-observed reporting lag, not a confirmed outage. Publishers began reporting in early September 2026 that the indexed pages report for their Google News sitemap in Search Console had stopped updating, even though their articles were still being crawled, indexed and shown in Google News. It is a narrower problem than an indexing outage: the sitemap submission was working, the articles were live, and only the report describing that work was behind. ## What publishers reported On WebmasterWorld, a publisher posting under the handle Micha described the indexed pages report for their news sitemap as stuck around August 28-29, 2026, despite newer articles continuing to get indexed and show up in Google News search results. The same post said the publisher's Google News source page, the publisher-branded page inside Google News, was updating extremely slowly compared to normal, with new articles taking longer than usual to appear there. A further complication reported in the thread: some articles were showing up in regular search results and in Top Stories carousels while still missing from the dedicated Google News tab. ## Reporting lag, not an indexing failure The distinction matters for how a publisher should react. If a sitemap is genuinely not being read, or articles are genuinely failing to index, the fix is a technical one: check the sitemap for malformed URLs, verify `robots.txt` is not blocking the news sitemap path, and confirm the article markup still meets Google News requirements. None of that applies here. The sitemap was being read, and the underlying articles were indexed and visible in Google News, which points to the indexed pages report itself lagging behind the real index state rather than the index being wrong. Chasing a technical fix for a dashboard that has not refreshed yet would be wasted effort. Google has not issued a public statement acknowledging the report as of this writing. The reports described here come from publishers on WebmasterWorld, not from a Google status page or a Google representative, so this should be read as a community-observed pattern rather than a confirmed and scoped incident. ## Why we care A frozen indexed pages report is easy to mistake for an indexing problem, and a publisher who reacts to a mistaken read can burn time re-submitting sitemaps or auditing article markup that was never broken. The useful check before doing either is the one the WebmasterWorld reports point to: search for a specific recent article directly in Google News and in regular search. If it shows up there, the sitemap and indexing pipeline are working and the report is simply behind. Watch the Google News source page and the indexed pages count over the following days rather than treating a stale number as evidence of a new outage. ## Frequently asked questions ### Is this a Google News indexing outage? No. Publishers reporting the issue said their news sitemap was still being read successfully and that new articles were, in fact, indexed and visible in Google News. What was not working was the Search Console report reflecting that indexing promptly, which makes this a dashboard freshness problem rather than an indexing failure. ### What exactly was stuck in Search Console? The indexed pages report for the news sitemap. A publisher posting on WebmasterWorld on September 6, 2026 said the report had not moved since around August 28-29, even as newer articles kept getting indexed and appearing in Google News. ### Did Google confirm the problem? Not in the source thread. The reports come from publishers on WebmasterWorld, not a Google status update or an acknowledgment from a Google representative, so treat this as a community-observed lag rather than a confirmed Google issue. ## Sources 1. [Google News Sitemap Indexed Pages Report Stuck In Search Console](https://www.webmasterworld.com/google/5133853.htm) - WebmasterWorld (primary) --- --- title: "SearchPilot: removing a breadcrumb link cut organic traffic 5.5%" url: https://seomadman.com/studies/breadcrumb-link-removal-ab-test-searchpilot section: studies published: 2026-09-05T00:00:00.000Z modified: 2026-09-05T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO", "Structured data"] --- # SearchPilot: removing a breadcrumb link cut organic traffic 5.5% ## The short answer SearchPilot, a real SEO A/B-testing firm, split-tested removing the self-referential link from the last breadcrumb on ecommerce product listing pages. The change cut organic traffic by a statistically significant 5.5%. SearchPilot traces the loss to the breadcrumb's schema markup, which was not updated to match the visible HTML change, confusing search engines about the page's structure. ## Key takeaways - SearchPilot's split test found that removing the self-referential link from the last breadcrumb on PLPs cut organic traffic by a statistically significant 5.5%. - The traffic drop was traced to a mismatch between the updated HTML and the breadcrumb's schema markup, which was left unchanged. - SearchPilot did not disclose the exact confidence level or the test's start and end dates in its published case study. - The test ran on real ecommerce product listing pages, isolating the single breadcrumb link as the only variable between control and variant. - Google Search Console's insights tool attributed the drop to a change in rankings rather than a change in clickthrough rate. Most advice on self-referential breadcrumb links, the last item in the trail that links back to the page a visitor is already on, is opinion: some guides call the link dead weight, others call it harmless. SearchPilot, a controlled SEO A/B-testing company, ran an actual split test that removed the link on one set of pages and left it in place on another. The result was a loss, not a gain, and the reason why matters more than the number itself. SearchPilot's own published case study, not our analysis, is the source here. ## What was tested and what SearchPilot found SearchPilot's customer, an ecommerce retailer, removed the self-referential link from the final breadcrumb item on product listing pages, converting it from a clickable link to plain text. The control group kept the link. Everything else on the page, the rest of the breadcrumb trail, product grids, filters and internal linking elsewhere, stayed identical between the two groups. The change produced a statistically significant 5.5% decrease in organic traffic, the opposite of what the customer expected from trimming a link that pointed nowhere new. SearchPilot's Google Search Console insights tool traced the drop to changed rankings rather than a lower clickthrough rate on stable rankings, meaning search engines were surfacing the pages less often or less prominently, not just that fewer people clicked the same listings. The stated cause is not the missing link on its own. It is that the breadcrumb's structured data markup was left describing a link that the visible HTML no longer had. SearchPilot calls that mismatch between schema and markup the likely source of the ranking drop: when the data that tells search engines how a page's hierarchy is wired disagrees with what a crawler actually renders, the page's structure becomes harder to interpret correctly. ## Why a controlled split test beats a before-and-after read A retailer that made this same change without running a split test would have seen traffic fall sometime afterward and had no reliable way to separate the breadcrumb edit from a core update, a seasonal dip or an unrelated sitewide change landing in the same window. SearchPilot's variant and control pages ran at the same time, on the same site, exposed to the same external conditions, so the 5.5% figure can be attributed to the one difference between the groups: the breadcrumb link and its now-mismatched schema. That same design is what let our [coverage of SearchPilot's FAQ content test](/studies/faq-content-ab-test-searchpilot) separate a real content lift from a schema change that did nothing on its own. Here the pattern runs the other way: a markup-level inconsistency, not the visible content, is what SearchPilot points to as the cause of a real loss. Both readings only hold because the comparison happened concurrently rather than across two time periods. ## Why we care The lesson is not "leave every self-referential breadcrumb link alone." It is that a markup change which looks purely cosmetic, converting one link to plain text, carries a second, easy-to-miss dependency: the structured data describing that same element. SearchPilot's case study reports a change made to the HTML without a matching change to the schema, and a real, measured traffic loss that followed. Anyone editing breadcrumb behavior should treat the visible markup and its schema as one unit to update together, and verify both, rather than assuming a small link removal has no structural side effects. ## Frequently asked questions ### What exactly did SearchPilot remove from the breadcrumb? Only the hyperlink on the last breadcrumb item, the one that pointed back to the page it was already on. The breadcrumb trail itself, and the text of that final item, stayed in place; only the self-referential link was stripped out and replaced with plain text. ### Why would removing a link to the current page hurt traffic at all? SearchPilot's own reading is that the harm did not come from the link removal itself but from an unrelated side effect, the breadcrumb's schema markup was not updated to match, so it still described a link that no longer existed in the HTML, likely confusing how search engines read the page's structure. ### Does this mean self-referential breadcrumb links should never be removed? SearchPilot frames the result as evidence about this specific implementation, an unsynced schema change, not a blanket rule against removing the link. A team making the same change with its schema markup updated in step would be testing a different, cleaner variable than the one this case study measured. ## Sources 1. [Will Removing Self-Referential Breadcrumb Links Improve Organic Traffic?](https://www.searchpilot.com/resources/case-studies/removing-self-referential-breadcrumb) - SearchPilot (primary) --- --- title: "Canonical tag checker" url: https://seomadman.com/tools/canonical-tag-checker section: tools published: 2026-09-05T00:00:00.000Z modified: 2026-09-05T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Canonical tag checker ## The short answer This tool checks a page URL against its declared canonical URL using the browser's own URL constructor. It verifies the canonical is an absolute URL, matches HTTPS, flags self-referencing versus cross-referencing canonicals, checks same-domain versus cross-domain targets, and flags tracking parameters left in the canonical. ## Key takeaways - Google recommends an absolute URL for rel=canonical, not a relative path. - A self-referencing canonical and a cross-referencing canonical are both valid, but they mean different things. - Google's documentation names redirects and rel=canonical annotations as strong signals, and sitemap inclusion as a weak one. - A canonical URL that still carries tracking or session parameters defeats the purpose of consolidating duplicate URLs. - This tool cannot detect a second conflicting canonical tag because it only reads the two URLs you type. Paste a page URL and the canonical URL it declares, and this tool checks the pair against Google's own documented canonicalization guidance. Every check below traces to a specific line in that documentation rather than to general SEO advice, and nothing typed into the tool leaves the browser: both URLs are parsed with the native URL constructor. ## Self-referencing versus cross-referencing canonicals A self-referencing canonical is a page's rel=canonical tag pointing back at itself. Google's documentation recommends including one on the canonical page itself, alongside whatever other pages point to it as duplicates. A cross-referencing canonical points somewhere else entirely, telling Google this page is a duplicate or near-duplicate of another URL. Both are correct, documented uses of the same tag; they are just answering different questions. A self-referencing canonical says "this is the version to index." A cross-referencing one says "index that one instead, not this one." Confusing the two, for example by leaving a self-referencing canonical on a page that is actually a duplicate, is a common way sites accidentally tell Google to keep indexing near-identical pages separately. ## The real signals Google uses when it overrides a declared canonical Google's documentation is explicit that a declared canonical is a hint, not a rule, and names the signals it actually weighs. Redirects and rel=canonical link annotations are both named as strong signals; a permanent redirect and an explicit canonical tag carry similar, high weight. Inclusion in a sitemap is named as a weaker signal on its own, though the documentation notes that stacking more than one of these methods toward the same target increases the odds that Google follows it. Beyond those three explicit methods, Google's documentation lists two further signals based on site setup rather than page markup: it prefers HTTPS over an equivalent HTTP version, and it prefers a URL that is part of an hreflang cluster. None of these override a correctly declared, self-consistent canonical in ordinary cases; they matter most when a site sends Google mixed signals, such as a sitemap listing one URL while the page markup points somewhere else. Run this check while a canonical tag is still in a draft template, before it ships to every page that template controls, since a mistake here quietly repeats across the whole site rather than showing up on a single page. ## Sources 1. [How to specify a canonical URL with rel="canonical" and other methods](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) - Google Search Central (primary) 2. [What is URL canonicalization](https://developers.google.com/search/docs/crawling-indexing/canonicalization) - Google Search Central --- --- title: "robots.txt tester: check a user-agent against a path" url: https://seomadman.com/tools/robots-txt-tester section: tools published: 2026-09-04T00:00:00.000Z modified: 2026-09-04T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # robots.txt tester: check a user-agent against a path ## The short answer This tool tests an existing robots.txt against one user-agent and one URL path, and shows which specific Allow or Disallow line decided the outcome. It applies the real precedence rule from RFC 9309: the most specific user-agent group, then the longest matching path, not the first or last rule written. ## Key takeaways - The most specific user-agent group applies, and the tool only falls back to the wildcard group when no named group matches. - Within a matched group, the longest matching Allow or Disallow path wins, not whichever rule happens to appear first or last in the file. - An Allow and a Disallow of equal length resolve in favor of the Allow rule, per RFC 9309. - This tester checks an existing robots.txt from the testing direction, which complements the site's generator tool that writes a new file from a crawler policy. - Wildcard characters match any sequence of characters, and a trailing dollar sign anchors a rule to the exact end of the URL. Publishing a robots.txt is easy. Knowing what it actually does to one crawler on one path is the part most people get wrong, because the rule that wins is not the rule they expect. ## Longest match wins, not first or last match Within the group that applies to a crawler, RFC 9309 says the rule with the most matching characters decides the outcome, regardless of where it sits in the file. A short `Disallow: /admin` followed later by a more specific `Allow: /admin/public` does not lose to whichever line comes last: the Allow rule is longer, so it wins, and a request for `/admin/public/page.html` is allowed even though `/admin` alone is blocked. This trips people up in both directions. A broad Disallow near the top of the file feels like it should win because it was written first; a narrow Allow added later feels like an afterthought. Neither position matters. Only length does, and when an Allow and a Disallow match with exactly the same number of characters, the specification breaks the tie in favor of the Allow. Group selection works the same way, one level up. A crawler that matches a named group, such as `Googlebot`, follows that group's rules and ignores the wildcard group entirely, even if the wildcard group would have produced a different verdict. Only a crawler with no named group falls back to `*`. ## Testing, not generating The site's other robots.txt tool asks a different question: given a policy decision about which AI crawlers may take your content, what should the file say? That tool writes a robots.txt and an llms.txt from a set of yes-or-no choices per crawler. This tool runs the file forward instead of writing it. Paste what already exists, or a draft before you publish it, and check what it actually permits for one crawler and one path. Use the generator to decide the policy; use this tool to confirm the file you ended up with encodes that policy correctly, especially once wildcards and multiple groups are involved and the interaction between rules stops being obvious on a read-through. Remember that robots.txt is a request a well-behaved crawler chooses to honor, not an access control mechanism. A verdict of disallowed here describes what the file says, not what every bot in the wild will do with it. ## Sources 1. [RFC 9309: Robots Exclusion Protocol](https://www.rfc-editor.org/rfc/rfc9309.html) - IETF (primary) 2. [How Google interprets the robots.txt specification](https://developers.google.com/search/docs/crawling-indexing/robots/robots_txt) - Google Search Central --- --- title: "Does llms.txt do anything? Three studies say mostly no" url: https://seomadman.com/studies/llms-txt-measured-traffic-impact section: studies published: 2026-09-03T00:00:00.000Z modified: 2026-09-03T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # Does llms.txt do anything? Three studies say mostly no ## The short answer Three independent checks asked whether llms.txt changes anything measurable, not how many sites have one. Ahrefs found 97% of ~38,360 valid files got zero AI-bot requests in May 2026. Search Engine Land tracked 10 sites for 90 days and found no traffic change in 8. A lone +11% citation figure carries its own author-stated confound. ## Key takeaways - Ahrefs' server-log analysis found 97% of roughly 38,360 domains with a valid llms.txt file received zero AI-bot requests for it in May 2026. - Search Engine Land tracked 10 sites for 90 days before and after adding llms.txt and found no measurable traffic change in 8 of them. - The two Search Engine Land sites that grew did so from new functional content, not from the file itself, per the article's own analysis. - An independent researcher measured an 11% citation lift on Claude and Perplexity across four properties, then said plainly his design cannot attribute it cleanly to llms.txt. - No study reviewed here isolates llms.txt as the sole cause of any change, which is a different and harder question than whether sites publish one at all. Two pieces on this site have already asked who publishes an llms.txt file. Our [adoption study](/studies/llms-txt-adoption-2026) found 14 of 60 major sites serve one, concentrated among SEO vendors and developer platforms. Our [tracker comparison](/reports/llms-txt-adoption-tracker-comparison) showed five trackers disagreeing on the adoption rate because none measured the same population. Neither piece asked the harder question: once a file exists on a server, does anything read it, and does having one change what an AI system does with the site. Three separate checks published in 2026 answer that question, and the answer is mostly no. ## The usage gap Ahrefs found underneath its own adoption number Ahrefs' analysis of 137,210 domains running its Web Analytics or Bot Analytics product found 28% serve a valid llms.txt file, roughly 38,360 domains, a figure already used in our tracker comparison. The same report goes further, checking server logs for whether anything actually requested those files. In May 2026, 97% of the roughly 38,360 valid files received zero requests. Ahrefs is explicit that even the remaining 3% is a ceiling on real usage, not a floor: a fetch does not mean the content was read or acted on, since "many bots may have fetched the llms.txt file without ever acting on what's inside." A file that nothing requests cannot be doing anything for the site that published it, which makes the adoption question and the usage question genuinely different findings, not two ways of stating the same one. ## Two small tests, two honest limitations Search Engine Land tracked 10 sites across finance, B2B SaaS, ecommerce, insurance and pet care, measuring AI traffic and crawl frequency for 90 days before and after adding llms.txt. Eight sites showed no measurable change. One declined 19.7%, a drop the piece attributes to unrelated causes. Two grew, 25% and 12.5%, but the article's own analysis credits that growth to new functional content the sites published alongside the file, not to the file itself: "llms.txt documented those efforts. It didn't drive them." A 10-site sample cannot settle the question for the whole web, and the piece does not claim it does. The one positive figure in this space comes from an independent researcher who tracked citations across four of his own properties over 90 days and measured an 11% overall lift after publishing llms.txt, concentrated almost entirely on Claude and Perplexity with no movement on ChatGPT Search or Google AI Overviews. He then undercut his own headline number in the same piece: "my +11% observation came from a window in which several changes shipped together, so the design does not support attributing it cleanly to llms.txt." That sentence is the reason this figure belongs in this piece at all. A researcher willing to name the hole in his own methodology, on a corpus he controls, is more useful than a cleaner-looking number from someone who did not check. ## Why we care **Adoption and impact are two different claims, and only one of them has evidence behind it right now.** Fourteen sites in sixty publishing a file, per our adoption study, tells you nothing about whether the file did anything once published. The usage and traffic data above is the actual answer to that second question, and it is a weak one: near-total non-use in the large sample, no effect in most of the small traffic test, and a positive citation number its own author will not stand behind without a caveat. **If a vendor pitches llms.txt as a traffic or citation lever, ask which of these three studies they are relying on.** None of the three supports a clean causal claim. The Ahrefs number shows the file mostly sits unread. The Search Engine Land test shows no effect in 8 of 10 real sites. The one number that moved comes from a researcher who told you himself not to trust it as isolated evidence, which is the standard every figure in [AI search](/topics/ai-search) coverage should be held to before it goes in a deck. ## Frequently asked questions ### Does publishing llms.txt increase AI citations or traffic? The best evidence available says usually not. Ahrefs found 97% of published files never get requested at all, and Search Engine Land's 10-site traffic test found no measurable change in 8 cases. One independent researcher measured an 11% citation lift, but stated himself that his own study design cannot attribute it cleanly to the file. ### Is this the same finding as the site's llms.txt adoption research? No. Our [adoption study](/studies/llms-txt-adoption-2026) and [tracker comparison](/reports/llms-txt-adoption-tracker-comparison) both measure who publishes a file. This piece asks a separate question: whether publishing one changes anything an AI bot does afterward. ### Why trust an 11% figure the author himself calls confounded? We are not treating 11% as a clean effect size. We are citing it because the author's own stated limitation, that several changes shipped in the same 90-day window and his design cannot isolate llms.txt from them, is the same honesty this site's sourcing rule requires, and it is a more useful data point with that caveat attached than without it. ## Sources 1. [We Analyzed 137K Sites: 97% of llms.txt Files Never Get Read](https://ahrefs.com/blog/llmstxt-study/) - Ahrefs (primary) 2. [Does llms.txt matter? We tracked 10 sites to find out](https://searchengineland.com/does-llms-txt-matter-467740) - Search Engine Land (primary) 3. [The GEO Measurement Study: 50,000 AI Citations in 90 Days, What Actually Moves Citation Share](https://guptadeepak.com/the-geo-measurement-study-50000-ai-citations-in-90-days-what-actually-moves-citation-share/) - Deepak Gupta --- --- title: "Sitemap vs robots.txt conflict checker" url: https://seomadman.com/tools/sitemap-robots-conflict-checker section: tools published: 2026-09-03T00:00:00.000Z modified: 2026-09-03T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Sitemap vs robots.txt conflict checker ## The short answer This tool cross-references a pasted sitemap against a pasted robots.txt file, extracting every loc URL and applying the same longest-match-wins precedence rule the site's robots.txt tester uses, then flagging any URL that the sitemap asks a crawler to fetch while robots.txt tells the same crawler not to fetch it. ## Key takeaways - A URL can be listed in a sitemap while also being blocked by a robots.txt Disallow rule for the same crawler. - This checker applies the exact longest-match-wins precedence rule from RFC 9309 that the site's robots.txt tester uses. - Google's own documentation states plainly that a disallowed URL will not be crawled, but does not explicitly address the sitemap conflict case. - Every conflict flagged here means the sitemap requests a crawl that robots.txt refuses for the tested user-agent. - Fixing a conflict means removing the URL from the sitemap or narrowing the Disallow rule, not just noting the mismatch. A sitemap tells a search engine "these pages exist, please crawl them." A robots.txt Disallow rule tells the same crawler "do not fetch this path." Both files can be published, both can be internally consistent, and still disagree with each other about the same URL. This tool pastes both files in, applies each one's own real parsing rules, and lists every sitemap URL that lands on the wrong side of that disagreement. ## Why this conflict happens in practice Nobody sets out to block a URL they also submitted for crawling. It happens because the two files are usually generated by different systems on different schedules: a build step or a CMS plugin regenerates the sitemap automatically from whatever pages exist right now, while robots.txt is a hand-maintained file that someone edited once and rarely revisits. A new section gets added to the disallow list to keep a staging path or an internal search results page out of the index, the sitemap generator has no idea that rule exists, and it keeps listing every URL under that path anyway. The two files drift apart silently because nothing in a normal deploy pipeline checks them against each other, which is exactly the gap this tool fills. ## What Google's documentation confirms, and what it does not Google's robots.txt introduction states plainly that content blocked by robots.txt will not be crawled or indexed by Google, while separately noting that a disallowed URL can still surface in search results without a description if other sites link to it, since the block prevents fetching the page, not knowledge of its existence. Google's sitemap documentation, read alongside it, never mentions the reverse case: neither page says what happens, or what Search Console reports, when a URL you deliberately submitted in a sitemap is also disallowed. That specific interaction is not addressed in either document, so this tool's honest claim is limited to the general rule both pages do state, applied mechanically to every URL you paste, rather than any specific documented outcome for the conflict itself. ## Using the result A flagged conflict is a signal to check intent, not an automatic bug. If the path was disallowed on purpose, the fix is almost always to drop it from the sitemap, since submitting a URL you are simultaneously blocking wastes crawl attention on a page the crawler is refusing to fetch. If the path should be crawlable, the fix is the Disallow rule instead. Either way, treat every conflict this tool reports as a decision to make, and recheck the pair of files here again once you have made it. ## Sources 1. [Robots.txt introduction and guide](https://developers.google.com/search/docs/crawling-indexing/robots/intro) - Google Search Central (primary) 2. [Build and submit a sitemap](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap) - Google Search Central 3. [RFC 9309: Robots Exclusion Protocol](https://www.rfc-editor.org/rfc/rfc9309.html) - IETF --- --- title: "Readability and reading time calculator" url: https://seomadman.com/tools/readability-reading-time-calculator section: tools published: 2026-09-02T00:00:00.000Z modified: 2026-09-02T00:00:00.000Z author: Adam Hafez topics: ["Content strategy"] --- # Readability and reading time calculator ## The short answer This tool scores pasted text with the standard Flesch reading ease formula, then estimates how long an adult takes to read it silently. It counts words, sentences and syllables live in your browser as you type, shows the score's plain language band from very easy to very confusing, and flags where each estimate is a heuristic, not a lookup. ## Key takeaways - The Flesch reading ease score comes from a published 1948 formula that weighs average sentence length and average syllables per word. - A higher score means easier text, and the score bands run from very easy at 90 to very confusing below 30. - Reading time is estimated at 238 words per minute, the adult silent reading average for non-fiction from a 2019 meta-analysis of 190 studies. - Syllable counting here is a vowel-group heuristic rather than a dictionary lookup, so it will miscount some words. - Sentence counting splits on end punctuation and cannot always distinguish an abbreviation from a real sentence break. Word count and sentence count are simple to get right. Readability is not, which is why the Flesch reading ease score exists: it turns sentence length and word complexity into a single number that correlates, on average, with how hard a passage is to follow. This tool computes that score and a reading time estimate entirely in your browser as you type. ## What the Flesch score actually measures The formula is 206.835 minus 1.015 times the average number of words per sentence, minus 84.6 times the average number of syllables per word. It rewards short sentences and short words, and it penalizes long ones. A score near 100 describes text built from short sentences and mostly one or two syllable words; a score near 0 describes long sentences built from long words. The score does not read for meaning, logic or accuracy. A grammatically broken string of short words can score high, and a precise technical sentence that needs its length to stay accurate can score low. Treat the number as a proxy for surface complexity, not as a verdict on whether the writing is good. ## Two honest limitations in this tool Sentence counting splits the text on a period, exclamation mark or question mark. It has no way to know that "Dr. Smith arrived." is one sentence rather than two, so text with many abbreviations, decimals or initials will read as having more sentences than it actually has, which understates the average sentence length. Syllable counting groups consecutive vowels and applies a small set of English spelling rules, including dropping a silent trailing e. It is the same approach used by most open readability tools that do not ship a pronunciation dictionary, and it will misjudge some irregular words. The Flesch score computed here should be read as a close estimate, not an exact figure. Paste a full paragraph, not a single sentence, for a stable score: short inputs swing widely on both the sentence-splitting and syllable-counting heuristics above. ## Frequently asked questions ### Where do the 206.835, 1.015 and 84.6 numbers come from? They are the coefficients of Rudolf Flesch's 1948 reading ease formula, published as 206.835 minus 1.015 times average sentence length minus 84.6 times average syllables per word. The constants have not changed since; they are reproduced in readability references and in most editing software. ### Why does the reading time not match how fast I actually read? 238 words per minute is a population average for silent reading of non-fiction text, drawn from a meta-analysis of 190 studies. Individual readers vary widely, and denser or more technical text is read more slowly than the average passage the studies sampled. ### Can I trust the syllable count for every word? No. It counts vowel groups and handles a few common English patterns, such as a silent trailing e, but it has no dictionary of real pronunciations. Words with unusual spelling, proper nouns and loanwords are the most likely to be miscounted. ## Sources 1. [Learn about the Flesch Reading Ease Formula](https://readabilityformulas.com/learn-about-the-flesch-reading-ease-formula/) - Readability Formulas (primary) 2. [How many words do we read per minute? A review and meta-analysis of reading rate](https://www.sciencedirect.com/science/article/abs/pii/S0749596X19300786) - Journal of Memory and Language (primary) --- --- title: "Keyword cannibalization checker" url: https://seomadman.com/tools/keyword-cannibalization-checker section: tools published: 2026-08-31T00:00:00.000Z modified: 2026-08-31T00:00:00.000Z author: Adam Hafez topics: ["Content strategy"] --- # Keyword cannibalization checker ## The short answer This free checker compares titles or H1s across your own pages and scores word-overlap similarity using the Jaccard method, entirely in your browser. Pairs above your chosen threshold are flagged for review. Google has never published an official cannibalization threshold; this heuristic only estimates overlap, not ranking impact or Google's actual selection process. ## Key takeaways - Cannibalization is SEO-industry jargon that Google itself does not officially use. - The similarity score is computed with Jaccard similarity, the size of the intersection of significant words divided by the size of their union. - Google's real guidance covers canonicalization and duplicate content, where its own systems choose which of your competing pages to show. - The 50 percent default threshold is this tool's own heuristic and not a number Google has published anywhere. - All comparison happens in your browser, so no title or URL you enter is ever sent anywhere. Two pages on the same site can end up chasing the same query without anyone deciding that on purpose: a new post gets written, an old guide never gets updated, and both sit in the index with titles that say almost the same thing. This tool compares the titles or H1s you enter and scores how much significant wording they share, so you can spot the pairs worth a closer look before you merge, redirect or rewrite anything. ## How the similarity score works Each title is lowercased, stripped of punctuation, and split into words. A small, deliberately non-exhaustive English stopword list, words like "a", "the", "and", "of" and "for", is removed from each side, because these carry no topical signal and would inflate every score. What is left is a set of significant words for each title. Jaccard similarity is then the size of the intersection of the two sets divided by the size of their union, expressed as a percentage. Two titles that share every significant word score 100%. Two titles that share none score 0%. A pair like "Best running shoes for 2026" and "Top running shoes: 2026 review" shares "running", "shoes" and "2026" out of a combined set of six significant words, a worked example the tool's own prefilled rows demonstrate directly. ## Cannibalization is jargon, canonicalization is the real mechanism "Cannibalization" is a term the SEO industry uses, not one Google's own documentation uses. What Google has actually published, in its guidance on consolidating duplicate URLs, is that when several pages on a site are similar enough, its systems select one canonical URL to show for a given query and may fold the others' signals into it. Which page gets chosen is decided by Google's own systems, not by which one you intended to rank. That is the real, citable mechanism behind the industry term. No Google document states a title similarity percentage that defines when this happens, so treat any number, including the 50% default in this tool, as a heuristic for where to look, not a threshold Google enforces. Run the check periodically as new pages are published, since overlap tends to build up gradually rather than appear all at once. ## Frequently asked questions ### Is cannibalization an official Google term? No. It is SEO-industry jargon for two pages competing for the same query. Google's own documentation talks about duplicate content and canonicalization instead, where its systems pick one URL to represent a set of near-identical pages in results. ### Why Jaccard similarity and not something more advanced? Jaccard similarity on significant words is simple, explainable and fully computable in the browser. It measures literal word overlap in a title, not meaning, so it is a starting signal for a manual check, not a ranking prediction. ### Does the threshold come from Google? No. Google has never published a similarity percentage that defines when two pages compete for a query. The 50% default here is this tool's own configurable heuristic, adjust it to match how strict you want the check to be. ## Sources 1. [Consolidate duplicate URLs](https://developers.google.com/search/docs/crawling-indexing/canonicalization) - Google Search Central (primary) 2. [How Search organizes information](https://developers.google.com/search/docs/fundamentals/how-search-works) - Google Search Central --- --- title: "SearchPilot: canonicalizing to a variant lifted variant traffic 22%" url: https://seomadman.com/studies/canonical-product-variant-ab-test-searchpilot section: studies published: 2026-08-30T00:00:00.000Z modified: 2026-08-30T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # SearchPilot: canonicalizing to a variant lifted variant traffic 22% ## The short answer SearchPilot, a real SEO A/B-testing firm, split-tested canonicalizing ecommerce product pages to a specific variation's URL instead of a self-referential tag. Variation pages saw an estimated 22% organic traffic uplift. Main pages saw no negative impact, and SearchPilot itself calls that half of the test inconclusive, even though it deployed the change overall. ## Key takeaways - SearchPilot's split test canonicalized product pages to a specific variation's URL instead of each variation carrying its own self-referential canonical. - The client had made all product variation pages self-referentially indexable beforehand, but saw inconsistent indexing and lower organic traffic than hoped. - Variation pages saw a positive result, with SearchPilot's best estimate a 22% organic traffic uplift on those pages. - Main product pages saw no negative impact, but SearchPilot describes that side of the test as inconclusive overall. - SearchPilot called its combined result positive and rolled the canonical change out to all relevant products, without disclosing the test's start and end dates. Canonical tags are supposed to be the quiet part of technical SEO: point a duplicate at the URL that should rank, and stop worrying about it. SearchPilot, a controlled SEO A/B-testing company, ran an actual split test on the opposite of the usual advice, canonicalizing a product page away from itself and onto a specific variation's URL. SearchPilot's own published case study, not our analysis, is the source for what follows. ## What was tested and what SearchPilot found The client's site used one URL for a product's main page and a separate URL per variation, size or quantity, distinguished by a parameter. Before the test, every one of those variation pages carried a self-referential canonical, keeping each one independently indexable. According to SearchPilot, "those pages were not getting indexed consistently, and were not receiving as much organic traffic as had been hoped," despite being made indexable on their own. The test changed the main product page's canonical tag to point at one specific variation's URL instead of at itself, testing whether consolidating signal onto a chosen variant would get that variant indexed and ranking reliably, while the main page kept performing in parallel. SearchPilot tracked main pages and variation pages as two separate outcomes rather than one blended number, the same separation our [canonical tag checker](/tools/canonical-tag-checker) draws between a self-referencing canonical and a cross-referencing one. Variation pages produced SearchPilot's stated result: "a positive result, with the best estimate being a 22% uplift to organic traffic to those pages." Main pages saw no negative impact, but SearchPilot's own wording calls that half "inconclusive overall." It does not publish a confidence interval for the 22% figure, and it does not disclose how long the test ran, gaps consistent with what this site has found across SearchPilot's other published case studies. ## Reading a mixed result honestly This is not a clean, universal win, and SearchPilot does not present it as one. One page type, variation pages, shows a real, estimated traffic gain from a single tag change. The other page type, main product pages, shows no measured harm but also no measured gain, which is a genuinely different statistical statement than a proven improvement. SearchPilot's own combined verdict, "the overall result was positive, and this change was deployed to all relevant products," rests on those two pieces together: a documented gain on one side, no cost on the other. Reporting the 22% alone, without the inconclusive main-page result sitting next to it, would overstate what SearchPilot itself measured. SearchPilot also flags that the result is conditional on site structure: variation count per product, internal linking, and how long products stay live on the site all shape whether the same change would replicate elsewhere. That caveat sits alongside the pattern our [breadcrumb link removal coverage](/studies/breadcrumb-link-removal-ab-test-searchpilot) already established, that a single markup-level signal can move indexation and traffic in either direction depending on implementation details a case study can't fully generalize away. ## Why we care A self-referencing canonical on every product variation looks like the safe, textbook choice, and our canonical tag checker treats it as valid because it is. This test is evidence that valid does not always mean effective: the client's variation pages were indexable and still underperformed, and pointing their canonical at a single variant instead measurably helped that subset without detectably hurting the pages that gave up the signal. Anyone running a similar product-variation setup should treat SearchPilot's 22% as a real but conditional data point, not a rule to apply site-wide without testing it against their own indexing and linking structure first. ## Frequently asked questions ### Did every product page in the test get a different canonical target? Yes, in effect. The site's structure used one URL for the main product page, plus a separate URL per variation distinguished by a parameter. The test pointed the main page's canonical at one of those variation URLs instead of at itself. ### Was the 22% uplift statistically significant? SearchPilot reports it as its best estimate for a positive result on variation pages, not as a certainty. It does not publish a confidence interval for that figure in the case study, the same gap it leaves on test duration. ### If the overall test was inconclusive, why did SearchPilot deploy the change? The inconclusive label applies specifically to the main product pages, which saw no negative impact either way. SearchPilot's own combined verdict, main pages unharmed plus a real estimated gain on variation pages, is what it calls positive, and that combined verdict is what it shipped. ### Does this contradict SearchPilot's breadcrumb schema test, where an HTML change caused a loss? No, they test different mechanisms. The breadcrumb test lost traffic to a schema and markup mismatch left behind by an edit. This test changed only the canonical tag's target, a single documented signal, and measured indexation and traffic on two page types separately. ## Sources 1. [Canonicalising to Product Variation Pages](https://www.searchpilot.com/resources/case-studies/canonicalising-to-product-variation-pages) - SearchPilot (primary) --- --- title: "Google confirms AI Overviews now auto-expand on some queries" url: https://seomadman.com/news/ai-overviews-dynamic-expansion section: news published: 2026-08-29T00:00:00.000Z modified: 2026-08-29T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # Google confirms AI Overviews now auto-expand on some queries ## The short answer Google confirmed on 28 August 2026 that AI Overviews can automatically expand into a full, detailed answer for some queries, resembling AI Mode, rather than staying compact behind a Show more control. Expansion cancels if a person has already started scrolling toward results below. Google has not said which query categories qualify or how often it happens. ## Key takeaways - Google confirmed on 28 August 2026 that AI Overviews can dynamically expand into a full, detailed answer on some queries. - The expanded form drops the traditional Show more control and resembles the presentation of AI Mode. - A Google spokesperson said the systems decide expansion per topic where it determines the fuller answer is most useful. - The automatic expansion cancels if a person has already started scrolling toward the results below the overview. - Google has not disclosed which query categories trigger expansion, how often it happens, or which ranking signals decide it. Google confirmed on 28 August 2026 that AI Overviews can now automatically expand into a full, detailed answer on some queries, rather than staying in the compact form behind a Show more control. A Google spokesperson told Search Engine Land: "For some queries, AI Overviews may dynamically expand for topics where our systems determine it's most useful for people." The expanded layout drops the Show more control entirely and resembles the presentation of AI Mode inside standard Search results. ## What does the expanded AI Overview look like? Instead of a short summary capped by a Show more link, qualifying queries now return the complete detailed answer immediately, pushing the standard organic results further down the page. Google said the change is meant to help people who want depth without an extra click: "Our research has shown that with this dynamic experience, users find Search more helpful and engage deeper in follow-up exploration." ## When does the expansion cancel? Google said the automatic expansion can be reversed mid-scroll. If a person has already started scrolling down toward the results below the overview, the system treats that as a signal the person wants standard results and cancels the expansion rather than forcing the longer answer on them. That framing suggests Google is weighing answer completeness against a user's evident intent to reach the rest of the page, on a per-session basis rather than a fixed per-query rule. ## What has Google not said? Google has not disclosed which query categories get the expanded treatment, how frequently it happens, or what ranking signals decide it. Search Engine Land reported the confirmation on 28 August 2026; 9to5Google independently observed the larger AI Overviews layout in its own coverage days later, but neither the trigger logic nor a rollout percentage has been published. ## Why we care A dynamically expanding AI Overview pushes organic results further down the page on an unknown subset of queries, without any stated way to detect which queries are affected before they change under you. Until Google publishes more, the only defensible position is what is confirmed: the Show more control can disappear, the expansion can cancel on scroll, and the selection logic is undisclosed. ## Frequently asked questions ### Does the Show more button still appear in AI Overviews? Not when a query qualifies for the dynamic expansion. Google removes the Show more control entirely and renders the full answer up front, so there is no click gate between the compact summary and the detailed one. ### Can the automatic expansion be stopped once it starts? Yes. Google said the expansion cancels if a person has already begun scrolling toward the standard results below the overview, so it does not override someone who is visibly trying to reach organic listings. ### Which searches trigger the bigger AI Overview? Google has not said. It described the decision as systems determining a topic is one where the fuller answer is most useful, without naming query categories, a rollout percentage, or the ranking signals involved. ## Sources 1. [Google is dynamically expanding AI Overviews for some queries](https://searchengineland.com/google-is-dynamically-expanding-ai-overviews-for-some-queries-486200) - Search Engine Land (primary) 2. [Google Search AI Overviews are getting bigger](https://9to5google.com/2026/08/31/google-search-ai-overviews-bigger/) - 9to5Google --- --- title: "Bulk title and meta description length checker" url: https://seomadman.com/tools/bulk-title-meta-checker section: tools published: 2026-08-29T00:00:00.000Z modified: 2026-08-29T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Bulk title and meta description length checker ## The short answer Paste many pages at once, one per line as URL, title and description, and this tool measures every title and description in pixels the way Google truncates them. It flags which pages would be cut on desktop or mobile, so a template-level problem across dozens of pages shows up in one pass instead of page by page. ## Key takeaways - Checking one page at a time hides a pattern that only shows up across many pages, such as a CMS template that always produces a title too long to fit. - Every title and description is measured in pixels with the same canvas technique as the single-page SERP preview tool, not by counting characters. - Rows that would truncate on the selected device are highlighted, so a large batch of pages can be scanned for problems in seconds. - Nothing typed into this tool is sent anywhere; every measurement happens in your browser. Most title and description problems are not written by a person typing into one field, they are generated by a template. A product page layout that always appends "| Brand Name - Free Shipping" to a title works fine for short product names and silently truncates for long ones, and nobody notices until dozens of listings in search results end mid-word. ## Why bulk checking catches what single-page tools miss A single-page preview tool answers one question well: does this one title fit. It cannot answer the question that actually matters at scale, which is whether the pattern your CMS or your templating logic produces holds up across every page that uses it. Paste an export of fifty product titles built from the same template and a systemic problem, such as a category name that pushes every title past the pixel budget, shows up as a cluster of highlighted rows rather than one edited field. ## When to use the single-page tool instead For a one-off check while editing a single page, the [SERP snippet preview](/tools/serp-snippet-preview) tool is faster: it shows the rendered snippet itself, not just a pass or fail width, which helps when you are still writing the copy rather than auditing what already shipped. Use that tool while drafting a page, and use this one after a crawl or export to confirm the whole site follows the pattern you intended. ## Reading the results A row marked truncated on mobile but not on desktop is not a bug in the tool, it reflects a real difference in how much width each layout allows. Fix the copy for the narrower of the two limits if the page needs to hold up everywhere, or accept the mobile truncation if the front-loaded part of the title still carries the meaning on its own. ## Frequently asked questions ### Why check many pages at once instead of one at a time? A single-page preview only ever shows you one outcome. Most truncation problems are not one bad title, they are a template that produces the same too-long pattern on every product page or every blog post. Checking a batch is the only way to see that pattern rather than one symptom of it. ### How is the pixel width calculated? The exact same way as the single-page SERP preview tool, by drawing each string with the browser's canvas text API at the font sizes Google uses in results, then reading back the rendered width. That is closer to real truncation than any character-count rule. ## Sources 1. [Control your title links in search results](https://developers.google.com/search/docs/appearance/title-link) - Google Search Central (primary) 2. [Control your snippets in search results](https://developers.google.com/search/docs/appearance/snippet) - Google Search Central (primary) --- --- title: "DOM.RIA's internal linking rebuild and its Googlebot crawl visits" url: https://seomadman.com/studies/internal-linking-crawl-coverage-case section: studies published: 2026-08-27T00:00:00.000Z modified: 2026-08-27T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # DOM.RIA's internal linking rebuild and its Googlebot crawl visits ## The short answer JetOctopus's own case study describes real estate marketplace DOM.RIA replacing a footer sitemap with mini-sitemaps linking directory pages, streets, districts and metro stations, to catalog pages Googlebot already crawled heavily. Over matched 15-day windows before and after, Googlebot visits to street pages rose from 525,000 to 1,398,000, district pages from 196,000 to 450,000. ## Key takeaways - JetOctopus's case study describes client DOM.RIA, a Ukrainian real estate marketplace, restructuring internal links to its geography-based directory pages. - The original approach, a footer sitemap of streets and house numbers, drew almost no Googlebot visits, only 16 in a 15-day window. - Moving those links into mini-sitemaps beside heavily-crawled catalog pages changed that, street pages rose from 525,000 to 1,398,000 Googlebot visits across matched 15-day periods. - District pages and metro pages saw comparable jumps, roughly 230% each, over the same before/after windows. - This is JetOctopus's own published account of its client and product, with an obvious incentive to show a favorable result, not an independently audited study. Internal linking is one of the few crawl-budget levers a site controls without waiting on Google, and JetOctopus, a log-file and crawl analysis vendor, published a case study describing exactly that lever in use on a client site. We read the case study directly rather than relying on how it circulates in secondary write-ups, several of which, we found while researching this piece, attach a different, more dramatic figure to it that the source itself does not support. ## What DOM.RIA changed JetOctopus's client DOM.RIA is a Ukrainian real estate marketplace with thousands of new listings added daily. Its directory pages, organized by street, district and metro station, are geography-dependent pages a real estate site depends on, but they sat behind a footer sitemap that Googlebot largely ignored: per the case study, the sitemap pages drew only 16 visits in a 15-day window. The team's fix was not to add more links in general, it was to move the existing links to a better position: mini-sitemaps for each city directory, placed next to the catalog pages Googlebot was already crawling heavily, replacing the old footer sitemap entirely. ## What the log data showed afterward Comparing matched 15-day periods before and after the change, JetOctopus reports Googlebot visits to street pages rising from 525,000 to 1,398,000, an increase of roughly 266%. District pages rose from 196,000 to 450,000 and metro pages from 10,000 to 23,000, both roughly 230% increases. These are crawl visit counts pulled from server log analysis, not an indexation or ranking outcome, and the case study does not report what happened to organic traffic or rankings for these page types afterward. ## Why this is one vendor's own case, not an independent audit JetOctopus sells the crawl-analysis tool used to produce these numbers, and the case study is JetOctopus marketing its own client work, not a third-party audit of DOM.RIA's logs. We also checked a widely repeated claim, that a JetOctopus case study showed crawl coverage rising from 40% to 70% after internal linking changes. Fetching JetOctopus's own internal-linking guide directly, that figure turns out to describe a hypothetical test set used to illustrate how to measure impact, not a real, named case. Several third-party SEO blogs cite it as if it were DOM.RIA's or another client's result; it is not, and we have left it out of this piece. We separately tried to verify a claim that pages four or more clicks deep see about 70% less crawl frequency than pages within two clicks, and could not trace it to any checkable dataset, so that figure does not appear here either. ## Why we care The mechanism DOM.RIA's case describes, moving links from a rarely-crawled location to sit beside pages Google already visits often, is a concrete, repeatable technique independent of this vendor's numbers. The honest caveat is that this is one company's account of its own client and its own tool, published to sell that tool, and the outcome measured is crawl visits, not indexation or rankings. Treat the direction as a real, log-verified signal worth testing on your own site, and treat the magnitude, 230 to 266%, as specific to one real estate marketplace's link graph, not a number to promise a client. ## Frequently asked questions ### Did crawl coverage really rise from 40% to 70% in this case? No, and we checked directly. That 40-to-70% figure appears on JetOctopus's own internal-linking guide, but as a hypothetical illustration on an unnamed test set, not a claim tied to DOM.RIA or any other named site. We use it nowhere in this article. ### What did DOM.RIA actually change? Per JetOctopus's case study, DOM.RIA had been linking to its geography-based directory pages, streets, districts, metro stations, only from a footer sitemap. It replaced that with mini-sitemaps placing those same links next to catalog pages Googlebot already crawled heavily, then removed the old sitemap. ### Is the click-depth to crawl-frequency figure in wider circulation verified? We could not trace a specific real source for a claim that pages four or more clicks deep see about 70% less crawl frequency. Search results attributing it to log analysis of e-commerce sites did not resolve to any checkable dataset or publication, so we leave that figure out of this piece. ## Sources 1. [Case Study: How DOM.RIA Doubled Their Googlebot Visits Using JetOctopus](https://jetoctopus.com/domria-casestudy/) - JetOctopus (primary) --- --- title: "Hreflang tag generator and validator" url: https://seomadman.com/tools/hreflang-tag-generator section: tools published: 2026-08-27T00:00:00.000Z modified: 2026-08-27T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO", "Indexing"] --- # Hreflang tag generator and validator ## The short answer This tool generates hreflang link tags for a set of URLs and language codes, then checks the entered data against Google's rules: every URL must reference itself, a language and region code can only point at one URL, and x-default is a recommended fallback. Add rows, copy the tags, and paste them into the head of each page. ## Key takeaways - Google ignores hreflang annotations for a URL if that URL does not also point back to itself and to every other language version in the set. - The x-default value is optional and works as a fallback for visitors whose language does not match any of the listed versions. - A language and region code such as en-US may only point at one URL; pointing the same code at two URLs makes the pair ambiguous. - Codes must use a lowercase ISO 639-1 language, with an optional uppercase ISO 3166-1 Alpha-2 region after a hyphen. Hreflang tags tell Google which URL to show for a given language and region, and which other URLs are alternate versions of the same page. Getting the tag syntax right is the easy part; the rules that make Google actually trust the set are what most hreflang implementations get wrong. ## Why reciprocity matters Google's own documentation states that if two pages do not both point to each other, the annotations are ignored. This means hreflang is not a one-way hint you drop on your primary page. Every URL in the set needs a link tag pointing at itself and at every other URL, including the version currently being crawled. A common failure mode is a site that lists all its translations on the English homepage but never adds the reciprocal tags on the translated pages themselves; Google treats that set as unreliable and may ignore it entirely for the URLs that fail to reference themselves. ## What x-default does, and does not, guarantee The x-default value marks a fallback page for visitors whose language and region do not match any of the listed versions, commonly a language selector or a default locale. Google documents it as optional and recommended, not required. Adding it does not change how the other language versions rank against each other; it only affects what a visitor with an unmatched language setting sees. Sites with only two or three language versions can often skip it without penalty, but any set built for a broad international audience benefits from having one. ## Usage note This tool runs entirely in the browser: no URL or code you enter is sent anywhere. Because it has no way to crawl the other pages in a set, its reciprocity check is limited to what the entered data can prove, that each URL has a row pointing back at its own language. It cannot confirm that the live page at that URL actually carries the matching tags, so treat a clean result here as a starting point, then verify the live pages with Search Console's International Targeting report. ## Sources 1. [Tell Google about localized versions of your page](https://developers.google.com/search/docs/specialty/international/localized-versions) - Google Search Central (primary) --- --- title: "Open Graph and X card preview" url: https://seomadman.com/tools/social-card-preview section: tools published: 2026-08-25T00:00:00.000Z modified: 2026-08-25T00:00:00.000Z author: Adam Hafez topics: ["Content strategy"] --- # Open Graph and X card preview ## The short answer This tool previews how og: and twitter: tags render as a shared link card on Facebook, LinkedIn and X. Enter a title, description, image and site name, then switch between the large-image layout and the X summary_large_image layout to see live counters. No platform publishes an exact truncation limit, so the counters are a practical guide, not an official rule. ## Key takeaways - The Open Graph protocol at ogp.me sets no character limit for og:title or og:description, and no required image ratio either. - Facebook and LinkedIn read only og: tags, while X reads twitter: tags first and falls back to the matching og: tag when one is missing. - No platform publishes an exact truncation point, so any character count shown as a hard limit is an approximation rather than documented fact. - A landscape source image renders best because every large-image card layout here crops the image into a wide box. ## What actually controls the preview A shared link card is built from meta tags in the page head, not from anything visible in the article itself. Facebook and LinkedIn read the `og:title`, `og:description`, `og:image` and `og:site_name` properties defined by the Open Graph protocol. X uses its own `twitter:card`, `twitter:title`, `twitter:description` and `twitter:image` tags, and falls back to the matching `og:` tag for any one of those it does not find. A page that sets only `og:` tags still gets a usable X card through that fallback; a page that sets conflicting `og:` and `twitter:` values will show different text on each platform. ## Why there is no official character limit The Open Graph protocol specification at ogp.me defines `og:title` and `og:description` as plain strings with no length constraint, and it does not document a recommended image ratio, only the optional `og:image:width` and `og:image:height` fields for stating the image's actual pixel dimensions. The truncation a viewer sees comes from each platform's own rendering, which none of them documents precisely and all of them can change without notice. A tool that claims an exact cutoff is presenting an inference as a fact; the counters here are labelled as a guide for that reason. ## Using this preview Paste the tags as they will actually ship, including the real image URL, and check both card layouts before publishing. A card that reads well cropped to a wide image and a couple of lines of text will survive most platform rendering differences; a card that only works at full, untruncated length will not. ## Frequently asked questions ### What is the official character limit for og:title and og:description? There isn't one. The Open Graph protocol at ogp.me does not define a character limit for either property. Platforms truncate in their own rendering, and none of them publishes the exact cutoff, so any specific number quoted elsewhere is an observed approximation, not a documented rule. ### What is the recommended og:image size? The protocol defines og:image:width and og:image:height as optional metadata describing the image you provide, not a requirement or a recommended ratio. In practice a landscape image works best, because large-image card layouts on every platform crop the image into a wide box rather than a square. ### Do Facebook and X read the same tags? No. Facebook and LinkedIn read only the og: family of tags. X reads its own twitter: tags first, for example twitter:title and twitter:image, and falls back to the matching og: tag when a twitter: tag is missing. ## Sources 1. [The Open Graph protocol](https://ogp.me/) - Open Graph Protocol (primary) --- --- title: "Google fixes Search Console favicon bug and a crawl stats data gap" url: https://seomadman.com/news/search-console-favicon-crawl-stats-bugs-fixed section: news published: 2026-08-24T00:00:00.000Z modified: 2026-08-24T00:00:00.000Z author: Adam Hafez topics: ["Search Console", "Technical SEO"] --- # Google fixes Search Console favicon bug and a crawl stats data gap ## The short answer Google fixed two unrelated Search Console bugs on Sunday, 23 August 2026, around 5pm ET: a favicon bug that replaced real site favicons with a default globe icon in search results, and a two-day Crawl Stats data gap starting around 14 to 15 August. Google's Rajan Patel had flagged the favicon fix as roughly 12 hours out the day before. ## Key takeaways - Google fixed two separate Search Console bugs on Sunday, 23 August 2026, at around 5pm ET. - One bug replaced real site favicons with a default globe icon in Google search results. - The other bug left a roughly two-day gap in Crawl Stats data starting around 14 to 15 August 2026. - Google's Rajan Patel said on Saturday, 22 August that a favicon fix was expected within about 12 hours, before it actually shipped the next day. - The two bugs affected different Search Console surfaces and were fixed on the same day by coincidence. Two unrelated Search Console problems closed out on the same day. Google fixed a bug that had been replacing real site favicons with a default globe icon in search results, and separately patched a gap in the [Search Console](/topics/search-console) Crawl Stats report, both around 5pm ET on Sunday, 23 August 2026. ## What was the favicon bug? For about a week, Google search results showed a generic globe icon instead of a site's real favicon for many sites, unrelated to any change the sites themselves had made. Site owners flagged it in Google's help forums as the icon most searchers use to visually confirm a result before clicking. Google's Rajan Patel addressed it directly on Saturday, 22 August, saying the fix was "not fixed yet, but should be in the next 12 hours or so." The fix landed the following day, Sunday 23 August, around 5pm ET, roughly a day after that estimate. ## What was the crawl stats gap? Separately, the Crawl Stats report in Search Console, the tool that shows how often Googlebot requests a site's pages, was missing about two days of data starting around 14 to 15 August 2026. Google restored the missing data points on the same Sunday as the favicon fix, around 5pm ET. ## Why we care Nothing here points to a ranking or indexing problem; both were reporting and display bugs, not signals that a site did something wrong. But a missing favicon can cost click-through in a results page where the icon is part of how a user recognizes a brand, and a data gap in [Crawl Stats](/topics/technical-seo) can send someone chasing a crawl-budget problem that was never real. If either looked wrong to you in the affected window, it was very likely Google's bug, not your site's. ## Frequently asked questions ### What was the Search Console favicon bug? For roughly a week before the fix, Google search results showed a default globe icon in place of many sites' real favicons, even though the sites' favicon setup had not changed. ### What was wrong with the Crawl Stats report? The Crawl Stats report in Search Console had a gap of about two days of missing data, starting around 14 to 15 August 2026, before Google restored the missing data points. ### Were the favicon bug and the crawl stats bug related? No. Search Engine Roundtable reported them as two distinct bugs on two different Search Console surfaces that happened to be fixed on the same day, Sunday 23 August 2026. ## Sources 1. [Google Fixes Favicon Bug & Search Console Crawl Stats Bug](https://www.seroundtable.com/google-fix-favicon-crawl-stats-41928.html) - Search Engine Roundtable (primary) --- --- title: "AI citation patterns shift sharply by search intent, Wix data shows" url: https://seomadman.com/studies/ai-citation-by-search-intent-wix section: studies published: 2026-08-24T00:00:00.000Z modified: 2026-08-24T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # AI citation patterns shift sharply by search intent, Wix data shows ## The short answer Wix Studio's AI Search Lab re-cut its million-citation dataset by search intent rather than content format. Articles are cited 2.7x more on informational queries than other intents, reaching 45.48% share. Listicles nearly double their average on commercial queries, to 40.86%. Product pages peak at 24.88% on transactional queries. ## Key takeaways - Wix Studio's AI Search Lab found articles cited 2.7x more on informational queries than on other query intents, reaching a 45.48% citation share there. - On commercial queries, listicles reach a 40.86% citation share, nearly double their share on other intent types. - On transactional queries, product pages peak at a 24.88% citation share, the highest any format reaches for any single intent in this breakdown. - This is the same 75,000-answer, 1,056,727-citation Wix dataset behind this site's earlier format-only report, cut by query intent instead of format alone. - Match content format to query intent, not just topic: a listicle written for an informational query competes against articles' 2.7x home-turf advantage. Wix Studio's AI Search Lab did not stop at ranking content formats against each other. The same 75,000 AI answers and 1,056,727 citations it pulled from ChatGPT, Google AI Mode and Perplexity also carry a second, sharper cut: how citation share moves once a query's intent, informational, commercial or transactional, is held constant. This site's [earlier report on citation rates by content format](/reports/ai-citation-rate-by-content-format) covered the format-only numbers, listicles at 21.9%, articles at 16.7%, product pages at 13.7%, as overall averages across every intent mixed together. The intent breakdown is the piece that number was hiding. ## Articles pull ahead sharply on informational queries Averaged across all query types, Wix found articles cited in 16.7% of citations, third behind listicles and roughly on par with how often they get picked in general. Split out to just informational queries, that share jumps to 45.48%, which the research states directly as articles being "cited 2.7x more for informational queries compared to other intents." No other format in the dataset moves that far above its own baseline for a single intent category. Listicles, by contrast, sit close to their own average on informational queries, at 21.68%, meaning the informational advantage belongs specifically to articles, not to long-form content generally. ## Listicles and product pages each win a different moment in the funnel Commercial queries, the research, comparison and best-of searches that precede a purchase decision, flip the leaderboard toward listicles. Their citation share reaches 40.86% there, which the study describes as "nearly double other intents," up from a 21.9% baseline across all query types. Transactional queries, where the asker is closer to buying than comparing, hand the lead to product pages instead: a 24.88% citation share, up from a 13.7% baseline, the highest single-intent share any format reaches anywhere in this breakdown. Read together, the three numbers describe a funnel: articles own the question stage, listicles own the comparison stage, product pages own the point of purchase. ## Why we care A format-only reading of AI citation data, the kind this site already published, tells a publisher which format gets cited most often on average. It does not tell them which format to use for a specific piece of content they are about to write. This intent breakdown does: an informational how-to page structured as a listicle is not competing on listicles' overall strength, it is competing against articles' 2.7x advantage on informational queries specifically, on their own turf. The practical move is to match format to the intent behind the query a page is meant to answer, not to default to whichever format wins the leaderboard on average, since that average is really three different leaderboards averaged together. ## Sources 1. [The content types most cited by LLMs](https://www.wix.com/studio/ai-search-lab/research/content-types-most-cited-by-llms) - Wix Studio, AI Search Lab (primary) --- --- title: "URL structure analyzer" url: https://seomadman.com/tools/url-structure-analyzer section: tools published: 2026-08-23T00:00:00.000Z modified: 2026-08-23T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # URL structure analyzer ## The short answer This tool parses a URL with the browser's own URL constructor and checks its length, path depth, query parameters, separator style and whether a segment looks like an opaque id. Some checks restate Google's documented URL structure guidance; others are labelled heuristics with no official Google number behind them. ## Key takeaways - Google recommends hyphens instead of underscores to separate words in a URL, and this tool checks for that directly. - Google's URL structure documentation states no specific character limit, so this tool's length check is a general heuristic, not an official Google rule. - A URL segment that looks like a long opaque id or hex string is flagged as a heuristic guess, never a certainty. - Trimming query parameters that do not change a page's content is guidance Google actually documents, not folklore. - Every check runs in the browser with the native URL constructor, so nothing typed into the tool is ever sent anywhere. Paste a URL and this tool parses it with the browser's own URL constructor, then runs a fixed set of checks against the result. Every check is labelled by where it comes from, so a documented Google recommendation is never shown the same way as a guess this tool makes on its own. ## What Google actually documents Google's URL structure page recommends readable words over long id numbers, hyphens instead of underscores to separate words, and trimming query parameters that do not change a page's content. It also covers percent encoding, URL fragments and case sensitivity. It does not state a specific character limit for a URL, and it does not give a maximum directory depth. Those two absences are worth naming directly, because both numbers get repeated as fact in general SEO advice without a source behind them. ## What this tool flags as a heuristic, not a rule Total character length, path depth, opaque id detection and path readability are all computed by this tool, not published by Google. The opaque id check looks for a path segment that is a long run of digits or hex-looking characters with no vowels or separators, which catches a database key or a session token but can also flag a real product code. Treat every heuristic result here as a diagnostic prompt to look closer, not as a pass or fail verdict. Use this tool while drafting a URL, before it is published and linked from anywhere else, since changing a live URL's structure later requires a redirect to avoid losing the page's existing signals. ## Sources 1. [URL structure best practices](https://developers.google.com/search/docs/crawling-indexing/url-structure) - Google Search Central (primary) --- --- title: "Three named companies that disclosed real AI-search traffic losses" url: https://seomadman.com/studies/named-publisher-traffic-declines section: studies published: 2026-08-21T00:00:00.000Z modified: 2026-08-21T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # Three named companies that disclosed real AI-search traffic losses ## The short answer Chegg's own Q4 2024 earnings show a real 24% year-over-year revenue drop, and its CEO explicitly blamed Google's AI Overviews. Business Insider and HubSpot both saw genuine traffic collapses too, but the credible reporting behind those numbers attributes the losses to a mix of AI search, algorithm updates, and each company's own strategy, not AI alone. ## Key takeaways - Chegg's Q4 2024 revenue fell 24% year-over-year, and its CEO directly attributed the drop to Google's AI Overviews in the company's own earnings release. - Business Insider's monthly traffic fell from around 160 million visits in 2020 to around 80 million in the first half of 2025, per Press Gazette's analysis of Similarweb data. - HubSpot's organic traffic fell from 13.5 million to 8.6 million visits in a month, but the collapse traces mainly to a Google algorithm update, not AI Overviews. - A widely repeated claim of a 27-38% AI-driven decline at CNN could not be traced to one consistent, checkable figure, so it is left out of this piece. - These three cases are the exception, not the rule, since most publishers never disclose the underlying traffic or revenue numbers needed to check a claim like this at all. Most publishers never say what their AI-search losses actually are in a number anyone outside the company can check. Three exceptions exist, because a public earnings release or a traffic-panel analysis by a named research firm put a figure on the record. A fourth widely circulated claim, about CNN, does not survive contact with a primary source and is left out below rather than repeated. ## Chegg: a 24% revenue drop the company put in writing Chegg's own fourth-quarter 2024 results, published on its investor relations site on 24 February 2025, report total revenue of $143.5 million, down 24% year-over-year. This is not a third-party estimate: it is Chegg's own disclosed financial result. CEO Nathan Schultz went further than the number itself, telling investors that Google's AI Overviews had turned Google "from a search engine into an answer engine" that keeps traffic on Google's own results page instead of sending it to sites like Chegg, and citing non-subscriber traffic that fell 49% in January 2025 compared with an 8% decline as recently as Q2 2024. Chegg has since sued Google over the same claim. This is the cleanest case in this piece: a real public company, its own disclosed number, and an on-the-record executive attribution to a specific Google product. ## Business Insider: real traffic loss, a less clear-cut cause Press Gazette's reporting, using Similarweb data, puts Business Insider's monthly traffic at around 160 million visitors in 2020, falling to around 80 million in the first half of 2025 - a real decline of roughly half over five years. That is a verified, checkable number from a credible trade publication that tracks publisher traffic monthly. It is not, however, a clean before/after AI-search comparison: the five-year window spans Business Insider's own editorial and paywall changes as well as the period when AI Overviews rolled out, and Press Gazette's coverage of the same newsroom cuts does not isolate AI search as the sole cause the way Chegg's own statement did. ## HubSpot: a real collapse, but the algorithm did more than AI Overviews HubSpot's organic traffic, tracked by Semrush and reported by Search Engine Land, fell from about 13.5 million monthly visits in November 2024 to about 8.6 million in December 2024 - a drop of roughly a third in a single month. That is a real, sourced number. What it is not is confirmation of the "AI killed 70-80% of HubSpot's traffic" framing that circulates in SEO commentary: Search Engine Land's analysis traces the December collapse mainly to Google's December 2024 core update and spam update, compounded by HubSpot's own pattern of publishing broad, SEO-first content - pages on topics like resignation letters and famous quotes - outside its actual product expertise. AI Overviews are named as a contributing factor in HubSpot's own commentary on the episode, not as the credited primary cause in the reporting that has actual traffic numbers attached to it. ## Why we care **These are the exception, not the rule.** A public earnings call or a named analytics firm's monthly tracker is what makes a number here checkable at all. The overwhelming majority of sites affected by AI search changes have no equivalent public disclosure, so a claim about "publisher traffic" in general cannot borrow Chegg's, Business Insider's, or HubSpot's specific number as proof of a universal effect. **Attribution is not automatic just because AI search changed in the same period.** Chegg's CEO made a direct, on-the-record causal claim tied to a specific product. HubSpot's own reporting points mostly at an algorithm update and its own content choices, with AI Overviews as one factor among several. Treating every publisher traffic drop published since 2024 as an "AI Overviews did this" data point, the way the dropped CNN figure was being used before this check, is exactly the kind of unsourced leap this site does not ship. ## Sources 1. [Chegg Reports 2024 Fourth Quarter and Full Year Financial Results](https://investor.chegg.com/Press-Releases/press-release-details/2025/Chegg-Reports-2024-Fourth-Quarter-and-Full-Year-Financial-Results/default.aspx) - Chegg, Inc. (primary) 2. [Business Insider cuts: Why 100+ staff are leaving and who's going](https://pressgazette.co.uk/publishers/digital-journalism/business-insider-cuts/) - Press Gazette 3. [HubSpot's SEO collapse: What went wrong and why?](https://searchengineland.com/hubspot-seo-organic-traffic-drop-451096) - Search Engine Land --- --- title: "XML sitemap structure validator" url: https://seomadman.com/tools/xml-sitemap-validator section: tools published: 2026-08-21T00:00:00.000Z modified: 2026-08-21T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # XML sitemap structure validator ## The short answer This validator parses pasted XML sitemap content in the browser, checking DOMParser output for real parse errors, then verifying the root element, namespace, and each url entry against the sitemaps.org protocol, including lastmod dates, changefreq values, and priority ranges, plus the 50,000 URL and 50MB size limits both sitemaps.org and Google document. ## Key takeaways - This tool parses XML in the browser with DOMParser and reports real parse errors instead of assuming the sitemap is valid. - A sitemap file must contain no more than 50,000 URLs and stay under 50MB uncompressed, per the sitemaps.org protocol and Google's own documentation. - Every url entry needs an absolute loc address, while lastmod, changefreq, and priority remain optional but are checked when present. - Google ignores changefreq and priority values entirely, even though the protocol still defines and allows them. - This validator checks structure only, so a clean pass does not confirm the listed pages actually exist or can be indexed. ## What this checks The validator runs two passes. The first parses the pasted text with the browser's native `DOMParser`, using the `text/xml` MIME type; if the markup is malformed, DOMParser inserts a `parsererror` node into the result instead of throwing, so the tool detects that node and shows the message it contains. The second pass only runs on well-formed XML: it confirms the root element is `urlset` declared in the sitemap 0.9 namespace, then walks every `url` entry checking for an absolute `loc`, a valid W3C Datetime `lastmod` if present, a `changefreq` value from the seven the protocol defines (always, hourly, daily, weekly, monthly, yearly, never), and a `priority` between 0.0 and 1.0 if present. ## The real limits A single sitemap file may list no more than 50,000 URLs and must be no larger than 50MB (52,428,800 bytes) uncompressed; both figures come directly from the sitemaps.org protocol page and are repeated in Google's own sitemap documentation. A site with more URLs than that needs multiple sitemap files listed in a sitemap index instead of one oversized file. `lastmod`, `changefreq`, and `priority` are all optional per the protocol, and Google states plainly that it ignores `changefreq` and `priority` entirely when crawling, using `lastmod` only when it can verify the date is accurate. ## What this cannot check Structural validity is not the same as crawlability. This tool never fetches the URLs it finds, so it cannot confirm any `loc` actually resolves, returns a successful status, or points at a page that is eligible for indexing. It also cannot tell you whether a page on the live site is missing from the sitemap altogether, since it only ever sees what was pasted in. ## Using the result Fix a parse error before reading anything else; a broken document means the structural checks never run. Once the XML is well formed, treat a missing `loc` as something to fix immediately, since a `url` entry without one is not a URL at all, and treat a bad `lastmod`, `changefreq`, or `priority` as a smaller cleanup rather than a blocker, since none of the three is required by the protocol. Confirm the sitemap is actually being read by submitting it through your search engine's own webmaster tools, which check reachability and indexing eligibility this tool does not attempt to replicate. ## Frequently asked questions ### Does this tool fetch my sitemap from its live URL? No. It only parses XML you paste into the textarea, entirely in your browser. This avoids a CORS-dependent network fetch and means nothing you paste is sent anywhere, but it also means you have to copy the file's contents yourself. ### Why does the namespace need to start with an unencrypted address? The sitemap 0.9 namespace is a fixed identifier string defined by the protocol, not a link the browser visits. Sitemaps.org has never revised it, so a sitemap using any other string for that value is not a valid sitemap regardless of how the rest of the file looks. ### Does a clean result mean my sitemap will be crawled correctly? It means the file is well formed and structurally correct. It does not confirm that the listed URLs exist, return a 200 status, or are eligible for indexing, and it cannot check pages missing from the file entirely. ## Sources 1. [Sitemaps XML format](https://www.sitemaps.org/protocol.html) - sitemaps.org (primary) 2. [Build and submit a sitemap](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap) - Google Search Central (primary) --- --- title: "How long domain migrations take to recover organic traffic" url: https://seomadman.com/studies/domain-migration-recovery-time section: studies published: 2026-08-19T00:00:00.000Z modified: 2026-08-19T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # How long domain migrations take to recover organic traffic ## The short answer Dan Taylor's Search Engine Journal study tracked 892 domain migrations and found the new domain took an average of 523 days to match the old domain's organic traffic. 17% never recovered within 1,000 days. The fastest recoveries landed in 19, 22, and 23 days, all tied to complete redirect mapping executed before or right at launch. ## Key takeaways - A Search Engine Journal study of 892 domain migrations found an average recovery time of 523 days, about 17 months, for the new domain to match the old domain's organic traffic. - 17% of the migrations in the sample never returned to their pre-migration traffic level even after 1,000 days of tracking. - The fastest recoveries, 19, 22, and 23 days, all involved complete 1:1 redirect mapping and pre-launch validation rather than partial or delayed redirects. - The study grew from 171 migrations in the author's 2023 dataset to 892 in 2024, and average recovery time still rose year over year rather than falling. - The author reports a correlation between larger backlink profiles and slower recovery, with the caveat that outliers tied to migration execution quality were common. Domain migrations, moving a site's content to a new domain and redirecting the old one, carry a known SEO risk, but how long the risk actually lasts has mostly circulated as folklore. Search Engine Journal contributor Dan Taylor ran a real, large-scale study of it: 892 tracked domain migrations, each measured for how many days the new domain took to reach the same estimated organic traffic the old domain had. We read the study directly. Here is what it found. ## The headline number, and the spread behind it The average across the 892 migrations was 523 days, about 17 months, for the new domain to match the old domain's organic traffic. That average sits on top of real spread, not a tight cluster. The shortest recovery times recorded were 19, 22, 23, and 33 days. At the other end, 17% of the migrations in the sample had not returned to their pre-migration traffic level even after 1,000 days of tracking, the point past which the study stops counting them as recovering at all. A smaller group, 25 migrations (2.8%), were marked inconclusive: traffic reached the old domain's level but never stabilized there. That range matters more than the average by itself. A site planning a migration around "expect roughly a year and a half" is planning around the middle of a distribution that also contains a three-week recovery and a one-in-six chance of never getting there. ## What separated the fast recoveries from the rest Taylor attributes the fastest recoveries, 19 to 23 days, to complete 1:1 redirect mapping covering every indexed URL, validated in staging before the domain switch, plus close monitoring for at least the first two weeks after launch. Launching the new URL structure with redirects live 24 to 48 hours before the full migration also comes up as a factor: it gives Google a head start crawling and processing the new paths instead of discovering them cold on migration day. Using Google Search Console's change of address tool is cited as smoothing the earliest post-launch lag. On the slow side, the study's author reports a correlation between the size of a site's backlink profile and how long recovery took, the reasoning being that every external site linking in has to be recrawled with the new destination reflected before that link value carries over. Taylor is explicit that this is a correlation with "a large number of outliers," which he attributes to how individual migrations were actually carried out rather than backlink count alone. ## Why we care The number worth planning around here is not 523, it is the range around it: weeks at the fast end, over 1,000 days and still not recovered for 17% of sites at the slow end, from the same set of migrations. The study's own account of what separated the two groups, full redirect coverage, pre-launch validation, and early monitoring, over partial or reactive redirect work, gives a domain migration checklist a publisher can act on before moving, not just a timeline to brace for afterward. ## Frequently asked questions ### How long does it take to recover organic traffic after a domain migration? Per a Search Engine Journal study of 892 domain migrations, the average was 523 days, about 17 months, for the new domain to match the old domain's organic traffic. The fastest cases recovered in 19 to 23 days; 17% of the sample had not recovered even after 1,000 days. ### What made the fastest recoveries different? The study's author reports the quickest recoveries, 19, 22, and 23 days, shared complete 1:1 redirect mapping covering every indexed URL, validation before the domain switch, and close monitoring in the first weeks after launch, rather than partial redirects or a slow cleanup afterward. ### Does a bigger backlink profile mean a slower migration? The study's author notes a correlation between larger backlink profiles and longer recovery, reasoning that more backlinks mean more external pages needing to be recrawled with the new URLs reflected, but flags a large number of outliers driven by how each migration was actually executed. ### Is 523 days the number every site should expect? No. It is a sample average across migrations of very different quality. The same dataset contains recoveries in under a month and migrations that never recovered, so execution quality, not elapsed time alone, is what the data associates with the outcome. ## Sources 1. [How Long Should an SEO Migration Take? [Study]](https://www.searchenginejournal.com/study-how-long-should-seo-migration-take/492050/) - Dan Taylor, Search Engine Journal (primary) --- --- title: "Meta robots tag builder" url: https://seomadman.com/tools/meta-robots-tag-builder section: tools published: 2026-08-19T00:00:00.000Z modified: 2026-08-19T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Meta robots tag builder ## The short answer This tool builds a robots meta tag or X-Robots-Tag header from checkboxes for the real documented directives: noindex, nofollow, none, noarchive, nosnippet, notranslate, noimageindex, unavailable_after, max-snippet, max-image-preview and max-video-preview. It flags which directives are Google-specific, warns when noindex is combined with a snippet-appearance directive, and runs entirely in your browser. ## Key takeaways - max-snippet, max-image-preview and max-video-preview only affect how Google renders a snippet, so combining them with noindex has no effect. - Google Search no longer honors noarchive, though the directive is still emitted by tools and may be read by other crawlers. - The same directive string is valid inside a meta tag and inside an X-Robots-Tag HTTP header, which is why this tool generates both from one input. - A robots meta tag only works on a page Google is allowed to crawl; blocking the page in robots.txt hides the tag from the crawler entirely. A robots meta tag and an X-Robots-Tag header carry the same directive string; the only difference is where it lives. A meta tag sits in a page's ``, so it only works on HTML that Google can parse. A header applies to any response, HTML or not, which is why it is the only option for controlling indexing on a PDF, image or other file Google fetches directly. ## Directives Google treats specially Most directives here (noindex, nofollow, none, nosnippet, notranslate, noimageindex, unavailable_after) come from the original robots meta convention and are the ones most crawlers recognize. Three are Google-specific: max-snippet, max-image-preview and max-video-preview only change how Google renders a snippet for an indexed page, and other search engines are not obliged to honor them. noarchive sits on the opposite side of that line: it used to be part of the same convention, but Google Search has retired it, so setting it no longer changes anything in Google's results even though the directive still exists. ## Why the warning fires max-snippet, max-image-preview and max-video-preview describe how much of a page's content appears inside its own snippet. That question only makes sense for a page that is indexed at all. Combine any of them with noindex, or with the none shorthand, and the directive is not wrong, just inert: the page will not have a snippet for those settings to shape. The tool surfaces this as a warning rather than blocking the combination, since a page mid-edit legitimately passes through states like this. Treat the generated tag as the instruction you are giving the crawler, not a guarantee: a page must also be reachable and not disallowed in robots.txt for Google to read the tag in the first place. ## Sources 1. [Robots meta tag, data-nosnippet, and X-Robots-Tag specifications](https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag) - Google Search Central (primary) --- --- title: "Google's own data: Rakuten and Vodafone Core Web Vitals A/B tests" url: https://seomadman.com/studies/rakuten-vodafone-core-web-vitals-case-studies section: studies published: 2026-08-17T00:00:00.000Z modified: 2026-08-17T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Google's own data: Rakuten and Vodafone Core Web Vitals A/B tests ## The short answer Google's web.dev case study library documents two named, dated A/B tests. Rakuten 24 ran a month-long 50/50 split test and measured 53.37% more revenue per visitor and 33.13% higher conversion on the performance-optimized page. Vodafone Italy cut LCP 31% by moving a widget's rendering server-side and resizing its hero image, and measured 8% more sales. ## Key takeaways - Rakuten 24 ran a month-long 50/50 A/B test and measured 53.37% more revenue per visitor and 33.13% higher conversion on the optimized version. - Vodafone Italy's optimized page improved Largest Contentful Paint by 31% and measured 8% more total sales, plus gains in lead-to-visit and cart-to-visit rate. - Vodafone's named changes were server-side rendering a widget and critical HTML, plus resizing, compressing and lazy-loading the hero image. - Both tests split real production traffic 50/50 rather than comparing before-and-after periods, controlling for seasonality and traffic-mix shifts. - Google selected and published both cases as examples of the pattern it wants publicised, so neither figure is a guaranteed or average effect size for every site. Google runs a small library of named, dated case studies at web.dev/case-studies, each attached to a real company and a real test. Two of them isolate Core Web Vitals specifically: Rakuten 24, a Japanese e-commerce retailer, and Vodafone Italy. Unlike Deloitte's 37-site correlation study or Shopify's aggregate LCP data covered on this site's [page speed and conversion rate piece](/studies/page-speed-conversion-rate-impact/), these two are single-company A/B tests that Google itself ran or reviewed and published under its own byline. Here is what each one actually tested, in Google's own words. ## Rakuten 24: a month-long split test on one landing page **The setup.** Rakuten's team picked a landing page with "significant traffic and conversion" so the test could produce a meaningful sample, then split traffic 50/50 for a month: half of visitors saw the original page (version B), half saw a performance-optimized version (version A) that was otherwise unchanged. The write-up, credited to four named Rakuten and Google engineers and last updated 24 August 2022, reports the optimized version's results relative to the original. **The business numbers.** Version A delivered a 53.37% increase in revenue per visitor and a 33.13% increase in conversion rate, alongside a 15.20% increase in average order value, a 35.12% reduction in exit rate, and a 9.99% increase in time on page. **The performance numbers behind it.** The same optimized version cut Cumulative Layout Shift by 92.72%, improved First Input Delay by 7.95%, First Contentful Paint by 8.45%, and Time to First Byte by 18.03%, relative to the unoptimized version. Separately, Rakuten also ran a field-data correlation analysis (not the A/B test) across its real user population and found good LCP associated with up to 61.13% higher conversion and 26.09% higher revenue per visitor, a wider, noisier number that supports the same direction without being the headline A/B result. ## Vodafone Italy: three specific changes, an 8% sales lift **The setup.** Vodafone's optimized and original pages ran as a 50/50 A/B split too, each getting roughly 100,000 clicks and 34,000 visits a day from paid display, search, social and app traffic, "visually and functionally identical" apart from the performance changes. Google published this one on 17 March 2021. **What actually changed.** Google names three changes, not a general "made it faster" claim: moving the rendering logic for one widget from client-side to server-side, server-side rendering the critical HTML, and hero-image work (resizing, SVG optimization, PNG compression and viewport-based lazy loading for below-the-fold images). **The result.** The optimized version improved Largest Contentful Paint by 31% and produced 8% more total sales, plus a 15% uplift in lead-to-visit rate and an 11% uplift in cart-to-visit rate. One honest wrinkle Google's own page reports: DOMContentLoaded actually increased 15% on the optimized version even as LCP improved, a reminder that one metric moving well does not mean every metric moves the same way. ## Why we care **These are Google's own selected success stories, not a random sample.** Google chose to publish Rakuten 24 and Vodafone Italy specifically because the numbers were good enough to make the point Google wants to make: Core Web Vitals work pays off in revenue, not just rankings. That is a legitimate reason to take Core Web Vitals seriously, and a bad reason to promise a client 53% more revenue from a similar change; Rakuten's own field data on the same site showed a much wider range of outcomes than its single A/B test headline. **An A/B test beats a before/after comparison, which is why these numbers travel further than Deloitte's or Shopify's.** Splitting live traffic 50/50 for the same weeks controls for seasonality, marketing pushes and traffic-mix shifts that a simple before-and-after read cannot; that is a stronger methodology than the correlational studies in our companion piece on [page speed and conversion rate](/studies/page-speed-conversion-rate-impact/), even though the two named cases here cover only two companies rather than dozens. **Cite the company and the exact change, not just the percentage.** "31% faster, 8% more sales" is Vodafone Italy's number for three named technical changes on one page in 2021. "53% more revenue per visitor" is Rakuten 24's number for one landing page over one month. Neither is a general Core Web Vitals multiplier; both are useful, specific, sourced evidence that the work matters. ## Frequently asked questions ### Were these controlled tests or just before-and-after comparisons? Both were A/B tests. Rakuten 24 split traffic 50/50 between an optimized landing page and the original for one month. Vodafone Italy also ran a 50/50 split, serving roughly 100,000 clicks and 34,000 visits a day to each version, with the two pages "visually and functionally identical" apart from the performance work. ### What exactly did Vodafone change to cut LCP by 31%? Per Google's write-up, three changes, moving the rendering logic for one widget from client-side to server-side, server-side rendering the critical HTML, and image work - resizing the hero image, optimizing SVGs, compressing PNGs and lazy-loading below-the-fold images by viewport. ### Do these figures apply to any site that improves Core Web Vitals? No. Google chose these two cases to publish as success stories; it does not claim they represent a typical or average effect size. Rakuten 24's own field-data analysis (separate from its A/B test) found good LCP correlated with up to 61.13% higher conversion on some segments and lower gains on others, which is itself a sign the multiplier varies by site and traffic mix. ## Sources 1. [Rakuten 24 case study](https://web.dev/case-studies/rakuten) - Google web.dev (primary) 2. [Vodafone case study](https://web.dev/case-studies/vodafone) - Google web.dev (primary) --- --- title: "Google search operator query builder" url: https://seomadman.com/tools/search-operator-builder section: tools published: 2026-08-17T00:00:00.000Z modified: 2026-08-17T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Google search operator query builder ## The short answer This tool builds a Google search query from separate fields for site:, filetype:, exact phrases and excluded words along with intitle:, inurl:, intext: and OR terms, which Google no longer documents but which still work. It shows the combined query as you type and opens it directly in Google search. ## Key takeaways - Google's current search help page documents only four operators: quotes, site:, the minus sign and filetype:. - intitle:, inurl:, intext: and OR still work in practice even though Google removed them from its own documentation. - The tilde synonym operator was dropped by Google in 2013 and is excluded here because it no longer does anything. - AROUND(n) is a long-observed but never officially documented proximity operator, so this tool leaves it out rather than presenting it as supported. - Every query is assembled in your browser, and nothing is sent anywhere until you choose to open it in Google. Google's search box accepts far more than plain keywords, but its own documentation of that syntax has shrunk. This tool builds a query from separate fields rather than asking you to memorize colons and quote marks, and it draws a hard line between what Google still documents and what merely still works. ## Operators Google still documents Google's current search help page lists exactly four pieces of syntax: quotation marks for an exact phrase, `site:` to restrict results to one domain, a leading minus sign to exclude a term, and `filetype:` to restrict results to one document format. Each of those is built into this tool without any warning label, because each is both current and functional. ## Operators that work but aren't documented `intitle:`, `inurl:`, `intext:` and the capitalized `OR` do not appear on Google's current operators page, but they are long-standing syntax that independent testing continues to show working as expected. This tool includes them, each marked unofficial, so you can use them without mistaking them for supported features. Two operators are deliberately absent: the tilde synonym operator, which Google switched off in 2013 and which now does nothing at all, and `AROUND(n)`, a proximity operator that has never been officially documented and produces inconsistent results, so it is left out rather than offered as if it were reliable. Treat the query this tool builds as a starting point. Google can still rewrite how any operator behaves without notice, and the only way to know a query works as intended is to run it and read the results it returns. ## Sources 1. [Refine web searches](https://support.google.com/websearch/answer/2466433) - Google Search Help (primary) 2. [Google Advanced Search Operators (2026 update)](https://ahrefs.com/blog/google-advanced-search-operators/) - Ahrefs --- --- title: "Do internal links still track with Google Search traffic in 2026?" url: https://seomadman.com/research/internal-linking-crawl-depth-zyppy-study section: research published: 2026-08-15T00:00:00.000Z modified: 2026-08-15T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Do internal links still track with Google Search traffic in 2026? ## The short answer Zyppy's 2022 study of 23 million internal links across 1,800 websites found pages with 0-4 internal links average roughly a quarter the Google Search clicks of pages with 40-44 links, though traffic declines again past 45-50. Google's own documentation says every page you care about needs a link from another page, since sitemaps are only a hint, not a guarantee. ## Key takeaways - Zyppy analyzed 23 million internal links across 1,800 websites and roughly 520,000 URLs, cross-referenced against Google Search Console click data. - Pages with 0 to 4 internal links averaged about a quarter of the Google Search clicks of pages with 40 to 44 internal links in Zyppy's dataset. - Traffic gains reversed past roughly 45 to 50 internal links, and Zyppy states plainly that its findings are correlational, not proof of causation. - Google's own documentation says every page you care about should have a link from at least one other page on your site. - Google states that a submitted sitemap is merely a hint and does not guarantee a page will be crawled, so links remain the primary discovery path. A single-site before-and-after case study can show what happened on one domain. What it cannot show is whether the pattern holds anywhere else. For that, the closest thing the industry has is Cyrus Shepard's Zyppy study, which measured 23 million internal links across 1,800 sites and lined the results up against real Google Search Console clicks. ## Zyppy's real numbers Zyppy pulled internal-link data from roughly 520,000 URLs across 1,800 websites, a total of 23 million internal links, then joined that dataset to each URL's actual Google Search Console click count. The headline pattern: URLs with 0 to 4 internal links pointing at them averaged about 2 clicks from Google Search, while URLs with 40 to 44 internal links averaged roughly 4 times that many. Past about 45 to 50 internal links, the relationship reverses and clicks start declining again as link count keeps climbing, a pattern Zyppy attributes partly to over-linked pages diluting the value of any one link and partly to bulk sitewide navigation links counting differently than unique, in-content links. On that second point, Zyppy is explicit that a link appearing in a sitewide footer or navigation menu may still pass a meaningful amount of PageRank, but functions as a single relationship with one anchor text, however many pages it appears on, unlike a one-off contextual link placed inside an article. Zyppy also states directly that this is mostly a correlation study, not a controlled experiment, and cautions readers against treating any of its conclusions as more certain than the data supports. ## Google's documented discovery mechanics Separately from what Zyppy measured, Google's own developer documentation explains the mechanic that makes link count matter in the first place. Google's guide to how search works describes three ways a page enters Google's index of known URLs: Google has already visited it, Google extracted a link to it from a page it already knows, or a site owner submitted it through a sitemap. Google's link best-practices page states the underlying expectation plainly: "Every page you care about should have a link from at least one other page on your site." A sitemap is not a substitute for that link. Google's own sitemap documentation says submitting one "is merely a hint: it doesn't guarantee that Google will download the sitemap or use the sitemap for crawling URLs on the site." A page with no internal link pointing to it depends entirely on Google finding it through a sitemap it may or may not act on, or through an external backlink, neither of which Google promises to honor. ## Why we care Put the two sources together and the picture is consistent, not identical. Zyppy's aggregate data shows a real, measurable relationship between how many internal links a page has and how much Google Search traffic it receives, at a scale far beyond any one site's crawl log. Google's own documentation explains a plausible mechanism for the low end of that curve: a page a search engine struggles to discover through links is a page that depends on weaker, unreliable fallbacks to be found at all. Neither source claims that adding internal links will move a specific page's rankings by a specific amount. What both support is a more modest, defensible claim: pages with very few internal links are working against how Google's crawler actually finds and revisits content, and that is a real, structural risk worth auditing for, not a superstition. ## Sources 1. [23 Million Internal Links - SEO Case Study](https://zyppy.com/seo/seo-study/) - Zyppy (primary) 2. [In-Depth Guide to How Google Search Works](https://developers.google.com/search/docs/fundamentals/how-search-works) - Google Search Central 3. [SEO Link Best Practices for Google](https://developers.google.com/search/docs/crawling-indexing/links-crawlable) - Google Search Central 4. [Build and Submit a Sitemap](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap) - Google Search Central --- --- title: "Anchor text diversity calculator" url: https://seomadman.com/tools/anchor-text-diversity-calculator section: tools published: 2026-08-15T00:00:00.000Z modified: 2026-08-15T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Anchor text diversity calculator ## The short answer This calculator classifies pasted inbound anchor texts against a target keyword and an optional brand name, sorting each into exact match, partial match, branded, generic, naked URL or other. It then shows the real percentage each category makes up, so you can read anchor diversity as a distribution rather than a single score, entirely in your browser. ## Key takeaways - A backlink profile built mostly from one exact-match anchor is the pattern Google's link spam guidance describes as manipulative, not a natural linking signal. - Google has never published an exact safe percentage for exact-match anchors, so this tool reports a distribution rather than issuing a verdict. - Partial match anchors are detected by containing the keyword or a majority of its individual words, not by an exact string comparison. - Branded anchors are only counted when you supply a brand or site name, because guessing at a brand from the keyword alone would be unreliable. - The generic anchor list is a small hardcoded set of common phrases, a starting heuristic rather than an authoritative taxonomy. Anchor text is the visible, clickable words in a link, and search engines have long used it as a signal of what the linked page is about. That makes it a target for manipulation: buy or trade enough links carrying the same exact keyword as anchor text, and you are trying to push a ranking signal rather than letting it form naturally from how other sites actually describe your page. ## What the categories mean Exact match is an anchor that, once lowercased and stripped of punctuation, equals your target keyword exactly. Partial match contains the keyword, or most of its individual words, without being an exact copy. Branded anchors contain the brand or site name you supplied, which is why that field is optional here rather than inferred. Generic anchors match a small hardcoded list of common phrases such as "click here" or "read more". Naked URL anchors are the link's own address used as its own text. Anything left over is reported as other, because forcing every anchor into a named bucket would misrepresent anchors that genuinely do not fit one. ## Why there is no pass or fail score Google's spam policies describe links carrying optimized, keyword-stuffed anchor text as a manipulation pattern associated with link schemes, not a neutral signal to be maximized. But Google has never published a specific exact-match percentage that counts as safe, and no legitimate source can cite one. A natural link profile mixes anchor types because different sites link to a page for different reasons, in their own words. This tool shows you that mix; deciding whether your split looks natural or engineered is a judgment call the distribution informs, not one it makes for you. Paste your own anchors above and adjust the keyword and brand fields to match the page you are checking. Run the same list through again after a link-building push to see how the mix shifted. ## Sources 1. [Spam policies for Google Search](https://developers.google.com/search/docs/essentials/spam-policies) - Google Search Central (primary) --- --- title: "Keyword density and content length checker" url: https://seomadman.com/tools/keyword-density-checker section: tools published: 2026-08-13T00:00:00.000Z modified: 2026-08-13T00:00:00.000Z author: Adam Hafez topics: ["Content strategy"] --- # Keyword density and content length checker ## The short answer This tool counts your draft's words, counts how often a keyword or phrase appears using whole-word matching, and calculates density as a percentage. There is no official ideal density to hit: Google has stated it does not score density, and instead flags unnatural repetition as keyword stuffing. Use the number to catch accidental overuse, not to chase a target. ## Key takeaways - There is no official optimal keyword density percentage, and this tool does not claim one. - Google's own spam policies name keyword stuffing, not a density threshold, as the practice to avoid. - Density here is calculated as keyword occurrences times the number of words in the phrase, divided by total word count. - The in-tool warning at heavy repetition is this tool's own heuristic, clearly labeled as such, not a published Google rule. - Everything runs in your browser; nothing you paste is sent anywhere. Word count and keyword repetition are easy to measure and easy to misuse. This tool measures both, plainly, so you can confirm a draft has not accidentally repeated a term far more than a human writer would, without turning that number into a target to hit. ## Why there is no official optimal keyword density Search engine optimization has circulated density targets for decades, most commonly a range somewhere between one and three percent. Google has never published such a target, and its own staff have said the opposite: rankings come from evaluating what a page is about and how well it answers a query, not from counting how many times a phrase repeats. Google's spam policies name the practice explicitly under keyword stuffing, describing it as filling a page with keywords or numbers in an attempt to manipulate rankings, often appearing in a list or group, unnaturally, or out of context. That page is a policy against manipulation, not a formula for a passing score. Chasing a density percentage optimizes for a number Google has said it does not use. ## What this number is actually useful for Density is still worth seeing, for a narrower reason than ranking. A draft edited in pieces can end up repeating a phrase far more than a person would naturally write it, especially after several rounds of keyword-focused revision. Seeing the raw count and percentage catches that kind of drift before publishing. Use it as a proofreading signal: if the count looks high for the length of the piece, read the passage back and see whether the repetition reads naturally or mechanically. Rewrite for the second case regardless of what percentage it produces. Content length works the same way here. A low word count paired with a claim to cover a topic in depth is a signal to add substance, not because Google counts words either, but because thin coverage of a topic is easy to spot once it is measured plainly. ## Frequently asked questions ### What is the ideal keyword density? There is no official ideal density. Google has repeatedly said it does not use a keyword-density-style score and instead evaluates relevance more holistically, judging text unnaturally packed with repeated terms as keyword stuffing rather than measuring it against a percentage target. ### Why does the tool warn me at a specific number then? The warning triggers on this tool's own heuristic for a phrase repeated an unnaturally high number of times in short text, clearly labeled as the tool's judgment call rather than a Google-published rule. It exists to catch accidental over-repetition, the kind Google's spam policies describe as keyword stuffing. ### Does matching count a phrase inside another word? No. Matching uses word boundaries, so a phrase like "cat" will not match inside "category". A multi-word phrase must appear as that exact sequence of words to count as one occurrence. ## Sources 1. [Spam policies for Google Search: keyword stuffing](https://developers.google.com/search/docs/essentials/spam-policies#keyword-stuffing) - Google Search Central (primary) --- --- title: "SearchPilot: promoting an H2 to H1 lifted organic traffic 4.5%" url: https://seomadman.com/studies/h2-to-h1-ab-test-searchpilot section: studies published: 2026-08-11T00:00:00.000Z modified: 2026-08-11T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # SearchPilot: promoting an H2 to H1 lifted organic traffic 4.5% ## The short answer SearchPilot, a real SEO A/B-testing firm, split-tested changing the top on-page heading from an H2 to an H1 on a travel company's listing pages. The change produced a statistically significant 4.5% increase in organic traffic, an estimated 3,000 extra monthly sessions once rolled out site-wide. SearchPilot does not disclose the exact test dates or confidence level. ## Key takeaways - SearchPilot's split test found that changing a travel site's top heading from an H2 to an H1 produced a statistically significant 4.5% increase in organic traffic. - SearchPilot estimated the change was worth roughly 3,000 additional monthly sessions once deployed across the client's full set of listing pages. - The test was a second iteration; an earlier run on a small subset of pages did not produce a clear enough result, so SearchPilot expanded it to four times as many pages. - SearchPilot's own case study reports the result as statistically significant without publishing an exact confidence level, credible interval or test date range. - Google's own SEO Starter Guide states that heading order does not affect Search rankings, so the mechanism behind this traffic gain is unverified. Whether an H1 outranks the same words wrapped in an H2 is one of the oldest arguments in on-page SEO, and most of it is opinion. SearchPilot, a controlled SEO A/B-testing company, ran an actual split test that changed only the tag: a travel company's listing pages had their top heading promoted from an H2 to an H1, with the visible text, position and everything else on the page held constant. SearchPilot's own published case study, not our analysis, is the source here. ## What was tested and what SearchPilot found The client's listing pages had no true H1: the top heading on the page was marked up as an H2. SearchPilot's variant group had that heading promoted to an H1; the control group kept it as an H2. The hypothesis, per SearchPilot's own case study, was that "updating the first heading to an H1 would help search engines better understand the page structure, align with SEO best practices, and improve organic traffic by boosting relevance and rankings." An earlier run of this same test, on a small subset of the client's pages, did not produce a clear enough result to act on. SearchPilot reran it on roughly four times as many pages in the same template, and that second test came back as a statistically significant positive result: a 4.5% increase in organic traffic, which SearchPilot estimated at around 3,000 additional monthly sessions once the change was rolled out site-wide. The case study does not publish a confidence level, credible interval or the calendar dates either run of the test covered. ## Why the heading tag itself is not a documented ranking factor Google's own SEO Starter Guide addresses this directly, and it does not agree with the hypothesis SearchPilot's client set out to test. On heading order and count, Google states plainly that "having your headings in semantic order is fantastic for screen readers, but from Google Search perspective, it doesn't matter if you're using them out of order." That is Google's documented position on heading structure and rankings: a matter of accessibility and readability, not a signal search ranks pages on. That leaves a real gap between what SearchPilot measured and why it happened. The 4.5% traffic increase is a controlled, statistically significant result; the mechanism behind it is not established by either SearchPilot's case study or Google's own documentation. A page that gains a correctly-tagged H1 also stops having a heading-structure defect, a missing top-level heading, that could plausibly affect how templates, snippets or other on-page elements render, independent of any ranking algorithm reading the tag name itself. SearchPilot does not make that claim either; this piece is not filling in a mechanism neither of them has stated. ## Why a controlled split test outweighs a tag-name opinion Every other split test we've covered from SearchPilot shares the same design: a control group and a variant group running at the same time, on the same site, so the comparison isolates one change from the seasonal and algorithmic noise a before-and-after read cannot separate out. Our coverage of [SearchPilot's breadcrumb link test](/studies/breadcrumb-link-removal-ab-test-searchpilot) found a markup mismatch that cost traffic; our coverage of [SearchPilot's FAQ content test](/studies/faq-content-ab-test-searchpilot) found a content addition that gained traffic while a schema-only change did nothing. This test adds a third data point in the same series: a single tag change, isolated from everything else on the page, moved traffic in a travel client's real production environment. ## Why we care An H2-to-H1 swap is one of the cheapest changes a site can make, and this case study gives it a real, measured result rather than a plausible-sounding rule. What it does not give is a reason to treat H1 as a ranking lever in general: Google's own documentation says heading order doesn't matter to Search, and SearchPilot's case study describes one page template that lacked a true H1 in the first place. The honest takeaway is narrower than "always use H1": check whether your top-level heading is actually marked up as one, and treat a missing H1 as a structural defect worth fixing, not because the tag name itself ranks, but because SearchPilot has now measured a real site where fixing it correlated with a real traffic gain. ## Frequently asked questions ### Does this mean an H1 always outranks an H2 for the same text? No. SearchPilot's own case study frames this as one result on one travel client's listing pages, not a rule about tag names. Google's own documentation says heading order does not affect rankings, so the traffic gain here cannot be attributed to the H1 tag alone acting as a ranking signal. ### Why did SearchPilot run this test twice? The first run, on a small subset of pages, did not produce a result clear enough to act on. SearchPilot expanded the second run to roughly four times as many pages in the same template, which is what produced the statistically significant 4.5% figure this piece reports. ### What exactly changed on the page besides the tag name? SearchPilot's case study describes the change as promoting the page's existing top heading from an H2 to an H1, correcting a page that had no true H1. It does not report any accompanying change to the heading's text, position or styling. ## Sources 1. [Does Changing an H2 to an H1 Improve Organic Traffic?](https://www.searchpilot.com/resources/case-studies/does-changing-an-h2-to-an-h1-improve-organic-traffic) - SearchPilot (primary) 2. [SEO Starter Guide: The basics of how to think about SEO](https://developers.google.com/search/docs/fundamentals/seo-starter-guide) - Google Search Central --- --- title: "JSON-LD structured data adoption grew from 34% to 41% of pages" url: https://seomadman.com/studies/structured-data-adoption-web-almanac section: studies published: 2026-08-11T00:00:00.000Z modified: 2026-08-11T00:00:00.000Z author: Adam Hafez topics: ["Structured data", "Technical SEO"] --- # JSON-LD structured data adoption grew from 34% to 41% of pages ## The short answer The Web Almanac, HTTP Archive's annual analysis of millions of crawled pages, found that JSON-LD structured data usage grew from 34% of pages in 2022 to 41% in 2024. RDFa (66%) and Open Graph (64%) remained the most widely used formats that year, ahead of JSON-LD, Twitter meta tags (45%) and Microdata (26%). ## Key takeaways - The Web Almanac's 2024 structured-data chapter found JSON-LD present on 41% of crawled pages, up from 34% in 2022. - RDFa (66%) and Open Graph (64%) were still the most common structured-data formats on the web in 2024, ahead of JSON-LD. - Twitter meta tags reached 45% of pages, Microdata 26%, and Facebook-specific meta tags 7%, per the same chapter. - The Web Almanac crawls millions of URLs monthly through HTTP Archive's own infrastructure, not a random sample of the entire web. - A page can carry more than one structured-data format at once, so these adoption rates are not mutually exclusive shares. HTTP Archive's Web Almanac, an annual analysis built on its own crawl of millions of live pages, tracked structured-data format usage across the web and found JSON-LD growing from 34% of pages in 2022 to 41% in 2024. That places JSON-LD, the format Google recommends, behind two older and broader formats in absolute share: RDFa at 66% of pages and Open Graph at 64%. Twitter meta tags sat at 45%, Microdata at 26%, and Facebook-specific meta tags at 7%. The chapter, written by Andrea Volpini, treats these as adoption rates for each format independently, not as a single pie that sums to 100%, since a page commonly ships more than one of them at once. ## What the Web Almanac actually measured HTTP Archive runs its crawl through its own WebPageTest infrastructure rather than sampling a handful of sites by hand. Its 2025 methodology page states the July 2025 crawl alone covered 16,213,084 websites, split into 15,426,398 mobile pages and 12,155,374 desktop pages, each rendered in a real Chrome environment and logged into BigQuery for public querying. The 2024 structured-data chapter ran on the equivalent crawl a year earlier, under the same continuous methodology HTTP Archive has used since the Almanac began. This is what makes the 34%-to-41% JSON-LD figure a genuine year-over-year comparison rather than two studies with different sampling built from scratch. ## What the numbers do and do not represent The crawl set is HTTP Archive's own list of URLs, built from the Chrome UX Report and its own history, which skews toward pages popular and stable enough to be crawlable at scale - not a uniform random sample of every page that exists. The chapter also measures format presence, not correctness or completeness: a page counted as having JSON-LD may carry a single minimal Organization block rather than the rich markup a publisher might assume when they read "41%." And because formats overlap, a rise in JSON-LD adoption does not mean RDFa or Open Graph declined by a matching amount; each format's share moves on its own. ## Why we care **JSON-LD's growth is real, but it is still the newer format catching up, not the leader.** Two-thirds of crawled pages already carry RDFa or Open Graph, mostly from social-preview meta tags rather than deliberate schema.org work, so a 41% JSON-LD share undercounts how much of a publisher's actual competitive set already ships some form of structured markup. **The comparison is trustworthy because it is one continuous methodology, not two.** HTTP Archive's crawl infrastructure and dataset shape are consistent enough between 2022 and 2024 that the before-and-after figure reflects real adoption change, not a change in how the data was gathered. **Presence is not quality.** A rising JSON-LD percentage says more pages carry the format at all; it says nothing about whether that markup validates, matches on-page content, or covers the entity types that actually earn rich results. ## Sources 1. [2024 Web Almanac: Structured Data](https://almanac.httparchive.org/en/2024/structured-data) - HTTP Archive (primary) 2. [2025 Web Almanac: Methodology](https://almanac.httparchive.org/en/2025/methodology) - HTTP Archive --- --- title: "ChatGPT Ads adds oCPC bidding and a product carousel" url: https://seomadman.com/news/chatgpt-ads-product-feeds section: news published: 2026-08-10T00:00:00.000Z modified: 2026-08-10T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # ChatGPT Ads adds oCPC bidding and a product carousel ## The short answer OpenAI updated ChatGPT Ads Manager on August 7, 2026: conversion-optimized cost-per-click (oCPC) bidding entered beta for product feed campaigns, dynamic URL parameters now populate landing page links automatically, and a multi-product carousel format is in testing. OpenAI also set August 17, 2026 as the date automatic advanced matching turns on for existing web pixels unless advertisers opt out. ## Key takeaways - OpenAI moved oCPC bidding into beta for product feed campaigns on August 7, 2026, still billed per click but delivered toward the clicks most likely to convert. - Advertisers can clone an existing CPC campaign into oCPC or create oCPC campaigns in bulk, with conversion events prefilled where available. - Dynamic URL parameters now support campaign_id, ad_group_id, ad_id and ad_account_id macros, populated automatically at delivery time. - A multi-product carousel format is in testing, showing several products from one advertiser's feed inside a single ad unit. - Automatic advanced matching becomes the default for existing web pixels on August 17, 2026 unless the advertiser opts out before then. OpenAI updated ChatGPT Ads Manager on August 7, 2026, and every change lands on the product feed side of the platform: conversion-optimized cost-per-click bidding moved into beta, landing page links gained macros for attribution, and a multi-product carousel format started testing at the bottom of a conversation. For retailers already treating ChatGPT as a shopping surface, this is the update that makes the feed itself the thing worth optimizing. ## What changed in the August 7 update Search Engine Roundtable's report on the OpenAI advertiser email lists four changes, all scoped to product feed campaigns rather than the platform generally. **oCPC bidding entered beta.** Conversion-optimized cost-per-click campaigns are now available for product feed campaigns. The initial release supports click-billed campaigns using fixed or manual bidding with a positive conversion bid cap: the advertiser still pays per click, but delivery shifts toward the clicks OpenAI predicts are likeliest to convert. Advertisers can clone an existing CPC campaign into a new oCPC campaign, or create oCPC campaigns in bulk, with conversion events prefilled where they already exist. **Dynamic URL parameters went live.** Landing page query parameters now support the macros campaign_id, ad_group_id, ad_id and ad_account_id, populated automatically at delivery time. That closes a basic attribution gap: a retailer can now tell which product feed campaign and ad drove a given session without hand-building URL variants for every SKU. **A multi-product carousel format entered testing.** OpenAI is testing a carousel that places several products from one advertiser's feed side by side in a single unit at the bottom of a ChatGPT conversation, letting a user compare items without leaving the exchange they are already having. **Automatic advanced matching gets a deadline.** Advanced matching is already the default on new web pixels. OpenAI will turn it on for existing web pixels on August 17, 2026 unless the advertiser opts out before then, a separate but related change to the same measurement stack the oCPC beta depends on for conversion signal. ## Why this matters for feed visibility, not just bidding Every part of this update assumes the advertiser already has a working product feed connected to ChatGPT Ads Manager, because oCPC needs conversion data tied to individual feed items and the carousel needs multiple eligible products to place side by side. That puts ChatGPT Ads in the same position Google Merchant Center has occupied for years: the feed is the asset, and bidding or ad format changes only compound on top of feed quality that is already correct. A retailer whose feed has thin titles, missing images or unclear availability will not get a meaningful lift from oCPC, because the model has weaker conversion signal to optimize against in the first place. The dynamic URL macros matter for the same reason technical SEO people already care about clean attribution: without campaign_id and ad_id resolving automatically, a retailer running product feed campaigns at scale has no efficient way to tell which SKUs and creative combinations are actually converting inside ChatGPT, as opposed to which ones simply got the most impressions. ## Why we care This is a bidding and measurement update dressed as a shopping feature, and that is the useful reading of it. OpenAI is not yet describing feed submission mechanics the way Google documents Merchant Center's spec, but the direction is the same: retailers who treat their ChatGPT product feed with the same rigor as a Merchant Center feed, accurate titles, current pricing, working images, will be the ones oCPC's conversion signal actually favors once it leaves beta. ## Frequently asked questions ### What is oCPC bidding in ChatGPT Ads? Conversion-optimized cost-per-click bidding, in beta for product feed campaigns as of August 7, 2026. Advertisers still pay per click, but OpenAI adjusts delivery toward the clicks it predicts are most likely to convert, using either fixed or manual bidding with a positive conversion bid cap. ### Do existing campaigns need to be rebuilt to use oCPC? No. Advertisers can clone an existing CPC campaign into a new oCPC campaign, or create oCPC campaigns in bulk, and OpenAI prefills conversion events where they are already available. ### When does automatic advanced matching turn on for existing web pixels? August 17, 2026. Automatic advanced matching is already the default for new web pixels; OpenAI is extending it to existing pixels on that date unless the advertiser opts out beforehand. ## Sources 1. [OpenAI ChatGPT Ads Updates: oCPC, Dynamic URLs, Multi-Product Carousel Format & More](https://www.seroundtable.com/openai-chatgpt-ads-updates-41828.html) - Search Engine Roundtable (primary) --- --- title: "One publisher's Google Discover traffic loss and recovery" url: https://seomadman.com/studies/discover-traffic-recovery-case section: studies published: 2026-08-09T00:00:00.000Z modified: 2026-08-09T00:00:00.000Z author: Adam Hafez topics: ["Content strategy"] --- # One publisher's Google Discover traffic loss and recovery ## The short answer An independent consultant's case study describes a client publisher's Google Discover traffic falling to zero impressions for about seven weeks after a core update. The consultant traced it to missing Discover-ready images, broken structured data, a schema bug crediting articles to the wrong site, and thin pages. Discover traffic returned the same day as Google's next core update. ## Key takeaways - One independent consultant's account of a client engagement describes Discover impressions falling to zero for about seven weeks after a Google core update. - The audit found articles without Discover-ready images, broken structured data, a schema bug crediting articles to a different site, missing bylines, and thin pages. - Recovery meant sizing images for Discover across nearly the whole catalogue, fixing the structured-data errors, and trimming the thinnest pages, then holding steady and waiting. - Every title in the client's network regained Discover visibility the same day, coinciding with a core update, and the flagship site posted its best Discover month on record. - This is one consultant's self-reported, unaudited account of a single client, with exact traffic numbers withheld at the client's request, not a formula to replicate. A consultant's Discover recovery story is a different kind of source than the algorithm-update coverage above: it is one person's account of one client, not a dataset or a Google announcement. Independent consultant Nerijus Masikonis published a case study describing a publisher client whose Google Discover impressions dropped to zero after a core update, stayed there for weeks, and then came back. We read the post directly. Here is what it actually says, in the consultant's own words, and why it should be read as a single anecdote rather than a repeatable playbook. ## What happened, in the consultant's own account The client's Discover traffic collapsed after a Google core update. Per the post, "the impressions went to zero and stayed there" for about seven weeks. Masikonis writes that his audit afterward found "articles without Discover-ready images, broken images and structured data, a schema bug crediting articles to a different site, missing authors and descriptions, and thin pages." That is a list of quality and technical signals, not a single named cause, and the post does not claim to know which item on that list mattered most to Google. ## What changed, and how Google responded The fixes described are concrete: Discover-sized images went out to "almost the whole catalogue," reaching 97% of articles by the consultant's own figure. The broken structured data and the schema bug misattributing articles to another site were corrected. Missing author bylines and descriptions were filled in. The thinnest, lowest-quality pages were removed rather than kept. After that, Masikonis writes that he "held the site steady and waited." Discover traffic did not return gradually, it came back "on the same day" as Google's next core update, across every title in the client's network, with the flagship site going on to post its best Discover month on record. ## Why this is one case, not a study Masikonis states outright that "traffic volumes are hidden at the client's request," so there is no absolute click or impression figure to check the recovery against, only the zero-impression period, the 97% image fix, and the relative claim of a record month. This is a single consultant's self-reported account of a single client engagement, published on his own site, not an audited tracker dataset or a Google statement. Nothing here establishes that the same fixes would recover Discover traffic for a different site, or that the timing next to a core update was cause rather than coincidence. ## Why we care The value of this case is the checklist, not the numbers. Discover-ready image sizing, clean structured data, correct site attribution, complete author and description metadata, and pruning thin pages are all things a publisher can audit today without waiting on Google. Treat the recovery timeline, the same-day return alongside a core update, as one data point worth watching for, not a mechanism this post proves. Read it alongside our coverage of the February 2026 Discover-only core update, which found that most of an article's Discover clicks land within a day of publishing, for the fuller picture of how fast this channel moves in both directions. ## Frequently asked questions ### Does this case study give exact traffic numbers? No. The consultant states plainly that traffic volumes are hidden at the client's request. The post gives directional detail instead, zero impressions for weeks, then a recovery to the site's best Discover month on record, and one hard figure, 97% of articles fitted with Discover-ready images. ### Is this independently verified data? No. It is one consultant's own, unaudited account of one client engagement, published on their own site. We read the source directly and report what it says, but nobody outside that engagement has confirmed the numbers or the cause. ### What actually caused the drop, according to the consultant? A Google core update, combined with site-wide quality issues the consultant's audit surfaced afterward, missing Discover-ready images, broken images and structured data, a schema bug attributing articles to a different site, missing author information and descriptions, and thin pages. ## Sources 1. [Google Discover recovery case study](https://masikonis.lt/case-studies/google-discover-recovery/) - Nerijus Masikonis (independent consultant) (primary) --- --- title: "Deloitte: 0.1s faster mobile speed lifted retail conversion 8.4%" url: https://seomadman.com/studies/page-speed-conversion-rate-impact section: studies published: 2026-08-08T00:00:00.000Z modified: 2026-08-08T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Deloitte: 0.1s faster mobile speed lifted retail conversion 8.4% ## The short answer Deloitte and Fifty-Five tested 37 retail, travel, luxury and lead-generation brand sites over four weeks in late 2019. A 0.1 second mobile speed improvement lifted retail conversion rate by 8.4% and average order value by 9.2%, while travel conversion rose 10.1%. Shopify's newer data found a similar pattern: 100 milliseconds slower load costs roughly 3.5% conversion. ## Key takeaways - Deloitte and data partner Fifty-Five tested 37 retail, travel, luxury and lead-generation brand sites across Europe and the US over four weeks in October and November 2019. - A 0.1 second mobile speed improvement was linked to an 8.4% lift in retail conversion rate and a 9.2% lift in average order value. - Travel conversion rate rose 10.1% for the same 0.1 second mobile speed improvement, though travel average order value moved only 1.9%. - Shopify's own 2026 analysis of Core Web Vitals data found that every 100 milliseconds of slower load time correlates with roughly 3.5% lower conversion. - Deloitte's own report calls the finding a correlation observed across 37 already-live sites, not a controlled experiment, and notes that desktop data showed contradicting results. Deloitte and Google-commissioned research firm Fifty-Five spent four weeks in late 2019 measuring what a fraction of a second of mobile page speed is worth to 37 brand sites. Their headline number, an 8.4% lift in retail conversion rate for a 0.1 second improvement, still gets quoted constantly. Shopify has since published its own, more recent read on the same relationship. Here is what each study actually measured, and where the two claims are Deloitte's and Shopify's findings, not ours. ## What Deloitte actually measured **Thirty-seven brands, one four-week window.** Fifty-Five recruited over 70 retail, travel, luxury and lead-generation brands across Europe and the US, and 37 passed its analytics, technical and qualitative audits. From 28 October to 24 November 2019, it collected mobile site speed data through Google Lighthouse and combined it with each brand's own web analytics: page views, bounce rate, funnel progression, conversion rate and average order value. **A regression model, not a controlled experiment.** Deloitte and Fifty-Five built a logarithmic regression model to correlate four key mobile speed metrics with each site's KPIs, requiring at least 95% statistical significance before a result was reported. Speed fluctuations were natural, arising from each site's own performance work and traffic conditions, never artificially induced. The published 0.1 second figure is the combined, cumulative effect of all four speed metrics moving together, not one isolated change. **Different verticals, different KPIs.** Retail and travel counted a completed transaction as conversion. Luxury counted an add-to-basket or "contact us" click. Lead generation counted a completed form. Retail conversion rose 8.4% and average order value rose 9.2%; travel conversion rose 10.1% with a smaller 1.9% average order value gain; luxury page views per session rose 8%; lead-generation informational pages saw an 8.3% bounce rate improvement. ## Why a correlation study is not a universal speed rule **This measures sites that were already live and already changing.** Deloitte's own limitations section is explicit: the 37 sites were "aggregated by vertical," which "may not fully reflect an individual site's product offering, design, or seasonality." The study found a correlation between naturally occurring speed changes and business metrics on sites that were already fast enough to be running production ecommerce, not a controlled test of speed at every point on the scale. **It does not extend to desktop, or to every speed range.** Deloitte says it looked for the same correlation on desktop and "found a lot of contradicting parameters," attributing that to desktop users being less sensitive to load time than mobile users. Nothing in the study implies a 0.1 second gain is worth the same 8.4% at every starting speed; a site already loading in under a second and one loading in eight seconds are not shown to behave the same way for the same improvement. **Shopify's newer figure is a similar shape of claim, not a replication.** Shopify's enterprise blog reports that across actively selling Shopify stores, every 100 milliseconds of slower load correlates with roughly 3.5% lower conversion, based on 28 days of Largest Contentful Paint data from around the turn of 2026. It also found stores with a 2.5 second LCP converting roughly 30% worse than stores at 1.5 seconds. Different platform, different metric, same broad conclusion: mobile speed and conversion move together, and the relationship looks steep at the low-millisecond end most publishers actually operate in. ## Why we care **The direction is well established; the exact multiplier is not portable.** Two independent studies, six years apart and built on different site populations, both find meaningful conversion sensitivity to small mobile speed changes. That is a solid reason to treat Core Web Vitals work as revenue work, not just a ranking checkbox. **Quote the vertical, not just the headline number.** "0.1 second equals 8.4% more conversions" is true only for Deloitte's retail sample in 2019. Travel, luxury and lead-generation sites in the same study moved by different amounts on different metrics, and neither study claims the effect is linear at every speed level. Cite the study, the vertical and the metric together, or don't cite the number at all. ## Frequently asked questions ### How many sites did Deloitte actually study? 37. Fifty-Five approached over 70 retail, travel, luxury and lead-generation brands across Europe and the US, and 37 qualified after analytics, technical and qualitative audits. Deloitte's own report says results "may not fully reflect the internet as a whole" for that reason. ### Does the 8.4% figure apply to every industry? No. Deloitte broke results out by vertical. Retail conversion rose 8.4% and average order value rose 9.2%. Travel conversion rose 10.1% but average order value rose only 1.9%. Luxury and lead-generation sites did not use conversion rate as their KPI at all; Deloitte tracked page views per session and form completions instead. ## Sources 1. [Milliseconds Make Millions](https://www.deloitte.com/ie/en/services/consulting/research/milliseconds-make-millions.html) - Deloitte Digital / Fifty-Five (commissioned by Google) (primary) 2. [Store speed and conversion: what the data shows](https://www.shopify.com/enterprise/blog/store-speed-conversion) - Shopify --- --- title: "Ahrefs: AI Overviews cut position-1 CTR by 58%" url: https://seomadman.com/studies/ai-overviews-click-through-rate-decline section: studies published: 2026-08-06T00:00:00.000Z modified: 2026-08-06T00:00:00.000Z author: Adam Hafez topics: ["AI search", "Search Console"] --- # Ahrefs: AI Overviews cut position-1 CTR by 58% ## The short answer Ahrefs analyzed Google Search Console data for 300,000 keywords, comparing December 2023 to December 2025. It found that pages ranking first now get a 58% lower click-through rate when an AI Overview appears, up from the 34.5% drop Ahrefs measured a year earlier using an equivalent March 2024 to March 2025 comparison. ## Key takeaways - Ahrefs compared position-1 organic click-through rate for the same 300,000-keyword sample in December 2023 and December 2025. - Pages ranking first now receive a 58% lower click-through rate when Google shows an AI Overview, according to Ahrefs. - The 34.5% figure Ahrefs published in April 2025 and the 58% figure published in February 2026 are two separate runs of the same method, not one revised number. - Non-AI Overview informational keywords also lost roughly half their position-1 click-through rate over the same two years, so part of the decline is not unique to AI Overviews. - This is Ahrefs' research on its own keyword sample, not a SEO Madman finding, and Google Search Console cannot show what a searcher does on the results page itself. Ahrefs has now run the same click-through-rate study twice. In April 2025 it reported that pages ranking first in Google lost 34.5% of their click-through rate when an AI Overview appeared above them. In February 2026 it reran the analysis on a longer time window and reported a bigger number: 58%. Both figures are Ahrefs' own research, built from its own keyword sample and Google Search Console data, not ours. ## What Ahrefs actually measured **A 300,000-keyword sample, split in two.** Ahrefs drew 150,000 keywords that showed an AI Overview and 150,000 informational keywords that did not, all from its Keywords Explorer database. For each keyword it pulled aggregated Google Search Console click-through rate for position 1 - clicks divided by impressions - at two points in time, then compared them. **The updated study used December 2023 and December 2025.** For keywords that went on to trigger an AI Overview, position-1 CTR was 7.3% in December 2023 and 1.6% in December 2025. For the informational keywords that never triggered one, CTR fell too, from 7.6% to 3.9% over the same two years. Ahrefs used that second, no-AI-Overview decline to forecast what the AI Overview keywords' CTR would have been without the feature: 3.7%. The gap between that 3.7% forecast and the actual 1.6% is where the 58% figure comes from. ## Two figures, two points in time **The earlier 34.5% number is not the same measurement, restated.** It came from a one-year window, March 2024 to March 2025, run before AI Overviews had reached as many countries and languages. The 58% figure is a fresh run on a two-year window that captures more of the rollout, and Ahrefs frames it as evidence the effect is deepening, not a correction of the earlier number. Cite whichever one matches the period you care about, and say which one you mean - they answer different questions. ## What Google Search Console can't show you **Correlation across many sites is not a forecast for any one page.** Ahrefs' sample spans 300,000 keywords across many domains; a single article's click-through rate depends on its own snippet, brand recognition and query intent, none of which this study isolates. **Search Console only reports what reaches it.** It shows clicks and impressions for a site's own organic listing, not what a searcher does inside the AI Overview itself, on Google's SERP more broadly, or on competitors' listings. A study built entirely on Search Console data, however large the sample, cannot see behavior that never reaches a publisher's own property - it can only measure the shrinking slice that does. ## Why we care **The direction of travel matters more than the exact percentage.** Two independently run studies from the same source, eight months apart, both show position-1 organic CTR falling further as AI Overviews mature. That is a reasonable basis for planning around less click-through from a page-one ranking, even without treating 58% as a number that applies uniformly to your own [AI search](/topics/ai-search) traffic. **Verify a vendor claim against the study it cites.** If you see "AI Overviews cut clicks by X%" without a date range, ask which Ahrefs run it comes from, or whether it is a different source entirely - Ahrefs' own writeup names several other studies with different methodologies and different numbers, from a roughly 50% CTR drop to one outlet's claim of 80 to 90%. ## Frequently asked questions ### Is this SEO Madman's own data? No. This is our reading of research Ahrefs published and ran twice, first in April 2025 and again in February 2026. We did not collect the underlying Search Console data ourselves, and we link to both Ahrefs posts so you can check the numbers against the source. ### Why are there two different percentages, 34.5% and 58%? They come from separate runs of the same Ahrefs methodology at different points in time. The 34.5% figure compared March 2024 to March 2025. The 58% figure, published later, compared December 2023 to December 2025 - a longer window, and one where AI Overviews had been live for longer. ## Sources 1. [Update: AI Overviews Reduce Clicks by 58%](https://ahrefs.com/blog/ai-overviews-reduce-clicks-update) - Ahrefs (primary) 2. [AI Overviews Reduce Clicks by 34.5%](https://ahrefs.com/blog/ai-overviews-reduce-clicks/) - Ahrefs (primary) --- --- title: "SearchPilot: FAQ content lifted traffic, FAQ schema did not" url: https://seomadman.com/studies/faq-content-ab-test-searchpilot section: studies published: 2026-08-05T00:00:00.000Z modified: 2026-08-05T00:00:00.000Z author: Adam Hafez topics: ["Content strategy", "Structured data"] --- # SearchPilot: FAQ content lifted traffic, FAQ schema did not ## The short answer SearchPilot, a real SEO A/B-testing firm, split-tested two separate FAQ changes on ecommerce product listing pages. Adding page-specific FAQ content to footer copy produced a statistically significant 9.7% increase in organic clicks. In a separate test, removing FAQ schema markup while keeping the FAQ content had no statistically significant impact on organic traffic either way. ## Key takeaways - SearchPilot's split test found that adding page-specific FAQ content to PLP footer copy produced a +9.7% increase in organic clicks at a 95% credible interval. - A separate SearchPilot split test removed only the FAQ schema markup, itemprop, itemscope and itemtype, while leaving the visible FAQ content in place. - That schema removal found no statistically significant impact on organic traffic, in either direction, once the content itself stayed untouched. - Both tests ran on real ecommerce product listing pages with everything else held constant, isolating the FAQ change as the only variable in play. - SearchPilot does not disclose exact test start and end dates in either case study, only that both are controlled experiments on its own testing platform. Most claims about FAQ content and SEO are observational: a site added FAQs, traffic went up sometime after, and the two get linked. SearchPilot, a controlled SEO A/B-testing company formerly known as Distilled ODN, ran two actual split tests that isolate the FAQ variable itself. One tested the content; the other tested the schema markup around it. The results point in different directions, and SearchPilot's own published case studies, not our analysis, are the source for both. ## What each test controlled for and found **Test one: adding FAQ content to footer copy.** SearchPilot added page-specific FAQ content below the existing footer copy on a set of ecommerce product listing pages, addressing category-level questions. The control group kept the existing footer copy with no FAQ content added; product grids, filters and internal linking stayed identical across both groups. The test delivered a positive result at the 95% credible interval, with an estimated 9.7% increase in organic clicks. SearchPilot attributes this to the added content letting the page match a wider set of long-tail and informational queries it wasn't previously targeting. **Test two: removing FAQ schema markup, keeping the content.** In a separate test on a different ecommerce customer's product listing pages, SearchPilot stripped only the `itemprop`, `itemscope` and `itemtype` microdata attributes from an existing, valid inline FAQ block, leaving the visible FAQ text untouched. Removing that markup produced no statistically significant impact on organic traffic in either direction. SearchPilot's own reading: since Google stopped showing FAQ rich results for most sites, the schema wrapper no longer does anything measurable to organic performance, positive or negative, even though it remains a valid Schema.org type. **Neither test discloses an exact run length.** Both published case studies describe the change, the control/variant setup and the statistical result, but not the calendar dates the test itself ran for. That is a real gap in what SearchPilot has made public, not something this piece is filling in. ## Why a split test outweighs a before-and-after comparison **The comparison happens at the same time, not across time.** A before-and-after read on a single site can't separate the effect of the change from whatever else happened in the same window: a core update, a seasonal traffic swing, a sitewide template change. SearchPilot instead runs a control group and a variant group concurrently on pages of the same site, so both groups experience the same external conditions and only the tested change differs between them. **The result carries an explicit confidence level.** The FAQ content test isn't reported as "traffic went up 9.7%"; it's reported as a positive result at the 95% credible interval, a statement about how likely the observed lift is to be real rather than noise. The schema removal test is reported the same way, as a null result: no statistically significant difference, not "we didn't check." That distinction, a designed test with a stated confidence level versus an anecdote with a percentage attached, is the entire reason these two numbers are worth citing and Deloitte-style before-and-after retail figures need the caveats [our page speed coverage](/studies/page-speed-conversion-rate-impact) already gives them. **A null result is still a result.** Most published SEO case studies only report wins. SearchPilot publishing an inconclusive test, FAQ schema removal moving nothing, is itself evidence: it means the FAQ content's traffic contribution in test one is coming from the text Google can read and match to queries, not from the structured data markup around it. ## Why we care FAQPage markup lost its Google rich result on 7 May 2026, as [we covered separately](/news/faq-rich-results-removed). That removal was a policy change: Google stopped showing a feature. These two SearchPilot tests answer a different question the policy change alone doesn't: whether the underlying FAQ content and its markup were doing anything for organic traffic in the first place. The content evidently was, by a measured 9.7%; the markup, on its own, evidently was not. For anyone deciding whether to keep writing FAQ copy now that it earns no snippet, that split is the actual answer: keep writing the content for the queries it can still match, and treat the schema as optional plumbing rather than a traffic lever. ## Frequently asked questions ### Is SearchPilot's 9.7% figure the same as saying FAQ content always helps SEO? No. SearchPilot's own case study frames it as one result on one set of ecommerce product listing pages, and cautions that results depend on how well the added FAQ content aligns with real user queries and how much content the page already had. It is evidence, not a universal multiplier. ### Does this mean FAQ schema markup is worthless? These two tests only measured organic traffic after Google stopped showing FAQ rich results in Search. Schema still has other jobs, machine readability for non-Google crawlers among them, that a traffic-only split test does not capture. See our coverage of the FAQ rich result removal for that side of the story. ### How is a SearchPilot split test different from a before-and-after comparison? SearchPilot runs simultaneous control and variant page groups on the same live site rather than comparing one period to another. That controls for seasonality, algorithm updates and sitewide changes hitting the whole site at once, which a before-and-after read cannot separate from the change being tested. ## Sources 1. [Will adding FAQ Content to Footer Copy Improve Organic Traffic?](https://www.searchpilot.com/resources/case-studies/will-adding-faq-content-to-footer-copy-improve-organic-traffic) - SearchPilot (primary) 2. [How does removing FAQ markup on pages with valid schema impact SEO?](https://www.searchpilot.com/resources/case-studies/removing-valid-faq-schema) - SearchPilot (primary) --- --- title: "Review and AggregateRating schema: Google's real required fields" url: https://seomadman.com/research/review-aggregaterating-schema-requirements section: research published: 2026-08-04T00:00:00.000Z modified: 2026-08-04T00:00:00.000Z author: Adam Hafez topics: ["Structured data"] --- # Review and AggregateRating schema: Google's real required fields ## The short answer Google's review-snippet documentation requires itemReviewed, author, and reviewRating for a single review, or ratingCount/reviewCount plus ratingValue for an aggregate rating, and it bans self-serving reviews, undisclosed incentivized reviews, and markup users cannot see on the page itself, exact rules most implementations never actually check against. ## Key takeaways - A single Review needs author, itemReviewed with an eligible @type, and a reviewRating carrying a ratingValue, per Google's documented required-property list. - An AggregateRating needs itemReviewed plus at least one of ratingCount or reviewCount, and Google states explicitly that at least one of the two is required. - Google's guidelines make a LocalBusiness or Organization page ineligible for the star feature when the reviewed entity controls the reviews about itself on its own site. - Google's technical guidelines require marked-up review content to be readily visible to users on the same page, not hidden markup with no matching on-page text. - Google states plainly that if bestRating is omitted a 5 is assumed and if worstRating is omitted a 1 is assumed, so the default scale is 1 to 5 unless declared otherwise. Most guidance on review schema repeats the same short list, add reviewRating, add an author, done. Google's own review-snippet documentation is longer than that list and stricter than it, because it does not only name required properties, it also names behavior it will disqualify a page for even when every property is technically present. The gap between "markup that validates" and "markup Google will actually show a star for" is exactly where most implementations fail. ## The real required and recommended properties Google's documentation splits into two eligible cases, and each has its own required set rather than one shared list. A single **Review** needs `author` (a `Person` or `Organization`, with what Google calls a valid name shorter than 100 characters), `itemReviewed` when the review is not nested inside the item it reviews, and `reviewRating` carrying a numeric `ratingValue`. The `itemReviewed` type has to be one Google actually recognizes for this feature: its documented list names, among others, Book, Course, Event, LocalBusiness, MediaObject, Movie, Organization, Product, Recipe and SoftwareApplication. A review of anything outside that list does not qualify for the star snippet regardless of how the rest of the markup is built. An **AggregateRating** without individual reviews attached needs `itemReviewed`, a numeric `ratingValue`, and, in Google's own words, at least one of `ratingCount` or `reviewCount`. Neither one alone with the other missing satisfies the rule; the documentation is explicit that one of the two specific properties must be present, not that a count of any kind is enough. Google's recommended, non-required additions are `datePublished` on a Review, and `bestRating` and `worstRating` on either a Review's `reviewRating` or an `AggregateRating`. Those three are worth adding but do not block eligibility on their own if a page is otherwise correctly built. ## The real documented abuse and validation rules The properties above are structural. Google separately disqualifies pages on behavior, and this is the part implementations miss because a validator that only checks property presence has nothing to say about it. The rule with the most practical bite is the self-serving one. Google's guidelines state that when the entity being reviewed controls the reviews about itself, a page using `LocalBusiness` or any other `Organization` type is ineligible for the star review feature, and that this applies whether the markup is direct or served through an embedded third-party widget. A business publishing testimonials about its own services on its own site, marked up as `LocalBusiness` reviews, is the exact shape this rule targets. It does not reach `Product` review markup on a retailer's own product pages, since the rule is scoped to `LocalBusiness` and `Organization` types specifically, which is why product review widgets remain common while self-hosted business-testimonial schema does not qualify. Separately, Google's technical guidelines ban fake or undisclosed incentivized reviews outright, defining the category to include reviews that are not based on a genuine experience of the product or service, and reviews written in exchange for money, discounts, vouchers, or free products that do not clearly and prominently disclose that incentive. A page can satisfy every required property and still fail this rule if the reviews behind the markup were bought without disclosure. The visibility rule closes the remaining gap: Google's guidelines require that the review content being marked up is readily available to users from the same marked-up page, stating it must be immediately obvious to users that the page has review content. Markup describing reviews with no matching visible text on the page is a documented violation on its own, independent of whether `ratingValue`, `author`, and `itemReviewed` are all correctly filled in. On the numeric scale, Google's documentation states the default is a 5-point scale, 1 lowest to 5 highest, and that a missing `bestRating` is assumed to be 5 while a missing `worstRating` is assumed to be 1. Neither property is required, but a site using a different scale, a 10-point or a 100-point rating, has to declare both explicitly or Google will read the value against the wrong default range. ## Why we care Every one of these rules is checkable against a live page in minutes: does `itemReviewed` carry an eligible type, is `ratingCount` or `reviewCount` present, does the reviewed entity control the reviews on a `LocalBusiness` or `Organization` page, is the review text actually visible where the markup claims it is, and does the declared scale match `bestRating`/`worstRating` if it is not 1 to 5. None of that requires guessing at Google's intent, all of it is stated on the documentation page itself. What Google's own reported numbers say about how often sites actually violate these rules at scale, rather than what the rules are, is covered on this site by [Google's review-fraud enforcement scale report](/reports/google-review-fraud-enforcement-scale), which traces Google's 2025 Maps enforcement totals separately from the rule text covered here. ## Frequently asked questions ### Does a page need both an individual Review and an AggregateRating? No. Google's documentation treats them as two separate eligible cases. A single Review needs author, itemReviewed, and reviewRating with a ratingValue. An AggregateRating needs itemReviewed, a ratingValue, and at least one of ratingCount or reviewCount. A page can carry either or both, but each case has to satisfy its own required properties on its own. ### Can a business mark up reviews of its own product on its own site? Only within limits Google states directly. The reviewed entity controlling the reviews about itself, on a page using LocalBusiness or any Organization type, makes that page ineligible for the star feature, whether the markup is direct or served through an embedded third-party widget. Product review markup on a retailer's own product pages is the common case that is not blocked by this specific rule, since it targets LocalBusiness and Organization types. ## Sources 1. [Review snippet (Review, AggregateRating) structured data](https://developers.google.com/search/docs/appearance/structured-data/review-snippet) - Google Search Central (primary) --- --- title: "Zero-click Google searches hit 68% in the US" url: https://seomadman.com/studies/zero-click-search-2026 section: studies published: 2026-08-04T00:00:00.000Z modified: 2026-08-04T00:00:00.000Z author: Adam Hafez topics: ["AI search", "Content strategy"] --- # Zero-click Google searches hit 68% in the US ## The short answer SparkToro and Similarweb found that 68.01% of Google searches in the United States ended without a click in the first four months of 2026, up from 60.45% in 2024. The June 2026 report links the jump to AI Overviews, now shown on more than 20% of searches, which cut click-through rates by nearly 60%. ## Key takeaways - SparkToro and Similarweb found that 68.01% of US Google searches ended without a click between January and April 2026. - That is up from 60.45% in 2024, the fastest two-year increase SparkToro has recorded in over a decade of tracking this metric. - Google AI Overviews now appear on more than 20% of searches and cut click-through rates by nearly 60% when shown, per the report. - Informational and local queries are hit hardest, at roughly 74% and 72% zero-click respectively, while transactional queries stay far lower at 31%. - A rising zero-click rate is a market-wide average, not a verdict on any single publisher's own traffic, which depends on rankings and query mix. Rand Fishkin published new zero-click numbers for SparkToro on 9 June 2026, built on a Similarweb desktop and mobile clickstream panel covering US searchers. The headline: 68.01% of Google searches in the US ended without a click in the first four months of 2026, up from 60.45% in 2024. SparkToro calls the two-year jump the fastest acceleration in the metric it has tracked in over a decade. Older comparison points exist - a widely cited ~45% figure from 2016 and 49% from 2019 - but those come from the now-defunct Jumpshot panel, a different data source, so this report treats them as historical context rather than as the same continuous series. ## What the report says is driving the increase SparkToro attributes most of the jump to AI Overviews, which it says now appear on more than 20% of Google searches and cut click-through rate by nearly 60% on the searches where they show. The report also names instant answers and other on-page UI elements that keep a searcher inside Google's results as contributing factors, alongside AI Mode, which SparkToro measured at just 0.34% of US searches for the same January-April 2026 window - too small on its own to explain the shift. The report is explicit that AI Overviews are the largest single factor it identifies, not the only one, and it does not claim to have isolated their effect from the other changes Google made to the results page in the same period. ## What a zero-click rate can and cannot tell a publisher The 68.01% figure is a national average across every kind of query. SparkToro's own breakdown shows the range underneath it: informational queries run around 74% zero-click and local queries around 72%, while commercial-investigation queries sit near 46% and transactional queries near 31%. A publisher whose traffic depends on transactional or commercial-intent terms is exposed to a different rate than this headline number implies, and a publisher whose own click-through and impression data in Search Console has not moved the way the national average has moved learns more from that first-party data than from the aggregate. The zero-click rate says how often Google answers a search itself; it does not say whether a specific site's own rankings, snippet, or query mix changed. ## Why we care **The direction is real and it is accelerating** - a 7.56 percentage point move in two years, against a much slower drift over the prior decade, is the kind of change that should show up in a publisher's own analytics too, not stay abstract. **AI Overviews are the report's leading explanation, not a proven sole cause.** Treat "AI Overviews are killing clicks" as this report's strongest hypothesis, backed by a real CTR comparison, rather than as a settled, fully isolated causal claim. **Query type still matters more than the headline number.** A site living on transactional queries is not living through the same 68% world as a site living on informational queries, and that distinction belongs in any plan built on this data. ## Sources 1. [In 2026, Less than One Third of Google Searches Still Send a Click](https://sparktoro.com/blog/in-2026-less-than-one-third-of-google-searches-still-send-a-click/) - SparkToro (primary) 2. [Zero-Click Marketing: What the 2026 Data Means](https://www.similarweb.com/blog/marketing/geo/zero-click-marketing/) - Similarweb --- --- title: "Mobile vs desktop Core Web Vitals: INP gap widest, CLS flips" url: https://seomadman.com/studies/mobile-desktop-cwv-pass-rate-gap section: studies published: 2026-08-02T00:00:00.000Z modified: 2026-08-02T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Mobile vs desktop Core Web Vitals: INP gap widest, CLS flips ## The short answer HTTP Archive's July 2025 Web Almanac performance chapter breaks Core Web Vitals down by individual metric rather than the all-three pass rate already covered elsewhere. INP shows the widest mobile-desktop split at 77% versus 97%, LCP sits at 62% versus 74%, and CLS reverses the pattern entirely, with mobile passing more often than desktop at 81% against 72%. ## Key takeaways - The 2025 Web Almanac, using CrUX field data through July 2025, found mobile LCP passes 62% of the time against 74% on desktop, a 12-point gap. - INP shows the widest split of the three metrics: 77% of mobile websites pass versus 97% of desktop websites, a 20-point gap that narrowed from 23 points in 2024. - CLS runs the opposite direction of the other two metrics, with 81% of mobile pages passing against 72% on desktop, making mobile the stronger device for that one metric. - The Web Almanac's chapter does not explain why INP's mobile-desktop gap is so much wider than LCP's, or why CLS reverses the pattern entirely. - Google's own web.dev guidance on INP cites "considerable variability in the capabilities of devices people use" without attributing the mobile-desktop gap to a single cause. A widely cited figure says 48% of mobile origins and 56% of desktop origins pass all three Core Web Vitals as of July 2025. That headline hides more than it shows, because "passes all three" collapses three very different stories into one number. Broken apart by metric, using the same July 2025 CrUX data behind that figure, the mobile-desktop gap is not one gap at all: it is wide for one metric, narrow for another, and reversed for the third. ## INP has the widest gap of the three Interaction to Next Paint is where mobile and desktop diverge most. The 2025 Web Almanac's performance chapter puts desktop INP at 97% good, "maintaining the high standard established in previous years," against 77% good on mobile, up from 74% in 2024. That is a 20-point gap, and the chapter notes it directly: the mobile-desktop split "has begun to narrow, shrinking from 23 percentage points in 2024 to 20 percentage points in 2025," but a 20-point gap is still the largest of the three metrics by a wide margin. The chapter does not state a specific cause for the underlying gap itself, only that it is narrowing. Google's own web.dev guidance on INP is similarly careful: it flags "considerable variability in the capabilities of devices people use" as a reason INP thresholds have to accommodate a wide device range, without pinning the mobile-desktop split on any one factor such as processing power or network conditions. ## LCP splits by a more moderate margin Largest Contentful Paint passes on 74% of desktop origins against 62% on mobile, a 12-point gap, roughly half the size of the INP split. The Almanac also reports mobile shows "nearly double the rate of 'poor' experiences" on LCP compared with desktop, 13% against 7%, so the mobile shortfall is not just fewer origins clearing the "good" bar; more of them land in the worst tier outright. As with INP, the chapter documents the size of the gap without stating what drives it. ## CLS is the one metric where mobile wins Cumulative Layout Shift reverses the direction of the other two: 81% of mobile pages pass CLS against 72% of desktop pages, a 9-point advantage for mobile. The Almanac notes this is not a one-off snapshot either, stating that "mobile maintains a higher share of good CLS than desktop throughout the entire timeframe" when the chapter looks at the trend from 2023 through 2025. The chapter offers no explanation for why CLS runs opposite to LCP and INP; it only documents that it does, consistently, across two years of monthly data. ## Why we care **The all-three figure hides which metric to fix first.** A site told it fails "Core Web Vitals" on mobile could be failing LCP, INP, or both, and the fix for each is different: LCP work generally targets render-blocking resources and image weight, INP work targets main-thread responsiveness to input. Treating "Core Web Vitals" as one problem instead of three risks fixing the wrong one. **INP deserves more attention on mobile than the combined figure suggests.** A 20-point gap is the largest disparity in the dataset, larger than LCP's, and it is the metric most directly tied to how a page responds to a visitor's taps and clicks rather than how fast it first paints. **CLS is not a mobile problem at all, by this data.** Sites chasing a lower CLS score on mobile specifically are optimizing against the metric where mobile already outperforms desktop; the layout-shift fix, if one is needed, more often belongs on the desktop template. ## Sources 1. [Performance | 2025 | The Web Almanac](https://almanac.httparchive.org/en/2025/performance) - HTTP Archive (primary) 2. [Interaction to Next Paint (INP)](https://web.dev/articles/inp) - web.dev --- --- title: "Pagination and infinite scroll: what Google actually indexes in 2026" url: https://seomadman.com/research/pagination-infinite-scroll-indexing section: research published: 2026-08-01T00:00:00.000Z modified: 2026-08-01T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Pagination and infinite scroll: what Google actually indexes in 2026 ## The short answer Google confirmed in March 2019 it had stopped using rel="next" and rel="prev" as an indexing signal years before that announcement. Google's documentation states Googlebot does not trigger scroll or click events, so infinite scroll content with no discrete URL behind it stays invisible to Search. Google's documented fix: give each content chunk a unique URL, paired with the History API. ## Key takeaways - Google Webmasters confirmed on March 21, 2019 that rel=next/rel=prev had not been used as an indexing signal for years, and retired the markup entirely. - Google's current pagination documentation states plainly that Google no longer uses these tags at all, though other search engines may still use them. - Google's crawlers generally don't trigger JavaScript functions that require user actions, including scrolling, to update page content. - Google's lazy-loading guidance says content should load on viewport visibility, not on a scroll or click event. - Google's documented fix for infinite scroll is a unique, persistent URL per content chunk, updated with the History API, not abandoning infinite scroll. Two claims get repeated constantly in technical SEO advice, and both trace back to real, dated statements from Google rather than to inference: rel=next/rel=prev has done nothing at Google for years, and infinite scroll can quietly hide content from the index unless it is built a specific way. Neither is a guess. Both are things Google has said, in writing, more than once. ## Rel=next/prev's real deprecation history The pagination markup rel="next" and rel="prev" was introduced by Google in 2011 to hint that a sequence of component pages belonged to one series. On March 21, 2019, Google Webmasters (the account now known as Google Search Central) announced it was retiring the tags as an indexing signal, and added a detail that mattered more than the retirement itself: Google had not actually been using rel=next/prev for indexing "for a number of years" before that announcement. The signal had quietly stopped mattering long before anyone said so publicly, a sequence documented at the time by [Search Engine Roundtable](https://www.seroundtable.com/google-rel-prev-next-change-27295.html). Google's own current documentation confirms the same position without hedging. Its [pagination best practices page](https://developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading) states it directly: "Google no longer uses these tags, although these links may still be used by other search engines." That single sentence is the entire status of rel=next/prev at Google today. Leaving the markup in an existing site does no harm, since Bing and some other crawlers still treat it as a discovery hint, but adding it now for Google's benefit accomplishes nothing. What Google asks for instead is unglamorous and structural: a unique URL per page, sequential `` links between them, and a canonical tag on each page pointing at itself rather than at page one. ## Infinite scroll's real indexing risk, and Google's real fix Infinite scroll fails for a more basic reason than pagination markup ever mattered: Googlebot does not scroll. Google's own [JavaScript SEO documentation](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) states that its crawlers "generally don't trigger JavaScript functions that require user actions to update the current page contents," and names scrolling and clicking specifically as the kind of interaction it does not simulate. A page that only loads its next batch of content when a human scrolls to the bottom is, from Googlebot's perspective, a page that stops after the first batch. Google's [lazy-loading guidance](https://developers.google.com/search/docs/crawling-indexing/javascript/lazy-loading) is just as direct about why: "Google Search does not interact with your page," so any loading mechanism gated on a scroll or click listener never fires for it. The fix Google documents is not to load content on scroll at all, but to load it based on viewport visibility, using the IntersectionObserver API or an equivalent, which fires independently of any user action Googlebot would have to fake. That handles content visibility, but it does not by itself solve indexing, because a page that still lives at one URL cannot be linked to, cited, or ranked as its later chunks separately. Google's documented fix for that half of the problem is the one worth building to: give each content chunk its own unique, persistent URL, its example is a page parameter like `?page=12`, and call the History API to update the visible URL once that chunk becomes the primary content on screen. That is not a workaround bolted on by SEO practitioners; it is Google's own stated recommendation for making infinite scroll compatible with indexing at all, and it is the same underlying requirement rel=next/prev was trying, and failing, to serve a decade earlier: a discrete, crawlable URL behind every distinct piece of content. ## Why we care Both claims collapse to one requirement, and it has not changed even as Googlebot's own rendering ability has: content needs a real, discrete URL to be indexed as its own thing. Rel=next/prev never changed that requirement, it was markup layered on top of URLs that already existed, which is exactly why Google could drop it silently for years before anyone noticed. Infinite scroll without real URLs violates the requirement directly, not through a markup gap but by never giving Googlebot a URL to land on for the content past the first load. The practical fix is the one Google itself documents: unique URLs per chunk, discovered through normal links rather than a scroll event, with the History API layered on top for the user experience. Anything built that way gets both the paginated URL structure engines have always needed and the continuous-scroll feel users expect, without betting indexing on Googlebot doing something its own documentation says it does not do. ## Frequently asked questions ### Does removing rel=next/rel=prev hurt rankings today? No. Google's own pagination documentation states it no longer uses those tags at all, a position it says predates its March 2019 announcement by several years. The markup is inert at Google; it can still be left in place harmlessly for other search engines, but it does nothing for Google indexing either way. ### Can Googlebot see content loaded by infinite scroll at all? Only if that content is reachable another way. Google's own documentation says its crawlers generally don't trigger scroll or click events to load more content, so scroll-only content with no separate URL is invisible to it. Content triggered by viewport visibility, or backed by its own paginated URL, is a different case and is indexable. ### What is Google's own recommended fix for infinite scroll? Give each loaded chunk a unique, persistent URL, Google's documentation uses a page-number parameter as its example, and update the visible URL with the History API once that chunk becomes the primary content on screen. That keeps the scrolling experience while giving Googlebot a discrete URL to crawl and index for each chunk. ## Sources 1. [Pagination Best Practices for Google](https://developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading) - Google Search Central (primary) 2. [Fix Lazy-Loaded Content](https://developers.google.com/search/docs/crawling-indexing/javascript/lazy-loading) - Google Search Central (primary) 3. [JavaScript SEO basics](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) - Google Search Central 4. [Google Now Says Rel=prev/next Is Not An Indexing Signal Anymore](https://www.seroundtable.com/google-rel-prev-next-change-27295.html) - Search Engine Roundtable 5. [Infinite scroll search-friendly recommendations](https://developers.google.com/search/blog/2014/02/infinite-scroll-search-friendly) - Google Search Central Blog --- --- title: "Do backlinks still correlate with rankings in 2026?" url: https://seomadman.com/research/backlinks-ranking-correlation-2026 section: research published: 2026-07-31T00:00:00.000Z modified: 2026-07-31T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Do backlinks still correlate with rankings in 2026? ## The short answer Backlinko's 11.8-million-result study found position 1 pages average 3x more referring domains than positions 2-10. Ahrefs' own 1-million-keyword study puts that correlation at just 0.255, weak by convention. Google's Gary Illyes has said links are not a top-three ranking factor. These studies cannot separate cause from a shared confound: established pages accumulate both links and rank. ## Key takeaways - Backlinko's 11.8-million-result study, updated April 2025, found position 1 pages average 3x more referring domains and 3.8x more backlinks than positions 2-10. - Ahrefs' own January 2025 study of 1 million US keywords found a Spearman correlation of only 0.255 between referring domains and ranking, a weak coefficient by normal convention. - Both firms explicitly warn that their own data cannot show causation, only association. - Google's Gary Illyes told Pubcon Pro in 2023 that links are not among the top three ranking factors and have not been for some time. - A third firm's claim that backlinks are worth exactly 13% of algorithm weight has no disclosed methodology behind it and should not be read as a measured fact. Two firms with two different large samples both find the same shape of relationship: pages that rank higher tend to have more referring domains pointing at them. Where they disagree is on how much that relationship is worth leaning on, and both say so themselves. ## The two studies, side by side Backlinko's ranking-factor study, last updated in April 2025, pulled backlink data from Ahrefs across 11.8 million Google results and found position 1 pages average 3x more referring domains and 3.8x more total backlinks than positions 2 through 10. That is a large, memorable gap, and it is the number most often cited to argue backlinks still decide rankings. Ahrefs ran its own study in January 2025, across the top 1 million US keywords by search volume, and reported the actual Spearman correlation: 0.255 for referring domains, 0.250 for followed referring domains only. Both are weak by the normal reading of a correlation coefficient, where values below roughly 0.3 indicate a real but modest association, not values that would let anyone predict rank from link count alone. Ahrefs published this specific number knowing it undercuts the stronger-sounding multiple-based framing, and both posts add the standard warning: correlation is not causation, and neither study's design can rule out reverse causation. ## What Google itself has said about links Google does not publish ranking-factor weights, so the closest thing to an official read comes from what its own staff say on the record. At Pubcon Pro in 2023, Google's Gary Illyes told attendees links are not among the top three ranking factors and have not been "for some time," adding that a page with zero external or internal links has ranked number one on the strength of content alone. That statement does not say links are worthless. It does say the industry's mental model, where link count is close to determinative, is outdated by Google's own account. ## The 13% claim that should not be treated as fact A frequently repeated figure holds that backlinks represent exactly 13% of Google's algorithm weight, down from 15% in 2024. That number comes from First Page Sage's own recurring internal estimate, presented without a disclosed methodology, survey instrument, or error margin. Google has never confirmed that any ranking factor carries a fixed percentage weight, and multiple current and former Google staff have said directly that no single factor gets a stable, query-independent share of the algorithm. Treat the 13% figure as one firm's proprietary estimation exercise, not a measured fact, and do not cite it as if Google had disclosed it. ## Why we care The honest read is a modest, real, positive association: more referring domains track with higher rank, at a strength that leaves most of the variance in Google's output unexplained. That is enough to justify earning links as part of a page's overall authority, and not enough to justify treating link count as a lever that moves rank on its own. Budget link-building as one input among many, not the one your ranking strategy hinges on, and be skeptical of any number, including a precise algorithm-weight percentage, that a source presents as more certain than Google itself has ever been willing to state. ## Sources 1. [We Analyzed 11.8 Million Google Search Results. Here's What We Learned About SEO](https://backlinko.com/search-engine-ranking) - Backlinko (primary) 2. [Google Says "Links Matter Less" - We Looked at 1,000,000 SERPs to See if It's True](https://ahrefs.com/blog/links-matter-less-but-still-matter/) - Ahrefs (primary) 3. [Links are not a top 3 Google Search ranking factor, says Gary Illyes](https://searchengineland.com/links-google-search-ranking-factor-gary-illyes-432422) - Search Engine Land 4. [The Google Algorithm Ranking Factors](https://firstpagesage.com/seo-blog/the-google-algorithm-ranking-factors/) - First Page Sage --- --- title: "Hreflang error rates: what's actually sourced, and what isn't" url: https://seomadman.com/research/hreflang-error-prevalence-2026 section: research published: 2026-07-29T00:00:00.000Z modified: 2026-07-29T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Hreflang error rates: what's actually sourced, and what isn't ## The short answer Two numbers circulate in hreflang advice: 72% of sites have a critical error per an "Ahrefs 2026 State of SEO survey," and one error invalidates 40% of implementations per Google's documentation. Neither traces to a real source. Ahrefs' real 2023 study found 67% of domains had some issue. Google's documentation describes real failure modes: reciprocity, x-default, and canonical alignment. ## Key takeaways - A commonly cited "72% of multi-country sites, Ahrefs 2026 State of SEO survey" statistic does not appear anywhere on ahrefs.com. - A commonly cited "a single error invalidates roughly 40% of implementations, per Google" claim does not appear anywhere on developers.google.com. - Ahrefs did publish a real hreflang study in August 2023 covering 374,756 domains, finding 67% had at least one issue, most often a missing x-default. - Google's documentation states plainly that hreflang tags without a reciprocal return link are ignored, not partially applied. - The x-default value is documented as optional and recommended, never as a requirement Google enforces. Search a few hreflang guides published this year and the same two numbers turn up again and again: 72% of multi-country sites have a critical hreflang error, attributed to an "Ahrefs 2026 State of SEO survey," and a single error invalidates roughly 40% of implementations, attributed to Google's own documentation. Both numbers are precise, both sound institutional, and neither one checks out. This piece traces each claim to its stated source, then lays out what Google's documentation actually says instead. ## The statistics that don't check out The 72% figure is usually presented as coming from an Ahrefs survey. Ahrefs does publish an annual "State of SEO" style content series and does publish real, well-documented hreflang research, which makes the claim easy to believe without checking. But no page on ahrefs.com states that 72% of multi-country sites have a critical hreflang error, and no survey matching that name and year was found. The number appears to circulate purely through repetition across downstream SEO blogs, each one citing the last. What Ahrefs actually published is a hreflang study dated 10 August 2023, built from a crawl of 374,756 domains using hreflang tags. Its real headline finding is that 67% of those domains had at least one issue, and its most common single problem was a missing x-default tag, present on 56.3% of the affected domains, followed by missing self-referencing tags and broken or redirected references. That is a real, dated, citable number, three years old at the time of writing and about all domains with hreflang rather than multi-country sites specifically. It is a plausible ancestor of the "72%" claim, close enough in shape that a rounding or a misremembering could explain the drift, but it is not the same statistic and it does not support the "2026" framing. The second claim, that a single error invalidates roughly 40% of implementations per Google Search Central, fares worse: it does not appear anywhere in Google's developer documentation at all. Google's real documentation explains rules, not live error rates on the wild web, and Google has never published a percentage of hreflang implementations it considers broken. Attributing a specific quantified statistic to Google when Google's own site contains nothing matching it is a more serious sourcing failure than an outdated Ahrefs number, because it invents institutional authority rather than merely misquoting a real one. ## What Google actually documents Strip away the invented percentages and what remains is real, verifiable, and arguably more useful: Google's documentation describes exactly which implementation mistakes break hreflang, even without attaching a frequency to them. **Reciprocity is not optional.** Google's [localized-versions documentation](https://developers.google.com/search/docs/specialty/international/localized-versions) states plainly that if two pages do not both point to each other, the tags are ignored. This is not a partial penalty; a one-directional hreflang relationship is treated as if it were not there. A page that lists every translation but is never listed back by those translations gets nothing from the annotation. **x-default is a fallback, not a requirement.** The same documentation describes x-default as a value to consider adding for a language or country selector or an auto-redirecting home page, used when no other language or region in the set matches the visitor's browser setting. Google recommends it; Google does not require it, and omitting it does not make the rest of a correctly reciprocal set invalid. **Canonical and hreflang are meant to agree, not compete.** Google's [canonicalization documentation](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) instructs sites using hreflang to point each page's canonical at a version in the same language, or the closest substitute if none exists in that exact language. That is a real, documented coupling: hreflang and canonical are meant to be built together, and a canonical that quietly points at a different language than its own hreflang set describes is exactly the kind of internal contradiction that undermines both signals. None of these three rules comes with an error-rate percentage attached, and that is the honest state of the documentation: Google tells implementers what breaks the system, not how often sites get it wrong. ## Why we care The lesson here is not really about hreflang. It is about how a number gets laundered into apparent authority: an invented figure gets a fake survey name, a fake year, and enough repetition across secondary sources that it starts to look better-sourced than research that actually exists. The real Ahrefs study got less attention than the fabricated 72% claim built in its shadow. The practical fix does not need a percentage at all. The three rules confirmed above, reciprocity, optional x-default, and canonical and hreflang built to agree, are exactly what this site's own [hreflang tag generator](/tools/hreflang-tag-generator) checks before a set of tags ships: every URL gets a row pointing at itself, duplicate language codes get flagged, and the tool's documentation is honest that it can only validate the data entered, not crawl the live pages to confirm reciprocity in production. Use it as a pre-flight check, then verify the live set in Search Console's International Targeting report, the same two-step confirmation this piece leaned on for its sourcing. ## Frequently asked questions ### Is the "72% of multi-country sites" hreflang statistic real? No credible primary source was found. It does not appear on ahrefs.com, and no "Ahrefs 2026 State of SEO survey" could be located. Treat any piece citing it without a working link to ahrefs.com as unsourced. ### Does Google say a single hreflang error invalidates 40% of implementations? Not in any documentation found on developers.google.com. Google's real documentation describes rules, such as the reciprocity requirement, rather than publishing error-rate statistics about sites in the wild. ### What does Ahrefs' real hreflang study actually say? Published 10 August 2023 and based on a crawl of 374,756 domains using hreflang, it found 67% had at least one issue, the most common being a missing x-default tag at 56.3% of those domains, followed by missing self-referencing tags and broken references. ## Sources 1. [Tell Google about localized versions of your page](https://developers.google.com/search/docs/specialty/international/localized-versions) - Google Search Central (primary) 2. [How to specify a canonical with rel="canonical" and other methods](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) - Google Search Central (primary) 3. [Over 67% of domains using hreflang have issues (study of 374,756 domains)](https://ahrefs.com/blog/hreflang-study) - Ahrefs --- --- title: "SearchPilot: nearby-region links lifted organic traffic 7%" url: https://seomadman.com/studies/nearby-regions-internal-linking-ab-test-searchpilot section: studies published: 2026-07-28T00:00:00.000Z modified: 2026-07-28T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # SearchPilot: nearby-region links lifted organic traffic 7% ## The short answer SearchPilot ran a controlled split test on a site with roughly 8,000 regional pages across the USA. Variant pages gained links from each of the 6 nearest neighboring regional pages, about twelve new internal links per page; control pages got none. Linked pages saw a 7% organic traffic uplift. ## Key takeaways - SearchPilot's client operated approximately 8,000 regional pages across the USA, each showing nearby physical company locations by geographic area. - The variant group added links from each regional page to its 6 nearest neighboring regional pages, roughly twelve new internal links per page on average. - The control group of regional pages received no new links, isolating the added internal links as the only variable in play. - Pages that received the new nearby-region links saw a 7% uplift in organic traffic compared to the unchanged control pages. - SearchPilot's own write-up does not disclose a confidence or credible interval for this result, unlike some of its other published split tests. A site with thousands of near-identical regional pages has an obvious internal linking gap: pages for neighboring areas rarely link to each other, even though they compete for related queries and sit close together in the site's own geography. SearchPilot, the same controlled SEO A/B-testing firm behind our [FAQ content split tests](/studies/faq-content-ab-test-searchpilot), ran a split test on exactly that gap, on a client with about 8,000 regional pages across the USA, each displaying nearby physical company locations by area. ## What the test changed SearchPilot split the regional pages into a control group and a variant group. On variant pages, it added links from each regional page to its 6 nearest neighboring regional pages, roughly twelve new internal links per page on average. Control pages kept their existing linking pattern unchanged, with nothing else added. Everything else on both groups of pages, content, layout, the rest of the site's navigation, stayed identical, so the only variable in play was the new nearby-region links. ## The result, and what SearchPilot did not disclose Pages that received the new links saw a 7% uplift in organic traffic compared to the unchanged control pages. SearchPilot's own conclusion was blunt: these regional pages had been starved of internal link equity, and giving them links from their closest neighbors passed some of that equity through, showing up as more organic traffic. Unlike SearchPilot's FAQ content test, this write-up does not state a confidence or credible interval for the 7% figure, and it does not give exact test start or end dates, only that it ran as a controlled experiment on SearchPilot's own testing platform. ## A controlled experiment, not a correlation study This is a different kind of evidence than the site's other internal linking coverage. JetOctopus's [DOM.RIA case study](/studies/internal-linking-crawl-coverage-case) measured Googlebot crawl visits before and after one client moved links to a better position on its own site, a single-site, before-and-after read. Zyppy's [23-million-link study](/research/internal-linking-crawl-depth-zyppy-study) went the other direction, correlating internal link counts against Google Search Console clicks across 1,800 sites, with no single site's links ever changed as part of the study. SearchPilot's nearby-region test sits between those two: one site, like DOM.RIA's case, but with a genuine control group running at the same time as the variant, like Zyppy's correlation could never establish on its own. It answers a question neither sibling piece can: whether adding links between already-existing, already-indexed pages causes a traffic change, isolated from whatever else happened on the site during the test window. ## Why we care Crawl visits rising, as in the DOM.RIA case, and click counts tracking with link count at scale, as in Zyppy's study, are both consistent with internal linking mattering. Neither proves that adding a link to an existing page changes its organic traffic, because neither ran a controlled test. SearchPilot's nearby-region test did, and it found a real, if modestly documented, uplift: 7% more organic traffic on pages that gained links from their closest geographic neighbors, nothing changed on the control pages that didn't. For any site with a cluster of related, thin, or isolated regional or category pages, that is the specific, tested case for cross-linking them to their nearest neighbors, not a general license to add links everywhere. ## Sources 1. [SEO Split Test: Lessons from Nearby Location Links](https://www.searchpilot.com/resources/case-studies/seo-split-test-lessons-nearby-location-links) - SearchPilot (primary) --- --- title: "AI citation hallucination rates: what three real studies found" url: https://seomadman.com/research/ai-citation-hallucination-rates section: research published: 2026-07-27T00:00:00.000Z modified: 2026-07-27T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # AI citation hallucination rates: what three real studies found ## The short answer AI systems fabricate or mangle citations at rates that vary wildly by study: GPTZero's January 2026 audit found hallucinated citations in about 1% of NeurIPS 2025 papers, Tow Center found citation errors in over 60% of AI search engine answers about news, and a Cureus study found ChatGPT-5 fabricated 7% of clinical references outright. No single rate is correct. ## Key takeaways - GPTZero's January 2026 audit of 4,841 NeurIPS 2025 papers confirmed at least 100 hallucinated citations across 53 papers, about 1% of the total. - The Tow Center for Digital Journalism found more than 60% of 1,600 AI search engine answers about news articles contained a citation error. - A Cureus study found ChatGPT-5 fabricated 7.13% of the 2,736 clinical references it generated, and got every field right in only 8% of queries. - The three studies test different systems and different definitions of hallucination, so their numbers cannot be averaged into one rate. - Publishers and SEOs should treat any single quoted AI hallucination rate as one study's number, not a settled industry fact. Every few months a new number claims to answer "how often does AI make up citations." Depending on which blog you read, that number is 1%, 7%, 40%, or 82%. All four figures trace back to real research, but they are not measuring the same question, and treating them as interchangeable is the actual problem. Three studies here can be verified at the source with a stated sample size and a stated method. The rest, including several widely repeated ranges, could not be traced past a secondary aggregator restating another aggregator, so they are not used. ## Three studies, three different questions GPTZero, the plagiarism and AI-detection company, published a report on January 21, 2026 checking whether citations inside 4,841 papers accepted to NeurIPS 2025, a top peer-reviewed AI conference, actually exist and match what they claim to cite. That is a question about human-authored academic papers that happen to contain AI-generated reference lists, not about a chatbot answering a live question. The Tow Center for Digital Journalism, publishing through Columbia Journalism Review, ran a different test in March 2025: it asked eight AI search tools, ChatGPT Search, Gemini, Perplexity, Perplexity Pro, DeepSeek Search, Microsoft Copilot, and two versions of Grok, to find and cite 200 real news articles from 20 publishers, 1,600 queries in total. That is a question about whether a live AI search answer correctly identifies and links a specific, real source. A Cureus study published July 30, 2026 asked a third question: when ChatGPT-5 answers a clinical question and cites medical guidelines, how often is each individual bibliographic field, author, title, journal, page numbers, actually correct. Researchers checked all 2,736 references the model generated across 350 queries built from American Academy of Orthopaedic Surgeons guidelines. ## What each one actually found GPTZero's Hallucination Check tool flagged citations that could not be verified through academic databases and DOI or URL lookups, then had a human expert confirm each flagged case before counting it. That process confirmed at least 100 hallucinated citations spanning 53 distinct papers, about 1.1% of the papers checked, with teams from Google, Meta, Harvard and Cambridge among those affected. It is the most tightly defined and independently verifiable figure of the three: a fixed population of finished papers, a named detection tool, and a human review step before publication. The Tow Center study found more than 60% of the 1,600 responses contained a citation error, defined as an incorrect article identification, wrong publisher attribution, or a missing or broken URL. Accuracy varied enormously by tool: Perplexity's free tier had the fewest errors at 37%, while Grok 3 reached 94%. More than half of Gemini's and Grok 3's responses cited fabricated or broken links that led to error pages. The Cureus study found ChatGPT-5 fabricated 7.13% of its 2,736 generated references outright, a figure close to what search snippets described as "7 to 8% for ChatGPT-5 with web search," and this is the one place in circulation where that specific range does trace to a real, dated study. But fabrication was not the main source of error: only 49.34% of citations were fully correct across every bibliographic field, and all citations in a single query were completely accurate in just 8% of cases. PMID and title were the fields most often wrong. ## Why the numbers don't add up to one figure A companion piece of research, "Source or It Didn't Happen," a 2026 arXiv paper proposing a multi-agent detection system called CiteTracer, illustrates why these figures resist averaging even further. Its own benchmark reports 97.1% detection accuracy, but that number describes how well its detector classifies citations in a dataset it built itself, 2,450 synthetic mutated citations plus 957 known-fabricated real-world ones, not the underlying rate at which any AI system hallucinates citations in ordinary use. It is evidence that citation hallucination is being taken seriously as a detection problem, not a fourth data point for a headline percentage. Line the three real figures up and the range runs from about 1% to over 60% for the same broad topic. That is not inconsistency in the research, it is three different definitions of "hallucination" applied to three different tasks: a citation existing at all, a citation pointing at the right article, and a citation's individual fields being correct. A single AI answer could score well on one of those tests and badly on another at the same time. Any figure quoted without naming which of these three questions it answers, or a fourth like it, should be treated as unverifiable. ## Why we care For a publisher, the Tow Center number is the one that matters day to day: when a licensing deal or a partnership gets an AI search tool to name your outlet, that citation still has close to even odds of misattributing the quote, linking a syndicated copy instead of the original, or breaking outright. A byline or a URL appearing correctly inside a chatbot's answer is not proof the system is citing reliably elsewhere, and a partnership does not fix that on its own. For an SEO evaluating an AI-citation-tracking tool, the GPTZero and Cureus studies are the more useful reference points, because they show that "verified" and "hallucinated" only mean something once the checker's method is stated. A tool that reports a single hallucination percentage without saying whether it is checking existence, attribution, or field-level accuracy is doing what the aggregator blogs did: collapsing three different measurements into one number that sounds more precise than it is. Ask which of the three questions above a tool actually answers before trusting its score. ## Sources 1. [GPTZero finds 100 new hallucinations in NeurIPS 2025 accepted papers](https://gptzero.me/news/neurips/) - GPTZero (primary) 2. [AI Search Has a Citation Problem](https://www.cjr.org/tow_center/we-compared-eight-ai-search-engines-theyre-all-bad-at-citing-news.php) - Columbia Journalism Review, Tow Center for Digital Journalism (primary) 3. [Evaluating the Citation Accuracy of ChatGPT-5 Using the American Academy of Orthopaedic Surgeons Clinical Practice Guidelines](https://pmc.ncbi.nlm.nih.gov/articles/PMC13525731/) - Cureus (primary) 4. [Source or It Didn't Happen: A Multi-Agent Framework for Citation Hallucination Detection](https://arxiv.org/abs/2605.08583) - arXiv --- --- title: "Google's own numbers: structured data lifted CTR 25-82%" url: https://seomadman.com/studies/structured-data-ctr-google-case-studies section: studies published: 2026-07-27T00:00:00.000Z modified: 2026-07-27T00:00:00.000Z author: Adam Hafez topics: ["Structured data"] --- # Google's own numbers: structured data lifted CTR 25-82% ## The short answer Google's own structured data documentation states that Rotten Tomatoes measured a 25% higher click-through rate after adding structured data to 100,000 pages, and Nestle measured an 82% higher click-through rate on pages that appear as rich results. Google gives no dates, sample sizes or markup types beyond those headline figures for either company. ## Key takeaways - Google's own structured data documentation reports Rotten Tomatoes measured a 25% higher click-through rate after adding structured data to 100,000 unique pages. - The same Google page reports Nestle measured an 82% higher click-through rate on pages that appear as rich results in search, versus pages that do not. - Google also credits the Food Network with a 35% increase in visits after converting 80% of its pages to enable search features, on the same page. - Google discloses no timeframe, sample size, markup type or methodology for any of the three figures beyond the headline percentage. - These are Google's own selected success stories, not a random or controlled sample, so they show structured data can help, not what a typical site should expect. Two numbers get quoted constantly in structured data pitches: Rotten Tomatoes at 25% higher click-through rate, Nestle at 82%. Both come from Google itself, not from a third party summarizing Google. Here is exactly where they live, what Google does and does not disclose about them, and why citing Google's own greatest hits is not the same as citing a representative study. ## What Google's own page actually says **Three companies, one paragraph.** Google's structured data documentation states plainly: "Rotten Tomatoes added structured data to 100,000 unique pages and measured a 25% higher click-through rate" for the enhanced pages versus pages without structured data. The same paragraph adds that "Nestle has measured pages that show as rich results in search have an 82% higher click-through rate than non-rich result pages," and that "the Food Network has converted 80% of their pages to enable search features, and has seen a 35% increase in visits." All three sentences sit on the same Google Search Central page, not on separate dedicated case-study pages the way Google's Rakuten recipe case study does. **No dates, no markup type, no sample window.** Google names the outcome and, for Rotten Tomatoes, the page count, and stops there. There is no disclosed year, no named schema type (movie, review, recipe or otherwise), no control methodology and no confidence interval for any of the three figures. A reader can verify that Google states the number; a reader cannot verify how Google's partners arrived at it. ## Why this is evidence structured data can help, not a typical result **These are Google's own selected success stories.** Google chose to publish these three examples out of every site that has ever added structured data. That is survivorship bias by construction: sites with a flat or negative result after adding markup have no reason to appear on a vendor's own promotional page, and Google has no obligation to publish them if they did. A 25% or 82% lift is real for the site that reported it, but nothing here says it is the median, the average, or even a common outcome. **Different markup, different rich result, different starting point.** Rotten Tomatoes' figure plausibly comes from review or aggregate rating markup surfacing star ratings in search; Nestle's figure is framed around whatever specific rich result Nestle's recipe or product pages earn. A site adding FAQ markup to thin pages, or organization markup to a homepage, is not adding the same thing these companies added, and should not expect the same multiplier. ## Why we care **Cite the source, not the number in isolation.** "Structured data increases CTR by up to 82%, according to Google" is defensible; "structured data increases CTR by 82%" is not, because it drops the fact that Nestle's figure describes Nestle's rich results, not a universal constant. Link to Google's own page when quoting either figure, since that is the only place either number is verifiable. **Treat the lack of methodology as a limit on the claim, not a reason to ignore it.** Google publishing these figures at all is meaningful: it is Google's own documentation, not a marketing blog's paraphrase, and Google has no incentive to overstate a competitor's or partner's result. But a case study built for a doc page is not a substitute for measuring your own before-and-after click-through rate once you ship structured data on your own site. ## Frequently asked questions ### Does Google say when these results were measured? No. Google's structured data documentation states the Rotten Tomatoes, Nestle and Food Network figures without a date, timeframe or sample period. Treat the percentages as Google-verified but undated. ### Are these figures from independent, controlled experiments? No. Google presents them as summaries volunteered by the companies themselves, not as findings from a controlled study Google ran. There is no control group, no significance test and no disclosed methodology. ### Where can I read the original source myself? Google's own structured data introduction page at developers.google.com/search/docs/appearance/structured-data/intro-structured-data states all three figures directly, with a link to Google's separate case-studies index for other, unrelated case studies. ## Sources 1. [Intro to How Structured Data Markup Works](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data) - Google Search Central (primary) 2. [SEO Case Studies and Success Stories](https://developers.google.com/search/case-studies) - Google Search Central --- --- title: "What academic research actually says about AI citation factors" url: https://seomadman.com/research/geo-citation-factors-academic-studies section: research published: 2026-07-25T00:00:00.000Z modified: 2026-07-25T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # What academic research actually says about AI citation factors ## The short answer Academic research is starting to measure which content factors actually predict citation by AI search engines. A 252,000-trial factorial study found topical relevance and list position dominate. A 100,000-response tracking study found only 2.9% of citations reach a brand's own domain. A diagnostic framework lifted citation rates 40% by fixing specific failure modes rather than rewriting pages. ## Key takeaways - A factorial experiment ran 252,000 trials across six LLMs and eighteen factors, finding topical relevance and list position are the strongest predictors of being cited first. - A tracking study of over 100,000 AI search responses found only 2.9% of citations point to a brand's own domain, while 75.2% point to other companies in the same space. - An agentic framework called AgentGEO lifted citation rates more than 40% relative to baselines while modifying only 5% of a page's content, versus 25% for other methods. - In a 12,240-query benchmark, 62.2% of citation failures traced to the page's content not matching what the query needed, not to technical or formatting problems. - All four papers are 2026 preprints or newly accepted submissions, not yet peer-reviewed, each testing a narrow set of LLMs that may not generalize to production engines. Search-industry blog posts have circulated GEO advice for two years now, quotations help, statistics help, structured data helps, backed mostly by aggregator posts citing each other rather than any named study. That is starting to change. Four papers published or accepted in 2026 ran controlled experiments or large-scale tracking studies specifically on what makes generative AI engines cite a source, and their actual text, not a summary of a summary, is the basis for what follows. ## The largest controlled experiment: position and relevance win The most rigorous of the four is a factorial study by Vishwakarma, Kumar and Jamidar, accepted to ACM SIGIR 2026. It built a two-document retrieval-augmented generation testbed: inject exactly two candidate sources into a model's context, vary exactly one content factor between them, and measure which source the first citation marker in the answer points to. Across six LLMs the team ran 252,000 trials covering eighteen content factors, using brand anonymization and counterbalanced source order to isolate content effects from simple position bias. The result undercuts a lot of GEO folklore: topical relevance and list position were the biggest drivers of being cited first, not any single piece of on-page dressing. Explicit price information and a recent timestamp helped consistently but by a smaller margin. Completeness and trust cues added smaller gains still, and formatting-only edits, the kind of change a checklist tool flags, had little measurable effect at all. ## Where citations actually land, and how failures get fixed A separate, much larger tracking study by Pratyush Kumar, run on the Ranqo platform, analyzed 102,025 AI prompt responses across 102 brands on five engines between March and May 2026. Its most striking number is not a percentage lift from adding a quote, it is where citations go at all: only 2.9% of citations pointed to a brand's own domain, while 75.2% pointed to other companies in the same space, corporate sources overall taking roughly 78% of all citations and the rest split among YouTube, Reddit, editorial media and Wikipedia. Ranked best-of listicles were the single most-cited content format, at about 21% of citations. The same study found visibility scales sharply with brand stature: global household names appeared in 73% of relevant first-run answers, established mid-market brands in 44%, and niche or small brands in just 11%. A third paper, by Tian, Chen, Tang, Liu and Jia, treats citation as something to diagnose rather than just measure. Their AgentGEO framework classifies why a specific page failed to be cited, then applies a targeted repair instead of a generic rewrite. Tested on a 12,240-query benchmark built from 204 real webpages, AgentGEO reached a 79.52% citation rate against a 68.80% baseline, a relative improvement of more than 40%, while touching only 5% of a page's content against 25% for baseline methods. Its failure analysis is the more useful finding for publishers: 62.2% of failures traced to the content simply not matching what the query needed, 27.1% to broader content-quality issues, and only 10.1% to technical integrity problems like malformed markup or blocked crawling. Formatting is rarely the bottleneck; substance is. ## A widely repeated figure that does not check out Search results for this topic keep surfacing a specific claim: that 68% of AI citations come from third-party sources and only 32% from brand-owned websites. That figure does not appear in any of the four papers checked for this piece, including Kumar's tracking study, the one paper that actually measures this split at scale. Kumar's real number is more extreme in the same direction, just 2.9% of citations land on a brand's own domain, not 32%, which suggests the circulating 68/32 figure is either from an unverifiable source or a garbled version of a different study's numbers. It is not used here. A critical survey covering the field from 2023 to 2026 also traces one specific number back to its actual source. Search snippets describe "252,000 trials across six LLMs and eighteen factors" without naming a paper; the survey attributes that exact figure to Vishwakarma et al.'s SIGIR 2026 paper, which this piece fetched and confirmed directly. The same survey separately reports, citing the original 2024 GEO paper by Aggarwal et al., a roughly 41% relative gain in position-adjusted word count from adding quotations, a figure this piece did not independently verify against Aggarwal et al.'s own text and so treats as one step more removed than the four primary findings above. ## Why we care For publishers, the concrete, verified takeaway is narrower than the SEO-blog version of GEO advice. Position in the retrieved set and topical relevance to the actual query dominate every factorial result checked here; no study reviewed found a formatting trick that outperformed simply being the most relevant, best-positioned source for the question being asked. Best-of listicle formats earning the largest single share of citations in Kumar's data is worth acting on: a page structured as a ranked comparison has a real, measured citation advantage over a generic landing page. And AgentGEO's failure breakdown is a useful diagnostic lens even without the tool itself: if a page is not getting cited, check whether it actually answers the query being asked before reaching for schema markup or citation-bait phrasing. What is not yet proven is anything close to a stable formula. Every number above comes from a specific set of LLMs tested on specific dates in 2026, none of it peer-reviewed, and the field is young enough that a widely repeated statistic, like the 68/32 citation split, can circulate for months without tracing to any real study at all. Treat any GEO percentage a vendor quotes the same way this piece treated one: ask which paper it is from, then go read that paper. ## Sources 1. [What Gets Cited: Competitive GEO in AI Answer Engines](https://arxiv.org/abs/2605.25517) - arXiv, accepted to ACM SIGIR 2026 (primary) 2. [Generative Engine Optimization at Scale: Measuring Brand Visibility Across AI Search Engines](https://arxiv.org/abs/2606.20065) - arXiv (primary) 3. [Diagnosing and Repairing Citation Failures in Generative Engine Optimization](https://arxiv.org/abs/2603.09296) - arXiv (primary) 4. [Optimizing Visibility in Generative Engines: A Critical Survey of Generative Engine Optimization 2023-2026](https://arxiv.org/html/2607.14035v1) - arXiv --- --- title: "Noindex does not save crawl budget, per Google's own documentation" url: https://seomadman.com/research/noindex-crawl-budget-reality section: research published: 2026-07-23T00:00:00.000Z modified: 2026-07-23T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Noindex does not save crawl budget, per Google's own documentation ## The short answer Noindex is widely applied as a crawl-budget fix, but Google's own crawl budget documentation says the opposite: Google still requests a noindex page, then drops it after reading the tag, which wastes crawling time rather than saving it. Google's documented alternative, robots.txt, prevents the fetch entirely but can leave an already-indexed page stuck in results indefinitely. ## Key takeaways - Google's large-site crawl budget documentation tells site owners not to use noindex for this purpose, since Google still requests the page and only drops it once it sees the tag. - The same documentation states plainly that this pattern wastes crawling time rather than saving it, which is the opposite of what noindex is commonly deployed to achieve. - Google's robots.txt introduction confirms the documented alternative: content disallowed in robots.txt is not fetched at all, a mechanically different outcome from noindex. - Google's robots.txt documentation states an indexed page can keep appearing, without a description, after a robots.txt block, since Google can no longer crawl it for noindex. - Google recommends robots.txt for pages you do not want crawled at all, reserving noindex for pages that must stay crawlable so Google can act on the tag. Noindex gets reached for constantly as a crawl-budget fix: tag the low-value pages, faceted filters, or thin parameter combinations as noindex, and the thinking goes that Google will stop wasting requests on them. Google's own documentation says this does the opposite of what site owners expect from it. ## The documented mechanism: noindex still costs a crawl Google's [large site owner's guide to managing crawl budget](https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget) addresses this pattern directly, not as an aside. Its guidance is not to use noindex for crawl budget management, and it gives the exact reason: Google still requests the page, and only after receiving that response and reading the noindex tag does it drop the page from the index. The crawl already happened by the time the directive takes effect. The documentation is explicit that this wastes crawling time rather than conserving it, which is the precise inversion of why site owners reach for noindex on large sections of a site in the first place. This is a structural property of how the tag works, not a caveat that applies only in some cases. A noindex meta tag lives inside the page's HTML, and a noindex HTTP header lives inside the page's response headers. Either way, Google's crawler has to fetch the full response before either location becomes visible to it. There is no way for Googlebot to know a page carries noindex without first requesting it, which means every noindex page in a crawl budget problem remains exactly as expensive to crawl as it was before the tag was added, indefinitely, since Google has to keep re-requesting it to confirm the tag is still there. The same documentation draws a parallel boundary around robots.txt, though for a different reason: it also advises against using robots.txt to temporarily reallocate crawl budget toward other pages, reserving that mechanism instead for URLs that should not be crawled at all. The two warnings are not the same warning. Noindex fails at crawl budget because the crawl happens anyway. Robots.txt is discouraged for temporary reallocation because it is meant as a durable block, not a budget dial to turn on and off. ## The real alternative, and its own real tradeoff Google's [introduction to robots.txt](https://developers.google.com/search/docs/crawling-indexing/robots/intro) documents the mechanism that actually withholds the crawl: a URL pattern disallowed in robots.txt is not requested by Google's crawler in the normal case, which is the mechanically different outcome that noindex cannot produce. This is the tool Google's crawl budget guidance points toward for large sections of low-value URLs, faceted navigation and tracking parameters among its own listed examples, precisely because it removes the request instead of letting it happen and discarding the result afterward. That mechanism carries a real, documented cost of its own, and it runs in the opposite direction from the noindex problem. A page already indexed before robots.txt starts blocking it can keep appearing in search results, without a description, because Google no longer crawls that URL to notice anything about it, including a noindex tag placed there afterward or content that no longer exists. Google's own robots.txt documentation is direct about the fix: use noindex, or another block Google can still read, when the actual goal is removing a page from the index, and reach for robots.txt only once that removal has taken effect, or on URLs that were never indexed to begin with. The sequencing matters more than either mechanism alone. A page that needs to come out of the index has to stay crawlable long enough for noindex to be read and acted on; blocking it in robots.txt first removes that path permanently, and a since-deleted or long-stale page can sit in search results with no description for as long as the block stands, because Google has no way to re-check it. The two tools solve different problems, aimed at different points in a page's lifecycle, not two competing fixes for the same one. ## Why we care The crawl-budget fix that gets reached for most often is the one Google's own documentation says does not work for that purpose, and the tool that does work carries a failure mode that looks identical to success from the outside: a page stops showing up as freshly crawled, sits quietly in the index with no description, and nobody notices because nothing is visibly broken. Getting this sequence right on a large site means noindexing pages that need to leave the index while they are still crawlable, waiting for that removal to be confirmed, and only then moving the URL pattern to robots.txt if the goal is to stop the crawl permanently. Reversing that order, or using robots.txt as a shortcut past noindex, produces the exact indefinite-limbo outcome Google's own documentation warns about, on pages that were only ever meant to disappear. ## Frequently asked questions ### Does adding noindex to a page reduce how often Google crawls it? No. Google's own crawl budget documentation states Google still requests the page first and only drops it from the index after reading the noindex tag in the response, which spends crawling time rather than saving it. ### What should be used instead of noindex to actually stop Google from crawling a URL pattern? Google's documentation points to robots.txt for that goal, disallowing the pattern so it is not fetched at all. That is a mechanically different action from noindex, which requires a successful crawl to take effect. ### Is robots.txt a safe replacement for noindex on a page that is already indexed? Not by itself. Google's robots.txt documentation warns that a URL indexed before being disallowed can keep appearing in results, without a description, because Google can no longer crawl it to see a noindex tag or notice it should be dropped. Getting an indexed page out of the index requires noindex, or another block Google can still read, applied before robots.txt cuts off the crawl. ## Sources 1. [Large site owner's guide to managing your crawl budget](https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget) - Google Search Central (primary) 2. [Introduction to robots.txt](https://developers.google.com/search/docs/crawling-indexing/robots/intro) - Google Search Central (primary) --- --- title: "Site reputation abuse: what the evidence actually shows" url: https://seomadman.com/research/site-reputation-abuse-what-is-actually-measured section: research published: 2026-07-23T00:00:00.000Z modified: 2026-07-23T00:00:00.000Z author: Adam Hafez topics: ["Core updates", "Technical SEO"] --- # Site reputation abuse: what the evidence actually shows ## The short answer Google's site reputation abuse policy has produced named manual actions against Forbes Advisor, CNN Underscored, WSJ Buyside and others since late 2024. Google said in March 2024 it would fight this with both manual actions and an algorithm; independent trackers report only manual actions through May 2026. Google has published no enforcement count. ## Key takeaways - Google's spam policy page defines site reputation abuse as third-party content published mainly because of a host's own ranking signals, not the third party's. - Google said in March 2024 it would enforce the policy with both manual actions and search algorithms; no public Google statement confirms the algorithmic half has shipped. - Search Engine Land and Search Engine Journal reported named manual actions against Forbes Advisor, CNN Underscored, WSJ Buyside and other sites' third-party sections in late 2024. - Google has never published a count of pages or sites affected by this specific policy. - Every case example in public circulation was found and publicized by an individual SEO practitioner watching their own client or competitor data, not by a systematic audit. Eighteen months after Google's first manual actions under the site reputation abuse policy, the practice it targets, renting a trusted domain's ranking signal to third-party content, has become a byword in SEO for something that no longer works. Whether that claim rests on evidence or on a handful of loud examples is a separate question, and one Google's own documentation does not answer. ## What Google actually defines and says it does **The policy's wording, current as of its 28 August 2026 update**, is precise about mechanism, not just intent: it "applies where third-party content is published on a host site mainly because of that host's already-established ranking signals, which it has earned primarily from its first-party content." The examples Google gives are specific: an educational site hosting sponsored payday-loan reviews, a medical site hosting a low-quality "best casinos" page written by someone else. The policy carves out wire services, syndication, forums and properly attributed affiliate content as acceptable, which is a narrower target than "any third-party content" would suggest. **Google committed to a dual enforcement track before any enforcement happened.** Its [March 2024 announcement](https://developers.google.com/search/blog/2024/03/core-update-spam-policies) of the new spam policies stated the plan was to fight site reputation abuse with both manual actions and search algorithms, with the policy taking effect from 5 May 2024. That is a commitment to two mechanisms, made in advance, against which later reporting can be checked. ## What has actually been observed **The manual actions are real and named.** [Search Engine Journal's coverage in December 2024](https://www.searchenginejournal.com/google-strengthens-policy-against-site-reputation-abuse/533018/) reported manual actions against CNN Underscored, WSJ Buyside, Forbes Advisor, USA Today's Reviewed, Newsweek's Vault and The Sun UK's shopping section, timed days before Black Friday that year. SEO practitioners Glenn Gabe and Lily Ray, cited in that reporting, described entire subfolders losing indexed pages. This is the strongest tier of evidence available on this topic: a named outlet, attributing specific claims to named practitioners, about specific named sites. **The algorithmic half of the promise is not confirmed to have shipped.** Glenn Gabe, writing on his own site in July 2024, said enforcement to that point had been manual-only, with the algorithmic component he expected still unreleased. A [Capconvert retrospective published in May 2026](https://www.capconvert.com/learn/blog/google-site-reputation-abuse-18-months) describes the same manual-only status roughly 18 months in. Neither source is Google itself, and no Google statement found in this research confirms or denies that the algorithmic component has since shipped inside a later, unlabeled spam or core update. That gap between what Google said it would build and what independent trackers can observe is the most honest thing that can be said about current enforcement. **No published number exists for total enforcement scope.** Not Google's policy page, not its March 2024 announcement, not the August 2026 EEA enforcement change, states a count of pages, sites or manual actions. Every figure attached to this policy in public circulation, including the query-loss numbers Capconvert attributes to Forbes Advisor and Fortune Recommends, comes from third-party visibility tools reading a domain's search performance, not from Google disclosing anything. ## The selection bias in every case study Every named example in this piece, and every other one in circulation, exists because a specific person was already watching that specific domain's data when a drop happened, and chose to publish it. Forbes Advisor and CNN Underscored are large enough that a subfolder going to zero shows up instantly in rank-tracking tools that SEO practitioners already had open. A mid-size publisher, or a smaller site running the exact same third-party subfolder arrangement, could receive an identical manual action and never produce a public case study, simply because nobody with an audience happened to be watching. That means the set of "confirmed" cases is not a sample of enforcement, it is a sample of enforcement that was both large enough and visible enough to someone already looking. Treat the list of named publishers as a lower bound on scope, not a census of it. ## What this means for publishers The policy's own wording, and the named cases so far, both point the same direction: a subfolder that exists mainly to borrow a host's authority, with little first-party editorial involvement, is the specific target, not any third-party content by definition. That much can be stated with confidence, because it comes from Google's own documentation. What cannot be stated with confidence is how common enforcement is beyond the publishers big enough to be watched, or whether the algorithmic detection Google promised in 2024 is now running quietly. A publisher weighing a licensed-subfolder deal should read the named cases as proof the policy is real and enforced against sites with real editorial resources, and read the absence of a published enforcement count as a reason not to assume a smaller, quieter arrangement is safe simply because it has not made the SEO news cycle yet. ## Frequently asked questions ### Has Google confirmed how many sites were hit by site reputation abuse manual actions? No. Google's documentation defines the policy and its own blog announced the enforcement plan, but no Google source publishes a count of affected pages, sites or manual actions. Every number in circulation, including query-loss figures for specific publishers, comes from third-party tools reading a site's visibility, not from Google. ### Is enforcement manual, algorithmic, or both? Google said in March 2024 it would use both. Independent trackers, including SEO consultant Glenn Gabe in mid-2024 and Capconvert in a May 2026 retrospective, report observing only manual actions in that window. No source found here has Google itself confirming the algorithmic half has shipped. ### Why do case studies about this policy only mention a handful of large publishers? Because the reporting is driven by individual practitioners noticing a drop in a site they already track, usually a large publisher with enough baseline visibility for a drop to be obvious in third-party tools. A smaller site with the same penalty would very likely not produce a public case study at all. ## Sources 1. [Spam policies for Google Search](https://developers.google.com/search/docs/essentials/spam-policies) - Google Search Central (primary) 2. [What web creators should know about our March 2024 core update and new spam policies](https://developers.google.com/search/blog/2024/03/core-update-spam-policies) - Google Search Central (primary) 3. [Google's Site Reputation Abuse Crackdown Hits Major Publishers](https://www.searchenginejournal.com/google-strengthens-policy-against-site-reputation-abuse/533018/) - Search Engine Journal 4. [Google's site reputation abuse spam policy and why an algorithmic approach to enforcing violations is the way forward](https://www.gsqi.com/marketing-blog/google-site-reputation-abuse-spam-policy-algorithmic-approach/) - GSQi (Glenn Gabe) 5. [Google Site Reputation Abuse: 18 Months In](https://www.capconvert.com/learn/blog/google-site-reputation-abuse-18-months) - Capconvert --- --- title: "NavBoost: what the DOJ trial and the API leak actually confirmed" url: https://seomadman.com/research/navboost-doj-trial-click-signals section: research published: 2026-07-21T00:00:00.000Z modified: 2026-07-21T00:00:00.000Z author: Adam Hafez topics: ["Core updates", "Technical SEO"] --- # NavBoost: what the DOJ trial and the API leak actually confirmed ## The short answer Google VP Pandu Nayak testified in the DOJ antitrust trial that NavBoost re-ranks results using roughly 13 months of aggregated click data. A separately leaked internal document named click categories including goodClicks, badClicks and lastLongestClicks. The two disclosures are independent and corroborate each other, though neither is a full account of current ranking. ## Key takeaways - Google VP of Search Pandu Nayak testified under oath that NavBoost is "one of the important signals" used to re-rank search results. - Nayak described NavBoost as memorizing clicks over a rolling window, reported by Search Engine Land as 13 months and 18 months before 2017. - A leaked internal document, independently obtained in May 2024, names click categories including goodClicks, badClicks and lastLongestClicks. - The leak's own first reporter cautioned that a named feature is not proof it currently affects ranking or carries meaningful weight. - For years Google's public statements treated click data as unconfirmed for ranking, a position the trial testimony sits in tension with. Two disclosures in 2024 landed on the same subject from opposite directions. In November 2023, Google VP of Search Pandu Nayak took the stand in *United States v. Google* and described a system called NavBoost. Six months later, an internal Google document reached [SparkToro's Rand Fishkin](https://sparktoro.com/blog/an-anonymous-source-shared-thousands-of-leaked-google-search-api-documents-with-me-everyone-in-seo-should-see-them/) from an anonymous source and named click categories that line up with what Nayak described under oath. Neither event was staged to corroborate the other. Read together, they are the closest the public has to independent confirmation of how click data moves through Google's ranking pipeline. ## What Nayak testified to Google's VP of Search told the court that NavBoost is "one of the important signals" Google uses, not the retrieval system itself. [Search Engine Land's trial coverage](https://searchengineland.com/how-google-search-ranking-works-pandu-nayak-435395) quotes him describing it as a memorization system that works from clicks on a query going back roughly 13 months, a window that was 18 months before a change in 2017. **Its job in the pipeline is culling, not fine-tuning.** Nayak's account, as reported, places NavBoost early: an initial retrieval stage returns a large candidate set of documents, and NavBoost uses historical click behavior to cut that set down before later ranking stages run. That is a different claim than "clicks nudge the final order," and it is worth keeping the two apart when the testimony gets summarized. **It cannot help pages with no click history.** By Nayak's own description, a new or rarely-clicked page gets nothing from NavBoost, because the system has no aggregated behavior to memorize for it. That limitation was part of the testimony, not an inference added afterward. ## What the leaked document named The Content Warehouse API leak is a separate chain of custody entirely. An anonymous source sent internal documentation to Erfan Azimi, who passed it to Rand Fishkin at SparkToro, who published his findings in May 2024 alongside analysis from iPullRank's Mike King. [Search Engine Land's coverage of the same leak](https://searchengineland.com/google-search-document-leak-ranking-442617) confirms the same field names independently: badClicks, goodClicks, lastLongestClicks and unsquashedClicks appear in the documentation as distinct click-related attributes. **The document names features; it does not state their weight.** Both outlets are explicit on this point. Search Engine Land reports that the leak "did not specify how any of the ranking features are weighted, just that they exist." Fishkin went further in his own post, warning readers directly not to treat a named API field as proof that Google currently uses it the way the name implies - a field can be retired, reserved for testing, or never shipped to production. **Treat the exact terms as leaked shorthand, not a public spec.** goodClicks, badClicks and lastLongestClicks read as plainly as the terms in this piece describe them, but they come from internal engineering documentation that Google has never authenticated in public. That caution applies to the names themselves, not just to their weighting. ## The tension with Google's own public position For roughly two decades, Google's public statements treated a direct ranking role for click data as something between unconfirmed and denied. A [2019 Google response reported by Search Engine Land](https://searchengineland.com/googles-ctr-answer-just-what-youd-expect-and-this-is-why-seos-go-bananas-313176) said interactions are used "for personalization, evaluation purposes and training data," a sentence built to avoid the word ranking rather than address it directly. **This piece states the tension; it does not resolve it.** Sworn testimony describing NavBoost as an important signal sits uneasily next to years of public phrasing that stopped short of confirming any such role. That is not the same as proof that every earlier public statement was false: Google's representatives may have been describing a narrower system, working from incomplete internal knowledge, or using "ranking signal" more narrowly than NavBoost's actual function. What can be said without overreaching is that the public framing and the sworn testimony do not match, and neither this trial nor this leak is the last word on exactly how today's ranking pipeline weighs a click. ## Why we care If a page has real search demand but no click history, in Nayak's own account of NavBoost, this particular signal has nothing to offer it - which puts the weight back on other ranking inputs and on [technical SEO](/topics/technical-seo) fundamentals that do not depend on accumulated behavior data. Neither the testimony nor the leak is grounds for chasing a specific click-pattern tactic; both sources here explicitly warn against reading more precision into named fields or a single number than the disclosure supports. Read the primary coverage linked above before repeating a specific figure, and hold the 13-month window and the exact leak terminology as reported claims, not settled specification. ## Frequently asked questions ### Does this prove Google uses click-through rate to rank pages today? It proves Google built a system, NavBoost, that a VP of Search testified under oath uses aggregated click history to re-rank results, and that internal documentation names specific click categories. It does not prove the exact weight of any single click category today, and the leak's own first reporter warned against treating a named field as proof of its current use. ### Why does the click-window figure vary between 13 and 18 months in different write-ups? Search Engine Land's trial coverage reports Nayak's testimony as a 13-month rolling window, down from 18 months before a 2017 change. Some secondary write-ups repeat only one of the two numbers, which is why this piece states both and attributes them to the testimony rather than treating either as a permanent constant. ### Is the leaked document itself public? The underlying Content API Warehouse documentation was shared with and analyzed by SparkToro and iPullRank, who published excerpts and analysis rather than the raw internal codebase. Google has not published or authenticated the document itself. ## Sources 1. [How Google Search and ranking works, according to Google's Pandu Nayak](https://searchengineland.com/how-google-search-ranking-works-pandu-nayak-435395) - Search Engine Land (primary) 2. [An anonymous source shared thousands of leaked Google Search API documents with me; everyone in SEO should see them](https://sparktoro.com/blog/an-anonymous-source-shared-thousands-of-leaked-google-search-api-documents-with-me-everyone-in-seo-should-see-them/) - SparkToro (primary) 3. [HUGE Google Search document leak reveals inner workings of ranking algorithm](https://searchengineland.com/google-search-document-leak-ranking-442617) - Search Engine Land 4. [Google's CTR answer just what you'd expect, and this is why SEOs go bananas](https://searchengineland.com/googles-ctr-answer-just-what-youd-expect-and-this-is-why-seos-go-bananas-313176) - Search Engine Land --- --- title: "VideoObject schema: the required properties Google actually documents" url: https://seomadman.com/research/videoobject-schema-required-properties section: research published: 2026-07-21T00:00:00.000Z modified: 2026-07-21T00:00:00.000Z author: Adam Hafez topics: ["Structured data"] --- # VideoObject schema: the required properties Google actually documents ## The short answer Google's own VideoObject documentation lists three required properties: name, thumbnailUrl and uploadDate. contentUrl and embedUrl are recommended, not required, contradicting a common claim. Dates need full ISO 8601 with a timezone offset; durations use ISO 8601 duration format like PT00H30M5S. A valid block still does not guarantee a rich result. ## Key takeaways - Google's VideoObject documentation lists only three required properties: name, thumbnailUrl and uploadDate. - contentUrl and embedUrl are recommended properties, not required ones, and Google treats them as alternatives to each other rather than a mandatory pair. - uploadDate must be full ISO 8601 with a time and timezone offset, matching Google's own example of 2024-03-31T08:00:00+08:00. - duration uses ISO 8601 duration format, with Google's own example PT00H30M5S standing for thirty minutes and five seconds. - Google states plainly that valid structured data does not guarantee a rich result will appear in Search. VideoObject is one of the schema.org types where a specific, wrong-sounding claim travels further than the source it is supposedly quoting. A four-property required list circulates in SEO advice: name, thumbnailUrl, uploadDate, and either contentUrl or embedUrl. Checked directly against Google's own current VideoObject documentation, that fourth requirement does not exist. Getting this distinction wrong matters in practice, since a validator or a checklist that treats a recommended property as required will flag pages that are, by Google's own definition, already compliant. ## The real required and recommended lists Google's structured data page for Video draws a firm line between two tables, and only three properties sit in the required one: `name`, the video's title; `thumbnailUrl`, a URL to the video's unique thumbnail image; and `uploadDate`, the date and time the video was first published. Nothing else appears in that table. `contentUrl` and `embedUrl` both live in the recommended table instead, and Google frames them as alternatives rather than a pair to satisfy together: it recommends providing `contentUrl` if possible, since that is the most effective way for Google to fetch the video content directly, and recommends falling back to `embedUrl` only if `contentUrl` isn't available. The rest of the recommended table covers `description`, `duration`, `expires`, `hasPart`, `ineligibleRegion`, `interactionStatistic`, `publication` and `regionsAllowed`, none of which is required either. A page missing all of these still satisfies Google's required set as long as `name`, `thumbnailUrl` and `uploadDate` are present and correctly formatted. ## The two formats that fail silently Both dated properties use ISO 8601, but in different notations, and a mismatch will not throw a JSON syntax error, it will simply be wrong data that Google either discards or misreads. `uploadDate` needs a full timestamp with a timezone offset; Google's own documented example is `2024-03-31T08:00:00+08:00`. A bare calendar date like `2024-03-31` is not the documented format, even though it happens to parse as valid JSON. `duration` uses ISO 8601 duration notation instead of timestamp notation, and Google's own example is `PT00H30M5S`, which its documentation glosses directly as "thirty minutes and five seconds." The leading `PT` marks a time duration, `H`/`M`/`S` mark hours, minutes and seconds, and the value has no colons or slashes anywhere in it, a format this site's own video schema uses the same way (see `duration` in the research collection's video entries, expressed as `PT12M30S` for twelve minutes thirty seconds). Google's thumbnail guidance is worth treating as a required check even though `thumbnailUrl` itself is the only formally required property touching it: the file "must be accessible by Googlebot and Googlebot Images," with Google specifically warning not to block it "with robots.txt or a login requirement," and to keep it "consistently available at a stable URL." A thumbnail that returns a login wall, a 404 after a redesign, or a redirect chain fails this requirement even when the `thumbnailUrl` string itself is well-formed. ## Markup passing does not mean the video ranks Google states its general caveat for structured data directly: it "does not guarantee that features that consume structured data will show up in search results," even for markup that satisfies every documented required and recommended property. A `VideoObject` block that validates cleanly still depends on the underlying video file being reachable, the thumbnail staying accessible over time, and the page's actual content matching what the markup asserts. None of that is something a schema check can confirm from the JSON-LD alone; it can only confirm the markup is internally correct. ## Why we care The gap between what circulates as VideoObject's required properties and what Google's own page actually requires is exactly the kind of error this site's editorial rule exists to catch: name, thumbnailUrl and uploadDate are required, contentUrl and embedUrl are recommended alternatives to each other, and the date and duration formats have exact documented examples that are easy to get subtly wrong without a syntax error ever surfacing. This site's [JSON-LD validator](/tools/json-ld-validator/) already checks required and recommended properties for Article, Product, FAQPage, HowTo, Organization, BreadcrumbList and Recipe against Google's own documentation the same way this piece did for Video; VideoObject is not one of its seven supported types yet, and adding it is a natural extension rather than a new category of check, since the underlying method, reading Google's documented tables directly, is identical. ## Frequently asked questions ### Are contentUrl and embedUrl required for VideoObject? No. Google's own required properties table lists only name, thumbnailUrl and uploadDate. contentUrl and embedUrl are both recommended, and Google presents them as alternatives to each other, with contentUrl preferred because it is the more effective way for Google to fetch the video file directly. ### What exact date format does uploadDate need? Full ISO 8601 with a time and timezone offset. Google's own documentation example is 2024-03-31T08:00:00+08:00, not a bare calendar date, which is the format a validator should check for. ### What exact format does duration need? ISO 8601 duration notation, not a timestamp. Google's own example is PT00H30M5S, which it describes as thirty minutes and five seconds, the same pattern used elsewhere on this site's VideoObject-adjacent schemas. ### Does valid VideoObject markup guarantee a video rich result? No. Google states directly that it does not guarantee a rich result will appear even for markup that follows every documented guideline. The thumbnail, video file and page itself must also be genuinely accessible and match what the markup claims. ## Sources 1. [Video (VideoObject, Clip, BroadcastEvent) structured data](https://developers.google.com/search/docs/appearance/structured-data/video) - Google Search Central (primary) 2. [Video best practices](https://developers.google.com/search/docs/appearance/video) - Google Search Central --- --- title: "Why four 2026 'ChatGPT market share' numbers do not agree" url: https://seomadman.com/reports/ai-chatbot-market-share-trackers-compared section: reports published: 2026-07-19T00:00:00.000Z modified: 2026-07-19T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # Why four 2026 'ChatGPT market share' numbers do not agree ## The short answer Four sources published a ChatGPT usage number in 2026: StatCounter's 76.85% is chatbot referral share, Similarweb's sub-60% figure is web-visit share, Sensor Tower's 1 billion is app installs, and OpenAI's own 900 million is self-disclosed weekly active users. Each is real and correctly reported. None can be averaged against the others, because none measures the same population. ## Key takeaways - StatCounter puts ChatGPT at 76.85% of worldwide AI chatbot referral traffic in April 2026, down from 84.21% a year earlier, based on referral logs from over 1 million websites. - Similarweb's web-traffic panel shows ChatGPT's share of generative AI site visits falling from 73.3% in August 2025 to as low as 52.7% in May 2026 as Gemini rose past 27%. - Sensor Tower estimates ChatGPT's app crossed 1 billion monthly active users in May 2026, the fastest app ever to reach that mark, but this is a third-party estimate. - OpenAI itself disclosed 900 million weekly active users in a February 2026 blog post, the only number here that comes directly from the company rather than a tracker. - None of these four figures describes the same population, so none can be added, averaged, or substituted for another in a single "AI market share" claim. Four different people can each cite a real, correctly-reported 2026 figure for "ChatGPT's market share" and all four can be right, because none of them measured the same thing. StatCounter's 76.85% counts referral traffic. Similarweb's low-50s-to-70s percentage counts web visits. Sensor Tower's 1 billion counts mobile app users. OpenAI's own 900 million counts the company's self-reported weekly active users across every surface it runs. Averaging any two of these produces a number nobody measured and nothing describes. ## Four trackers, four populations | Source | What it measures | Population | Figure | Date | | --- | --- | --- | --- | --- | | StatCounter | Referrer share in website analytics logs | Traffic AI chatbots send onward to other websites | ChatGPT 76.85% (down from 84.21% a year earlier) | April 2026 | | Similarweb | Domain-level web visits | People visiting each chatbot's own site or app in a browser | ChatGPT fell from 73.3% (Aug 2025) to as low as 52.7% (May 2026), recovering to 55.5% by August 2026, as Gemini rose from roughly 13% to 27.8% | Aug 2025 - Aug 2026 | | Sensor Tower | Mobile app-analytics panel | Monthly active users of the ChatGPT mobile app | 1 billion, the fastest app in history to the mark | May 2026 | | OpenAI (self-disclosed) | The company's own platform logs | Weekly active users across ChatGPT, all platforms | 900 million | February 2026 | StatCounter's number comes from referral data across more than 1 million websites receiving over 3 billion monthly page views: whichever chatbot last sent a visitor to one of those sites gets credited. That makes it a measure of *outbound link behavior*, not overall usage - a chatbot whose users mostly stay inside the chat window, rather than clicking a cited source out to another site, will read smaller on this metric than its total audience would suggest. Similarweb's panel instead measures visits to the AI tools' own domains and apps, which is a much larger population than StatCounter's referral logs capture. Similarweb is explicit that this excludes API usage and embedded assistants "where much of the AI usage occurs now," so even this broader number understates total usage of the underlying models. The trend is real and repeated across several months of Similarweb's own data: ChatGPT's share of generative-AI web visits was about 86% in January 2025, 73.3% by August 2025, down to 64.5% in January 2026 and 52.7% by May 2026, before a partial recovery to 55.5% in August 2026. Gemini moved the other way, from roughly 5% in January 2025 past 21% in January 2026 and to 27.8% by May 2026. Sensor Tower and OpenAI describe an entirely different kind of number: not a share of a category at all, but a raw user count, and from two different sources with two different definitions. Sensor Tower is an independent mobile-analytics firm estimating monthly active users of the ChatGPT app specifically; OpenAI's own figure is weekly active users across every platform it operates, announced by the company itself in a blog post tied to its funding round. A "billion users" headline and a "900 million users" headline six weeks apart are not describing the same metric, the same time window, or even the same company as the source. ## The fifth claim that does not survive checking A widely repeated 2026 statistic holds that "ChatGPT, excluding Copilot, attracts 60.7% of all AI search traffic" as of February 2026. It shows up, word for word or close to it, across several SEO statistics roundups. None of those roundups names the underlying tracker, links to a primary report, or discloses a methodology - each one appears to be restating the others rather than an original source. Searching for the figure's origin turns up only more listicles repeating the same number, never a dataset, panel description, or named research firm behind it. This report leaves it out. A market-share figure with no traceable source is not a citable fact, no matter how many sites repeat it. ## Why we care **"AI search market share" is four different questions wearing one headline.** Before repeating any 2026 ChatGPT statistic, ask which of these it answers: referral traffic out to other sites, visits to the chatbot's own domain, mobile app installs, or the company's self-reported active users. Two of those are broad usage measures, one is referral behavior specifically, and one is an app-store-adjacent estimate that excludes desktop and API traffic entirely. **The self-disclosed number is the most authoritative and the narrowest.** OpenAI's 900 million is the only figure here that comes from the company rather than an outside panel, which makes it the one figure that cannot be second-guessed on data-collection methodology. But it is also the figure hardest to compare with anything else, because OpenAI has not published the underlying platform, device, or geographic breakdown that would let a third-party tracker check it against their own measurements. **A number nobody can trace is worse than no number at all.** The 60.7%-excluding-Copilot figure looks precise enough to be safely reused, and that is exactly what makes it dangerous: a specific decimal invites citation even when nothing behind it can be checked. Treat any AI-usage statistic that a page states without linking to who measured it and how as unverified until proven otherwise. ## Frequently asked questions ### What is ChatGPT's real market share in 2026? There is no single correct answer. Say which tracker and which population - AI chatbot referral traffic (StatCounter, 76.85%), generative AI web visits (Similarweb, roughly 53-73% depending on the month), mobile app users (Sensor Tower's 1 billion), or OpenAI's own self-reported weekly active users (900 million). A bare "market share" figure without one of those four attached is not a complete claim. ### Why do StatCounter and Similarweb disagree so much about ChatGPT's decline? They track different traffic. StatCounter measures how often each AI chatbot appears as the referrer in website analytics logs, which is dominated by whichever tool people click links from most. Similarweb measures total visits to each chatbot's own domain, a broader population that includes people who never click through to another site at all. A chatbot can lose referral share while holding visit share, or the reverse. ### Is ChatGPT's 1 billion users the same as OpenAI's 900 million users? No, and the six-week gap between the two announcements makes that easy to miss. OpenAI's 900 million is a company-disclosed count of weekly active users across every surface it operates, announced in a February 2026 blog post. Sensor Tower's 1 billion is an independent analytics firm's estimate of monthly active users of the ChatGPT mobile app specifically, reported in June 2026. Different metric (weekly vs. monthly), different population (all platforms vs. app only), different source (the company vs. a third-party estimator). ### Is the "60.7% excluding Copilot" figure real? It could not be traced to a named tracker, dataset or methodology. It appears, uncited, across several SEO statistics listicles that all restate each other rather than a primary source. This report excludes it rather than repeat an unverifiable number. ## Sources 1. [OpenAI: ChatGPT now has 900 million weekly active users](https://searchengineland.com/chatgpt-900-million-weekly-active-users-470492) - Search Engine Land (primary) 2. [ChatGPT falls to all-time low as AI chatbot referral market continues to fragment](https://gs.statcounter.com/press/chatgpt-falls-to-all-time-low-as-ai-chatbot-referral-market-continues-to-fragment) - StatCounter Global Stats 3. [AI search stats](https://aisearch.similarweb.com/blog/gen-ai-stats/) - Similarweb 4. [Google Gemini gains share as ChatGPT declines in Similarweb data](https://www.searchenginejournal.com/google-gemini-gains-share-as-chatgpt-declines-in-similarweb-data/564690/) - Search Engine Journal 5. [ChatGPT claws back web traffic share to 55.5 percent as Gemini's brief comeback fades](https://the-decoder.com/chatgpt-claws-back-web-traffic-share-to-55-5-percent-as-geminis-brief-comeback-fades/) - The Decoder 6. [ChatGPT app reportedly hits 1 billion monthly active users, faster than any previous app](https://tech.yahoo.com/ai/chatgpt/article/chatgpt-app-reportedly-hits-1-billion-monthly-active-users-faster-than-any-previous-app-212611905.html) - Yahoo Tech (Sensor Tower data) --- --- title: "Core Web Vitals and rankings: what the correlation shows" url: https://seomadman.com/research/core-web-vitals-ranking-correlation-2026 section: research published: 2026-07-19T00:00:00.000Z modified: 2026-07-19T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Core Web Vitals and rankings: what the correlation shows ## The short answer CrUX data puts Core Web Vitals pass rates at 48% of mobile origins and 56% of desktop origins as of July 2025. A separate 2,500-keyword study found position 1 pages pass Core Web Vitals about 10 points more than position 9 pages. Google says relevance wins even with sub-par page experience, so the honest reading is association, not proof. ## Key takeaways - The 2025 Web Almanac, built on CrUX data from July 2025, found 48% of mobile origins and 56% of desktop origins pass all three Core Web Vitals. - LCP is the weakest of the three metrics on mobile, with only 62% of mobile origins passing it compared with 77% for INP and 81% for CLS. - A Screaming Frog study of 2,500 keywords and roughly 20,000 URLs found position 1 results pass Core Web Vitals near 19-20% of the time against 10-11% for positions 5 through 9. - Google's own documentation says it shows the most relevant content even when page experience is sub-par, which caps how much weight a correlation study can imply. - Sites that rank well and pass Core Web Vitals often share a third cause, such as engineering investment, so the gap is not proof that fixing LCP alone moves rankings. Every few months a number resurfaces that sounds too clean to be true: some precise share of the web passes Core Web Vitals, and pages that pass supposedly rank higher because of it. Both halves of that claim exist in real data. Neither half says what the SEO folklore around it usually claims. ## What the field data actually says The Chrome UX Report is the only public, large-scale measurement of how real visitors experience real pages, and the clearest citable read of it comes from the HTTP Archive's Web Almanac. Its 2025 performance chapter, built on CrUX data through July 2025, puts the share of origins passing all three Core Web Vitals at 48% on mobile and 56% on desktop. Broken down by metric, mobile LCP is the weak link at 62% passing, against 77% for INP and 81% for CLS. A widely repeated figure claiming 55.9% of origins passed as of May 2026 circulated in search results while researching this piece. It could not be traced to the CrUX dashboard, the HTTP Archive, or any outlet citing CrUX data directly, only to secondary blog posts restating each other. It is not used here for that reason. ## What the correlation study found, and what it does not prove A Screaming Frog analysis pulled Core Web Vitals status for roughly 20,000 URLs ranking across 2,500 keywords in UK search results, using the PageSpeed Insights API against CrUX data. Position 1 results passed Core Web Vitals near 19-20% of the time; positions 5 through 9 flattened to roughly 10-11%, a gap the study's own author describes as unlikely to mean Core Web Vitals is a hidden major ranking factor. That hedge matters. A pre-filtered set of already-ranking URLs will tend to skew toward sites with more resources across the board: better hosting, more engineering attention, more mature content operations. A faster page and a higher-ranking page can share a cause without either one causing the other, and this study's sample size and single-country, single-snapshot design mean it has not been replicated at a scale that would settle the question either way. ## What Google itself says Google's own page experience documentation is unambiguous about the ordering: Search "always seeks to show the most relevant content, even if the page experience is sub-par." Page experience is described as something that can help decide between pages that are already similarly relevant, not a signal that competes with relevance directly. That statement, from the party that controls the ranking system being studied, is the strongest available evidence for how much weight Core Web Vitals actually carries, and it is consistent with both datasets above: real, measurable, and secondary to content. ## What this means for prioritizing the work Treat Core Web Vitals as a floor, not a lever. If a site is failing LCP or INP outright, that is a defensible, evidence-backed fix: it removes a plausible tie-breaking disadvantage and, separately, protects conversion and user experience regardless of what it does to rankings. But do not sell Core Web Vitals work to a client or a stakeholder on the promise of a ranking jump from a passing score alone. The field data shows roughly half of origins already pass; the correlation data shows an association among sites that were already competing well; and Google says relevance decides first. Fix real failures, measure the outcome you actually control, such as bounce rate or conversion, and keep the ranking claim honest. ## Sources 1. [Page experience and Search ranking](https://developers.google.com/search/docs/appearance/page-experience) - Google Search Central (primary) 2. [Performance | 2025 | The Web Almanac](https://almanac.httparchive.org/en/2025/performance) - HTTP Archive (primary) 3. [How Many Sites Actually Pass The Core Web Vitals Assessment?](https://www.screamingfrog.co.uk/blog/passing-the-cwv-assessment/) - Screaming Frog --- --- title: "Googlebot's two-wave rendering: how long JS content actually waits" url: https://seomadman.com/research/javascript-rendering-googlebot-delay section: research published: 2026-07-17T00:00:00.000Z modified: 2026-07-17T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Googlebot's two-wave rendering: how long JS content actually waits ## The short answer A 2024 Vercel and MERJ study tracked over 100,000 Googlebot fetches on nextjs.org and found 100% of valid HTML pages were eventually fully rendered. The median delay between crawl and render was 10 seconds, but the 99th percentile stretched to roughly 18 hours. Google confirms a two-wave process: HTML first, JavaScript later, on a queue with no fixed wait time. ## Key takeaways - Vercel and MERJ analyzed over 100,000 Googlebot fetches on nextjs.org in April 2024 and reported 100% of valid HTML pages were fully rendered. - The measured render delay had a median of 10 seconds and a 75th percentile of 26 seconds, but stretched to about 3 hours at the 90th percentile and about 18 hours at the 99th. - Google's own JavaScript SEO documentation confirms the two-wave structure: an initial HTML crawl, then a separate rendering pass once resources allow. - Google's documentation states the rendering queue delay can be a few seconds but can also take longer, without naming a fixed maximum. - Google's own crawl budget documentation says most sites do not need to think about crawl budget at all; it names large or rapidly-changing sites as the exception, not the rule. Googlebot does not read a JavaScript-rendered page the way a browser does, in one pass. It fetches the raw HTML first, queues the links it finds there, and executes the page's JavaScript separately, later, when rendering capacity is available. That structure is old news to anyone who has read Google's own documentation. What has been harder to pin down is how long the gap between those two steps actually runs in practice, and a 2024 study set out to measure exactly that instead of describing it only in general terms. ## What the study measured [Vercel and MERJ](https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process) instrumented nextjs.org with Vercel's own Edge Middleware for 30 days in April 2024, comparing Googlebot requests recorded in server logs against rendering beacons fired once a page's JavaScript had actually executed. Two smaller sites, monogram.io and basement.io, were included as secondary checks. After excluding error responses and pages marked non-indexable, the study tracked over 100,000 Googlebot fetches and matched roughly 37,000 of them to a completed render. **Every valid page in the sample eventually rendered.** The study's own figure is that 100% of valid HTML pages resulted in a full-page render. That is a completion rate, not a speed claim, and it is worth keeping the two apart: it says Googlebot did not give up on any page in the sample, not that every page rendered quickly. **Speed is where the real variation shows up.** The median time between crawl and completed render was 10 seconds, and a quarter of pages rendered within 4 seconds. That is fast enough that most JavaScript-dependent content in this sample was not meaningfully delayed at all. ## The slow tail is the part worth remembering A median of 10 seconds understates the picture on its own, because the distribution has a long tail. The 75th percentile was 26 seconds, still fast, but the 90th percentile stretched to roughly 3 hours, the 95th to roughly 6 hours, and the 99th to roughly 18 hours. A small share of pages in the sample waited nearly a full day for their JavaScript to execute. **This lines up with Google's own framing, not against it.** Google's [JavaScript SEO documentation](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) describes the render queue directly: a page may stay on it for a few seconds, but it can take longer than that, with no committed maximum. The study puts real numbers on a delay Google has always described only qualitatively, and both sources agree on the shape, fast for most pages, with a real tail for some. ## Why we care For most sites, the practical read is not "chase faster rendering," it is "don't assume JavaScript content is invisible to Google by default." A page whose critical content depends on client-side JavaScript is very likely to render, per this study's own numbers, and often within seconds. The exception worth planning for is the tail: a page that needs to be indexed within minutes, not hours, should not depend on the render queue at all, whether through server-side rendering or static generation for that specific content. It is also worth resisting the jump some coverage makes from "render delay exists" straight to "crawl budget problem." Google's own [crawl budget documentation](https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget) is explicit that most sites do not need to manage crawl budget as a distinct concern at all; that applies mainly to large or very fast-changing sites. A render-delay finding on one Next.js site in one month of 2024 is not evidence that typical single-page apps are burning crawl budget at scale, and no verifiable source was found for that specific claim. ## Frequently asked questions ### Does the 100% full-render figure mean Google renders every JavaScript site perfectly? No. It is the completion rate the study measured on one site, nextjs.org, over one 30-day window in 2024, after excluding error pages and pages marked non-indexable. It says every valid page eventually got rendered in that sample, not that rendering was instant or that every framework performs the same way. ### What is two-wave indexing, in Google's own terms? Google's JavaScript SEO documentation describes crawling and rendering as separate steps rather than one pass. Googlebot fetches and parses the raw HTML first, queuing any links it finds; a headless Chromium instance executes the page's JavaScript in a later, separate step once rendering resources are available. Google's own wording says that wait can be a few seconds but can also take longer, without committing to a fixed number. ### Should a typical site worry about crawl budget because of render delay? Google's own crawl budget documentation says most sites do not need to think about crawl budget as a distinct problem; it applies mainly to very large sites or sites whose pages change very fast. A render-delay finding on JavaScript content is a separate question from crawl budget, and conflating the two overstates the risk for a typical site. ## Sources 1. [Javascript SEO: How Google Crawls, Renders & Indexes JS](https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process) - Vercel (primary) 2. [Google's JavaScript Rendering Capabilities](https://merj.com/blog/googles-javascript-rendering-capabilities) - MERJ 3. [JavaScript SEO basics](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) - Google Search Central (primary) 4. [Large site owner's guide to managing your crawl budget](https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget) - Google Search Central --- --- title: "E-E-A-T and author schema: what is actually verifiable" url: https://seomadman.com/research/author-schema-eeat-what-is-verifiable section: research published: 2026-07-15T00:00:00.000Z modified: 2026-07-15T00:00:00.000Z author: Adam Hafez topics: ["Content strategy"] --- # E-E-A-T and author schema: what is actually verifiable ## The short answer Google's own documentation and public statements describe E-E-A-T as a concept used to train and evaluate its ranking systems, not a scored ranking input. A commonly cited "8% overall, 24% for YMYL" statistic traces to a marketing blog with no disclosed methodology. A separate claim about author-schema pages and AI citation rates could not be traced to any named study. ## Key takeaways - Google Search Liaison Danny Sullivan stated directly that E-E-A-T "is not a ranking factor," calling it a rater-guideline concept instead. - The commonly cited "8% overall, 24% for YMYL" E-E-A-T weighting traces to DollarPocket, a marketing blog with no disclosed statistical methodology behind that figure. - A frequently repeated claim that unattributed pages are "40% less likely" to be cited by AI engines could not be traced to any named, checkable study. - Google's Article structured data documentation lists the author property as recommended, not required, and ties it to display features, not ranking. - Google explicitly states structured data does not guarantee that any feature consuming it will appear in search results. SEO content repeats two kinds of statement about E-E-A-T and author schema markup: what Google itself has published, and a much larger volume of specific-sounding percentages attributed to studies that are rarely named or linked. Before citing either kind, we checked both against what a reader could actually verify. ## The percentages that do not check out One frequently repeated figure holds that E-E-A-T signals correlate with roughly 8% of ranking weight across all queries, rising to about 24% for YMYL (Your Money or Your Life) queries, credited to a "DollarPocket correlation study." DollarPocket is a real, reachable site publishing a page titled [SEO Ranking Factors Study 2025](https://www.dollarpocket.com/seo-ranking-factors-study). It is not a research organization: it is a personal finance and internet marketing blog. The page states the 8% and 24% figures without disclosing a formula, a statistical method, or named authors - the byline is an "Editorial Team." Nothing on the page allows a reader to check how those numbers were derived. We are not using this figure, and any piece that cites it as a study should be read with that in mind. A second claim, that pages without a named author are "40% less likely" to be cited by AI engines, turns up constantly in AI-search-optimization content but does not trace to a specific, checkable study. Coverage of how AI answer engines choose sources does discuss author attribution as one factor among several - named authors, visible dates, and linked external sources are described as things that plausibly help a claim get picked up - but none of that coverage produces this particular figure or names a study behind it. We could not verify it, so it does not appear here as fact. Neither of these findings proves the underlying idea is wrong. Named authorship and topical expertise may well correlate with something Google's or an AI engine's systems reward. What can be said is that these two specific numbers, as commonly repeated, are not traceable to a source that would survive scrutiny. ## What Google itself actually says Google's own position on E-E-A-T is more consistent, and more available to check directly, than the secondary content built on top of it. Search Liaison Danny Sullivan addressed the point directly in February 2024, [reported by Search Engine Roundtable](https://www.seroundtable.com/google-eeat-factors-36879.html): "It's not a ranking factor. It's not a thing that's going to factor into other factors." He was responding to a question about whether hiring a credentialed expert to write content would itself improve rankings, and the answer was that it would not, because expertise is not a value Google's systems score on its own. **Google frames E-E-A-T as a tool for raters, not an input for ranking.** The [December 2022 Search Central announcement](https://developers.google.com/search/blog/2022/12/google-raters-guidelines-e-e-a-t) that added the second E, for experience, describes E-E-A-T as part of the guidelines Google's human search quality raters use "to help evaluate the performance of our various search ranking systems," and states plainly that the guidelines "don't directly influence ranking." That is a specific, important distinction: raters use E-E-A-T to judge whether Google's systems are behaving as intended, which is a different mechanism than a page's content being scored against an E-E-A-T value at query time. **"Built to reward" is looser than "a scored input."** Google's own materials, including its [helpful content documentation](https://developers.google.com/search/docs/fundamentals/creating-helpful-content), describe E-E-A-T as qualities that Google's ranking systems are "built to reward" through other, separately named and measurable signals - links, reputation signals, and content-quality indicators among them. That phrasing avoids both extremes: it is not "E-E-A-T does nothing," and it is not "E-E-A-T is a ranking factor with a number attached." ## What Google's structured data documentation says about author markup Google's [Article structured data documentation](https://developers.google.com/search/docs/appearance/structured-data/article) states that Article markup, which covers Article, NewsArticle and BlogPosting types, has no required properties at all - only recommended ones, and author is one of several recommended fields alongside headline, image, and date properties. **The stated purpose is display, not ranking.** The documentation says this markup can help Google "understand more about the web page and show better title text, images, and date information for the article in search results." Nowhere does it say author markup, or Article markup generally, moves a page's position in results. **Google explicitly disclaims a ranking guarantee.** The same documentation states outright that Google "does not guarantee that features that consume structured data will show up in search results." That single sentence covers author markup along with every other recommended property on the page: adding it makes a page eligible for certain display treatments, not entitled to them, and says nothing about ranking position either way. ## Why we care Publishers can verify two things independently, and should treat them differently. First: Google's own statements, quoted above, are checkable and consistent - E-E-A-T is a rater-guideline concept the company has repeatedly said is not a scored ranking factor, and author schema markup is documented as a display aid with an explicit no-guarantee disclaimer, not a ranking lever. Second: the specific percentages circulating around both topics - an 8% or 24% E-E-A-T weight, a 40% AI-citation penalty for missing bylines - are marketing content dressed as research, and neither traces to a source worth citing. The practical guidance that survives this is unglamorous: publish real author bios with verifiable credentials because that is good practice and matches what Google's raters are told to look for, add Article and Person schema because it is free and may earn display features, and do not repeat a specific percentage about either one unless you can find - and link to - the study yourself. ## Frequently asked questions ### Is E-E-A-T a Google ranking factor? Google says no. Search Liaison Danny Sullivan stated directly that E-E-A-T "is not a ranking factor" and "not a thing that's going to factor into other factors." Google's own framing is that E-E-A-T describes qualities its ranking systems are built to reward through other, separately named signals, and that raters use the concept to evaluate those systems, not to score pages directly. ### Does adding author schema markup improve rankings? Google's Article structured data documentation does not make that claim. It lists author as a recommended, not required, property, and ties its purpose to display features such as better title text and date information in search results. The same documentation states structured data does not guarantee that any feature consuming it will actually appear in results. ### Where does the "8% overall, 24% for YMYL" E-E-A-T figure come from? It traces to DollarPocket, a personal finance and internet marketing blog publishing under an "Editorial Team" byline, with no disclosed statistical methodology for how those percentages were calculated. That does not meet a bar for citation, so this piece does not use the figure. ## Sources 1. [Our latest update to the quality rater guidelines: E-A-T gets an extra E for Experience](https://developers.google.com/search/blog/2022/12/google-raters-guidelines-e-e-a-t) - Google Search Central (primary) 2. [Article (Article, NewsArticle, BlogPosting) structured data](https://developers.google.com/search/docs/appearance/structured-data/article) - Google Search Central (primary) 3. [Google Says EEAT Is Not A Ranking Factor Nor A Thing That Factors Into Other Factors](https://www.seroundtable.com/google-eeat-factors-36879.html) - Search Engine Roundtable 4. [SEO Ranking Factors Study 2025: Analysis of 10M Search Results](https://www.dollarpocket.com/seo-ranking-factors-study) - DollarPocket 5. [Creating helpful, reliable, people-first content](https://developers.google.com/search/docs/fundamentals/creating-helpful-content) - Google Search Central --- --- title: "Does content length correlate with rankings and AI citations?" url: https://seomadman.com/research/content-length-ranking-citation-correlation section: research published: 2026-07-15T00:00:00.000Z modified: 2026-07-15T00:00:00.000Z author: Adam Hafez topics: ["Content strategy"] --- # Does content length correlate with rankings and AI citations? ## The short answer Ahrefs' December 2025 study of 174,048 pages behind 1.6 million AI Overview citations found a Spearman correlation of just 0.04 between word count and citation likelihood, essentially zero. Backlinko's separate 11.8-million-result study found word count evenly distributed across top-10 positions, no meaningful edge for longer pages. The common 'write more words' advice does not hold up in either dataset. ## Key takeaways - Ahrefs' December 2025 study of 174,048 pages and 1.6 million cited URLs found a Spearman correlation of just 0.04 between word count and AI Overview citation. - More than half of AI Overview-cited pages, 53.4%, run under 1,000 words, undercutting advice to write long for AI visibility. - Backlinko's 11.8-million-result study, updated April 2025, found average page-one word count of 1,447 words evenly spread across positions 1 through 10. - Ahrefs says longer pages get cited because long content is what the web mostly publishes, not because length itself drives citation. - Both firms warn this correlation data cannot separate length as a cause from length as a byproduct of comprehensive coverage. "Write more words" is some of the oldest advice in SEO, repeated so often it reads as settled fact. Two dated correlation studies, one aimed at classic Google rankings and one aimed at AI Overview citation, both put a number on that claim instead of just asserting it, and in both cases the number is smaller than the advice implies. ## The AI-citation number: 0.04 Ahrefs published a study on 3 December 2025 that pulled 560,346 AI Overviews, identified 1,677,876 cited URLs inside them, and successfully extracted usable content for 174,048 of those pages. Across that set, the Spearman correlation between a cited page's word count and its citation was 0.04, a figure Ahrefs itself describes as essentially zero. The same dataset found 53.4% of cited pages run under 1,000 words, well short of the "comprehensive long-form guide" model that AI-search advice usually recommends. A correlation this close to zero means word count carries almost no predictive value for whether AI Overviews cite a page at all. ## What the classic-ranking data shows Backlinko's ranking-factor study, last updated 14 April 2025 and built on 11.8 million Google results, reports the average word count of a page-one result at 1,447 words. That number alone sounds like an endorsement of long content, but the same study found word count evenly distributed across positions 1 through 10: a page sitting at position 1 has no measurable word count advantage over a page sitting at position 10, once both have already reached the first page. Backlinko states directly that its design cannot explain why longer content tends to appear on page one in the first place, only that it does not appear to move a page's position once it is there. ## The shared confound both firms name Both studies point at the same alternative explanation for their own numbers: pages that cover a topic thoroughly tend to run long as a side effect, not because extra words themselves earn extra rank or citation weight. Ahrefs puts this plainly for its AI Overview data, arguing that long pages get cited because long content is simply what most publishers on a given topic produce, not because AI Overviews reward length on its own terms. Neither firm's correlational design can separate "length causes visibility" from "topics that need depth produce length," and both say so in their own published caveats rather than leaving readers to assume causation. ## Why we care Treat word count as an output of doing the work, not a target to hit before publishing. A brief that specifies "cover these five subtopics with primary sources" will naturally land wherever it lands, sometimes 600 words, sometimes 2,500, and that length is a byproduct of what the topic required, not a lever pulled to satisfy Google or an AI Overview. Padding a thin brief to hit an arbitrary word count target does not move rankings by Backlinko's own data, and does close to nothing for AI citation by Ahrefs' own data. Write to the topic's actual depth, then stop. ## Sources 1. [Short vs. Long Content in AI Overviews: The Data Says Both Work](https://ahrefs.com/blog/short-vs-long-content-in-ai-overviews/) - Ahrefs (primary) 2. [We Analyzed 11.8 Million Google Search Results. Here's What We Learned About SEO](https://backlinko.com/search-engine-ranking) - Backlinko 3. [The Long-Form Content Illusion: Why Longer Content Isn't Better](https://ahrefs.com/blog/long-form-content/) - Ahrefs --- --- title: "What Google actually names in its own ranking systems guide" url: https://seomadman.com/research/google-ranking-systems-documented section: research published: 2026-07-14T00:00:00.000Z modified: 2026-07-14T00:00:00.000Z author: Adam Hafez topics: ["Core updates", "Technical SEO"] --- # What Google actually names in its own ranking systems guide ## The short answer Google's own ranking systems guide names 17 current systems, from BERT and RankBrain to SpamBrain and site diversity, plus four retired ones including the helpful content system, now folded into core ranking. It gives each a short functional description, never a weight or formula, and it does not name NavBoost. ## Key takeaways - Google's ranking systems guide names 17 current systems and 4 retired ones, each with a one or two sentence functional description. - BERT, MUM, neural matching, passage ranking and RankBrain are the five systems the page itself labels as AI systems. - The page states plainly that the helpful content system has been retired and folded into core ranking systems, contradicting any assumption that it still runs as a separate signal. - SpamBrain is named as one system within a broader "spam detection systems" section, not as its own standalone heading. - NavBoost, the click-based re-ranking system described in DOJ trial testimony, does not appear anywhere on Google's own official systems page. SEO discourse mostly runs on what got leaked or what a witness said under oath in an antitrust trial. Less discussed is that Google also just publishes a list. The "Guide to Google Search ranking systems," maintained on Google's own developer documentation, names specific systems by name and gives each one a short, plain description of its job. It is not a spec and it is not a weight table, but it is real, it is current, and almost nobody quotes it directly. ## Systems the page labels as AI systems Five of the named systems get the same qualifier from Google: "AI system." **BERT** (Bidirectional Encoder Representations from Transformers) "allows us to understand how combinations of words express different meanings and intent." **MUM** (Multitask Unified Model) is described as capable of understanding and generating language, but the guide is explicit that it is "not currently used for general ranking," only for narrower applications such as COVID-19 vaccine information searches and featured snippet callouts. **Neural matching** understands "representations of concepts in queries and pages" and matches them to each other. The **passage ranking system** identifies individual sections of a page to judge relevance to a search more precisely than page-level matching allows. **RankBrain** helps Google "understand how words are related to concepts," so a page can rank for a query even without the exact words used in the search. **The distinction between RankBrain and neural matching is one Google draws itself, not one this piece is inferring.** Both concern understanding meaning beyond literal keyword matching, and Google lists them as separate systems with separate one-line descriptions rather than treating one as a successor to the other. ## Systems for specific ranking needs The rest of the guide's current entries handle narrower jobs rather than general language understanding. **Crisis information systems** cover both personal crises, such as suicide or poison-related queries surfacing hotline content, and wide-scale events through the SOS Alerts system. **Deduplication systems** keep near-identical pages from cluttering one results page. The **exact match domain system** stops a domain name alone, such as one built from a keyword phrase, from earning outsized ranking credit. **Freshness systems** raise newer content for queries where Google judges recency matters, its own example being a just-released movie or a recent earthquake. **Link analysis systems and PageRank** remain listed as part of Google's core ranking systems, in use "since Google first launched," though the guide says how PageRank works "has evolved a lot since then." **Local news systems** surface local sources through features like Top Stories and Local News. **Original content systems** aim to show original reporting ahead of sites that merely cite it, supported by canonical markup. **Removal-based demotion systems** downrank sites with a significant volume of valid legal removals or personal-information removal complaints. **Reliable information systems** work to surface authoritative pages, elevate quality journalism, and, when reliable information is thin, show content advisories on rapidly changing topics. The **reviews system** rewards "high quality reviews... written by experts or enthusiasts who know the topic well." The **site diversity system** generally limits results to two listings per site, treating most subdomains as part of the root domain. **Spam detection systems**, the guide says, include **SpamBrain by name** among the tools used against spam policy violations, a detail worth flagging because SpamBrain gets no heading of its own; it is named inside the spam detection section rather than listed as a standalone entry the way BERT or RankBrain are. ## What got retired, and why it matters The guide keeps a "Retired systems" section for exactly this reason: names change status, and Google says so rather than quietly dropping them. As of this page's current version, four systems are listed there: **Hummingbird**, a major 2013 ranking overhaul; **Panda**, folded into core ranking systems in 2015; **Penguin**, aimed at link spam and folded in during 2016; and, notably, the **helpful content system**, which Google's guide now describes as incorporated into its broader core ranking systems rather than continuing to operate as a separate one. Anyone still describing "the helpful content system" as a distinct, currently-running system is describing an earlier state of Google's own documentation, not its current one. ## Why we care This site already published a piece on [NavBoost](/research/navboost-doj-trial-click-signals), built entirely from DOJ trial testimony and a leaked internal document, precisely because Google has never put NavBoost on a page like this one. That gap is the honest finding here: Google maintains a real, named, publicly documented list of ranking systems, and NavBoost, described under oath by its own VP of Search as "one of the important signals," is not on it. That does not mean the guide is dishonest or that NavBoost is fabricated; it means the industry's two best public windows into Google's ranking systems, official documentation and trial disclosure, currently describe two non-overlapping sets of names, and treating either set as the complete picture overstates what either source actually offers. Read the guide for what Google is willing to name and describe in its own words, and read the NavBoost piece for what it takes a subpoena to surface. Neither is the full architecture, and Google's own page says so directly: this is "some of our more notable ranking systems," not all of them. ## Frequently asked questions ### Does Google's official systems guide mention NavBoost? No. NavBoost does not appear anywhere on the current ranking systems guide. It is known publicly only through DOJ v. Google trial testimony and a separately leaked internal document, both covered in a separate piece on this site, not through anything Google has published on its own developer documentation. ### Is the helpful content system still a separate ranking system? No, not as a standalone system. Google's guide lists it under "Retired systems," stating it was folded into the broader core ranking systems rather than continuing to run on its own. ### Does Google say how much each named system affects rankings? No. The guide gives short, plain-language functional descriptions of what each system is for, not a weight, a percentage, or a formula. Treat every description here as what the system is meant to do, not as a measurement of its influence on any given query. ## Sources 1. [A guide to Google Search ranking systems](https://developers.google.com/search/docs/appearance/ranking-systems-guide) - Google Search Central (primary) --- --- title: "Local ranking factor percentages: what's real, what's not" url: https://seomadman.com/research/local-seo-ranking-factors-verifiable section: research published: 2026-07-13T00:00:00.000Z modified: 2026-07-13T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Local ranking factor percentages: what's real, what's not ## The short answer A specific breakdown, GBP signals 32%, on-page 19%, reviews 16%, links 15%, behavioral 8%, citations 7%, circulates widely in local SEO content. It does not match Whitespark's real 2026 Local Search Ranking Factors report, which puts GBP signals at 32% but review signals at 20% and on-page at 15%. Google names only relevance, distance, and prominence. ## Key takeaways - The breakdown often quoted as GBP 32%, on-page 19%, reviews 16%, links 15%, behavioral 8%, citations 7% does not appear on whitespark.ca or brightlocal.com in that combination. - Whitespark's real 2026 chart puts GBP signals at 32%, reviews at 20%, on-page at 15%, behavioural at 9%, links at 8%, citations at 6%, personalization at 6%, and social at 4%. - That real chart is built from 47 local search experts scoring 187 individual factors from 0 to 5, so it measures practitioner consensus, not a causally measured algorithm weight. - Google's own Business Profile documentation names only three ranking factors, relevance, distance, and prominence, and discloses no percentages for any of them. - Google states directly that there is no way to request or pay for a better local ranking, which rules out any of these weights being purchasable. Search a few local SEO articles published this year and a specific breakdown keeps turning up: GBP signals are 32% of the local ranking algorithm, on-page signals 19%, reviews 16%, links 15%, behavioral 8%, citations 7%. It reads like a real, sourced chart. Whitespark and BrightLocal do run real, long-running annual local ranking factor surveys, which makes the number easy to believe without checking. This piece checked it, found what Whitespark's real chart actually says instead, and confirmed what Google itself is willing to name. ## The breakdown that circulates The 32/19/16/15/8/7 figures are usually attributed, loosely, to "Whitespark or BrightLocal 2025 data." Neither site publishes that combination. Whitespark's real, dated 2026 report does contain a chart with the same category names, GBP signals, on-page signals, review signals, link signals, behavioural signals, citation signals, plus two categories the circulating claim leaves out entirely, personalization and social signals. Its real numbers for local pack and Maps rankings are GBP signals 32%, review signals 20%, on-page signals 15%, behavioural signals 9%, link signals 8%, citation signals 6%, personalization 6%, social signals 4%. Only the GBP figure, 32%, matches. Every other number is shifted: review signals is 20% in the real chart, not 16%, on-page is 15%, not 19%, and link signals is 8%, not the 15% the circulating claim assigns it. That is not a rounding difference or an old survey year drifting slightly, it is a different set of numbers wearing the same category labels. A single correct figure sitting inside five incorrect ones is exactly the shape a plausible-sounding fabrication takes: close enough to a real source that no single number looks obviously wrong. ## What Whitespark's real report actually measures The real chart is not decorative. Whitespark's own methodology description states that "47 of the best and the brightest local search experts are invited to complete a comprehensive 2-hour survey," scoring 187 individual factors from 0 to 5 across four areas: local pack and Maps ranking impact, local organic ranking impact, conversion impact, and AI search visibility impact. The percentages in the group-weighting chart are built from those summed, ranked scores. That is a real, citable methodology, and it is also a specific kind of measurement: 47 practitioners reporting what they believe correlates with ranking, not a controlled experiment isolating what Google's live algorithm actually weighs. Google's local algorithm is not observable from outside, so no third party, however careful, can publish a causally measured weight for any local ranking factor. Whitespark's report is useful precisely because it is honest about being a consensus survey rather than something it is not. ## What Google itself documents Strip away every third-party percentage and Google's own position is short and comes with no numbers at all. Its [Business Profile documentation](https://support.google.com/business/answer/7091?hl=en) states that local results are based mainly on three factors. **Relevance** is "how well a Business Profile matches what someone is searching for." Google says complete and detailed business information helps it match a profile to the right searches. **Distance** is "how far each business is from the customer who's searching," calculated from a searcher's shared location or, absent that, from what Google can otherwise infer about where they are. **Prominence** is "how well-known a business is," including signals like inbound links and review volume; Google states plainly that "prominent places are more likely to show up in search results." Google attaches no percentage, no weighting, and no ranked order to these three. The same documentation also states there is no way to request or pay for a better local ranking, closing off the idea that any of this can be purchased outright. ## Why we care The lesson is not really about local SEO percentages specifically. It is about how a real number, one correct figure inside a real, methodologically sound survey, gets copied into a new combination with five wrong ones and keeps circulating because the source organization's name is real and its survey does exist. Whitespark's actual report is more useful than the version built from it: it tells you the categories are real, GBP signals really do lead, and it is honest that the whole exercise is 47 experts scoring what they believe matters, not a measured test of Google's code. That distinction matters for how this site treats any local ranking claim going forward: a percentage attributed to a real survey gets checked against that survey's actual, current publication before it ships, not against what a downstream blog says the survey found. Google's own three named factors, relevance, distance, and prominence, are the one part of this topic that needs no such verification, because Google is the primary source for its own algorithm. ## Frequently asked questions ### Is the "GBP signals 32%, on-page 19%, reviews 16%" local ranking breakdown real? Not as a combination. No page on whitespark.ca or brightlocal.com publishes those six numbers together. Whitespark's real 2026 chart does put GBP signals at 32%, but its other categories carry different percentages. ### Does Google publish percentage weights for local ranking factors? No. Google's Business Profile documentation names three factors, relevance, distance, and prominence, and describes each in a sentence. It has never attached a number to any of them. ### What does Whitespark's real Local Search Ranking Factors report measure? It surveys 47 named local search experts who score 187 factors from 0 to 5 across local pack, local organic, and AI search visibility. The resulting percentages reflect what those experts believe matters, not a measured causal test of Google's algorithm. ## Sources 1. [Tips to improve your local ranking on Google](https://support.google.com/business/answer/7091?hl=en) - Google Business Profile Help (primary) 2. [Local Search Ranking Factors 2026](https://whitespark.ca/local-search-ranking-factors/) - Whitespark (primary) --- --- title: "How three CTR trackers reported three different position-1 rates" url: https://seomadman.com/reports/organic-ctr-by-position-2026 section: reports published: 2026-07-11T00:00:00.000Z modified: 2026-07-11T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO", "AI search"] --- # How three CTR trackers reported three different position-1 rates ## The short answer Three independent CTR trackers published 2026 position-1 organic click-through rates that disagree by 12 points: Backlinko found 27.6% from 4 million search results, First Page Sage's meta-analysis put it at 39.8%, and Advanced Web Ranking's continuous tracker reports quarter-over-quarter shifts rather than a fixed number at all. The gap is method, not disagreement about reality. ## Key takeaways - Backlinko's analysis of 4 million Google search results found a 27.6% click-through rate at position 1, with the top three results capturing 54.4% of all clicks. - First Page Sage's 2026 meta-analysis of multiple CTR datasets reports position 1 at 39.8%, falling to 18.7% at position 2 and 1.6% by position 10. - Advanced Web Ranking's continuously updated tracker reports a quarter-over-quarter percentage-point shift across 22 industries, not one fixed baseline curve. - Position-1 estimates from the three trackers span 27.6% to 39.8%, a 12-point gap driven by different data and formats, not contradictory measurements. - Ahrefs' own by-position breakdown shows AI Overviews cut click-through rate by 58% at position 1, 50.8% at position 2, and 46.4% at position 3. Ask three trackers what click-through rate the Google's number one organic result gets and you get three different answers: 27.6%, 39.8%, and no single figure at all. Backlinko ran one large-sample analysis. First Page Sage built a meta-analysis of several outside sources. Advanced Web Ranking runs a continuous, multi-industry panel that reports quarter-over-quarter shifts rather than a fixed curve. None of the three is wrong; each answers a differently framed question, and averaging them together would produce a number none of the three trackers actually measured. ## Three curves, three methods | Tracker | Data source | Sample | Reporting format | Position 1 | | --- | --- | --- | --- | --- | | Backlinko | Semrush-aggregated Google Search Console data | 4 million search results across 1,312,881 pages and 12,166,560 queries | One-time analysis, last updated April 2025 | 27.6% | | First Page Sage | Meta-analysis of Backlinko, Sistrix, Wordstream, BrightLocal, LocalIQ, Danny Sullivan and Search Engine Journal, plus its own internal data | Not disclosed | Published May 2025, updated December 2025 | 39.8% | | Advanced Web Ranking | Its own Google Search Console-based panel across 22 industries | Millions of search terms and thousands of websites, international, split by desktop and mobile | Continuous since September 2015; reports quarter-over-quarter percentage-point change, not a fixed curve | Not published as one figure | First Page Sage's curve is the only one of the three published as a full ten-position table: 39.8% at position 1, 18.7% at position 2, 10.2% at position 3, 7.2% at position 4, 5.1% at position 5, 4.4% at position 6, 3.0% at position 7, 2.1% at position 8, 1.9% at position 9 and 1.6% at position 10. Backlinko publishes position 1 and the top-three combined share, 54.4% of all clicks, without a full per-position table. Advanced Web Ranking's tool renders an interactive curve rather than a static number, refreshed monthly since September 2015, most recently for July 2026. ## Why the numbers do not agree **They start from different data.** Backlinko's 27.6% comes from one pull of real Google Search Console accounts, aggregated through Semrush, unfiltered by SERP type: local packs, shopping carousels and other features that suppress clicks are baked into the average. First Page Sage's 39.8% is a meta-analysis that leans on Backlinko's own numbers among several other sources, plus First Page Sage's undisclosed internal data, and the company's own writeup says its figures skew toward cleaner organic SERPs with fewer competing features. A meta-analysis inherits every input study's blind spots without disclosing which ones dominate the blend, which is most of the gap between the two. **They measure different things.** Backlinko and First Page Sage each publish a static snapshot: one number per position, true as of one point in time. Advanced Web Ranking's quarterly report does the opposite. Its Q1 2026 release compares Q1 2026 averages against Q4 2025 rather than stating a baseline figure, reporting that the first five desktop positions rose by a combined 10.54 percentage points quarter over quarter while mobile position 1 fell 2.20 points, across 22 tracked industries. A tracker built to show change cannot be read as a single comparable baseline next to trackers built to show a snapshot. **Device and vertical mix are not held constant.** Advanced Web Ranking splits desktop from mobile because, in its own words, CTR runs higher on mobile at the top positions; Backlinko and First Page Sage both report a single blended figure. None of the three discloses an identical vertical mix, so a tracker weighted toward informational queries will read differently from one weighted toward commercial or local intent, even before any difference in method. ## What the AI Overview breakdown adds None of these three baseline curves accounts for AI Overviews. For that, Ahrefs' own study is the more useful source, and this site has already covered its headline finding that position-1 organic CTR fell 58% between December 2023 and December 2025 when an AI Overview appears; see [Ahrefs: AI Overviews cut position-1 CTR by 58%](/studies/ai-overviews-click-through-rate-decline) for that full comparison rather than repeating it here. The same Ahrefs report also breaks the decline down by position, a cut this site has not previously cited: -58.0% at position 1, -50.8% at position 2, -46.4% at position 3, tapering to -19.4% by position 10. Ahrefs' own framing is blunt about what that tapering means: the impact gets "less dramatic" further down the page mostly because positions 2 through 10 already start from a low click-through rate with little room left to fall. Laid against the three baseline curves above, the AI Overview effect is large enough on its own to explain most of the spread between Backlinko's 27.6% and First Page Sage's 39.8%, without needing three different trackers to disagree about anything else. ## Why we care **A position-1 CTR number without its tracker attached is not a citable fact.** Whether a deck says 27.6% or 39.8% for the top spot changes forecast traffic by roughly 40%, and the difference comes entirely from which tracker's dataset and definition of "position 1" is behind the number, not from any disagreement about how Google actually behaves. **The tracker built to show change, not a snapshot, is arguably the most honest of the three.** Advanced Web Ranking's refusal to publish one fixed curve, instead reporting how CTR moved this quarter, is a harder number to misquote in a slide than a single static percentage, even though it is less convenient to cite. The two snapshot trackers are useful for a ballpark; the quarterly tracker is useful for knowing whether that ballpark is still shrinking. ## Frequently asked questions ### Which organic CTR number should I use for position 1? Say which tracker it comes from. Backlinko's 27.6% is a single large-sample snapshot from April 2025, First Page Sage's 39.8% is a meta-analysis of several outside sources with no disclosed sample size, and Advanced Web Ranking does not publish one fixed number at all. "Organic CTR at position 1 is X%" is not a complete claim without naming the tracker and the date. ### Why is First Page Sage's number so much higher than Backlinko's? First Page Sage's figure is a meta-analysis built partly from Backlinko's own data plus several other sources, weighted toward what the site describes as cleaner organic SERPs. Backlinko's 27.6% is a single dataset pulled through Semrush from real Google Search Console accounts, unfiltered by SERP type, so it includes results crowded by ads, local packs and other features that depress clicks. ### Does any of these trackers account for AI Overviews? Not in the baseline curve. All three describe AI Overviews as a separate, large depressor of CTR rather than folding it into the position-1 figure. Ahrefs' dedicated study, covered separately on this site, is the one with a published by-position breakdown of the AI Overview effect itself. ## Sources 1. [We Analyzed 4 Million Google Search Results. Here's What We Learned About Organic CTR](https://backlinko.com/google-ctr-stats) - Backlinko (primary) 2. [Google Click-Through Rates (CTRs) by Ranking Position in 2026](https://firstpagesage.com/reports/google-click-through-rates-ctrs-by-ranking-position/) - First Page Sage 3. [Google Organic CTR Tool](https://www.advancedwebranking.com/free-seo-tools/google-organic-ctr) - Advanced Web Ranking 4. [Google CTR Stats - Changes Report for Q1 2026](https://www.advancedwebranking.com/blog/ctr-google-2026-q1) - Advanced Web Ranking 5. [Update: AI Overviews Reduce Clicks by 58%](https://ahrefs.com/blog/ai-overviews-reduce-clicks-update) - Ahrefs --- --- title: "How five llms.txt trackers reported five different adoption rates" url: https://seomadman.com/reports/llms-txt-adoption-tracker-comparison section: reports published: 2026-07-08T00:00:00.000Z modified: 2026-07-08T00:00:00.000Z author: Adam Hafez topics: ["AI search", "Technical SEO"] --- # How five llms.txt trackers reported five different adoption rates ## The short answer Five trackers published llms.txt adoption numbers in 2026, and none of them agree: Rankability found 8.7% of the top 1,000 sites, Ahrefs found 28% of its customer base, SE Ranking found 10.13% across 300,000 domains, and a Majestic Million scan found 7.4%. The gap is method, not disagreement about reality. ## Key takeaways - Five independent trackers measured llms.txt adoption in 2026 and produced results between 7.4% and 28%, because none of them measured the same population. - Rankability found 8.7% of the top 1,000 Tranco-ranked sites serve a valid file, rising to 15.8% among the 549 domains it could actually reach. - Ahrefs found 28% adoption across 137,210 customer domains, but its own report cautions that Ahrefs Web Analytics customers skew more technical than the web at large. - SE Ranking's scan of nearly 300,000 domains found 10.13% adoption and no measurable correlation between the file and AI citation frequency. - Originality.ai's monitoring of over 3 million sites recorded an 8.8x rise in llms.txt files, from 4,088 in June 2025 to 36,120 by May 2026. Ask five people what share of websites publish an llms.txt file and you get five numbers: 7.4%, 8.7%, 10.13%, 15.8%, 28%. None of them is wrong. Each one answers a different question - a different population, crawled with a different definition of "has the file" - and treating any one of them as *the* adoption rate is the actual error. ## Five counts, five populations | Tracker | Population | What counted as adoption | Result | | --- | --- | --- | --- | | Rankability | Top 1,000 sites by Tranco (traffic-based ranking), June 2026 list | HTTP 200 with plain-text content on `/llms.txt`; soft-404 HTML and empty bodies excluded | 8.7% (87/1,000); 15.8% among the 549 domains it could reach a verdict on | | SE Ranking | Roughly 300,000 domains, selection criteria not published | File detected present; validity criteria not published | 10.13% | | Ahrefs | 137,210 domains running Ahrefs Web Analytics or Bot Analytics | HTTP 200, confirmed via server logs as real Markdown rather than HTML | 28% (about 38,360 domains) | | Chris Humphrey | Top 10,000 domains in the Majestic Million, June 2026 crawl | HTTP 200 and a genuine Markdown body; 313 of 1,050 200-responses were soft-404 HTML pages and excluded | 7.4% (737 sites); only 55% of those met the full recommended structure | | Originality.ai | Continuous monitor of 3+ million sites | Not published in detail | Grew 8.8x, from 4,088 files in June 2025 to 36,120 in May 2026 | ## Why these numbers cannot be averaged together **The populations barely overlap.** A traffic-ranked top 1,000 (Rankability), a link-graph-ranked top 10,000 (Chris Humphrey), a 300,000-domain sample of unstated selection (SE Ranking), and one vendor's own customer list (Ahrefs) are four different slices of the web, and only one of them - Ahrefs - even claims to include mid-size sites that never heard of the spec. Ahrefs says so itself: "Ahrefs Web Analytics customers skew more technical and SEO-aware than the web at large," and its own report tells readers to treat the 28% figure as an upper bound, not a web-wide rate. That is the most honest sentence in any of these five studies, and it is the reason Ahrefs' number is the highest of the five by a wide margin. **"Has llms.txt" is not one definition.** Rankability and Chris Humphrey both publish the detail that matters most here: a plain HTTP 200 overcounts, because a large share of sites answer any unknown path with a styled 404 page under a 200 status. Chris Humphrey's crawl hit exactly that - 1,050 domains returned 200 for `/llms.txt`, and 313 of them were soft 404s, not files. Only the 737 that remained after excluding those counted toward his 7.4%. SE Ranking and Originality.ai report a number without publishing that filter, so their figures may or may not have the same correction applied - there is no way to check from what they've published. **The dates do not line up either.** Rankability's figure is a June 2026 Tranco list processed in August 2026. Chris Humphrey's crawl ran in June 2026. Ahrefs' server-log analysis covers May 2026. SE Ranking's study reads as late 2025. Originality.ai's 8.8x growth figure is the only one that holds population and method constant across a full year, which is what makes it a trend line rather than a single snapshot - the other four are four different snapshots of four different things, not four points on the same curve. ## Why we care **A single adoption percentage, quoted without its population and its definition, is not a citable fact.** If a pitch or a deck says "X% of websites now have llms.txt," the next question is always which tracker, which population, and which month - and, per this report, the honest answer sometimes has to be "we don't know, because that tracker didn't publish it." **The two most reusable numbers here are the two with published methodology you could rerun yourself.** Rankability's soft-404 exclusion and reachable-subset breakdown, and Chris Humphrey's Markdown-validation and quality-structure check, are the kind of disclosure that lets a reader verify the claim instead of trusting the headline - which is the same bar this site holds its own [reports](/reports) to. **None of these five trackers measured whether llms.txt does anything.** Adoption is a count of files on servers, not a signal that any answer engine reads. For that question, see our companion piece on [who actually publishes llms.txt and why](/studies/llms-txt-adoption-2026) - the file's audience problem is a separate finding from its adoption rate, and conflating the two is its own common error in [AI search](/topics/ai-search) coverage this year. ## Frequently asked questions ### Which llms.txt adoption number should I quote? None of them alone. Say which tracker, which population and which date range the number comes from, the way this report does, because "llms.txt adoption is X%" is not a complete claim on its own. ### Why do Ahrefs and Rankability disagree by 3x? Different populations. Ahrefs measured its own Web Analytics customer base, which it explicitly flags as more technical than the average site; Rankability measured a traffic-ranked top 1,000 that includes sites with no reason to know llms.txt exists. ### Is any of this growth real, or just better measurement? Originality.ai's 8.8x rise over twelve months, from 4,088 to 36,120 files across the same 3-million-site monitor, is the closest thing here to a real trend line, since it holds the population and method constant across the period rather than comparing two different trackers. ## Sources 1. [LLMS.txt Adoption: 8.7% of the Top 1,000](https://www.rankability.com/data/llms-txt-adoption/) - Rankability 2. [LLMs.txt: Why Brands Rely On It and Why It Doesn't Work](https://seranking.com/blog/llms-txt/) - SE Ranking 3. [We Analyzed 137K Sites: 97% of llms.txt Files Never Get Read](https://ahrefs.com/blog/llmstxt-study/) - Ahrefs 4. [llms.txt Adoption: Data From the Top 10,000 Sites](https://chrishumphrey.ai/research/state-of-llms-txt-2026) - Chris Humphrey (primary) 5. [LLMs.txt Tracking Study and Live Dashboard](https://originality.ai/blog/llms-txt-tracking-study) - Originality.ai --- --- title: "How many confirmed Google updates ship a year, 2015 to 2026" url: https://seomadman.com/reports/confirmed-update-frequency-2015-2026 section: reports published: 2026-07-07T00:00:00.000Z modified: 2026-07-07T00:00:00.000Z author: Adam Hafez topics: ["Core updates"] --- # How many confirmed Google updates ship a year, 2015 to 2026 ## The short answer Ahrefs' tracker counts 87 confirmed major Google updates between 2015 and year-to-date 2026, averaging six to nine a year with a 2021 spike of fourteen. Google itself reports over 4,000 total Search improvements in 2023 alone - a figure for undisclosed daily tweaks, not confirmed major updates, and the two must never be quoted as the same thing. ## Key takeaways - Ahrefs' Google Algorithm Updates History lists 87 confirmed major updates from 2015 through year-to-date 2026. - The busiest year on record is 2021 with 14 confirmed updates, driven by spam, page experience and product review updates layered on top of two core updates. - Google's own "How Search Works" page reports 700,000-plus experiments and 4,000-plus improvements to Search in 2023 - a total-changes figure, not a confirmed-update count. - The confirmed count for 2023 was 9 major updates, meaning Google's own 4,000-plus figure for that year describes roughly 450 times more changes than the confirmed-update count. - 2026 has recorded 6 confirmed updates through 18 August, on pace with the 2015-2020 average after the higher-volume 2021-2022 period. Every year someone asks how many Google updates actually happened, and every year the honest answer depends on which number you mean. Google confirms a small set of major updates by name. It also reports launching thousands of changes it never names at all. Conflating the two produces headlines like "Google changes Search 4,000 times a year" applied to a table of eight or nine named events - true of neither number. ## The confirmed count, year by year | Year | Confirmed major updates | | --- | --- | | 2015 | 6 | | 2016 | 5 | | 2017 | 4 | | 2018 | 5 | | 2019 | 8 | | 2020 | 7 | | 2021 | 14 | | 2022 | 10 | | 2023 | 9 | | 2024 | 8 | | 2025 | 5 | | 2026 (through 18 Aug) | 6 | Total: 87 confirmed updates across eleven full years plus 2026 year-to-date. The average across full years (2015-2025) is just under 8 a year. 2021 is the outlier at 14, driven by Google layering spam, page experience, product review and Core updates in the same twelve months rather than any single update running longer than usual. ## Why "confirmed major update" and "total changes" are not the same number Google's own "How Search Works" documentation states it "ran over 700,000 experiments that resulted in more than 4,000 improvements to Search" in 2023. That is Google's figure, for Google's own count of everything it shipped that year: ranking tweaks, UI changes, spam-signal adjustments, most of them small enough that no site owner could isolate one in their analytics even if they tried. The confirmed count for the same year, 2023, was 9. Google's total-changes figure for 2023 is roughly 450 times the confirmed-update count for that year. Neither number is wrong - they measure different things. The 4,000-plus figure answers "how much does Google touch Search in a year." The count in the table above answers "how many of those touches did Google name publicly, with a start date you can check your own traffic against." Only the second number is something a site owner can use to date a ranking change; the first cannot be attributed to anything specific because Google never says which sites, queries or signals each of those thousands of changes affected. ## Why we care If you are trying to explain a traffic move, the table above is the list of dates worth checking your [Search Console](/topics/search-console) export against - not the 4,000-plus figure, which names no dates and no sites. When a client or a headline cites "Google changes its algorithm thousands of times a year" as justification for treating every unexplained ranking shift as an update, this is the distinction to bring back to the conversation: thousands of changes happened, none of them named, and the [core update](/topics/core-updates) count for that same year was in the single or low double digits. ## Frequently asked questions ### How many confirmed Google updates happen in a typical year? Across 2015 to 2026 year-to-date, the count per year ranges from 4 (2017) to 14 (2021), with most years landing between 5 and 10. There is no fixed cadence; the number moves with how much Google chooses to name and announce. ### Is Google's "4,000 improvements a year" figure the same as the update count in this table? No. That figure, from Google's own "How Search Works" page, counts every launched change to Search in 2023, most of it undisclosed and untraceable to any single ranking shift. The 9 confirmed major updates for 2023 in this table are the subset Google named publicly. ### Why does the count for 2026 stop at 6? Because this report was compiled on 11 September 2026 and only counts updates confirmed by that date. The August 2026 spam update is the most recent entry; anything after this report's publish date is not reflected here. ## Sources 1. [Google Search Status Dashboard](https://status.search.google.com/summary) - Google (primary) 2. [How Google Search Works - Rigorous testing](https://www.google.com/search/howsearchworks/how-search-works/rigorous-testing/) - Google (primary) 3. [Google Algorithm Updates History](https://ahrefs.com/google-algorithm-updates) - Ahrefs --- --- title: "Mobile-first indexing, from 2016 test to 2023 completion" url: https://seomadman.com/reports/mobile-first-indexing-completion-status section: reports published: 2026-07-06T00:00:00.000Z modified: 2026-07-06T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO", "Indexing"] --- # Mobile-first indexing, from 2016 test to 2023 completion ## The short answer Google tested mobile-first indexing from November 2016 and announced the rollout complete on 31 October 2023. Its current documentation says most Googlebot crawl requests now use the smartphone crawler, and warns that a mobile page with less content than its desktop equivalent loses that content from the index entirely. ## Key takeaways - Google first announced it was testing mobile-first indexing on 4 November 2016, on the Google Webmaster Central Blog. - The site-by-site rollout ran publicly from March 2018 through repeated deadline extensions in 2019 and 2020. - Google announced the transition was complete on 31 October 2023, in a post titled "Mobile-first indexing has landed". - Google's current Googlebot documentation states the majority of crawl requests now use the smartphone crawler, and a minority use the desktop crawler. - Google warns that a mobile page with less content than its desktop equivalent has that content excluded from indexing, not merely deprioritized. Mobile-first indexing is not a 2026 story so much as a finished one: Google announced the switch essentially complete in October 2023, nearly seven years after the first public test. What is current in 2026 is Google's own documentation describing what that switch means day to day, and the parity failure mode it still warns sites about. ## The rollout, in Google's own dated posts Google first announced it was testing mobile-first indexing on 4 November 2016, on the Search Central (then Webmaster Central) blog. The idea: since most searches happen on mobile devices and most sites still built desktop-first, Google would start basing indexing on the mobile version of a page's content rather than the desktop version, for the sites it selected for the experiment. The public, site-by-site rollout followed in "Rolling out mobile-first indexing," published in March 2018, and continued through further posts in May 2019 (mobile-first indexing set as the default for newly created domains) and March 2020 ("Announcing mobile first indexing for the whole web"). Google extended its own deadlines more than once as sites it had flagged were not yet ready; a July 2020 post and a November 2021 update both describe the same pattern of pushing the remaining sites over individually rather than on a single fixed date. Google declared the transition complete on 31 October 2023, in a post titled "Mobile-first indexing has landed." Google did not publish a completion percentage. The post instead describes a small remaining category of sites - those broken on mobile devices, blocking the mobile crawler via robots.txt, or redirecting all mobile traffic to a homepage - that Google would keep crawling with the legacy desktop Googlebot indefinitely, because there is no usable mobile version to index. Search Engine Land's coverage of the same announcement quotes the post's framing directly: the "trek to Mobile First Indexing is now complete." ## What it means in practice, and the common failure mode Google's current mobile-first indexing documentation states the mechanism plainly: Google crawls, indexes and ranks using the mobile version of a page's content, fetched with the smartphone crawler. Its Googlebot documentation adds the crawl-side consequence of that: for most sites, the majority of Googlebot crawl requests now use the smartphone crawler, with a minority still using the desktop crawler for the exceptions described above. The parity requirement is the part that produces real ranking losses. Google's documentation is explicit that structured data must match between mobile and desktop versions of a page, that title elements and meta descriptions must be equivalent across both, and - most consequentially - that "if your mobile site has less content than your desktop site" the fix is updating the mobile version so its primary content is equivalent to desktop's. Content that exists only on the desktop version of a page is not indexed at a discount; under mobile-first indexing it is not indexed at all, because Google never sees it. Sites that once built a stripped-down "mobile view" as a performance shortcut, or that still hide secondary content behind a mobile accordion that never loads in the DOM, are describing exactly the failure mode this documentation names. ## Why we care Mobile-first indexing is not a project with an open action item for most sites anymore; Google finished the rollout in 2023 and now treats it as the default mechanism, not a migration in progress. The item worth auditing in 2026 is narrower and easy to miss: pull up your own mobile rendering with Search Console's URL Inspection tool and compare it, section by section, against desktop. Any text, image, or structured-data block present on desktop and absent on mobile is invisible to Google, not merely deprioritized - and that gap is the one Google's own documentation still calls out by name. ## Frequently asked questions ### When did Google finish moving all sites to mobile-first indexing? Google announced completion on 31 October 2023, in a Search Central blog post titled 'Mobile-first indexing has landed.' Google did not publish a completion percentage; it described a small remaining set of sites - ones broken on mobile, blocking mobile crawling, or redirecting mobile visitors to a homepage - as staying on desktop crawling indefinitely. ### Does Google still use Googlebot Desktop at all? Yes, for a minority of requests. Google's Googlebot documentation states the majority of crawl requests now use the smartphone crawler and a minority use the desktop crawler, without giving an exact split. ## Sources 1. [Mobile-first indexing](https://developers.google.com/search/blog/2016/11/mobile-first-indexing) - Google Search Central Blog (primary) 2. [Rolling out mobile-first indexing](https://developers.google.com/search/blog/2018/03/rolling-out-mobile-first-indexing) - Google Search Central Blog (primary) 3. [Mobile-First Indexing by default for new domains](https://developers.google.com/search/blog/2019/05/mobile-first-indexing-by-default-for) - Google Search Central Blog (primary) 4. [Announcing mobile first indexing for the whole web](https://developers.google.com/search/blog/2020/03/announcing-mobile-first-indexing-for) - Google Search Central Blog (primary) 5. [Mobile-first indexing has landed - thanks for all your support](https://developers.google.com/search/blog/2023/10/mobile-first-is-here) - Google Search Central Blog (primary) 6. [Mobile-first indexing best practices](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing) - Google Search Central (primary) 7. [What Is Googlebot](https://developers.google.com/search/docs/crawling-indexing/googlebot) - Google Search Central (primary) 8. [Google says mobile-first indexing is complete after almost 7 years](https://searchengineland.com/google-says-mobile-first-indexing-is-complete-after-almost-7-years-434011) - Search Engine Land --- --- title: "x-default's real history: what Google has actually said, on record" url: https://seomadman.com/research/hreflang-x-default-google-statements section: research published: 2026-07-06T00:00:00.000Z modified: 2026-07-06T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # x-default's real history: what Google has actually said, on record ## The short answer Google introduced hreflang's x-default value on 10 April 2013, not October 2013 as sometimes repeated. John Mueller has said hreflang does not change rankings. Gary Illyes wrote in May 2023 that x-default also aids URL discovery and conversions. Google's current documentation, updated 22 December 2025, is the authoritative version today. ## Key takeaways - Google's real x-default announcement was published 10 April 2013 by Pierre Far, not October 2013 as some pieces claim. - John Mueller has said on record, from a Google hangout reported 18 January 2022, that hreflang does not change which pages rank, only which version is shown. - Gary Illyes wrote in a 8 May 2023 Google blog post that x-default also helps with URL discovery and with redirecting unconverted visitors, beyond its original fallback role. - Google's current localized-versions documentation, last updated 22 December 2025, calls x-default a recommended value for a fallback page, not a requirement. - Where an older statement and the current documentation could both be checked, this piece treats the current documentation as the deciding version. x-default is one hreflang value, and Google has explained it in public at least three separate times over more than a decade: the value's own introduction in 2013, a widening of its role in 2023, and the plain ranking clarification that runs through Google's guidance on hreflang in general. Each of those is real and dated. This piece lays out the wording each time, in order, and then says which version is authoritative today: the current documentation, not the oldest or the most quotable statement. ## The real history, in order **10 April 2013 - the introduction.** Google's own announcement, "Introducing 'x-default hreflang' for international landing pages," was posted to the Search Central Blog by Pierre Far, then a Webmaster Trends Analyst. The post's own timestamp reads Wednesday, 10 April 2013, which matters because a "Google introduced hreflang x-default in October 2013" claim circulates in some hreflang guides; it does not match the primary source. The 2013 post frames x-default narrowly: a home page that shows a country selector, or that dynamically changes content by geolocation or Accept-Language headers, should carry `hreflang="x-default"` so Google's algorithms know that page "doesn't target any specific language or locale and is the default page when no other page is better suited." **18 January 2022 - the ranking clarification.** John Mueller has repeated, across several Google Search Central hangouts, that hreflang does not affect ranking. The clearest dated instance found for this piece is a Google hangout reported by iloveseo.net on 18 January 2022: "the hreflang wouldn't change the ranking of these pages, it would just make sure that the preferred version is shown in the search results." That statement addresses hreflang as a whole rather than naming x-default by name, and no on-record quote isolating x-default specifically from the ranking question was located, so this piece reports the broader statement rather than inventing a narrower one that was not said. **8 May 2023 - the role widens.** Gary Illyes posted "How x-default can help you" to the Google Search Central Blog on Monday, 8 May 2023, opening with "a few recent issues made us realize that the hreflang x-default value is potentially underused." The post adds two uses past the 2013 framing: x-default URLs "may be used for URL discovery," useful on large sites where not every localized URL is well linked internally, and x-default can redirect a visitor a page cannot convert, Illyes' own example being a German-only essay sending non-German speakers to a language selector "where they might actually convert in some other way." Neither use appears in the 2013 post; both are real additions, on record, a decade later. ## What Google's current documentation says now Of the three, only one is documentation rather than a blog post, and it is the one that should settle any disagreement between the others. Google's localized-versions page, last updated 22 December 2025, defines the reserved value directly: "used when no other language/region matches the user's browser setting." It calls x-default "recommended for specifying the fallback page for users whose language settings don't match any of your site's localized versions," which keeps the 2013 post's fallback framing but drops its narrower "home page" scope. It then adds a line that resolves the tension between the 2013 post and the 2023 widening: "you can use the x-default value for any page, it was designed for language selector pages and so it will work best with those." That is the current, working position: x-default is not limited to home pages, but it was built for language and country selectors, and other uses inherit whatever weaker signal follows from a page that was not designed with x-default in mind. None of the three older statements is contradicted by the current page. The 2013 post's narrower scope reads as an early framing later relaxed, not as a factual error; Illyes' 2023 additions read as genuinely new information layered onto the original mechanism; and nothing in the current documentation calls x-default, or hreflang generally, a ranking signal, which is consistent with what Mueller said in 2022. Where this piece had to choose which version to state as fact, it chose the current documentation, dated December 2025, over any older post. ## Why we care A single hreflang value having three separate, real, dated explanations across thirteen years is not a contradiction to untangle so much as a normal history to trace honestly, which is different from treating whichever quote is easiest to find as if it were still current. This site's companion piece on [hreflang error prevalence](/research/hreflang-error-prevalence-2026) traced a different failure mode: statistics attributed to Google or to a named study that turn out not to exist on either source's own site. The failure here would be smaller but similar, an old date or an old scope getting repeated past the point where the current documentation already moved past it. Implementing x-default correctly today does not require any of the three historical statements above; it requires the current documentation's own wording, which this site's [hreflang tag generator](/tools/hreflang-tag-generator) builds its reciprocity and self-reference checks against directly, rather than against a 2013 blog post or a 2023 follow-up that Google itself has since folded into the page that matters. ## Frequently asked questions ### When did Google actually introduce the x-default hreflang value? On 10 April 2013, in a Google Search Central Blog post titled "Introducing x-default hreflang for international landing pages," posted by Pierre Far. A widely repeated "October 2013" date does not match the post's own timestamp. ### Does x-default improve rankings? No. John Mueller has said, in a statement reported 18 January 2022, that hreflang changes which version of a page is shown, not whether it ranks. Google's current documentation never describes x-default as a ranking factor either. ### Is x-default still just for redirecting home pages? Not only that. Gary Illyes' May 2023 Google Search Central Blog post added that x-default URLs can aid URL discovery and can redirect visitors a page cannot convert, widening the original 2013 framing. ### What does Google's documentation say about x-default today? As of its 22 December 2025 update, Google's localized-versions page calls x-default a recommended value for specifying a fallback page, notes it works with any page but "was designed for language selector pages," and never calls it required. ## Sources 1. [Tell Google about localized versions of your page](https://developers.google.com/search/docs/specialty/international/localized-versions) - Google Search Central (primary) 2. [Introducing "x-default hreflang" for international landing pages](https://developers.google.com/search/blog/2013/04/x-default-hreflang-for-international-pages) - Google Search Central Blog (primary) 3. [How x-default can help you](https://developers.google.com/search/blog/2023/05/x-default) - Google Search Central Blog (primary) 4. [Google Says Again: Hreflang Won't Change Ranking](https://iloveseo.com/seo/google-says-again-hreflang-wont-change-ranking/) - iloveseo.net --- --- title: "How often AI Overviews actually appear, January 2025 to April 2026" url: https://seomadman.com/reports/ai-overviews-serp-prevalence-2026 section: reports published: 2026-07-04T00:00:00.000Z modified: 2026-07-04T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # How often AI Overviews actually appear, January 2025 to April 2026 ## The short answer Semrush found AI Overviews rose from 6.49% of tracked keywords in January 2025 to a peak near 24.61% in July, then eased to 15.69% by November. A separate Semrush study of commercial-intent keywords found AI Overview appearance grew a further 71% on average through April 2026, with jobs and education queries exceeding 60%. ## Key takeaways - Semrush found AI Overviews appeared on 6.49% of its 10 million-plus tracked keywords in January 2025. - That share peaked near 24.61% in July 2025 before easing back to 15.69% by November 2025, according to Semrush. - A follow-up Semrush study of 600,000-plus keywords found commercial-intent AI Overview appearance grew 71% on average between November 2025 and April 2026. - By April 2026, more than 60% of high-CPC jobs and education keywords in that Semrush panel triggered an AI Overview. - Conductor measured a separate 21.9 million-query sample at 25.11% prevalence for a four-week window in September and October 2025, well above Semrush's nearby figure. Ask how often Google shows an AI Overview and you will get a different number depending on who tracked it. Semrush, which runs the largest published keyword panel on this question, has now tracked the same phenomenon for more than a year, and its own numbers alone show a share that tripled, peaked and pulled back - before rising again in the segment that pays for search traffic. ## What Semrush's own tracking shows Semrush's first study followed more than 10 million keywords in its database from January through November 2025, checking each one for AI Overview presence. AI Overviews appeared on 6.49% of those keywords in January 2025. That share climbed through the first half of the year to a peak of about 24.61% in July, then fell back to 15.69% by November - roughly a two-thirds retreat from the peak inside four months. Semrush followed up with a second study, this one narrower and more recent: more than 600,000 keywords from its U.S. desktop database, tracked from November 2025 through April 2026 and split by industry, search intent and cost per click. Commercial-intent SERPs saw AI Overview appearance grow by 71% on average over that window, while transactional-intent SERPs actually fell 5%. By April 2026, jobs and education keywords - a high-CPC category - had more than 60% AI Overview coverage, the highest reported figure in either Semrush study. These two studies measure different things: the first is an overall panel share, the second is growth within commercial-intent keywords plus one segment's absolute figure. Neither extends the other into a single continuous line, and Semrush has not published a full-panel percentage for any month after November 2025. ## Why the numbers do not agree across trackers Conductor, an independent competitor in this space, analyzed 21.9 million Google searches over a four-week window from 15 September to 12 October 2025 and found 5.5 million of them - 25.11% - generated an AI Overview. That sits close in time to Semrush's July 2025 peak of 24.61% but well above the 15.69% Semrush reported for November, the month nearest to Conductor's own window. The gap is not an error in either study. Semrush and Conductor pull from different keyword panels, different industries, different geographies and different detection logic for what counts as an AI Overview actually rendering. A tracker weighted toward informational, long-tail queries will report a lower share than one weighted toward the health and finance categories where AI Overviews appear most often. Treat every prevalence figure, including the ones in this piece, as specific to its own panel rather than as a universal constant - and never average two trackers' numbers together as if they measured the same population. ## Why we care A single prevalence percentage tells you almost nothing about your own site. What matters is whether AI Overviews appear on the specific keywords you rank for, and both Semrush studies agree on the direction: commercial and high-CPC queries are gaining AI Overview coverage faster than the overall panel average. Check your own [Search Console](/topics/search-console) query list against which of your terms sit in a high-CPC, commercial-intent category - those are the ones where a July-2025-sized swing is now the more likely outcome, not the exception. ## Frequently asked questions ### What is the real percentage of searches that show an AI Overview? There is no single answer. Semrush's 10 million-keyword panel measured 15.69% in November 2025 after a July peak of 24.61%; Conductor's separate 21.9 million-query sample measured 25.11% for a September to October 2025 window. Both are real, both are correctly measured, and they still disagree because they track different keywords with different tools. ### Is AI Overview prevalence still rising in 2026? For commercial-intent keywords, yes - Semrush's follow-up study found a 71% average increase in appearance between November 2025 and April 2026, with jobs and education queries passing 60%. That is a different metric than the overall panel share reported for 2025, so read it as a trend within a segment, not a replacement figure for the full-panel percentage. ### Why do AI Overview trackers disagree so much? Each one defines its own keyword panel, geography, device and login state, and each uses its own detection logic for what counts as "an AI Overview appeared." Semrush, Conductor and every other tracker are measuring the same phenomenon through different windows, so a single month can produce numbers a factor of two apart. ## Sources 1. [Semrush AI Overviews Study: What 2025 SEO Data Tells Us About Google's Search Shift](https://www.semrush.com/blog/semrush-ai-overviews-study/) - Semrush (primary) 2. [AI Overviews are expanding across commercial intent search [Study]](https://www.semrush.com/blog/ai-overviews-commercial-search-study/) - Semrush (primary) 3. [The 2026 AEO / GEO Benchmarks Report](https://www.conductor.com/academy/aeo-geo-benchmarks-report/) - Conductor --- --- title: "HTTPS as a Google ranking signal in 2026" url: https://seomadman.com/research/https-ranking-signal-2026 section: research published: 2026-07-03T00:00:00.000Z modified: 2026-07-03T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # HTTPS as a Google ranking signal in 2026 ## The short answer Google confirmed HTTPS as a ranking signal in 2014, calling it a very lightweight factor affecting fewer than 1% of queries, then folded it into page experience, which does not directly affect rankings. Firefox Telemetry now shows 83.7% of pageloads over HTTPS globally, and Let's Encrypt holds a 67.5% certificate authority market share, making HTTPS baseline rather than differentiator. ## Key takeaways - Google's 2014 announcement described HTTPS as a very lightweight ranking signal affecting fewer than 1% of global queries. - Google's page experience documentation states plainly that signals beyond Core Web Vitals do not directly affect rankings. - Firefox Telemetry recorded 83.67% of global pageloads over HTTPS as of 10 September 2026, per Let's Encrypt's own stats page. - W3Techs measured Let's Encrypt's SSL certificate authority market share at 67.5% of websites on 11 September 2026. - Google has never published a numeric weight for HTTPS, so near-universal adoption is what actually erodes its power to differentiate pages. Twelve years ago Google said HTTPS would help you rank, and hedged that statement so carefully it still reads as an understatement today. The company has never walked the announcement back, and it has never strengthened it in public either. What has changed is not Google's language but the web underneath it: HTTPS went from a minority protocol to the default, which quietly settles the practical question even where the ranking question stays open. ## What Google actually said in 2014 The announcement is short and specific. On 7 August 2014, Google's Search Central blog, under the byline of Zineb Ait Bahajji and Gary Illyes, confirmed that HTTPS had become a ranking factor after months of internal testing. The company's own characterization of its strength has not been improved on since: "For now it's only a very lightweight signal, affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content, while we give webmasters time to switch to HTTPS." The post left the door open to strengthening the signal over time, as an incentive for adoption rather than a description of a current ranking mechanism. ## Twelve years later, still lightweight Google's current page experience documentation is the closest thing to an update. It asks site owners to self-assess whether "pages are served in a secure fashion" as one input among several, alongside Core Web Vitals, mobile-friendliness and the absence of intrusive interstitials. But the same documentation draws a sharp line: beyond Core Web Vitals, it states, other page experience aspects do not directly help a site rank higher in search results. HTTPS sits on the side of that line that Google says does not move rankings by itself. It still matters for user trust and for protecting the connection, which the documentation frames as aligned with what ranking systems reward indirectly, but that is a different claim than a direct ranking boost, and Google has not made the stronger claim since 2014. ## What the adoption data shows now Whatever weight the HTTPS signal carries, it increasingly has little left to differentiate. Let's Encrypt's own stats page, sourced from Firefox Telemetry as a 14-day moving average, put the share of pageloads served over HTTPS at 83.67% globally as of 10 September 2026, rising to 96.23% for USA users and 94.48% for Japan users. Let's Encrypt itself reported 683.5 million active certificates and roughly 7.65 million new certificates issued per day on that date. Separately, W3Techs' SSL certificate authority survey, dated 11 September 2026, measured Let's Encrypt as the certificate authority behind 64.2% of all websites it tracks, a 67.5% share of the certificate authority market once sites with no recognized authority are excluded. Both figures describe adoption near or above the point where a comparison between two competing pages would find them equally covered. ## Why we care The honest summary has not changed in over a decade, only its practical stakes have. Google confirmed HTTPS as a ranking signal, called it very lightweight at launch, and has published no larger number since. That alone would argue against chasing HTTPS as a ranking lever. What has changed is the adoption curve: with most of the web already on HTTPS, the signal has less and less room to separate one page from another, because the comparison it was designed to break ties on is now a comparison between two pages that both qualify. Serve HTTPS because a plaintext site is a liability and a trust failure, not because it is a ranking strategy. If a site is still on HTTP in 2026, that is the finding worth acting on, not the size of the signal. ## Sources 1. [HTTPS as a ranking signal](https://developers.google.com/search/blog/2014/08/https-as-ranking-signal) - Google Search Central (primary) 2. [Page experience and Search ranking](https://developers.google.com/search/docs/appearance/page-experience) - Google Search Central (primary) 3. [Let's Encrypt Stats](https://letsencrypt.org/stats/) - Let's Encrypt 4. [Usage Statistics and Market Share of SSL Certificate Authorities for Websites](https://www.w3techs.com/technologies/overview/ssl_certificate) - W3Techs --- --- title: "How Google's scaled-content spam enforcement moved through 2026" url: https://seomadman.com/reports/spam-policy-enforcement-2026 section: reports published: 2026-07-02T00:00:00.000Z modified: 2026-07-02T00:00:00.000Z author: Adam Hafez topics: ["Core updates", "Technical SEO"] --- # How Google's scaled-content spam enforcement moved through 2026 ## The short answer Google's spam policy defines scaled content abuse by outcome, not production method: mass pages that fail to help users, however they were made. Google revised the policy on 15 May 2026 to cover manipulation of AI Overviews and AI Mode, then ran spam updates in June and August that analyst Glenn Gabe documented hitting programmatic and AI-generated content sites. ## Key takeaways - Google's spam-policies page defines scaled content abuse as pages generated "for the primary purpose of manipulating search rankings and not helping users," whatever produced them. - Google revised its spam policy on 15 May 2026 to cover manipulating generative AI responses, extending scaled content abuse to AI Overviews and AI Mode. - Google confirmed two spam updates in 2026, one in June and one in August, the second running roughly two and a half days per the Search Status Dashboard. - Analyst Glenn Gabe of GSQi documented four blinded case studies from the August update, including a 1.5-million-URL site and a site that lost over 200,000 queries. - Google publishes no official count of pages or sites actioned for spam; every traffic figure here comes from third-party analysis of visible ranking movement. Google's spam policy has said the same thing since before 2026: scaled content abuse is about outcome, not tooling. What changed this year is the surface area the policy covers and how visibly Google enforced it. Between the March 2026 core update and the August 2026 spam update, the industry's read on that enforcement came almost entirely from independent case-study work, because Google itself does not publish the numbers. ## What the policy actually says Google's spam-policies page defines scaled content abuse as "many pages... generated for the primary purpose of manipulating search rankings and not helping users," and is explicit that the test is "no matter how it's created." Generative AI is listed as one method among several - alongside scraping, automated transformation, and stitching content together - not as a prohibited category on its own. A site can publish AI-written pages and stay clear of the policy; the policy is triggered by scale without editorial value, whatever produced it. On 15 May 2026, Google revised the policy to add a line explicitly covering "attempting to manipulate generative AI responses in Google Search," extending existing categories - scaled content abuse, site reputation abuse, link spam, cloaking - to AI Overviews and AI Mode rather than creating a new one. A page built to be cited in an AI answer through the same manipulative patterns Google already prohibited in classic rankings is now unambiguously in scope for the same enforcement. ## What enforcement looked like on the ground Google confirmed two spam updates in 2026: one in June, and one that started 18 August and finished roughly two and a half days later, on 21 August, per the Search Status Dashboard. Spam updates re-apply existing policy rather than re-scoring the index the way a core update does, so a site hit by one has a specific practice to point to, not a general quality verdict. Analyst Glenn Gabe of GSQi published four blinded case studies from the August update, each tied to a scaled or AI-generated content pattern: a programmatic, AI-generated site in an ultra-YMYL niche; a thin Amazon affiliate site built substantially with AI-generated content; a 1.5-million-URL site, roughly 85% programmatic, hit across every section; and a site using scaled content abuse alongside misleading redirects. Reported losses ranged from just over 14,000 queries on the affiliate site to more than 200,000 queries on the YMYL programmatic site. None of these figures come from Google; they are Gabe's read of each site's own visible query data, and he named them as such. ## The limit of what can be said here Google has never released a page-count or site-count for spam enforcement, in 2026 or any other year. The Search Status Dashboard confirms that an update ran and for how long; it says nothing about how many URLs it touched. That gap is why this report leans on Gabe's named, attributed case studies rather than an aggregate percentage: a range presented as "typical impact" without a named source and a stated sample is not a figure this site will publish, however often it circulates in search results and forum threads. ## Why we care If a content programme on your site scales production - AI-written, scraped, or templated - the policy test that matters is whether a human reader would call an individual page worth publishing on its own, not whether the tooling that made it was AI. Before the next spam update lands, audit by practice rather than by page: identify anything published at a volume no editorial process reviewed, and decide whether it would exist if search traffic were removed from the calculation. That is the same question Gabe's case studies answer for the sites he named, and it is the one Google's own wording points to before any update arrives. ## Frequently asked questions ### Does Google's spam policy prohibit AI-generated content? No. Google's own wording is explicit: scaled content abuse is 'typically focused on creating large amounts of unoriginal content that provides little to no value to users, no matter how it's created.' AI production is one listed example of scaling, not a separate ban. ### Does Google publish how many pages or sites it has actioned for spam? No. Google confirms spam-update start and end dates on its Search Status Dashboard but does not release a count of pages removed or sites demoted. Traffic-impact figures in this report come from independent analysts reading public ranking data, not from a Google transparency report. ## Sources 1. [Spam policies for Google web search](https://developers.google.com/search/docs/essentials/spam-policies) - Google Search Central (primary) 2. [Google's August 2026 Spam Update - Scaled Content Abuse, AI Content, Programmatic Content, Thin Affiliates, And More [Case Studies]](https://www.gsqi.com/marketing-blog/august-2026-google-spam-update-case-studies/) - GSQi (Glenn Gabe) 3. [Google confirms spam policies apply to AI Overviews and AI Mode](https://searchengineland.com/google-updates-search-spam-policies-to-clarify-it-applies-to-generative-ai-responses-477657) - Search Engine Land --- --- title: "What Google's own Discover documentation actually requires" url: https://seomadman.com/reports/discover-technical-eligibility-requirements section: reports published: 2026-06-30T00:00:00.000Z modified: 2026-06-30T00:00:00.000Z author: Adam Hafez topics: ["Content strategy"] --- # What Google's own Discover documentation actually requires ## The short answer Google's own Discover documentation requires images at least 1200 pixels wide with more than 300,000 total pixels, paired with the max-image-preview:large meta setting, to be eligible for large-image treatment. It also names clickbait, sensationalism, and withheld context as reasons Discover will not recommend a page, and states no special structured data is required. ## Key takeaways - Google's Discover documentation sets an image floor of at least 1200 pixels wide with more than 300,000 total pixels, shown alongside a 16x9 example. - That image size only matters combined with the max-image-preview:large setting; without it, Discover will not use a large image treatment at all. - Google names clickbait and sensationalism specifically, describing tactics that use misleading or exaggerated details or that cater to morbid curiosity, titillation, or outrage. - Discover will withhold recommendations from content that hides crucial information needed to understand what it is about, even if the page is otherwise eligible. - Google's page states no special structured data is required for eligibility; schema.org markup or an og:image tag only controls which image gets picked. Most Discover advice sites describe impact after the fact: which pages gained, which dropped, which update caused it. Google's own Discover documentation reads differently. It is a checklist of what has to be true about a page before Discover will consider surfacing it at all, and its exact wording rarely survives being paraphrased. ## The image requirement, exactly as Google states it Google's page sets a specific floor: images should be "at least 1200 px wide" with "high resolution of more than 300,000 total pixels," illustrating this with a 16x9 example image at 1280x720 pixels, which comes to 921,600 total pixels. That size requirement is written to work alongside the `max-image-preview:large` setting, either the meta robots tag or a corresponding HTTP header. Without that setting present, Discover does not apply a large-image treatment to the page regardless of how the image itself is sized, so the pixel floor and the meta setting function as a pair, not two independent options. Google's page also states plainly that no special tags or structured data are required for basic Discover eligibility. Where it does make a recommendation, it is narrower than eligibility: use either schema.org markup or an `og:image` meta tag to tell Google which image on the page to prefer, which is a control over image selection, not a gate on whether the page can appear at all. ## Google's documented content policies for Discover Beyond formatting, Google's Discover page names specific content behaviors it screens for, in its own words. It tells publishers to "avoid clickbait and similar tactics to artificially inflate engagement by using misleading or exaggerated details," and separately to "avoid sensationalism tactics that manipulate appeal by catering to morbid curiosity, titillation, or outrage." A third, related standard: content that withholds crucial information required to understand what it is about is treated the same way, even short of outright misleading claims. The page also lists content types Discover "might not recommend" outright: job applications, petitions, forms, code repositories, and satirical content. These are named as categories, not as penalties for a specific violation, so a page can be well-formed and non-misleading and still sit outside Discover's surface simply by falling into one of them. For what these documented policies looked like in practice during a real ranking change, not just as written rules, see our report on [Google's February 2026 Discover-only core update](/news/discover-first-dedicated-algorithm-update/), which covers the verified before-and-after impact data from that rollout. This piece is limited to what Google's own eligibility page states; it does not repeat that impact analysis. ## Why we care The two halves of this documentation matter for different reasons. The image spec is a pass or fail technical check: a publishing workflow that ships images narrower than 1200 pixels, or that omits `max-image-preview:large`, has ruled itself out of Discover's large-image treatment before any editorial judgment about the article applies. The content policies are the opposite, a set of editorial standards Google states it applies regardless of how technically correct the page is. Treat both as gates to clear before publishing, not diagnostics to run after traffic disappoints. ## Frequently asked questions ### Is 1200 pixels a hard cutoff for Discover images? Google's page states an image should be at least 1200 pixels wide with more than 300,000 total pixels, but this requirement only takes effect when the page also carries the max-image-preview:large setting. Without that setting, Discover can still surface the page, just without the larger image treatment the size requirement is written for. ### Does Discover need its own structured data? No. Google's page states plainly that no special tags or structured data are required for basic eligibility. It recommends schema.org markup or an og:image meta tag only as a way to control which image Discover picks, not as an eligibility requirement. ### Does this replace general Google content quality guidance? No, and it should not be read as a substitute for it. This piece only covers what Google's Discover-specific documentation states directly, because that page is a distinct eligibility surface from ranking guidance for regular Search. ## Sources 1. [Get your content on Google Discover](https://developers.google.com/search/docs/appearance/google-discover) - Google Search Central (primary) --- --- title: "What Google has actually said about Google Lens search volume" url: https://seomadman.com/reports/google-lens-visual-search-growth section: reports published: 2026-06-30T00:00:00.000Z modified: 2026-06-30T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # What Google has actually said about Google Lens search volume ## The short answer Google has disclosed Google Lens's own monthly search volume several times since 2021: more than 12 billion by June 2023, nearly 20 billion by October 2024, and a further 65% year-over-year jump reported at Google I/O 2025. Widely repeated claims that "22%" or "26%" of Google queries are image-based trace to no Google source and are excluded here. ## Key takeaways - Google's own blog said Lens handled more than 12 billion visual searches a month in June 2023, up roughly 4x from about 3 billion in 2021. - By October 2024, Google's blog put the figure at nearly 20 billion visual searches every month, a further 67% climb in about sixteen months. - At I/O 2025, Pichai said Lens grew 65% year over year with 100 billion-plus visual searches that year, and Google's blog separately cited 1.5 billion monthly Lens users. - No blog.google post or named Google statement supports the widely repeated claims that Google Images drives 22% of all web searches or that 26% of Google queries are image-based. - Google discloses these figures itself at events and in blog posts without ever publishing the measurement methodology or panel behind any of them. Google is one of the few sources that can actually say how much visual search happens, because Lens sits inside Search and Google controls the count. It has shared that number in public several times since 2021, and the figures line up into a real growth curve - but a lot of what circulates as "Google Lens statistics" online is not that curve. It is invented precision from aggregator sites, and this piece draws the line between the two. ## What Google itself has said, in order Google's product blog said in June 2021 that Lens was being used "over three billion times per month," a figure widely reported at the time as roughly a 4x increase from the prior year. By June 14, 2023, Google's own blog post "8 ways Google Lens can help make your life easier" put the number at "more than 12 billion visual searches on Lens" every month - itself described elsewhere by Google as a 4x increase in the two years since. On October 3, 2024, a Google Search blog post titled "Ask questions in new ways with AI in Search" raised that figure again: "Google Lens is now used for nearly 20 billion visual searches every month." That is roughly a 67% increase over the prior disclosure, in about sixteen months. Google changed how it reported the metric at its I/O 2025 keynote on May 20, 2025. Sundar Pichai told the audience that Lens "grew 65% year over year, with more than 100 billion visual searches already this year" - a cumulative, year-to-date figure rather than a monthly rate, reported by outlets including TechCrunch since no blog.google post repeats the line verbatim. The same week, Google's own "AI Mode in Google Search" blog post cited a related but different number: "more than 1.5 billion people are using [Lens] to search what they see every month," a count of monthly users rather than monthly searches. Read together, the three 2023-2025 data points show real, sustained growth; the two 2025 figures show Google shifting toward growth-rate and user-count framing rather than repeating a single monthly-search number. ## What we could not verify, and left out Two claims recur across dozens of SEO-statistics roundup pages: that "Google Images drives 22% of all web searches" and that "image-based searches represent 26% of all Google queries." Neither traces to blog.google, a Google executive quote, a named study or any dated source. One version of the 26% claim even attaches itself to a distorted restatement of Google's own Lens numbers - citing "20 billion visual searches per month as of March 2026, a 43% increase from 14 billion in 2024" - which contradicts the dated figures above (12 billion in mid-2023, not 14 billion in 2024) and appears to be an aggregator's guess dressed up as precision. Per this site's sourcing rule, both the 22% and the 26% figures are excluded rather than repeated. ## Why we care The verified numbers still tell a clear story: Google has never reported a decline in Lens usage, and every dated disclosure from 2021 through 2025 points the same direction. That is reason enough to treat product imagery and on-page images as a ranking surface in their own right, not an afterthought. Descriptive file names, specific alt text and structured [product data](/topics/structured-data) are what Lens and Google's other image-matching systems have to work with when they decide what a photo shows and what page to attach it to - the same signals that matter for regular image search matter here too. What this report cannot tell you is how much of your own traffic comes through Lens specifically, because Google has never broken out that channel in [Search Console](/topics/search-console); until it does, treat visual-search readiness as good image-SEO practice rather than a metric you can track in isolation. ## Frequently asked questions ### How many visual searches does Google Lens handle per month? The last figure Google itself has published is "nearly 20 billion visual searches every month," stated on blog.google in October 2024. Google has not published a full-panel monthly figure since. At its May 2025 I/O keynote it instead cited a 65% year-over-year growth rate and more than 100 billion visual searches for the year to that point - a different metric shape than a monthly count. ### Is it true that 22% of all web searches or 26% of Google queries are image-based? No traceable Google statement supports either figure. Both numbers appear only on SEO-statistics roundup sites with no named source, no date and no methodology, and one version of the claim even misstates Google's own published numbers. Treat both as unverified until a primary source surfaces. ### Why doesn't Google publish how it measures visual search volume? Google has never disclosed a methodology, panel definition or geography breakdown for its Lens usage figures. Every number in this piece comes directly from a Google blog post or an on-stage statement by a Google executive, not from independent measurement, and none of it can be audited against raw data. ## Sources 1. [8 ways Google Lens can help make your life easier](https://blog.google/products/google-lens/google-lens-features/) - Google (primary) 2. [Google updates: AI-Organized Search, Google Lens, and more](https://blog.google/products-and-platforms/products/search/google-search-lens-october-2024-updates/) - Google (primary) 3. [AI Mode in Google Search: Updates from Google I/O 2025](https://blog.google/products-and-platforms/products/search/google-search-ai-mode-update/) - Google (primary) 4. [Sundar Pichai shares some Google Lens stats](https://techcrunch.com/snippet/3009713/sundar-pichai-shares-some-google-lens-stats/) - TechCrunch --- --- title: "Google's AI Mode terms for French publishers" url: https://seomadman.com/news/ai-mode-france-publisher-terms section: news published: 2026-06-29T00:00:00.000Z modified: 2026-06-29T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # Google's AI Mode terms for French publishers ## The short answer On 29 June 2026, Google told French press publishers by letter that AI Mode and AI Overviews would reach France, with a communicated deadline of 23 September. Google committed to a publisher opt-out, separate reporting of AI-generated impressions, and compensation under neighboring rights for the roughly 450 publishers already covered by that framework. ## Key takeaways - Google sent French press publishers a letter on 29 June 2026 confirming AI Mode and AI Overviews would launch in France by 23 September. - Google committed to an opt-out so a publisher can keep its content out of AI features without losing classic search visibility. - Google committed to reporting AI-generated impressions separately from classic search impressions. - Roughly 450 publishers already covered by France's neighboring-rights agreement were promised additional compensation for content used in AI Mode. - Google activated the features early, on 22 July, and press alliance APIG filed a competition complaint on 11 August arguing the rollout breached earlier commitments. Google told French press publishers, in a letter dated 29 June 2026, that AI Mode and AI Overviews were coming to France, with a deadline it communicated as 23 September. The letter set out three commitments publishers had been asking for since neighboring-rights disputes over news snippets began years earlier: an opt-out, separate traffic reporting, and compensation. ## What Google promised **An opt-out that does not cost classic ranking.** Publishers can keep their content out of AI Mode and AI Overviews without it affecting how they rank in standard search results, addressing the all-or-nothing tradeoff publishers had objected to. **AI impressions reported separately.** Google committed to breaking out impressions generated by AI features from impressions generated by classic search, so a publisher can see the two surfaces apart in its own reporting rather than one number hiding the other. **Neighboring-rights pay extended to AI Mode.** The roughly 450 publishers already covered by France's neighboring-rights agreement were told the mechanism would extend to content reused in AI-generated answers, on top of the compensation that agreement already covers for snippets in classic search. ## Why neighboring rights are the mechanism here France's neighboring-rights law gives press publishers a claim when a platform reuses their content, and Google has been through this fight before: a 500,000 euro-scale case became a 250 million euro fine in 2024 for falling short of a 2022 compensation agreement. Extending that same mechanism to AI Mode, rather than negotiating a separate scheme, keeps the new dispute inside a framework French regulators already enforce. That history is also why the June letter did not settle anything. Google activated AI Mode and AI Overviews in France on 22 July, weeks ahead of the September date it had communicated, and on 11 August the press alliance APIG filed a complaint with France's competition authority, arguing the rollout used publisher content without the prior authorization or dedicated compensation the 2022 commitments require. ## Why we care The commitments are a template, not a settled outcome: an opt-out, separated AI reporting, and neighboring-rights pay is the shape other markets should expect Google to offer as AI Mode expands, and the fact that publishers are still disputing compliance in the one market where the terms are written down is the signal to watch. If you operate in France, check whether your neighboring-rights payments now itemize AI Mode separately from snippet compensation, and if you operate elsewhere, this is the language to ask for before a launch reaches you. ## Frequently asked questions ### When do AI Mode and AI Overviews actually apply in France? Google communicated 23 September 2026 as the deadline in its 29 June letter to publishers, but activated the features early, on 22 July 2026. ### Can a French publisher block its content from AI Mode without losing normal search visibility? Google committed to an opt-out that removes a publisher's content from AI features while leaving its classic search ranking untouched, according to the terms it communicated to publishers. ### Does neighboring-rights compensation now cover AI-generated answers? Google told the roughly 450 publishers already covered by France's neighboring-rights agreement that the mechanism would extend to content reused in AI Mode and AI Overviews, on top of existing snippet compensation. ## Sources 1. [300 French newspapers file complaint over Google AI Overviews](https://searchengineland.com/french-newspapers-complaint-google-ai-overviews-484631) - Search Engine Land (primary) 2. [Google faces French complaint as AI summaries cut traffic up to 38%](https://ppc.land/google-faces-french-complaint-as-ai-summaries-cut-traffic-up-to-38/) - PPC Land --- --- title: "How much link equity does a 301 redirect actually pass?" url: https://seomadman.com/reports/redirect-link-equity-retention-estimates section: reports published: 2026-06-29T00:00:00.000Z modified: 2026-06-29T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # How much link equity does a 301 redirect actually pass? ## The short answer No source, including Google, has published a measured figure for how much link equity a 301 redirect passes. Google's statements, from Matt Cutts in 2013 to Gary Illyes in 2016, say redirects lose "no" or "identical" equity to a link, without a number. Moz's widely quoted 90-99% range is an estimate, not a study, and Semrush avoids a figure entirely. ## Key takeaways - Google has never published a specific percentage for how much link equity a 301 redirect passes, in any statement traced for this report. - Matt Cutts said in 2013 that PageRank lost through a 301 is "currently identical" to what dissipates through a normal link, without quantifying either figure. - Gary Illyes tweeted in July 2016 that "30x redirects don't lose PageRank anymore," a stronger claim than Cutts' 2013 statement, still with no number attached. - Moz's redirection guide states a 301 "passes between 90-99% of link equity," the most specific figure in circulation, but does not publish a study or crawl behind it. - Semrush's own 301 redirect guide says search engines transfer "almost all" ranking power, choosing the same unquantified language Google itself uses. Ask how much link equity a 301 redirect passes and every answer sounds precise: 90%, 99%, "almost all," "no loss at all." None of them is a measurement. Nobody outside Google can observe how PageRank moves through Google's index, which means every figure in this piece, including the ones attributed to Google itself, is a public statement of position rather than a number anyone verified from the outside. ## What Google has actually said, and never said Google's own position has moved twice on the record, and neither move came with a percentage. In a February 2013 video, Matt Cutts said "the amount of PageRank that dissipates through a 301 is currently identical to the amount of PageRank that dissipates through a link" - a statement that a redirect loses no more than an ordinary hyperlink does, without saying how much a link loses either. In July 2016, Gary Illyes went further in a tweet: "30x redirects don't lose PageRank anymore," dropping even the comparison to a regular link. John Mueller has since added the caveats that matter in practice: redirecting to a topically unrelated page risks Google treating it as a soft 404, and a chain of several redirects behaves worse than one clean hop, even though no single hop is said to have a fixed cost. Put together, this is thirteen years of consistent Google messaging in one direction - "close to full value, and increasingly no measurable loss" - and zero years of Google naming a number. That gap is not an oversight. PageRank's internal calculation is one of the things Google has never published in disclosed detail for any purpose, redirects included, so a percentage was never on the table to begin with. ## The industry's own estimates: a number and a shrug The one specific figure that circulates widely, "301 redirects pass 90-99% of link equity," comes from Moz's own redirection guide. Moz states the range as guidance, not as a finding from a disclosed crawl or study, and does not publish the methodology behind it. The figure also predates Illyes' 2016 statement by several years, which is part of why it keeps getting cited alongside claims that contradict it: the 90-99% range and "redirects don't lose PageRank anymore" cannot both be describing the same current reality, and only one of the two sources says how it arrived at its position (neither, in fact - Moz gives a range with no visible study, and Google gives a tweet with no visible study either). Semrush, by contrast, declines to give a number at all. Its own 301 redirect guide says search engines "typically transfer almost all of the old page's ranking power to the new page," choosing the same kind of unquantified language Google itself uses rather than repeating Moz's range or proposing a figure of its own. That is itself informative: a tool vendor with its own crawl data and a direct commercial reason to publish a precise number chose not to. ## Why we care **Every number in this piece describes a public position, not a measurement.** No source cited here, Google included, has published a disclosed methodology for isolating how much authority a 301 redirect passes versus every other signal that changes when a URL moves. Treat "90-99%," "almost all," and "no loss anymore" as three ways of saying the same thing with different confidence, not as three competing facts to average. **The actionable guidance sits underneath the disagreement, not inside it.** Every source agrees, without needing a number, that a 301 to a genuinely equivalent page passes most or all of a page's authority, and that the real risk is a redirect to an unrelated destination, which Google has said on the record it may not credit at all. That distinction is worth more than any percentage in this piece. **A single redirect's estimated pass-through rate is a separate question from what a real redirect chain does to traffic.** This report covers the per-hop estimate; a documented, measured outcome from one migration belongs in our [case studies](/studies) rather than in a comparison of publicly stated positions like this one, and the two should never be quoted as if they answer the same question. ## Frequently asked questions ### What percentage of link equity does a 301 redirect pass, according to Google? Google has never published a percentage. The closest thing to an official position is Gary Illyes' 2016 statement that 30x redirects "don't lose PageRank anymore," which is a claim about direction, not a measured figure. ### Is the 90-99% figure from Ahrefs or Moz? Moz. The exact range traces to Moz's own redirection guide, which states it as guidance rather than as the result of a published study or disclosed crawl, and it predates Google's 2016 statement that redirects no longer lose PageRank at all. ### Should I still worry about link equity loss when redirecting a page? The real risk documented on the record is a redirect to a topically unrelated page, which Google has said it may treat as a soft 404 and not credit at all, not a fixed percentage tax on every redirect. ## Sources 1. [30x redirects don't lose PageRank anymore](https://x.com/methode/status/757923179641839616) - Gary Illyes (Google) (primary) 2. [Google: There is no PageRank dilution when using 301, 302, or 30x redirects anymore](https://searchengineland.com/google-no-pagerank-dilution-using-301-302-30x-redirects-anymore-254608) - Search Engine Land 3. [Google: PageRank Dilution Through A 301 Redirect Is A Myth](https://searchengineland.com/google-pagerank-dilution-through-a-301-redirect-is-a-myth-149656) - Search Engine Land 4. [What Is a 301 Redirect? (Redirection Guide)](https://moz.com/learn/seo/redirection) - Moz 5. [301 Redirects: What They Are & How to Implement Them](https://www.semrush.com/blog/301-redirects/) - Semrush --- --- title: "Search Console configures Performance reports from a prompt" url: https://seomadman.com/news/search-console-ai-config-tool section: news published: 2026-06-28T00:00:00.000Z modified: 2026-06-28T00:00:00.000Z author: Adam Hafez topics: ["Search Console", "AI search"] --- # Search Console configures Performance reports from a prompt ## The short answer Search Console's Performance report now accepts natural-language requests. Describe the query, page, device, country or date-range filter you want, and AI-powered configuration converts it into the report settings and applies them for you. Google rolled it out as an experimental feature on 4 December 2025, starting with a limited set of websites before expanding further. ## Key takeaways - Google announced AI-powered configuration for the Search Console Performance report on Thursday, 4 December 2025. - A natural-language prompt is converted into filters, comparisons and metric selections instead of manual setup. - The tool covers three tasks, applying filters, configuring date-range comparisons, and choosing which of the four available metrics to display. - It works only inside the Performance report for Search results and is not available for Discover or News reports. - Google says the tool cannot sort tables or export data, and it can misinterpret a request, so every suggested filter needs a manual check before you trust the numbers. Search Console's Performance report has always rewarded people who knew exactly which filter, comparison and metric to click through to reach an answer. Google's new AI-powered configuration, announced on Thursday, 4 December 2025, replaces that clicking with a sentence: describe the analysis, and the report configures itself. ## What the tool actually does Google frames the feature narrowly, as configuration rather than analysis. It handles three tasks: applying filters by query, page, country, device, search appearance or date range; setting up comparisons, including custom date ranges, without the usual manual steps; and choosing which of the four available metrics, Clicks, Impressions, Average CTR and Average Position, to display based on what was asked. Google's own examples show the range it is built for: "Show me queries on phone searches that contain the word 'sports' in the last 6 months" for targeted filtering, "Compare traffic for my pages that contain '/blog' in this quarter to the same quarter last year" for a complex comparison, and "Show me the Average CTR and Average Position of my queries in Spain in the last 28 days" for metric selection. Each prompt produces a suggested configuration that a user then applies, rather than a written answer. ## Where it stops The scope is deliberately narrow. It supports only the Performance report for Search results, not Discover or News. Google also warns that "AI can sometimes misinterpret requests," and tells users to review the suggested filters before analysing the data rather than trusting them outright. And the feature is built for configuration alone: it cannot sort the table or export data, so both still route through the report's existing controls. Access is limited for now. Google is rolling out AI-powered configuration "to a limited set of websites" and says it will expand gradually, so the prompt box will not appear in every account's Performance report yet. ## Why we care A tool that turns "compare mobile queries containing sports this quarter to last" into the correct filter, comparison and metric stack removes a real source of friction for anyone who audits Performance data regularly, but it changes nothing about what the underlying numbers mean. The report still counts clicks, impressions, CTR and position the way it always has, so the accuracy warning is the part worth keeping: a prompt that gets misread produces a report that looks authoritative and measures the wrong thing. ## Frequently asked questions ### Does this replace manual filters in Search Console? No. Manual filters still work exactly as before. AI-powered configuration is an added entry point that turns a written request into the same filter, comparison and metric controls, so it saves clicks rather than replacing the underlying report. ### Which Search Console reports support it? Only the Performance report for Search results. Google's announcement states plainly that it is not available for Discover or News reports, so those two still require manual configuration. ### Can the tool sort or export data? No. Google describes the feature as scoped to configuration only, meaning filters, comparisons and metric selection. Sorting the table and exporting data are outside what it does, so both still need the existing report controls. ## Sources 1. [Streamline your Search Console analysis with the new AI-powered configuration](https://developers.google.com/search/blog/2025/12/ai-powered-configuration) - Google Search Central Blog (primary) 2. [Google Search Console tests "AI-powered configuration" to create dynamic reports](https://searchengineland.com/google-search-console-tests-ai-powered-configuration-to-create-dynamic-reports-465637) - Search Engine Land --- --- title: "Bot traffic passes human traffic on Cloudflare's network" url: https://seomadman.com/news/bot-traffic-passes-human-traffic section: news published: 2026-06-26T00:00:00.000Z modified: 2026-06-26T00:00:00.000Z author: Adam Hafez topics: ["AI search", "Technical SEO"] --- # Bot traffic passes human traffic on Cloudflare's network ## The short answer Cloudflare CEO Matthew Prince said on 3 June 2026 that bot traffic had overtaken human traffic on Cloudflare's network, automated requests for HTML pages at roughly 57 percent against 43 percent from humans. He had forecast that crossover for 2027, at SXSW in March. Cloudflare's own blog confirmed the threshold in July: AI training now drives most crawler activity. ## Key takeaways - Cloudflare CEO Matthew Prince said on 3 June 2026 that automated traffic passed human traffic on Cloudflare's network for the first time. - The split runs close to 57 percent bot against 43 percent human for worldwide HTTP requests to HTML pages, per Cloudflare's own reporting. - Prince had forecast that crossover for 2027 at SXSW in March 2026, so it arrived roughly eighteen months early. - Cloudflare's July 2026 blog post reports that AI training crawlers now account for 52 percent of crawler requests, up from 22 percent in spring 2025. - For site owners, server logs and crawl-budget decisions increasingly describe non-human traffic as the majority case, not the exception. Cloudflare CEO Matthew Prince said on X on 3 June 2026 that automated traffic had overtaken human traffic on Cloudflare's network for the first time. Worldwide HTTP requests for HTML pages now run close to 57 percent bot against 43 percent human, and Prince had not expected that line to cross until 2027. ## What Prince said, and what changed Prince had put a date on this before. At SXSW in March 2026 he forecast that bot traffic would exceed human traffic online by 2027. It arrived roughly eighteen months earlier than that, and he said as much publicly when the crossover showed up in Cloudflare's own numbers. The company's July 2026 blog post on the agentic internet confirmed the same threshold in its own words: more than half of traffic on the internet is now non-human. The figure is a request-share measurement, not a count of distinct bots or sessions. It describes what share of HTML page requests hitting Cloudflare's network came from automated clients over a given period, sampled the same way Cloudflare tracks any other traffic composition metric on Radar. ## The crawler mix behind the number Cloudflare's July post also broke the bot share down by what the crawler was doing. AI training requests made up 52 percent of crawler activity in June 2026, up sharply from 22 percent in spring 2025. Mixed-use crawlers, the kind that blend search, agent browsing and training in one client, accounted for more than 36 percent. Crawling for classic search indexing alone was already a small and shrinking share of the total by comparison. That breakdown matters more to a publisher than the headline split does. A site's logs mixing training, search and agent traffic under one "bot" label hides which category is actually driving the load, and which one is worth spending crawl budget or server capacity to accommodate. ## Why we care Server logs, analytics dashboards and crawl-budget planning were all built on an assumption that humans are the majority case and bots are the exception to filter out. Cloudflare's own numbers say that assumption no longer holds on its network, and the shift arrived faster than the company that tracks it expected. A technical SEO reading raw traffic totals without separating human sessions from AI training, search and agent crawlers is now reading a number that is, more often than not, describing something other than a person. ## Frequently asked questions ### Does the 57 percent figure cover all internet traffic, or just Cloudflare's network? Just Cloudflare's network, worldwide HTTP requests to HTML pages that pass through its infrastructure. Cloudflare sits in front of a large share of the web, but not all of it, so the exact split elsewhere will differ even if the trend line matches. ### Is all of that bot share AI crawlers? No. It spans AI training crawlers, AI search and answer bots, and older categories such as uptime monitors and legacy scrapers. Cloudflare's own breakdown puts AI training requests at 52 percent of crawler activity in June 2026, up from 22 percent in spring 2025, ahead of the other AI crawler categories. ## Sources 1. [Content Independence Day, one year on: building the business model for the agentic Internet](https://blog.cloudflare.com/agentic-internet-bot-report/) - Cloudflare Blog (primary) 2. [Cloudflare: Bots now make up 57% of webpage requests](https://searchengineland.com/cloudflare-bots-webpage-requests-479608) - Search Engine Land 3. [Online bot traffic will exceed human traffic by 2027, Cloudflare CEO says](https://techcrunch.com/2026/03/19/online-bot-traffic-will-exceed-human-traffic-by-2027-cloudflare-ceo-says/) - TechCrunch 4. [Bots have now passed human traffic online, Cloudflare boss laments](https://www.tomshardware.com/tech-industry/artificial-intelligence/bots-have-now-passed-human-traffic-online-cloudflare-boss-laments-says-agentic-traffic-wasnt-expected-to-eclipse-real-people-until-next-year) - Tom's Hardware --- --- title: "Featured snippet stats: which numbers are real, and which aren't" url: https://seomadman.com/research/featured-snippets-what-is-verifiable section: research published: 2026-06-25T00:00:00.000Z modified: 2026-06-25T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO", "Content strategy"] --- # Featured snippet stats: which numbers are real, and which aren't ## The short answer Circulating featured-snippet numbers (23.7%, 35%, and 19% prevalence; 41.2% of voice searches) trace to no named, dated source with disclosed methodology. Ahrefs' real 2017 study of 100k keywords found snippets in 12.29% of queries, averaging 8.6% of clicks against 19.6% for the result beneath. Ahrefs' 2025 study shows AI Overviews have since cut snippet visibility 64%. ## Key takeaways - The commonly cited "23.7% of all search results pages" featured snippet figure traces only to secondary aggregator sites, none of which name a tracker, sample size, or date. - Ahrefs' real, dated study (29 May 2017, ~100k keywords for CTR, ~14M for prevalence) found featured snippets in 12.29% of queries, not 23.7%, 35%, or 19%. - That same Ahrefs study found a position-1 featured snippet captured about 8.6% of clicks on average, against 19.6% for the organic result sitting directly beneath it. - The "41.2% of voice searches return a featured snippet" claim doesn't match Backlinko's real 2018 study: 40.7% of voice answers came from a page that also held a snippet. - Google's own documentation describes the featured snippet mechanism and opt-out controls but publishes no prevalence or CTR statistic at all. Search "featured snippet statistics" and the same handful of numbers recur across dozens of posts: snippets appear in 23.7% of search results, or 35%, or 19%, depending which post you land on; featured snippet CTR is 35.1%, or an older Ahrefs figure of 8.6%; and 41.2% of voice searches return a featured snippet. The spread between the low and high prevalence claims is nearly 2x. This piece traces each number to whatever it claims as a source, keeps the ones that check out, and drops the ones that don't. ## The prevalence numbers that don't check out None of 23.7%, 35%, or 19% traces to a named, dated study with disclosed methodology. The 23.7% figure appears in aggregator posts that cite each other rather than a tracker; one repeats it alongside a claimed "19.2% in 2025" prior-year figure, also unsourced, that would itself contradict the unrelated "19%" claim circulating elsewhere as a current number. The 35% figure turns out to be two different things wearing the same digits: a 35.1% click-share result from a 3,500-respondent self-report survey run by Engine Scout in April 2022, which asked people about their perceived clicking behavior rather than measuring actual SERP click logs, and a separate, unrelated Ahrefs data point about one domain's snippet-triggering queries falling 35% in six months. Neither is a general featured-snippet prevalence rate, and neither matches how it gets cited. The 19% figure has no disclosed source at all; it does not match either of Ahrefs' two real, dated prevalence numbers below. ## What Ahrefs actually measured, twice Ahrefs has published two real, dated, disclosed studies that bracket this topic eight years apart. **29 May 2017, ~100k keywords for CTR, ~14 million of a 112 million keyword database for prevalence.** Featured snippets appeared in 12.29% of queries. Where a snippet was present, the snippet itself captured an average 8.6% of clicks, the organic result sitting directly beneath it captured 19.6%, and a normal #1 result with no snippet present above it captured 26%. That last comparison is the study's real finding: a featured snippet did not just add a new result, it took clicks that would otherwise have gone to position one and redistributed most of them to position two instead. **22 July 2025, 1 million randomly selected US desktop SERPs.** Featured snippet visibility fell from 15.41% in January 2025 to 5.53% in June 2025, a 64% relative decline, correlated at -0.91 with the growth of AI Overviews over the same window. This is the study that actually answers whether the 2017 numbers still describe today's SERP: they describe a layout that six in ten of its own featured-snippet queries no longer produce. ## What Google's own documentation says [Google's featured-snippet documentation](https://developers.google.com/search/docs/appearance/featured-snippets) describes the mechanism, not a rate. It states that Google's systems determine algorithmically whether a page would make a good featured snippet, that a site owner cannot manually mark or request one, and that a page can opt out entirely with a nosnippet rule or reduce its odds with a shorter max-snippet setting. No click-through percentage and no share-of-queries statistic appears anywhere in it. Any claim that attributes a specific CTR or prevalence figure to Google itself is attributing a number Google has not published. ## The voice search claim, traced "41.2% of voice searches return a featured snippet" does not match the study it most plausibly descends from. Backlinko's real, dated voice search study, published 28 February 2018 from an analysis of 10,000 Google Home results, found that 40.7% of voice search answers came from a page that also held a featured snippet in desktop search results. That is a narrower and different claim: it says a correlation existed between a page's featured-snippet status and its odds of being read aloud by Google Home, not that four in ten voice searches directly surfaced a snippet on screen. The 41.2% figure appears to be drift from the real 40.7%, close enough to look like a citation and different enough not to be one. ## Why we care The through-line across all four unverifiable claims is the same: a real number existed somewhere in the chain, and repetition sanded off its edges until the source, the date, and the exact question it answered all fell away, leaving only a percentage that sounds precise enough to trust. That matters more than usual here because the underlying SERP has genuinely changed: Ahrefs' own tracking shows featured snippet prevalence fell 64% in the first half of 2025 as AI Overviews expanded, so a 2017 CTR figure, real or not, describes a search results page that most featured- snippet queries no longer produce. Publishing a number without its source doesn't just risk being wrong today; it risks staying uncorrected after the SERP it described has moved on. Anyone citing a featured-snippet statistic should be able to name the tracker, the sample, and the date, or should say plainly that no such source could be found. ## Frequently asked questions ### Is the "23.7% of search results have a featured snippet" statistic real? No named, dated primary source was found for it. It circulates only through secondary SEO blog posts that restate each other, none of which cites a tracker, a sample size, or the study it supposedly came from. ### What is the real featured snippet click-through rate? Ahrefs' 2017 study of about 100k keywords found the featured snippet itself captured roughly 8.6% of clicks on average, while the organic result directly beneath it captured roughly 19.6%. No comparably disclosed, current study was found to replace this dated figure. ### Does 41.2% of voice searches really return a featured snippet? No. The real study this likely descends from, Backlinko's 2018 analysis of 10,000 Google Home results, found 40.7% of voice answers came from a page that also happened to hold a featured snippet in desktop search, a correlation, not a direct capture rate, and a different number. ### Has Google ever published its own featured snippet CTR or prevalence number? Not in its developer documentation. Google describes how featured snippets are selected and how to opt out of them, but does not publish a click-through rate or a percentage of queries that trigger one. ## Sources 1. [Ahrefs' Study Of 2 Million Featured Snippets: 10 Important Takeaways](https://ahrefs.com/blog/featured-snippets-study/) - Ahrefs (primary) 2. [How SERP Features Have Evolved in the AI Era](https://ahrefs.com/blog/how-serp-features-have-evolved-in-the-ai-era) - Ahrefs (primary) 3. [Featured Snippets and Your Website](https://developers.google.com/search/docs/appearance/featured-snippets) - Google Search Central (primary) 4. [Voice Search SEO Study: Results From 10,000 Voice Searches](https://backlinko.com/voice-search-seo-study) - Backlinko (primary) 5. [Featured Snippets Study: Results From 3,500+ Internet Users](https://enginescout.com.au/featured-snippets-study/) - Engine Scout --- --- title: "llms.txt and robots.txt have two separate, unrelated standards tracks" url: https://seomadman.com/news/w3c-llms-txt-standardization-draft section: news published: 2026-06-24T00:00:00.000Z modified: 2026-06-24T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # llms.txt and robots.txt have two separate, unrelated standards tracks ## The short answer Blog posts this year describe a June 2026 W3C draft formalizing llms.txt and giving it precedence over robots.txt. We could not find that draft on w3.org. What W3C actually has is a tracking issue opened in April 2025, still marked an early-stage investigation. A separate, real IETF working group standardizes robots.txt-adjacent AI signals and is not about llms.txt. ## Key takeaways - Jeremy Howard of Answer.AI proposed llms.txt on 3 September 2024 as a community convention, never a W3C or IETF submission. - The W3C's only documented engagement with llms.txt is GitHub issue 506, opened 27 April 2025 and still labeled an early-stage investigation. - We could not locate the June 2026 W3C working draft that multiple blog posts describe by name, and no page on w3.org matches that description. - The IETF's AI Preferences working group is real, chartered 7 January 2025, and it standardizes preference signals attached to robots.txt, a different project from llms.txt. - Nothing here changes ranking or crawling behavior today, since neither effort has shipped a document any crawler is bound to follow. A claim has been circulating since around June 2026: the W3C has published a working draft that formalizes llms.txt, adding a versioning header, a strict markdown subset and, most notably, giving llms.txt precedence over robots.txt when the two conflict. We went looking for the draft itself. We could not find it, and the two real standards efforts nearby are not the one being described. ## What llms.txt actually is Jeremy Howard, of Answer.AI and fast.ai, proposed llms.txt on 3 September 2024. The idea is a markdown file at a site's root, `/llms.txt`, listing a site's most important pages with one-line descriptions so a language model can navigate a large site within a limited context window. Howard's own post frames it as a convention, comparable to robots.txt or sitemap.xml in spirit but not affiliated with either. It was never submitted to the W3C or the IETF. Our own count of 60 major sites found 14 serving one, concentrated among [SEO vendors and developer platforms](/studies/llms-txt-adoption-2026), not publishers. ## What the W3C has actually done with it The W3C's Technical Strategy Pipeline is where the organization logs proposals it is watching before any working group forms around them. [Issue 506 in the w3c/strategy repository](https://github.com/w3c/strategy/issues/506), opened 27 April 2025 and labeled "AI", covers llms.txt. Its own text calls the proposal "in an early stage" and notes it "does not introduce any new format." As of this writing that issue is still open, with no linked working draft, no community group charter and no Technical Report. We searched w3.org's own Technical Reports index and found nothing matching the "AI Crawler Guidance Standardization" title that several blog posts attribute to a June 2026 publication, and none of those posts link to the document they describe. We are treating that specific claim as unverified and are not repeating its details as fact. ## The IETF effort is real, and it is a different project The IETF's AI Preferences working group, AIPREF, was chartered on 7 January 2025 and has an approved charter on the [IETF datatracker](https://datatracker.ietf.org/doc/charter-ietf-aipref/). Its scope is standardizing vocabulary for AI-related content preferences, such as distinguishing crawling for search retrieval from crawling for model training, and attaching that vocabulary to robots.txt, the file defined by RFC 9309, and to HTTP headers. That work is active and citable, and we covered its two current Internet-Drafts in detail [in a separate piece](/news/ietf-aipref-robots-txt-successor). It has no connection to llms.txt's page-listing format: one project is about what a crawler is permitted to do, the other is about which pages a model should read first. ## Why we care The two efforts get blended into one story because they both touch the boundary between robots.txt and AI crawlers, and a confident blog post is easier to write than a github.com issue is to read. For a technical reader, the distinction matters: AIPREF is a chartered IETF working group building toward an RFC, while llms.txt's only W3C footprint is a single tracking issue still at the investigation stage. Neither has produced a document a crawler is obligated to follow, so nothing here changes what you should ship in [robots.txt](/tools/robots-and-llms-txt-generator) today. If a vendor cites the June 2026 W3C draft specifically, ask them for the URL: we looked and could not find one. ## Frequently asked questions ### Is llms.txt now a W3C standard? No. The only W3C artifact we could verify is a tracking issue in the w3c/strategy repository, opened in April 2025 and still marked as an early-stage investigation. That is several steps before a working draft, and far short of a Recommendation. ### Does llms.txt now override robots.txt? We found no primary source for that claim. It appears in blog posts describing an unverified June 2026 W3C draft, but no W3C working draft, community group or Technical Report matching that description exists on w3.org as of this writing. ### What is the IETF AI Preferences group actually doing? It is standardizing how AI-related preferences get attached to content and to robots.txt, things like distinguishing crawl-for-training from crawl-for-retrieval. It has nothing to do with llms.txt's page-listing format. ## Sources 1. [llms.txt (W3C Technical Strategy Pipeline tracking issue)](https://github.com/w3c/strategy/issues/506) - W3C (primary) 2. [AI Preferences (aipref) working group charter](https://datatracker.ietf.org/doc/charter-ietf-aipref/) - IETF (primary) 3. [/llms.txt: a proposal to provide information to help LLMs use websites](https://www.answer.ai/posts/2024-09-03-llmstxt.html) - Answer.AI (primary) 4. [Dataset: AI crawler policies and llms.txt across 60 sites](https://seomadman.com/data/ai-crawler-policies.json) - SEO Madman --- --- title: "Google removes FAQ rich results from Search" url: https://seomadman.com/news/faq-rich-results-removed section: news published: 2026-06-22T00:00:00.000Z modified: 2026-06-22T00:00:00.000Z author: Adam Hafez topics: ["Structured data", "Technical SEO"] --- # Google removes FAQ rich results from Search ## The short answer Google stopped showing FAQ rich results in Search on 7 May 2026, ending a phase-out that began with an August 2023 restriction to authoritative government and health sites. FAQPage markup remains a valid Schema.org type and causes no harm left in place, but produces no visible Google feature. Other crawlers, including Bingbot and PerplexityBot, still read it. ## Key takeaways - Google's own documentation confirms FAQ rich results stopped appearing in Search on 7 May 2026. - Google will drop the FAQ search appearance filter, rich result report and Rich Results Test support in June 2026, and Search Console API support in August 2026. - Google did not publish a blog post explaining the removal, only a notice added to its structured data documentation. - The change completes a three-year phase-out that began in August 2023, when FAQ rich results were restricted to authoritative government and health sites. - FAQPage remains a valid Schema.org type, and crawlers outside Google, including Bingbot and PerplexityBot, still read it even though Google's classic rich result is gone. Google has stopped showing FAQ rich results in Search. The change took effect on 7 May 2026, according to a notice Google added to its own structured data documentation, and it closes out a phase-out that started in August 2023. The feature is gone from the results page; the schema itself is not gone from the web. ## What Google actually said Google did not publish a blog post about the removal. The only public record is a notice added to the FAQ structured data documentation, later folded into the [Search Central changelog](https://developers.google.com/search/updates#removing-faq-rich-result): "FAQ rich results are no longer appearing in Google Search. We will be dropping the FAQ search appearance, rich result report, and support in the Rich results test in June 2026. To allow time for adjusting your API calls, support for the FAQ rich result in the Search Console API will be removed in August 2026." Three dates follow from that notice. FAQ rich results stopped appearing on 7 May 2026. The search appearance filter, the rich result report and Rich Results Test support go in June 2026. Search Console API support for the FAQ rich result type ends in August 2026, giving teams pulling that data a window to adjust their calls before it disappears. ## A three-year phase-out, not a single decision This did not happen in one step. In August 2023, Google restricted FAQ rich results to well-known, authoritative government and health sites, cutting the feature for everyone else. The same period narrowed HowTo rich results to mobile only, before removing them entirely by September 2023. May 2026 finishes the job Google started then: the last sites still eligible for a FAQ rich result, the authoritative government and health properties, lose it too. Neither removal came with a stated reason from Google beyond the documentation notices themselves. The pattern across both is the same: a feature narrows in scope first, then disappears once the narrower version stops being worth maintaining. ## What to do with FAQPage markup now Google's documentation is explicit that unused structured data does not cause problems for Search, and FAQPage is still a valid [Schema.org](/topics/structured-data) type. There is no stated penalty for leaving the markup in place, only the loss of the Google feature it used to produce. The markup is not only read by Google, either. Bingbot, PerplexityBot and other retrieval-focused crawlers used by AI answer systems still parse FAQPage data on the open web. Removing it would strip a machine-readable answer format that those systems can still use, in exchange for a Google feature that is no longer there to lose. Keeping the markup costs nothing measurable; stripping it trades away a format other consumers still read for no offsetting benefit on Google. ## Why we care A rich result disappearing is routine. What is worth tracking is the shape of the decision: Google narrowed FAQ eligibility for three years before cutting it entirely, gave no public explanation beyond a documentation notice, and left the underlying schema untouched. That is the pattern to watch for the next rich result on a restricted eligibility list, and it is a reminder that structured data now has an audience beyond the search engine that popularized it. ## Frequently asked questions ### Should I remove FAQPage markup from my pages? Google's own documentation says unused structured data does not cause problems, and FAQPage is still a valid Schema.org type. There is no stated penalty for keeping it, only the loss of the Google feature it used to power. ### Does any Google surface still use FAQ markup? Google's notice covers the classic FAQ rich result in Search. It does not say whether FAQPage data feeds any other Google system, and Google has not published a separate statement on that. ### What was the August 2023 change? Google restricted FAQ rich results to well-known, authoritative government and health websites, cutting them for every other site. The same period saw HowTo rich results reduced to mobile only before being removed entirely by September 2023. ## Sources 1. [Latest documentation updates: Removing documentation for the FAQ rich result feature](https://developers.google.com/search/updates#removing-faq-rich-result) - Google Search Central (primary) 2. [Google Drops FAQ Rich Results From Search](https://www.searchenginejournal.com/google-drops-faq-rich-results-from-search/574429/) - Search Engine Journal --- --- title: "Article schema has no required properties, only recommended ones" url: https://seomadman.com/research/article-schema-no-required-properties section: research published: 2026-06-22T00:00:00.000Z modified: 2026-06-22T00:00:00.000Z author: Adam Hafez topics: ["Structured data"] --- # Article schema has no required properties, only recommended ones ## The short answer A common technical-SEO assumption is that Article schema has required fields. Google's own documentation says otherwise: no properties are required, only recommended ones, among them an image supplied in three separate aspect ratios. Recommended is not optional to ignore, since Google ties these properties directly to rich-result eligibility rather than basic indexing. ## Key takeaways - Google's Article structured data documentation states there are no required properties for Article, NewsArticle or BlogPosting, only recommended ones. - The documented recommended properties are headline, image, datePublished, dateModified, author, author.name and author.url, and publisher is not among them. - Google recommends supplying the image property in three separate aspect ratios, 16x9, 4x3 and 1x1, at a minimum of 50,000 pixels when width is multiplied by height. - Google's own stated reason for the recommended properties is that they help Google understand the page and show better title, image and date information in search results. "Required" gets applied to Article schema constantly in technical-SEO checklists and audits: no headline, fails; no image, fails; no author, fails. Google's own Article structured data documentation does not say that, and has not said it for the version of the page live today. It names recommended properties and states directly that none of them are required. ## Google's own statement: no required properties Google's [Article, NewsArticle, BlogPosting structured data documentation](https://developers.google.com/search/docs/appearance/structured-data/article), last confirmed updated 2026-09-08, states it plainly: there are no required properties, and the instruction is to add the properties that apply to the content, not to satisfy a minimum checklist. That single sentence undoes a lot of audit language built around Article schema having a pass or fail gate the way Product or Recipe genuinely do, where Google's own documentation for those types does list hard requirements. This is not a loophole in the schema.org spec that Google happens to tolerate. It is Google's stated position for this specific type, distinct from how it documents other types on the same page family. A JSON-LD block that carries only `@context`, `@type` and nothing else is not malformed under this rule; it is simply a block that supplies none of the properties Google recommends, which is a different problem with a different fix. ## The recommended properties, and the image aspect-ratio detail The documented recommended properties are `author`, `author.name`, `author.url`, `dateModified`, `datePublished`, `headline` and `image`. Author can be a Person or an Organization, and Google recommends the `url` sub-property specifically so the author can be identified as a distinct entity rather than left as a bare string. Publisher, despite circulating in some secondhand summaries of this schema, is not among the properties Google's current page actually recommends for Article. The easiest one to under-supply is `image`. Google does not ask for one representative image; it asks for images in three separate aspect ratios, 16x9, 4x3 and 1x1, each at a minimum resolution of 50,000 pixels when width is multiplied by height. A page that ships a single square thumbnail, or a single wide hero image, has satisfied the property in name but not in the shape Google's documentation actually describes, since none of the other two crops exist for Google to select depending on the surface it is rendering the result on. ## Why we care The site's own [JSON-LD validator](/tools/json-ld-validator) already reflects this distinction correctly: it states outright that Google marks no properties as strictly required for Article, and flags a missing recommended property as a warning rather than a failure, which matches what this review verified directly on Google's page. The [structured data generator](/tools/schema-markup-generator) is honest about a different thing, that it applies an asterisk to properties "Google treats as required" across several schema types at once, Product and BreadcrumbList among them, which do carry genuine requirements; it does not currently call out that Article itself has none, so a team using it should not read an unstarred Article field as unimportant, only as not gating. The practical shift this piece argues for is in prioritization, not in whether to bother with Article schema at all. Google's own reasoning for these properties is that they help it understand the page and show better title, image and date information in results, which is an eligibility and display-quality claim, not an indexing gate. A team should treat a missing `datePublished` or a single-aspect-ratio image as a specific, named cost to how the article can display, not as a build-breaking error to fix before anything else ships, and should stop describing Article schema audits in the pass-or-fail language that Google's own documentation reserves for types like Product and Recipe instead. ## Frequently asked questions ### Does Article structured data have any required properties? No. Google's own Article structured data documentation states there are no required properties for Article, NewsArticle or BlogPosting, only recommended ones, and that the only obligation is to add whichever properties apply to the content. ### Which properties does Google recommend for Article schema? Author (as a Person or Organization, with author.name and author.url), dateModified, datePublished, headline and image. Publisher is not among Google's documented recommended properties for this type, despite appearing in some secondhand summaries. ### Why does the image property need three aspect ratios? Google's documentation asks for multiple high-resolution images in 16x9, 4x3 and 1x1 aspect ratios, each at a minimum of 50,000 pixels when width is multiplied by height, so different search surfaces can each use a crop that fits. ### If a property is only recommended, does skipping it cost anything? By Google's own stated reasoning, yes, in display quality rather than indexing. Google says these properties help it show better title text, images and date information for the article in search results, which is a rich-result and presentation concern, not a basic-crawling one. ## Sources 1. [Article, NewsArticle, BlogPosting structured data](https://developers.google.com/search/docs/appearance/structured-data/article) - Google Search Central (primary) --- --- title: "Publishers with OpenAI deals get 48% more ChatGPT citations" url: https://seomadman.com/news/openai-licensing-deals-citation-premium section: news published: 2026-06-20T00:00:00.000Z modified: 2026-06-20T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # Publishers with OpenAI deals get 48% more ChatGPT citations ## The short answer Otterly.AI and Press Ranger cross-referenced 129.3 million AI citations across seven platforms against confirmed publisher licensing deals for June 2026. Publishers with an OpenAI deal averaged 10.2 citations per cited page on ChatGPT versus 6.9 for unlicensed publishers, a 48% premium. Google and Perplexity showed no matching home-platform advantage, and the authors call the pattern an association, not a cause. ## Key takeaways - Publishers with an OpenAI licensing deal averaged 10.2 ChatGPT citations per cited page versus 6.9 for publishers with no deal, a 48% premium. - Publishers licensed only with OpenAI saw a 112% premium on ChatGPT specifically, the largest gap the study reports for any single platform pairing. - Microsoft Copilot showed an 85% premium for OpenAI-licensed publishers, the largest of any platform in the study. - Google AI Overviews, Google AI Mode and Gemini each cited Google-licensed publishers slightly less than unlicensed publishers. - Perplexity showed parity between its own licensees and unlicensed publishers, with no home-platform citation advantage. A publisher's licensing deal with OpenAI tracks with a real citation gap inside ChatGPT, and the gap does not repeat on Google or Perplexity. That is the headline finding from a study Otterly.AI ran with Press Ranger, published 25 June 2026, which is the first attempt to join the deal side of AI licensing to the citation side at the scale of an actual platform sample. ## What the study measured Otterly.AI and Press Ranger cross-referenced 129.3 million AI citations, drawn from 19,812,878 cited URLs, against a list of every confirmed publisher AI licensing deal on record, for the month of June 2026. Seven platforms are covered: ChatGPT, Google AI Overviews, Google AI Mode, Perplexity, Microsoft Copilot, Gemini and Claude. Publishers with an OpenAI deal averaged 10.2 citations per cited page on ChatGPT, against 6.9 for publishers with no deal at all, a 48% premium. Publishers licensed with OpenAI and nobody else did better still: 112% more citations per page on ChatGPT than unlicensed publishers. Across all seven platforms combined, the OpenAI-licensed premium narrows to 46%, and the platform with the single largest gap was not ChatGPT at all but Microsoft Copilot, where OpenAI-licensed publishers saw an 85% premium. ## The premium does not repeat elsewhere The pattern breaks down once the licensing partner and the platform are the same company. Otterly.AI reports that "all three Alphabet platforms cite licensed publishers slightly less than publishers with no deal," covering Google AI Overviews, Google AI Mode and Gemini. Perplexity "sits at parity": publishers with a Perplexity deal see no measurable citation advantage on Perplexity itself, and Perplexity-only licensees underperform unlicensed publishers on other platforms by the study's own account. So of the two home-platform relationships the study can test directly, one, OpenAI and ChatGPT, shows a large premium, and the other two, Google and its three surfaces plus Perplexity, show none. ## Who actually has these deals News Corp, Conde Nast, Hearst and People Inc (formerly Dotdash Meredith) are among the publishers with reported OpenAI content-licensing agreements, confirmed independently by Axios and TheWrap's coverage of the Hearst deal and by OpenAI's own announcements for the others. Terms vary: some combine training-data access with in-answer attribution and links, others cover a narrower set of archives. ## What the study does not claim Otterly.AI and Press Ranger are explicit that the relationship is "association, not causation." A licensing deal does not, on this data, prove that OpenAI is thumbing the scale for its named partners. Licensed publishers may also carry stronger technical SEO, faster crawl access, or brand signals ChatGPT was already favoring before any deal existed, and the study cannot separate those from a direct licensing effect. The authors' own framing is the ceiling on what this data supports, and it stops at correlation. ## Why we care This is the first citation study built by joining an actual list of confirmed publisher deals to platform-scale citation counts, rather than guessing at a licensing effect from anecdote. The number worth remembering is not 48%, it is that the premium exists only where the licensor and the platform are the same company, and vanishes or reverses everywhere else. That pattern is consistent with a platform favoring its own paying partners, but the study's authors stop short of calling it proof, and so should anyone citing this piece. ## Frequently asked questions ### Does this prove licensing deals cause more citations? No. Otterly.AI and Press Ranger describe the finding as an association rather than a proven cause. A licensing deal correlates with more visible confidence in a publisher's brand and technical readiness, either of which could independently affect citation counts. ### Which publishers have confirmed OpenAI content deals? News Corp, Conde Nast, Hearst and People Inc (formerly Dotdash Meredith) are among the publishers with reported OpenAI licensing agreements, each covering different terms for training data access and in-answer attribution. ### Did Google-licensed publishers do better on Google's own AI surfaces? No. The study found Google AI Overviews, Google AI Mode and Gemini all cited Google-licensed publishers slightly less often than publishers with no licensing deal at all. ## Sources 1. [News Publishers With OpenAI Deals Get +48% More AI Citations on ChatGPT](https://otterly.ai/blog/ai-news-licensing-deals/) - Otterly.AI (primary) 2. [Exclusive: OpenAI and Hearst strike content deal](https://www.axios.com/2024/10/08/openai-hearst-ai-content-deal) - Axios 3. [OpenAI, Hearst Strike Content Licensing Partnership](https://www.thewrap.com/openai-hearst-content-licensing-partnership/) - TheWrap --- --- title: "How often Google rewrites a meta description: three studies compared" url: https://seomadman.com/reports/meta-description-rewrite-rate-compared section: reports published: 2026-06-19T00:00:00.000Z modified: 2026-06-19T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # How often Google rewrites a meta description: three studies compared ## The short answer Two studies measured this six weeks apart in 2020. Portent found Google rewrites meta descriptions 71% of the time on mobile and 68% on desktop, across 30,000 keywords. Ahrefs found 62.78%, across 20,000 keywords and 192,656 pages. Search Engine Journal's "over 70%" headline is coverage of Portent's figure. The gap is method and device split, not a real disagreement. ## Key takeaways - Portent's September 2020 study of 30,000 keywords found Google rewrites meta descriptions 71% of the time on mobile and 68% on desktop, via STAT Search Analytics. - Ahrefs' October 2020 study of 20,000 keywords and 192,656 unique pages found a 62.78% rewrite rate, splitting to 59.65% for fat-head keywords and 65.62% for long-tail keywords. - Search Engine Journal's "over 70% of the time" headline is coverage of Portent's own mobile figure, not a third independent dataset. - Ahrefs found Google displays a page's own meta description in the snippet only 37.22% of the time overall, even before counting partial rewrites. - All three figures come from within six weeks of each other in 2020, so the 62.78% to 71% spread reflects different sample composition and device handling, not a trend over time. Ask how often Google uses a page's own meta description and you can get 71%, 68% or 62.78% rewritten, depending on which September 2020 study you open. Portent and Ahrefs ran independent studies six weeks apart, using different tools and different sample compositions, and neither number is wrong. Search Engine Journal's widely cited "over 70% of the time" headline is coverage of Portent's own mobile figure, not a separate measurement. ## The real numbers, study by study Portent's Evan Hall pulled first-page organic results for 30,000 keywords through STAT Search Analytics, split by mobile and desktop, and wrote a script to compare each rendered SERP snippet against the source page's meta description tag. Any snippet text not contained in the meta description tag counted as a rewrite. The result: Google rewrote the description 71% of the time on mobile and 68% of the time on desktop, meaning a site's own wording survived roughly three times in ten. Portent also found rewrite rates ticked up for positions 4 through 6, which the study speculated was Google trying to boost relevance for results below the top three. Ahrefs' Michal Pecánek ran a separate study a month later, analyzing 20,000 keywords and 192,656 unique ranking pages. Ahrefs found a 62.78% overall rewrite rate, splitting to 59.65% for fat-head (high-volume) keywords and 65.62% for long-tail keywords, meaning the more specific a query, the more likely Google was to write its own snippet. Ahrefs also reported that a page's meta description was shown as the snippet, unmodified, only 37.22% of the time overall, a separate number from the rewrite rate since a "not shown" snippet is a different outcome than a partial rewrite. Search Engine Journal's Matt G. Southern covered Portent's study on publication and titled the piece around the mobile figure, "Google Rewrites Meta Descriptions Over 70% of the Time." It is the source most people quoting "70%" are actually citing, whether they know it traces back to Portent's mobile number or not. ## Why Google rewrites a description Neither study tested Google's reasoning directly; both only measured outcomes. For the reasoning, Google's own Search Central documentation is the primary source. It states Google generates its own snippet "when we think it gives users a more accurate description than would be possible purely from the on-page content," and separately warns site owners that descriptions built from "long strings of keywords... don't give users a clear idea of the page's content, and are less likely to be displayed as a snippet." The same page also flags generic, vague description text as a reason Google is less likely to use what a page provides, and recommends unique, page-specific wording instead. That gives three named factors from Google itself, none of them measured against a rewrite rate by either study here: query relevance (Google picks whichever passage on the page best answers the specific search), keyword stuffing, and generic or duplicated description text across pages. A description that fails any of those tests is a plausible target for rewriting, but no published study ties a specific one of these three factors to a specific percentage point, the way the title tag studies isolated H1 match and character length. ## Why we care **A meta description you wrote survives Google's rewriter a minority of the time**, on both studies here, roughly three times in ten on Portent's numbers and closer to four times in ten on Ahrefs'. That is still a reason to write one carefully: Google's own guidance ties the rewrite decision to genericness and keyword stuffing, both things a site controls, even though no study has isolated those levers with a measured before-and-after the way the title tag research has. **Meta descriptions and title tags are rewritten for different reasons at different rates**, and citing one figure for both elements is a common mistake in SEO decks. This site's [title tag rewrite rate study](/studies/title-tag-rewrite-rate-study) found Google rewrites titles 61.6% to 76% of the time, driven mostly by brand-name stripping and H1 mismatch, mechanics that do not apply to a meta description, which has no equivalent on-page heading to match against. Treat the two studies as answering related but separate questions, not the same question asked twice. ## Frequently asked questions ### Which meta description rewrite rate should I cite, 71% or 62.78%? Name the study. Portent's 71% is a mobile-only figure from 30,000 keywords pulled through STAT Search Analytics in September 2020. Ahrefs' 62.78% is a blended figure from 20,000 keywords and 192,656 pages a month later. Neither number is wrong; "Google rewrites descriptions X% of the time" is not a complete claim without the study attached. ### Is the Search Engine Journal "over 70%" figure a third study? No. It is Search Engine Journal's write-up of Portent's own 71% mobile figure, published two weeks after Portent's post. It confirms and amplifies one dataset rather than adding a second independent measurement. ### Why does Google rewrite a meta description at all? Google's own Search Central documentation says it generates a snippet when it believes that gives a more accurate description than the page's own tag would, and separately warns that keyword-stuffed or generic descriptions are less likely to be used as written. Neither study tested Google's stated reasons directly; both only measured the outcome. ### Does this apply the same way to title tags? No, title tags and meta descriptions are rewritten for different reasons at different rates. See this site's separate coverage of [how often Google rewrites a title tag](/studies/title-tag-rewrite-rate-study), which found a 61.6% to 76% range driven mostly by brand-name removal and H1 mismatch, factors these two meta-description studies do not test for. ## Sources 1. [How Often Google Ignores Our Meta Descriptions](https://portent.com/blog/seo/how-often-google-ignores-our-meta-descriptions.htm) - Portent (primary) 2. [How Often Does Google Rewrite Meta Descriptions? (New Data Study)](https://ahrefs.com/blog/meta-description-study/) - Ahrefs (primary) 3. [Google Rewrites Meta Descriptions Over 70% of the Time](https://www.searchenginejournal.com/google-rewrites-meta-descriptions-over-70-of-the-time/382140/) - Search Engine Journal 4. [Control your snippets](https://developers.google.com/search/docs/appearance/snippet) - Google Search Central --- --- title: "IETF's AI Preferences group is still drafting, not shipping" url: https://seomadman.com/news/ietf-aipref-robots-txt-successor section: news published: 2026-06-18T00:00:00.000Z modified: 2026-06-18T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO", "AI search"] --- # IETF's AI Preferences group is still drafting, not shipping ## The short answer The IETF chartered an AI Preferences (AIPREF) working group on 7 January 2025 to standardize how sites express preferences about AI training and use. As of September 2026 it has two Internet-Drafts, not published RFCs, covering a vocabulary of preference terms and how to attach them through robots.txt or an HTTP header. Nothing here changes today's robots.txt configuration. ## Key takeaways - The IETF's AI Preferences working group was chartered on 7 January 2025, following an IAB workshop on AI-Control and a side meeting at IETF 121. - The charter names the Robots Exclusion Protocol, RFC 9309, and HTTP response headers as candidate delivery mechanisms rather than proposing to replace either. - As of September 2026 the group has produced two Internet-Drafts, not published RFCs, a vocabulary draft and an attachment draft, both on the Proposed Standard track. - The vocabulary draft currently defines two preference categories, train-ai and search, each expressed as a simple allow or disallow value. - The attachment draft proposes a Content-Usage directive in robots.txt alongside a matching Content-Usage HTTP response header, not a replacement file. The IETF has a working group standardizing how a site tells AI systems what they may do with its content, and it has been at it for a year and a half without publishing a single RFC. The AI Preferences (AIPREF) working group was chartered on 7 January 2025, growing out of an IAB workshop on AI and content control and a side meeting at IETF 121 the previous November. As of September 2026 it has produced two Internet-Drafts. Neither is a finished standard. ## What the charter actually asks for AIPREF's charter describes the goal as standardizing "building blocks that allow for the expression of preferences about how content is collected and processed for Artificial Intelligence (AI) model development, deployment, and use." It names Well-Known URIs under RFC 8615, specifically the Robots Exclusion Protocol of RFC 9309, and HTTP response header fields as candidate mechanisms for attaching those preferences to content. The charter frames these as delivery options the working group can build on, not as a problem statement about robots.txt itself, and the datatracker record does not contain language calling existing AI-vendor signals confusing or non-standard. That framing shows up in commentary around the group, not in the charter text. The practical background is not controversial even without a quotable charter line: several AI companies already publish their own robots.txt user-agent tokens, GPTBot and Google-Extended among them, and site owners have had no single vocabulary for saying yes to search use while saying no to model training. AIPREF's job is to give that distinction a standard shape. This is a separate effort from llms.txt, the informal file-at-the-root convention some blog posts have wrongly attributed to a W3C standards track; AIPREF never touches llms.txt and has no relationship to it. ## The two drafts, and what they cover **draft-ietf-aipref-vocab** defines the preference vocabulary. As of version 07, dated 18 August 2026, it specifies two usage categories: train-ai, for using content to modify an AI model's learned parameters, and search, for retrieval applications whose primary purpose is directing users back to the original source. Each category takes a simple allow or disallow value; categories the vocabulary does not yet cover remain unspecified rather than defaulting either way. **draft-ietf-aipref-attach**, version 05, also dated 18 August 2026, defines how a preference gets attached to content: a new Content-Usage directive inside robots.txt, and a matching Content-Usage HTTP response header for sites that would rather signal at the response level than the file level. Both mechanisms are meant to coexist with RFC 9309 rather than supersede it. Both drafts carry the standard Internet-Draft boilerplate stating they do not reflect working group consensus in whole or in part, and both are dated to expire in February 2027 if not revised or advanced. That is normal for an active draft, not a sign of stalling, but it does mean the vocabulary and the syntax can still change before either document reaches working group last call. ## Why we care Nothing here changes what belongs in a robots.txt file today. The working group has not published an RFC, the vocabulary covers exactly two preference categories, and the attachment syntax is still draft text that IESG review could still alter. What's worth tracking is the direction: if AIPREF finishes, sites get one IETF-sanctioned way to say "index and cite me, don't train on me" instead of the patchwork of vendor-specific tokens crawlers currently interpret however they choose. Technical SEOs should watch draft-ietf-aipref-attach advance past working group last call before treating a Content-Usage directive as something to deploy, not before. ## Frequently asked questions ### Does this replace robots.txt? No. The attachment draft adds a new Content-Usage directive that would sit inside an existing robots.txt file, alongside a matching HTTP response header for sites that prefer that route. RFC 9309 stays the base protocol either way. ### Can I use AIPREF today? Not as a ratified standard. Both documents are Internet-Drafts, meaning they can still change before working group last call, IESG review and publication as RFCs. Nothing in this effort is a shipped feature any crawler is contractually bound to honor yet. ### Who is actually building this? The IETF AI Preferences working group, chaired by Suresh Krishnan and Mark Nottingham, with liaison relationships to the IPTC, the PLUS Coalition, and WHATWG or W3C for related content-format work. ## Sources 1. [AI Preferences (aipref) - Working Group](https://datatracker.ietf.org/wg/aipref/about/) - IETF Datatracker (primary) 2. [Charter for Working Group: AI Preferences (aipref)](https://datatracker.ietf.org/doc/charter-ietf-aipref/) - IETF Datatracker (primary) 3. [A Vocabulary For Expressing AI Usage Preferences](https://datatracker.ietf.org/doc/draft-ietf-aipref-vocab/) - IETF Datatracker 4. [Associating AI Usage Preferences with Content in HTTP](https://datatracker.ietf.org/doc/draft-ietf-aipref-attach/) - IETF Datatracker 5. [RFC 9309: Robots Exclusion Protocol](https://www.rfc-editor.org/rfc/rfc9309) - RFC Editor --- --- title: "AI crawler block rate: how often a 403 actually stops the bot" url: https://seomadman.com/reports/ai-crawler-blocking-rate-trend-2026 section: reports published: 2026-06-17T00:00:00.000Z modified: 2026-06-17T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # AI crawler block rate: how often a 403 actually stops the bot ## The short answer Across Cloudflare's network, AI crawler requests returning HTTP 403 Forbidden ran at 7.9% in the first half of 2026, with overall 4xx responses to crawlers climbing from 10.2% in Q2 2025 to 35.8% by Q2 2026. That is a live response-code measurement, distinct from counting how many robots.txt files merely name a crawler in a disallow rule. ## Key takeaways - In H1 2026, 7.9% of verified AI crawler requests on Cloudflare's network returned HTTP 403 Forbidden, plus 0.7% rate-limited with 429. - Overall 4xx responses to crawler requests rose from 10.2% in Q2 2025 to 35.8% in Q2 2026, while clean 200 OK responses fell from 80.5% to 49.2% over the same span. - A disallow rule and a 403 measure different things: a Q1 2026 scan of 4,047 robots.txt files found GPTBot named in 5.52% of disallow rules, ahead of CCBot and ClaudeBot. - Cloudflare made blocking AI crawlers the default for new domains from 1 July 2025, and says customers blocked over 416 billion AI bot requests in the policy's first five months. - A robots.txt disallow is a request a crawler can ignore, while a 403 is enforced at the edge regardless of whether the bot ever reads the rules file. "AI crawlers are getting blocked more" is easy to say and hard to measure, because two entirely different things get called "blocking": a line in robots.txt asking a crawler to stay away, and a server actually returning HTTP 403 when the crawler shows up anyway. Our own read of 60 robots.txt files [found who writes the rule](/research/ai-crawler-policies-news-sites). This report tracks the other half - how often the request itself gets refused, and how that rate has moved over the past year. ## The rate that measures the actual request TechnologyChecker.io draws on Cloudflare Radar's bot response-status data, which classifies traffic from crawlers Cloudflare has verified against each operator's published IP ranges and records the live HTTP status returned to each request. In the first half of 2026, 7.9% of those verified AI crawler requests came back HTTP 403 Forbidden, with a further 0.7% rate-limited at 429 - roughly one in twelve AI crawl attempts actively refused, before counting the ones that were merely slowed down. Widen the lens to all 4xx responses - forbidden, rate-limited, or hitting a dead URL - and the trend is sharper still. Clean 200 OK responses to crawler requests fell from 80.5% in Q2 2025 to 49.2% in Q2 2026, while 4xx responses climbed from 10.2% to 35.8% over the same stretch. More than one in three AI crawler requests now hits some kind of block, a rate that has more than tripled in a year on the same network, measured the same way each time. ## Disallow rules count something different A second TechnologyChecker.io dataset - a text scan of 4,047 robots.txt files as of Q1 2026, growing to 4,223 by July - answers a different question: which crawlers get named in a disallow rule at all, not whether any of their requests were ever refused. In that Q1 2026 sample, GPTBot appeared in 5.52% of disallow rules, ahead of CCBot (5.08%), ClaudeBot (4.88%), Google-Extended (4.44%) and Bytespider (4.23%). That figure cannot be read against the 403 rate above as if they measured the same thing. A disallow rule is a published intention a crawler can simply ignore - our robots.txt read of 60 publishers found [exactly that gap between intention and](/research/ai-crawler-policies-news-sites) what a site actually enforces at the edge. A 403 is enforced regardless of whether the crawler ever fetched the rules file. The two trackers publish their methodology separately for this reason, and treating a disallow-rule share as a blocked-request rate - or vice versa - overstates or understates what is actually happening at the server. ## Cloudflare changed the default, then published the count The infrastructure context for both numbers: on 1 July 2025, Cloudflare's own "Content Independence Day" post changed the default so AI crawlers are blocked unless a site owner opts them in, and the company's one-year-later report confirms this applies to new domains by default. Existing domains kept whatever setting they already had. Cloudflare CEO Matthew Prince said at WIRED's Big Interview event in December 2025 that customers had blocked more than 416 billion AI bot scraping requests in the five months since that policy took effect - a count reported by Search Engine Land, Computerworld and others, though not itself the subject of a dedicated Cloudflare blog post at that point. ## Why we care **A rising 403 rate and a rising disallow-rule count both describe more resistance to AI crawlers, but they are not the same fact and should not be quoted as if they were.** If a claim cites a percentage of AI bot requests being blocked, ask whether the source measured live response codes or counted robots.txt rules - the gap between the two, visible in our own [robots.txt research](/research/ai-crawler-policies-news-sites), is often the difference between a policy that exists on paper and one a server actually enforces. **The trend, on the metric that measures enforcement, is unambiguous: it is rising, fast.** A tripling of 4xx responses to AI crawlers within a year, on the same network, measured the same way each period, is the closest thing in this space to a real trend line rather than a single snapshot - the caveat is that it describes Cloudflare's network, not the open web as a whole, the same population caveat that applies to any single-vendor dataset in [AI search](/topics/ai-search) measurement. ## Frequently asked questions ### Does a robots.txt disallow rule mean a crawler is actually blocked? Not by itself. A disallow rule is a published request that a well-behaved crawler chooses to honor. Whether a request was actually refused is a separate, measurable fact - the HTTP status code the server returned - and TechnologyChecker.io's two datasets track these separately rather than treating a rule as proof of a block. ### What share of AI crawler requests actually get blocked? On Cloudflare's network, 7.9% of verified AI crawler requests returned HTTP 403 in H1 2026, with a further 0.7% rate-limited. Zoomed out further, all 4xx responses to crawlers - forbidden, rate-limited or not-found - rose from 10.2% of requests in Q2 2025 to 35.8% by Q2 2026. ### Did Cloudflare block AI crawlers by default before July 2025? No. Cloudflare's own 1 July 2025 announcement, "Content Independence Day," changed the default so that AI crawlers are blocked unless a site owner opts them in, and its one-year-later report confirms this applies to new domains by default. Existing domains kept their prior settings unless the owner changed them. ## Sources 1. [What AI Crawlers Actually Want? (August 2026 Update)](https://technologychecker.io/blog/ai-crawler-statistics) - TechnologyChecker.io (primary) 2. [Bot Traffic Statistics 2026: How Much of the Web Is Automated](https://technologychecker.io/blog/bot-traffic-statistics) - TechnologyChecker.io 3. [We Analyzed robots.txt Across Cloudflare's Network: Publishers Now Block Training Bots and Allow Answering Bots](https://technologychecker.io/blog/robots-txt-ai-crawlers-blocking-report) - TechnologyChecker.io 4. [Content Independence Day: no AI crawl without compensation!](https://blog.cloudflare.com/content-independence-day-no-ai-crawl-without-compensation/) - Cloudflare Blog (primary) 5. [Content Independence Day, one year on: building the business model for the agentic Internet](https://blog.cloudflare.com/agentic-internet-bot-report/) - Cloudflare Blog (primary) 6. [Cloudflare: 416 billion AI bot requests blocked since July](https://searchengineland.com/cloudflare-416-billion-ai-bot-requests-blocked-since-july-465704) - Search Engine Land --- --- title: "IndexNow adoption grows in 2026, but not at Google" url: https://seomadman.com/news/indexnow-adoption-google-holdout section: news published: 2026-06-16T00:00:00.000Z modified: 2026-06-16T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # IndexNow adoption grows in 2026, but not at Google ## The short answer IndexNow, the instant-indexing protocol Bing and Yandex launched in October 2021, has grown from 16 million sites submitting 1.2 billion URLs daily in 2022 to 3.5 billion URLs daily by December 2024, per Bing's own numbers. Naver, Seznam.cz and Yep also receive pings. Google still does not participate and has issued no roadmap to do so. ## Key takeaways - Bing reported more than 16 million websites submitting over 1.2 billion URLs per day to IndexNow in August 2022, its first public adoption figure. - That grew to more than 60 million websites and 1.4 billion URLs submitted daily by Bing's two-year update in October 2023. - Bing's most recently published figure, from December 2024, puts submissions at more than 3.5 billion URLs per day. - IndexNow's own FAQ lists Bing, Yandex, Naver, Seznam.cz and Yep as the search engines that receive its pings, and Amazon began adopting it as a submitter in 2025. - Google has never joined IndexNow and has published no roadmap to do so; the only on-record Google reaction remains a skeptical 2021 remark from John Mueller. IndexNow has kept growing since Bing and Yandex opened it in October 2021: Bing's own published figures put daily submissions at 3.5 billion URLs by the end of 2024, up from 1.2 billion when the company first shared a number in 2022. What has not changed is which engine receives those pings. Google is not one of them, and nothing it has published says that will change. ## The growth, by Bing's own numbers Bing has reported IndexNow's scale three times on its webmaster blog, each figure larger than the last: - **August 2022:** "more than 16 million web sites are publishing over 1.2 billion URLs per day to the IndexNow API." - **October 2023:** "60 million websites joining us daily and 1.4 billion URLs submitted each day." - **December 2024:** more than 3.5 billion URLs submitted per day, alongside a claim that 18% of all new URLs clicked in Bing's web search results arrived through IndexNow. Bing has not published a newer aggregate submission count since that December 2024 post. Its 2025 posts name individual adopters, including Amazon, Shopify and Milestone, rather than a fresh total. Treat 3.5 billion as the most recent verified figure, not a 2026 one. ## Who actually receives the pings IndexNow's own FAQ names five search engines as participants: Bing, Yandex, Naver, Seznam.cz and Yep. A site that pings the IndexNow API reaches all five with one submission, which is the entire point of the protocol: no more filing separate URLs with each engine's own tool. Amazon is a more recent name in IndexNow's story, but as a submitter rather than a receiving engine. Bing's May 2025 post describes Amazon adopting IndexNow to push its own product and listing URLs, alongside Shopify and Milestone doing the same for merchant sites. ## Where Google stands Google is absent from IndexNow's own list of participating engines, and its Search Central documentation makes no mention of the protocol. There is no Google roadmap, beta or stated intention to adopt it. The closest thing to an on-record Google reaction is a quip from Search Advocate John Mueller when IndexNow launched in 2021, describing Google's crawlers as content to "be crawled less often" rather than pushed to. Nothing since has moved that position onto paper. Google instead directs sites toward sitemaps, regular crawling and the Search Console URL Inspection tool, with the separate [Indexing API](/topics/technical-seo) reserved for job postings and livestream pages. None of those give a site the instant, multi-engine push that IndexNow offers for the five engines it does reach. ## Why we care The honest framing is adoption by Bing, Yandex and three smaller engines, not universal adoption. Google still sends the majority of organic search traffic for most sites, so a protocol it does not receive cannot replace sitemaps or crawl-budget work, whatever its growth curve looks like elsewhere. Add IndexNow for the engines it reaches; keep everything else aimed at Google unchanged. ## Frequently asked questions ### Does Google support IndexNow? No. IndexNow's own FAQ lists Bing, Yandex, Naver, Seznam.cz and Yep as the search engines that receive submissions. Google is not among them, has published no Search Central documentation about the protocol, and has given no public commitment to join it. ### What is the most recent adoption figure Bing has published? More than 3.5 billion URLs submitted per day, from a Bing Webmaster Blog post dated 12 December 2024. Bing has published adopter names since, including Amazon, Shopify and Milestone in 2025, but no newer aggregate submission count. ### Should a site stop using sitemaps and XML pings if it adopts IndexNow? No. IndexNow is a push notification to the engines that support it; it does not reach Google, which still relies on sitemaps, crawling and the Search Console URL Inspection tool. The two mechanisms are complementary, not substitutes for each other. ## Sources 1. [Look How Far We've Come: IndexNow Expands Adoption Across Industries](https://blogs.bing.com/webmaster/December-2024/Look-How-Far-We-ve-Come-IIndexNow-Expands-Adoption-Across-Industries) - Bing Webmaster Blog (primary) 2. [IndexNow - Celebrating two years of growth!](https://blogs.bing.com/webmaster/october-2023/IndexNow-Celebrating-two-years-of-growth) - Bing Webmaster Blog (primary) 3. [IndexNow adoption gains momentum](https://blogs.bing.com/webmaster/august-2022/IndexNow-adoption-gains-momentum) - Bing Webmaster Blog (primary) 4. [IndexNow FAQ](https://www.indexnow.org/faq) - IndexNow (primary) 5. [IndexNow Enables Faster and More Reliable Updates for Shopping and Ads](https://blogs.bing.com/webmaster/May-2025/IndexNow-Enables-Faster-and-More-Reliable-Updates-for-Shopping-and-Ads) - Bing Webmaster Blog 6. [Google's absence from IndexNow raises questions about web indexing standards](https://ppc.land/googles-absence-from-indexnow-raises-questions-about-web-indexing-standards/) - PPC Land --- --- title: "AI citation rate by content format: what checks out" url: https://seomadman.com/reports/ai-citation-rate-by-content-format section: reports published: 2026-06-16T00:00:00.000Z modified: 2026-06-16T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # AI citation rate by content format: what checks out ## The short answer Vendor blogs circulate exact-sounding AI citation rates by content format, but most do not trace to a real source. A real Wix study of 1,056,727 citations found listicles at 21.9%, articles at 16.7%, product pages at 13.7%. A real DeltaV Digital panel found listicles at 61% in B2B tech specifically. Three other widely repeated figures could not be verified anywhere. ## Key takeaways - Wix's AI Search Lab analyzed 1,056,727 citations, finding listicles at 21.9%, articles at 16.7%, and product pages at 13.7% of all citations. - DeltaV Digital tracked 25,337 citations across eight industries in 2026, finding listicles at 61% of citations in B2B tech specifically, not as a universal figure. - A real academic paper found a 17.3% citation-rate gain from structural optimization across six engines, but an industry blog presents that finding as its own research. - A widely repeated claim that original-data pages get a 71% citation rate, comparison pages 64%, and listicles 61% does not appear on any source it is attributed to. - A '156% higher selection rate' figure turned up attached to three different, unrelated claims across three vendor sites, each citing a different, unfetchable source. Five precise-sounding statistics about which content format gets cited most by AI search have been circulating across SEO and GEO vendor blogs through 2026. Each one is quoted as if it were a single settled fact. Checking each against the page it is supposedly published on turns up a narrower and messier picture: two real studies with real sample sizes, one real academic paper being passed off as proprietary industry research, and three figures that do not survive contact with their own stated source. ## The two figures that hold up Wix Studio's AI Search Lab published the most rigorous of the group. Researcher Tom Wells analyzed 75,000 AI answers and 1,056,727 citations retrieved from three engines, ChatGPT, Google AI Mode and Perplexity, using deliberately non-branded prompts so the results were not skewed toward users already naming a company. Listicles accounted for 21.9% of citations, articles for 16.7%, and product pages for 13.7%. The methodology section discloses the model list, the prompt design choice, and the publication date, 2026-03-23, which is enough to treat the number as a real, checkable finding rather than a repeated slogan. DeltaV Digital, run by VP of Operations Brandon Kidd, published a second real dataset: 21,075 AI engine responses tracked across ChatGPT, Perplexity, Gemini, Google AI Overviews and Google AI Mode between April 14 and July 13, 2026, yielding 25,337 citations to the 240 most-cited URLs across eight industries. Its own page states that ranked listicles reached 61% of citations specifically in the B2B technology services vertical, not as a figure that applies to every industry, and the report's central argument is that citation patterns differ by industry rather than following one universal format ranking. A third source, cited by Search Engine Land, comes from Evertune Research: an analysis of 25,000 cited URLs drawn from the 6,000 most-cited URLs per model across six engines, spanning roughly 400 million citations. It found that 63% of the most-cited URLs pointed to listicles, and that ranked lists made up 71% to 86% of those listicles rather than unranked lists or institutional rankings. This is a different cut of the same underlying pattern as the Wix and DeltaV figures, format matters and listicles lead, but it is a distinct, separately disclosed dataset, not a repeat of the same number under a new name. ## The three figures that do not check out **"Original-data studies get a 71% citation rate, comparison pages 64%, ranked listicles 61%."** This exact triple circulates on multiple vendor blogs, several of which cite DeltaV Digital as the source. DeltaV Digital's own page does not contain these three numbers as a three-way breakdown; it contains one industry-specific figure, 61% for listicles in B2B technology services, that only partially matches. When the pages actually publishing the 71%/64%/61% claim were checked directly, one (MaxAEO) presented it as proprietary internal monitoring with no external dataset link, and another (Presence AI) presented similar but not identical figures, 67% for comprehensive guides, 71% for FAQ schema, as self-published research with no linked raw data. The claim does not trace to one real, checkable study; it traces to at least two vendors publishing similar-sounding but non-matching numbers, neither externally verifiable. **"Original research earns citations at 20x the rate of thin content."** Search results attribute this figure to a synthesis of "four independent 2026 datasets," and one of the pages carrying that framing, Digital Applied's own citation-ranking-factors report, was fetched directly. Its real content covers a meta-analysis of several named datasets (a Zyppy 54-experiment review, an Ahrefs 75,000-brand correlation study, a BuzzStream four-million-citation analysis, and others) but does not state a 20x multiplier anywhere in the text. Ritner Digital, another page repeating the general claim that original research outperforms thin content, also does not state a 20x figure when checked directly. The multiplier could not be traced to any single page that actually publishes it with a method behind it. **"Pages combining text, images, video and structured elements show 156% higher selection rates."** This is the clearest case of a number being recycled. Checking three different pages that use "156%" turned up three different, unrelated claims: one site attaches 156% to multi-modal content selection, citing an unfetchable "AI Mode Boost 2025" report and admitting its own breakdown table is "derived," not copied from a published figure. A second site attaches the same 156% to adding original data or statistics to a page, citing "Authoritas 2026." A third, separately worded claim on the same general topic instead cites SEMrush for a completely different multiplier, 1.4x, for multi-format content. Three vendor pages, three different underlying claims, one recycled number, and no single fetchable primary source behind any version of it. ## A real academic figure wearing an industry-research costume One number in the original list of five does trace to something real: a 17.3% citation-rate improvement from structural optimization, tested across six generative engines. It comes from a genuine, fetchable paper, "Structural Feature Engineering for Generative Engine Optimization," by Yu, Yang, Ding and Sato, posted to arXiv in March 2026. The abstract states the figure plainly and names the six-engine test set, though it does not disclose page or trial counts in the abstract itself. What makes this one worth a section of its own is not the number, it is who is presenting it. Machine Relations Research's synthesis page states outright that its 17.3% figure is drawn from "GEO-SFE (Yu et al., University of Tokyo / University of Tsukuba / Hiroshima University / NII, arXiv 2603.29979, March 2026)," which is honest attribution. But other vendor pages in the same search results repeat the 17.3% figure without naming Yu et al. at all, presenting it as though it were proprietary GEO-tool research rather than an academic paper's finding. A real number, correctly sourced in one place, is being laundered into unattributed vendor content elsewhere, which is a different failure mode than the three figures above that were not real to begin with. ## Why we care This specific corner of SEO content, precise percentages about which content format AI search cites most, is currently one of the most citation-unstable areas this site has checked. Two of five widely repeated statistics traced to real, disclosed studies. One traced to a real academic paper being presented, in places, as if it were unattributed vendor research. Two more could not be verified on any page that claims to originate them, despite specific search effort against several named vendor blogs. None of this means content format is irrelevant to AI citation. It means the specific numbers attached to that claim are, right now, mostly unreliable. A reader who sees "71% citation rate" or "20x more citations" quoted without a named study, a disclosed sample size, and a link that actually contains the number, should treat the figure as unverified until proven otherwise, the same standard this report applied to check it. ## Frequently asked questions ### Do original-data pages really get cited 71% of the time by AI search? That specific figure, alongside comparison pages at 64% and ranked listicles at 61%, does not appear on any of the pages it circulates under. The one real, comparable figure this report could verify is DeltaV Digital's 61% listicle citation share, and that number applies only to B2B technology services, not content formats in general. ### What is the one number in this report that is both real and directly comparable across formats? Wix Studio's AI Search Lab study, which analyzed over a million citations across ChatGPT, Google AI Mode and Perplexity and found listicles at 21.9%, articles at 16.7%, and product pages at 13.7% of citations, with a disclosed sample size and named researcher. ## Sources 1. [The content types most cited by LLMs](https://www.wix.com/studio/ai-search-lab/research/content-types-most-cited-by-llms) - Wix Studio, AI Search Lab (primary) 2. [AI search citations study: what 25,000+ citations reveal](https://www.deltavdigital.com/resources/reports/ai-citation-study/) - DeltaV Digital 3. [Structural Feature Engineering for Generative Engine Optimization: How Content Structure Shapes Citation Behavior](https://arxiv.org/abs/2603.29979) - arXiv 4. [AI search loves listicles: What 25,000 URLs reveal about citations](https://searchengineland.com/ai-search-loves-listicles-what-25000-urls-reveal-about-citations-477682) - Search Engine Land, citing Evertune Research 5. [How Content Structure Affects AI Citation Rates: The GEO-SFE Research Framework (2026)](https://machinerelations.ai/research/content-structure-ai-citation-rates-2026) - Machine Relations Research --- --- title: "What Google and Bing actually say about schema and AI" url: https://seomadman.com/news/structured-data-ai-citation-priority section: news published: 2026-06-14T00:00:00.000Z modified: 2026-06-14T00:00:00.000Z author: Adam Hafez topics: ["Structured data", "AI search"] --- # What Google and Bing actually say about schema and AI ## The short answer Schema.org's vocabulary reached 823 types and 1,529 properties with the version 30.0 release on 19 March 2026. Google's own documentation states no special schema.org markup is required for AI Overviews or AI Mode. Microsoft has separately said structured data helps its Copilot systems understand content, though no verbatim quote confirms the exact wording used. ## Key takeaways - Schema.org's vocabulary now counts 823 types and 1,529 properties as of the version 30.0 release on 19 March 2026. - Google's own AI features documentation states plainly that no special schema.org markup is required for AI Overviews or AI Mode. - Microsoft Bing's Fabrice Canel was reported in March 2025 as confirming schema markup helps its LLMs understand content, though no verbatim quote survives in the public record. - Sites should not chase a specific performance lift statistic for schema and AI citations, because no verifiable, named study currently supports one. - Google and Bing currently take different public positions, with Google downplaying structured data's necessity for AI while Bing frames it as an understanding aid. Two search companies, two different public positions on the same question. Google's developer documentation says plainly that structured data is not required to appear in AI Overviews or AI Mode. Microsoft has been reported, separately, as saying schema markup helps its Copilot systems understand content. Neither statement is the sweeping "schema equals AI visibility" story that circulates in SEO blogs, and schema.org's own release notes show the vocabulary keeps growing for reasons that have little to do with AI search specifically. Here is what each party has actually said, and what has not been verified. ## What schema.org's own numbers say Schema.org's documentation states the vocabulary "currently consists of 823 Types, 1,529 Properties, 19 Datatypes, 96 Enumerations and 535 Enumeration members." The most recent major release, version 30.0, shipped on 19 March 2026 and added a Credential class and an Error class with an errorCode property, among other additions logged in the project's own release notes. That is a durable fact anyone can check today by opening the release history. It is not, on its own, evidence that AI systems weight structured data more heavily than they did before the release. ## What Google says, and does not say Google's "AI features and your website" documentation, last updated 10 December 2025, addresses the structured-data question directly: "There's also no special schema.org structured data that you need to add" to appear in AI Overviews or AI Mode. The same page still recommends existing structured-data practice as part of general SEO, but it stops short of claiming schema markup earns a site AI citations specifically. That distinction, required for rich results eligibility versus optional for AI features, is the one worth keeping straight before adding markup on the strength of an AI promise. ## What Bing has said, and what remains unverified Search Engine Land and Search Engine Roundtable both reported in March 2025 that Fabrice Canel, principal product manager at Microsoft Bing, confirmed on stage at SMX Munich that schema markup helps Microsoft's LLMs, including Copilot, understand web content. Neither outlet published a verbatim quote of Canel saying that specific sentence: the confirmation traces back to a LinkedIn post summarising his talk, which Canel then engaged with in the comments rather than issuing his own written statement. Treat the underlying claim, that schema aids comprehension, as credibly sourced but not independently quotable, and treat any number attached to it (a lift percentage, a citation-rate multiplier) as unverified until a named study says otherwise. ## Why we care The honest version of this story is smaller than the one making the rounds: one company says structured data is optional for AI features and always has been, the other has a reported, not directly quoted, statement that it helps their models understand a page. Neither has published a number connecting schema completeness to citation frequency. A publication that repeats an unsourced lift statistic because it sounds plausible has stopped doing the one thing that separates reporting from marketing copy, tracing every figure back to where it came from. ## Frequently asked questions ### Does adding schema markup guarantee an AI citation? No. Neither Google nor Microsoft has published a mechanism that ties structured data to citation odds. Google's own documentation says no special schema.org markup is needed to appear in AI Overviews or AI Mode at all. ### Is there a real study behind the "schema sites get cited more" claims circulating in SEO blogs? We could not find one. Every version we traced led back to an uncited blog post or a paraphrase of a paraphrase, not a named study with a methodology. Until one surfaces, treat the figure as marketing copy, not data. ### Why does Google's guidance sound more cautious than Bing's? The two companies have published different things. Google's is a standing developer-documentation page that explicitly rules out a special AI schema. Bing's is a reported confirmation from one product manager at a conference, without a published follow-up document of its own. ## Sources 1. [Releases - Schema.org](https://schema.org/docs/releases.html) - Schema.org (primary) 2. [Schemas - Schema.org](https://schema.org/docs/schemas.html) - Schema.org (primary) 3. [AI features and your website](https://developers.google.com/search/docs/appearance/ai-features) - Google Search Central (primary) 4. [Microsoft Bing/Copilot use schema for its LLMs](https://searchengineland.com/microsoft-bing-copilot-use-schema-for-its-llms-453455) - Search Engine Land 5. [Schema Helps Microsoft's LLMs (Copilot) Understand Your Content](https://www.seroundtable.com/schema-llms-copilot-bing-microsoft-39093.html) - Search Engine Roundtable --- --- title: "The page experience update: the real 2021-2022 rollout timeline" url: https://seomadman.com/reports/page-experience-update-timeline section: reports published: 2026-06-13T00:00:00.000Z modified: 2026-06-13T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # The page experience update: the real 2021-2022 rollout timeline ## The short answer Google previewed page experience ranking in May 2020, set a May 2021 launch date that November, then delayed the mobile rollout to mid-June 2021, completing it by the end of August 2021. Desktop followed from February to the end of March 2022. Google's current documentation now treats Core Web Vitals as the only page experience component that directly affects ranking. ## Key takeaways - Google first previewed the page experience ranking change on 28 May 2020, then set a May 2021 launch date in a follow-up post that November. - A 19 April 2021 post delayed the mobile rollout to "mid-June this year," with a later update confirming it was complete by the end of August 2021. - Desktop rollout followed a separate timeline - begin February 2022, complete by the end of March 2022 - per Google's 4 November 2021 announcement. - An August 2021 update clarified that Safe Browsing was never used as a page experience ranking signal, despite appearing in a similarly named Search Console report. - Google's current page experience documentation states that beyond Core Web Vitals, the other original components no longer "directly" affect ranking, only user satisfaction. "Page experience" reads like a single Google algorithm update in most SEO recaps, but Google's own posts describe something slower and more staged: a preview, a delay, two separate rollouts a year apart, and a documentation page that quietly narrowed what the system covers. The dates below come from Google's own Search Central posts and the "Updates" notes it appended to them afterward, not from third-party recaps. ## The mobile rollout: preview, delay, completion Google first previewed the change on 28 May 2020, in a post that explicitly separated announcement from action: "the ranking changes described in this post will not happen before next year," with at least six months' notice promised before any launch. That November, a follow-up post set the date: page experience signals would roll into ranking in May 2021, combining the three original Core Web Vitals metrics (LCP, FID, and CLS) with existing signals for mobile-friendliness, HTTPS security, and the avoidance of intrusive interstitials. The May 2021 date did not hold. A post published 19 April 2021 announced a gradual rollout "starting in mid-June this year" instead, adding that "page experience won't play its full role as part of those systems until the end of August." Google described the staged approach as adding a flavor gradually rather than all at once, so it could watch for unintended effects as the rollout reached more sites. Google later appended an update to that same post, dated 15 June 2021, saying the rollout was live globally and "will be complete by the end of August 2021" - the same window the April post had originally projected. ## Desktop, on a separate calendar a year later Desktop page experience ranking was not part of the original 2021 rollout at all. Google announced its own timeline for desktop on 4 November 2021, stating rollout would "begin in February 2022" and be "complete by the end of March 2022," using the same signal set that had already shipped on mobile - with mobile-friendliness dropped, since it does not apply to a desktop URL. A 22 February 2022 update confirmed the desktop rollout had started on schedule and reiterated the end-of-March completion date. One correction landed in between the two rollouts. Google appended an update to its original posts on 4 August 2021 clarifying that Safe Browsing "isn't used as a ranking signal," despite Safe Browsing status appearing in Search Console under its own section outside the Page Experience report. This was a correction of a misreading, not a change to what the system actually did. ## What is current in 2026 versus what Google announced in 2021 Two things have measurably changed since the original rollout, both documented by Google itself rather than inferred. First, the metric set changed on schedule with Google's own stated plan to revise it "on a yearly basis": First Input Delay (FID), one of the three original Core Web Vitals, was replaced by Interaction to Next Paint (INP) on 12 March 2024, per update notes Google added to both the 2020 and 2021 posts. Second, and more consequential for how sites should prioritize page experience work: Google's current documentation, last updated 10 December 2025, narrows what the system does in ranking terms. The original 2021 posts presented HTTPS security, mobile-friendliness, and the absence of intrusive interstitials as page experience ranking components on equal footing with Core Web Vitals, complete with a signal-by-signal comparison table for mobile versus desktop. The current documentation instead states plainly: "Beyond Core Web Vitals, other page experience aspects don't directly help your website rank higher in search results." Those other aspects, including HTTPS, mobile-friendliness, intrusive interstitials, excessive ads, and content distinction, remain listed as a self-assessment checklist, but Google now frames them as contributing to user satisfaction rather than functioning as ranking inputs on their own. ## Why we care The rollout dates matter less in 2026 than the documentation shift does. A site auditing page experience today that still treats HTTPS, mobile-friendliness, and interstitial avoidance as independent ranking levers, the way the original 2021 posts described them, is optimizing against a framing Google itself has since narrowed. Core Web Vitals is the one component Google's current documentation says "directly" affects ranking; the rest are baseline hygiene that keep a page eligible to compete, not separate scoring inputs. Treat the checklist as diagnostic, not as a set of ranking factors to chase individually - and treat any recap, including this one, as worth checking against Google's dated posts directly rather than the secondhand summary that usually survives. ## Frequently asked questions ### When did the page experience update actually finish rolling out? In two stages. Mobile rolled out from mid-June 2021 and was complete by the end of August 2021, per an update Google added to its April 2021 post. Desktop followed separately: it began in February 2022 and was complete by the end of March 2022, per Google's November 2021 announcement and a February 2022 update confirming the start. ### Is Safe Browsing part of Google's page experience ranking signal? No. Google added a clarification to its original posts on 4 August 2021 stating Safe Browsing isn't used as a ranking signal, even though Safe Browsing status appears in Search Console outside the Page Experience report. This corrected a common misreading rather than removing something that had been there. ## Sources 1. [Evaluating page experience for a better web](https://developers.google.com/search/blog/2020/05/evaluating-page-experience) - Google Search Central Blog (primary) 2. [Timing for bringing page experience to Google Search](https://developers.google.com/search/blog/2020/11/timing-for-page-experience) - Google Search Central Blog (primary) 3. [More time, tools, and details on the page experience update](https://developers.google.com/search/blog/2021/04/more-details-page-experience) - Google Search Central Blog (primary) 4. [Timeline for bringing page experience ranking to desktop](https://developers.google.com/search/blog/2021/11/bringing-page-experience-to-desktop) - Google Search Central Blog (primary) 5. [Understanding page experience in Google Search results](https://developers.google.com/search/docs/appearance/page-experience) - Google Search Central (primary) --- --- title: "Gemini 3.7 Flash reaches AI Mode, a day after its release" url: https://seomadman.com/news/gemini-3-7-flash-ai-mode section: news published: 2026-06-12T00:00:00.000Z modified: 2026-06-12T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # Gemini 3.7 Flash reaches AI Mode, a day after its release ## The short answer Google added Gemini 3.7 Flash to AI Mode's model picker on 14 August 2026, one day after releasing the model itself. The upgrade is limited to Google AI Pro and Ultra subscribers in English, selectable from the plus icon in the Ask anything bar, and Google says it improves instruction-following in AI Mode's answers. ## Key takeaways - Gemini 3.7 Flash became selectable inside AI Mode on 14 August 2026, one day after Google released the model itself. - The new model is available only to Google AI Pro and Ultra subscribers, not to AI Mode's free tier. - Google's own framing emphasises instruction-following and intent understanding rather than factual accuracy or citation quality. - Selecting the model requires opening the plus icon in AI Mode's Ask anything bar and choosing it from the model menu. Google's AI Mode picked up a new engine on 14 August 2026: Gemini 3.7 Flash, selectable from the model menu a single day after Google shipped the model itself. Robby Stein, Google's VP of Product for Search, announced the rollout directly, describing the model as "better at following instructions and understanding your intent, so you get even more helpful responses." ## What actually changed Gemini 3.7 Flash replaces the prior "workhorse" model behind AI Mode's default reasoning for subscribers who opt in. It carries a large input context window and a knowledge cutoff of March 2026, which matters for how much of a long page or conversation the model can hold in view when it answers. None of Google's public description touches ranking, indexing, or how sources get chosen; the change is confined to how the model reasons over and phrases the answer once retrieval has already happened. ## Who can use it, and how The model is gated behind a Google AI Pro or Ultra subscription and is live globally in English. Reaching it takes a manual step: opening the plus icon in AI Mode's "Ask anything" bar and picking Gemini 3.7 Flash from the model menu rather than the default option. Free-tier AI Mode users do not see the option at all. ## Why we care A model swap inside AI Mode is invisible in every ranking-tracking tool a site runs, because it changes phrasing and reasoning quality, not which pages get pulled in. It is worth watching for a narrower reason: Google has now shipped two model generations into AI Mode inside a single year, which means the answer layer above your citations is on a materially faster upgrade cycle than the ranking layer underneath it. ## Frequently asked questions ### Can free AI Mode users try Gemini 3.7 Flash? Not at launch. The model menu that exposes Gemini 3.7 Flash is limited to Google AI Pro and Ultra subscribers; Google has signalled a wider rollout may follow but has not committed to a date. ### Does a newer model change how pages get cited in AI Mode? Google's own description of the update talks about instruction-following and intent understanding, not sourcing or citation behaviour. There is no stated change to how AI Mode selects or attributes pages. ### How is this different from a Google Search algorithm update? A core or spam update changes ranking signals across classic Search. This is a swap of the underlying language model inside one feature, AI Mode, and it does not touch the ranking of blue links. ## Sources 1. [Gemini 3.7 Flash rolling out in Google Search](https://searchengineland.com/gemini-3-7-flash-rolling-out-in-google-search-485058) - Search Engine Land (primary) 2. [Google Brings Gemini 3.7 Flash To AI Mode In Search](https://www.searchenginejournal.com/google-brings-gemini-3-7-flash-to-ai-mode-in-search/585923/) - Search Engine Journal --- --- title: "Search Console adds a branded vs non-branded query filter" url: https://seomadman.com/news/search-console-branded-query-filter section: news published: 2026-06-10T00:00:00.000Z modified: 2026-06-10T00:00:00.000Z author: Adam Hafez topics: ["Search Console"] --- # Search Console adds a branded vs non-branded query filter ## The short answer Search Console's Performance report can now split query data into branded and non-branded views. Google classifies queries with an internal AI-assisted system, not manual keyword rules, and warns some queries may be misidentified. Announced 20 November 2025, the filter reached all eligible sites on 11 March 2026, covering web, image, video and news results. ## Key takeaways - Google announced the branded queries filter in Search Console on Thursday, 20 November 2025, and expanded it to all eligible sites on 11 March 2026. - The filter lives inside the Search results Performance report and splits impressions, clicks, average position and CTR into branded and non-branded views. - Google classifies branded queries with an internal AI-assisted system rather than manual keyword or regex rules, and site owners cannot edit the classification. - Google states that some queries may occasionally be misidentified due to the dynamic, contextual nature of brand classification. - The filter only appears for top-level properties with sufficient query and impression volume, so smaller or path-scoped properties may not see it yet. Search Console's Performance report has always returned one number for a query set that is really two different stories: people who already knew the brand and typed it, and people who found the page with no brand intent at all. Google's new branded queries filter, announced Thursday, 20 November 2025 and now live for all eligible sites as of 11 March 2026, splits that number in the report itself. ## How the filter works The filter sits inside the Search results Performance report and offers two views. Branded shows performance for queries that include the site's brand name or closely associated products, Google's own example is Gmail for google.com. Non-branded shows everything else. Applying it limits impressions, clicks, average position and CTR to the selected group, and it works across all four search types the report covers: web, image, video and news. Google also added a card to the Insights report that shows the click split between branded and non-branded traffic directly, without requiring the filter to be applied by hand. ## How branded queries are identified Google is explicit that this is not the regex or keyword matching already available under "Filter by query." The classification comes from what Google calls "an internal, AI-assisted system." It covers the brand name in every language the site is queried in, common misspellings, and queries that never mention the brand name but clearly refer to a unique product or service the site owns. Google also states a limitation directly: "Due to the dynamic and contextual nature of brand classification, some queries may occasionally be misidentified." The post adds that the filter changes nothing about ranking, it is a reporting segmentation only. Rollout has two eligibility conditions worth checking before assuming the filter is broken: it works only on top level properties, not URL path or subdomain properties, and only on sites with enough query and impression volume for Google's signals to classify with confidence. ## Why we care Blended Performance numbers reward brand awareness and SEO work with the same line on the same chart, and the two do not move for the same reasons. Branded query volume tracks marketing spend, press coverage and word of mouth, a site can see clicks and impressions climb for months without a single ranking improving for a query a stranger would actually type. Non-branded volume is the number that answers whether the site is winning new searchers rather than reconfirming people who already knew where to look. Splitting the two in the report where the numbers already live, using Google's own signals rather than a hand-built keyword list, makes it possible to credit organic work correctly instead of averaging it into a brand-recognition trend line. ## Frequently asked questions ### How does Google decide which queries count as branded? Google states the classification is not a regular-expression or keyword match, the kind already available under "Filter by query." It is produced by an internal, AI-assisted system that recognizes the site's brand name across languages and common typos, plus queries that name a unique product or service without using the brand name itself. ### Can a site owner add or correct branded terms manually? Google's announcement does not describe any manual override, allowlist or training step. The classification is generated by Google's system alone, and the post's own limitation notice, that some queries may occasionally be misidentified, implies there is no site-side correction available yet. ### Why is the filter missing from some properties? Google lists two conditions in its rollout notes. The filter only applies to top level properties, not URL path or subdomain properties, and it requires enough query and impression volume for Google's signals to classify reliably. ## Sources 1. [Introducing the branded queries filter in Search Console](https://developers.google.com/search/blog/2025/11/search-console-branded-filter) - Google Search Central Blog (primary) 2. [Google expands Search Console branded queries filter to all eligible sites](https://searchengineland.com/google-search-console-branded-queries-filter-expands-471387) - Search Engine Land --- --- title: "AI Overview traffic decline: seven claims, four hold up" url: https://seomadman.com/reports/ai-overview-traffic-decline-estimates-compared section: reports published: 2026-06-09T00:00:00.000Z modified: 2026-06-09T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # AI Overview traffic decline: seven claims, four hold up ## The short answer Independent measurements of how much AI Overviews cut publisher traffic disagree sharply: a randomized field experiment found outbound clicks fell 39.8%, an agency's client-data analysis found organic click-through rate down 61%, and disclosed company figures range from Chegg's 24% revenue decline to a disputed HubSpot estimate of 70 to 80%. None of these figures measure the same thing. ## Key takeaways - The first randomized field experiment on AI Overviews, posted to SSRN in April 2026, found outbound organic clicks fell 39.8% when an AI Overview appeared. - Seer Interactive's client-data analysis, updated in September 2025, found organic click-through rate on AI-Overview queries fell 61%, from 1.76% in June 2024 to 0.61%. - A Reuters Institute report published in January 2026, using Chartbeat data from over 2,500 publisher sites, found global Google referral traffic down about a third year over year. - Chegg disclosed a 24% year-over-year revenue decline in its own February 2025 earnings report and has since sued Google, naming AI Overviews as a cause. - A widely repeated claim that HubSpot lost 70 to 80% of its blog traffic traces to third-party SEO-tool estimates that HubSpot's own blog post disputes as overstated. Ask how much AI Overviews have cut into search traffic and the honest answer is: it depends which of at least seven claims you mean, and they were not all measuring the same thing. We checked each one against its original source rather than repeating whichever number showed up first in a search. Four trace to distinct, credible, dated studies with real methodology behind them. Three did not hold up as independent measurements and are excluded below rather than repeated. ## The figures that check out **A randomized field experiment: outbound clicks down 39.8%.** Saharsh Agarwal (Indian School of Business) and Ananya Sen (Carnegie Mellon University's Heinz College) built a Chrome extension that randomly assigned 1,065 US-based participants to see AI Overviews or have them hidden, across 68,089 searches. Conditional on an AI Overview appearing, outbound organic clicks fell 39.8% and zero-click searches rose 34.5%, with no measurable gain in reported satisfaction or information quality. The paper was first posted to SSRN on 3 April 2026 and last revised 17 June 2026. It is the only figure in this report built on random assignment rather than a before-and-after comparison, which is what lets the authors call the effect causal rather than correlational. **An agency's client data: organic click-through rate down 61%.** Seer Interactive tracks 3,119 informational search terms across 42 client organizations, pulling Google Search Console and Google Ads data alongside third-party AI Overview presence tracking. Its September 2025 update found organic click-through rate on queries where an AI Overview appeared fell from 1.76% in June 2024 to 0.61%, a 61% relative drop, against 25.1 million tracked organic impressions. This is not a random sample of the web; it is Seer's own client accounts, weighted toward the query types most exposed to AI Overviews in the first place. **Industry-wide referral data: publisher traffic down about a third.** The Reuters Institute for the Study of Journalism's Journalism and Technology Trends and Predictions 2026 report, published 12 January 2026, cites Chartbeat data across more than 2,500 publisher sites showing global Google search referral traffic down roughly a third year over year to November 2025. A separate Chartbeat cut reported by Axios in March 2026 found the decline was uneven by publisher size: about 22% for large publishers, 47% for medium ones, and 60% for small ones, over the same kind of window. Neither figure isolates AI Overviews from the rest of how Google's results page has changed; both describe referral traffic broadly. **One company's own disclosed number: revenue down 24%.** Chegg reported fourth-quarter 2024 revenue of $143.5 million, down 24% year over year, in its own 24 February 2025 earnings release, and has since sued Google, naming AI Overviews as a cause of its traffic and revenue decline. This is the only figure in the set that is a company's own audited financial disclosure rather than a third-party traffic estimate, and it measures revenue, not clicks or visits. ## The figures we could not verify, and why **"Business Insider down 55%, April 2022 to April 2025" does not trace cleanly to that number.** The underlying reporting is real: the Wall Street Journal, via Similarweb data, reported in June 2025 that organic search traffic to Business Insider, HuffPost and the Washington Post was down roughly 50% over three years, and that the New York Times' organic-search traffic share fell from 44% to 36.5% over the same period. The specific "55%, April 2022 to April 2025" framing that circulates in SEO blogs is a more precise restatement than the original reporting supports, so this report uses the traceable ~50%-over-three-years figure instead and does not repeat the sharper number. **CNN's decline is Similarweb-via-press, not a named study.** The New York Post reported in July 2025, citing Similarweb, that CNN.com traffic fell 28% year over year to 311.7 million visits. That figure is real and traceable. The wider "27 to 38%" range attached to CNN elsewhere in SEO content compiles several different comparison windows into one number without naming which is which, so this report cites the one figure with a clear source and period (28%, year over year to mid-2025) and drops the compiled range. **HubSpot's 70 to 80% is a disputed third-party estimate, not HubSpot's own figure.** SEO-tool analyses (Surfer, AthenaHQ and others) estimate HubSpot's organic blog traffic fell from roughly 24 million monthly visits to 6 to 7 million between late 2024 and early 2025, a 70 to 75% drop by their own math. HubSpot's own July 2026 blog post engages with these estimates directly and argues they overstate the decline and ignore a deliberate multi-year shift away from blog pageviews toward YouTube, podcasts and newsletters. This report includes the claim because it is traceable to named tools and HubSpot's own response, but treats it as the least reliable figure here: an outside estimate the subject itself contests. ## Why these are not directly comparable **They measure different metrics.** A click count, a click-through rate, total site visits, and company revenue are four different numbers that can move independently. Click-through rate can fall even when raw clicks hold steady, if impressions rise faster; revenue can fall for reasons that have nothing to do with search, including layoffs, pricing changes or a shrinking market. Reading any one of these as a stand-in for "traffic" erases what it actually counted. **They cover different query sets and site types.** The SSRN experiment used a general panel of US searchers across whatever queries they ran. Seer Interactive's client accounts are weighted toward informational queries, the category most exposed to AI Overviews. Chegg is a single company in education technology; CNN and Business Insider are general news. A 39.8% average across all query types and an 81% estimate for one company's blog are not describing the same population, even before either number's own uncertainty is considered. **They cover different, overlapping time windows.** The SSRN data was collected in early 2026; Seer's comparison starts in June 2024; the Reuters Institute figure is year-over-year to November 2025; Chegg's is a single quarter against the same quarter a year earlier. AI Overviews expanded in reach and query coverage across all of this period, so a study run later is measuring a more mature, further-rolled-out feature than one run in 2024, independent of any difference in method. ## Why we care **A single "AI Overviews cut traffic by X%" headline number is not a complete claim.** Whether the right figure for a forecast is 24%, 39.8%, 61% or something closer to 80% depends entirely on whether you are modeling clicks, click-through rate, total visits or revenue, for what kind of query, over what window, and that dependency is exactly what most quoted versions of this stat strip out. **The rigor of the source matters more than the size of the number.** A randomized experiment with a modest 39.8% effect is stronger evidence than an unverified 80% estimate the subject company disputes. Before using any AI Overview traffic figure in a deck or a forecast, trace it to its original study, note whether the design was randomized or observational, and check that its metric matches the one you actually need. ## Frequently asked questions ### Which AI Overview traffic decline figure is the most reliable? The 39.8% figure, because it is the only one built on randomized assignment rather than an observational comparison. Saharsh Agarwal and Ananya Sen's field experiment randomly hid or showed AI Overviews to 1,065 people, which is the one design here that can support a causal claim rather than a correlation. ### Why do Seer Interactive's numbers and the SSRN study disagree so much? They measure different things for different populations. Seer's 61% figure is a click-through-rate drop, clicks divided by impressions, on informational queries inside 42 client accounts. The SSRN study measures the count of outbound clicks per search across a general panel. A CTR can fall by more than a click count falls if impressions on AI-Overview queries also rose over the same period, which is what Seer's own data shows. ### Is the HubSpot 70 to 80% figure real? It is a real, traceable estimate from third-party SEO tools, not a number HubSpot itself has confirmed. HubSpot's own July 2026 blog post addresses the claim directly and argues the decline is smaller and partly a deliberate strategic shift away from blog pageviews, not solely an AI Overview effect. ## Sources 1. [The Impact of Google AI Overviews on Publisher Traffic and User Experience: Evidence from a Field Experiment](https://ssrn.com/abstract=6513059) - SSRN (Saharsh Agarwal, Indian School of Business; Ananya Sen, Carnegie Mellon University) (primary) 2. [AIO Impact on Google CTR: September 2025 Update](https://www.seerinteractive.com/insights/aio-impact-on-google-ctr-september-2025-update) - Seer Interactive (primary) 3. [Journalism and Technology Trends and Predictions 2026](https://reutersinstitute.politics.ox.ac.uk/sites/default/files/2026-01/Trends_and_Predictions_2026.pdf) - Reuters Institute for the Study of Journalism (primary) 4. [Exclusive: Small publishers hit hardest by search traffic declines](https://www.axios.com/2026/03/17/chartbeat-search-traffic-ai-chatbots) - Axios 5. [Google's AI search features are killing traffic to publishers](https://techcrunch.com/2025/06/10/googles-ai-overviews-are-killing-traffic-for-publishers/) - TechCrunch 6. [Top news sites suffer drastic drop in web traffic since Google added AI search](https://www.yahoo.com/news/top-news-sites-suffer-drastic-214616304.html) - New York Post 7. [Chegg Reports 2024 Fourth Quarter and Full Year Financial Results](https://www.chegg.com/about/newsroom/press-release/chegg-reports-2024-fourth-quarter-and-full-year-financial-results) - Chegg, Inc. (primary) 8. [Did HubSpot Really Lose 80% of Blog Traffic? Here's What Actually Happened, and What It Means for Marketers](https://blog.hubspot.com/marketing/blog-traffic-loss-explainer) - HubSpot (primary) --- --- title: "Search Central Live expands to Bogota and Ciudad de Mexico" url: https://seomadman.com/news/search-central-live-events-latam-europe section: news published: 2026-06-08T00:00:00.000Z modified: 2026-06-08T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Search Central Live expands to Bogota and Ciudad de Mexico ## The short answer Google's Search Central team announced two in-person events for September and October 2026: a three-day Deep Dive conference in Barcelona, Spain, and, for the first time ever in Latin America, Search Central Live sessions in Bogota and Ciudad de Mexico. Both are free, limited-seat gatherings covering Google Search, Discover and News. ## Key takeaways - Search Central Live comes to Bogota, Colombia on October 19, 2026, the first time Google has held the event there. - Google returns to Ciudad de Mexico on October 15, 2026, following earlier editions there and past events in Argentina and Brazil. - Search Central Live Deep Dive Europe runs three days in Barcelona, Spain, from September 30 to October 2, 2026. - The Barcelona Deep Dive covers crawling, indexing, ranking and search trends across sequential daily tracks rather than one overview session. - All three events are free but seat-limited, and each requires a separate application for an invitation. Google's Search Central team posted two event announcements this year that, taken together, say more about where Google is investing in-person community time than about any ranking change: a three-day Deep Dive conference in Barcelona, Spain, and, new for 2026, Search Central Live sessions in Bogota, Colombia and Ciudad de Mexico. Neither event changes how Search works. Both are calendar items for anyone in the region who wants a seat in the room. ## Latin America gets its first Bogota date The September 8, 2026 post says Search Central Live is coming to Bogota "for the first time ever," on October 19. The week before, on October 15, the team returns to Ciudad de Mexico, a city that has hosted the event before. Google frames both as part of a broader Latin America push that already includes past editions in Argentina and Brazil. The invitation list is wide: SEOs, publishers, creators, digital marketers and website owners. Sessions cover Google Search, Google Discover and News, with some presentations in English and Spanish translation available. Ciudad de Mexico runs October 15 from 8:30am to 1:30pm; Bogota runs October 19 from 2:30pm to 6:30pm. Registration for both closes September 16, 2026, with confirmations going out September 21. ## Barcelona runs a different format entirely The Europe event, announced July 6, 2026, is not a standard Search Central Live. Search Central Live Deep Dive Europe 2026 runs three full days in Barcelona, from September 30 to October 2, built as a sequential curriculum rather than a set of standalone talks: crawling and Search Console diagnostics on day one, rendering and indexing (including canonicalization and internationalization) on day two, and serving, ranking and search features, plus Google Trends, on day three. Attendance is free but capped, and Google required a separate application by September 5, 2026, with invitations going out by September 10. The event is English-only, with no translation service, and Google says it prioritizes European-based applicants while still accepting global ones. ## Why we care None of this moves a single ranking. What it tells a publisher or SEO team is where Google is choosing to put its Search Relations staff face to face with the community, and Latin America getting a first Bogota date alongside a returning Ciudad de Mexico slot is a real signal about regional investment, not a minor scheduling note. If your team operates in Colombia, Mexico or Spain, these are free seats worth applying for early: all three events describe limited capacity and a formal registration deadline, not walk-up attendance. ## Sources 1. [Search Central Live is coming to Bogota and Ciudad de México](https://developers.google.com/search/blog/2026/09/search-central-live-mexico-and-colombia) - Google Search Central Blog (primary) 2. [Search Central Deep Dive Europe 2026: Apparently we're going to Barcelona](https://developers.google.com/search/blog/2026/07/search-central-live-deep-dive-europe-2026) - Google Search Central Blog --- --- title: "AMP's traffic record: five publishers, five different outcomes" url: https://seomadman.com/reports/amp-traffic-impact-cases-compared section: reports published: 2026-06-05T00:00:00.000Z modified: 2026-06-05T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # AMP's traffic record: five publishers, five different outcomes ## The short answer Five named AMP case studies disagree on traffic. Independent.ie gained roughly 55% mobile search traffic; Belfast Telegraph, under the same publisher, saw none. Chartbeat and the Daily Beast found only 1 in 3 of 159 publishers had a clear gain. Kinsta lost 59% of mobile leads. Search Engine Land and Future plc later dropped AMP with no traffic loss. ## Key takeaways - Independent.ie reported roughly 55% higher mobile search traffic from AMP, but its own Head of SEO credited a first-mover advantage, not AMP itself. - Chartbeat and the Daily Beast analyzed 159 publishers and found only 34% (1 in 3) showed a statistically clear traffic increase from AMP, averaging +22% with wide variance. - Kinsta, a lead-generation site rather than a publisher, saw mobile leads fall 59% after two months on AMP and reversed the rollout. - Belfast Telegraph, launching AMP in 2019 under the same publisher group as Independent.ie, measured no traffic change but a 49% drop in mobile digital ad revenue. - Search Engine Land and Future plc removed AMP in 2021 and 2022 and reported no traffic loss; Future's audience director said monetization improved. Ask whether AMP helped or hurt publisher traffic and the honest answer is: both, depending on which real site you look at. Five documented, named cases below span a lead-generation host, a national newspaper group's two different titles, a 159-publisher academic-style study, and two publishers who later ripped AMP out. None of them agree, and the disagreement is the finding. ## Five sites, five results **Independent.ie gained roughly 55% mobile search traffic when it adopted AMP.** Daniel Smullen, Head of SEO at Independent News & Media, reported the increase directly, then supplied the caveat that matters most: he attributed the gain to "the first-mover advantage of additional traffic from the AMP Top Stories carousel, and also because at that time, we had a terribly slow mobile site." Early adoption and a bad baseline, not AMP in the abstract, did most of the work. **Belfast Telegraph, a regional title in the same publisher group, launched AMP in 2019 and saw no measurable traffic change at all - but a 49% decline in mobile digital ad revenue.** Smullen reported both cases in the same article. Same company, same technology, different title, and the opposite result on both axes that mattered: traffic held flat while ad revenue collapsed, largely from AMP's ad-format and rendering restrictions. **Chartbeat and the Daily Beast ran the closest thing here to a controlled study, and found the mixed picture holds at scale.** Chartbeat compared traffic before and after AMP implementation across 159 publishers and found an average lift of +22%, but only 34% of those publishers, about 1 in 3, showed a statistically significant increase at 95% confidence. The Daily Beast's own A/B test inside the same research found no statistical evidence of higher Google-driven pageviews from its AMP pages, and lower revenue on the AMP format. **Kinsta, a managed WordPress hosting company with no news content, lost 59% of its mobile leads after two months running AMP**, alongside a 16.67% drop in mobile newsletter signups and a 10.53% drop in mobile account creations. Kinsta disabled AMP and published the numbers as a warning to other conversion-focused sites: a template built to strip a slow news article down to load fast can just as easily strip out the trust signals and forms a B2B site needs to convert. **Search Engine Land and Future plc both later removed AMP and reported no traffic loss.** Search Engine Land saw a 34% drop specifically in AMP traffic between July and August 2021, after Twitter stopped referring mobile users to AMP pages and Google's Top Stories carousel began admitting non-AMP results; it turned AMP off that November. Future plc migrated 80 to 90% of its pages off AMP starting the prior autumn, and Stuart Forrest, its director of audience operations, said plainly: "there's been no impact on volume, and all the impact on revenue that we had hoped for." ## Why these numbers cannot be averaged together **The sites are not comparable populations.** A news publisher racing to win Google's AMP-only Top Stories carousel in 2016, a B2B hosting company measuring form fills in 2018, and a publisher group removing AMP once the carousel stopped requiring it in 2021 are three different businesses answering three different questions. Averaging Independent.ie's +55% against Kinsta's -59% produces a number that describes nothing real. **The baseline before AMP explains more variance than AMP itself.** Independent.ie's own account credits a "terribly slow mobile site" for most of its gain - AMP looks best precisely where the existing mobile experience was worst. Kinsta and Future plc, already investing in site speed for conversion or Core Web Vitals reasons, had less room for AMP's stripped-down template to help and more to lose from its ad and layout restrictions. **The competitive incentive changed underneath every case.** Through mid-2021, AMP was the only way into Google's Top Stories carousel on mobile, which is exactly the incentive Independent.ie and the Daily Beast were responding to. Once Google's Page Experience update removed that requirement in July 2021 and let any page meeting Core Web Vitals thresholds qualify, the traffic case for keeping AMP mostly disappeared - which is precisely when Search Engine Land and Future plc both left without losing traffic. ## Why we care **AMP's own relevance has faded since Core Web Vitals became the metric that actually gates Top Stories.** Google removed the AMP requirement from mobile Top Stories in July 2021 in favor of Core Web Vitals thresholds any page can meet, which is why the two most recent cases here are both removals with no traffic cost, not adoptions with a traffic gain. A technology-adoption case study from 2016 is not evidence about 2026's ranking mechanics. **A single AMP traffic number, quoted without its site type and era, is not a citable claim.** "AMP increased traffic by 55%" and "AMP cut traffic-driving leads by 59%" are both real, verified, named results. Neither one is "the effect of AMP" - each is the effect of AMP on one specific site, in one specific competitive and technical context, and reporting one without the other misrepresents both. **The pattern that actually replicates is about baseline speed, not AMP.** Every case where AMP helped involved a site that was slow before adopting it; every case where removing AMP cost nothing involved a site whose non-AMP pages already met modern performance thresholds. That is a Core Web Vitals story wearing an AMP costume, and it is the more useful takeaway for [technical SEO](/topics/technical-seo) in 2026 than any single case study's headline number. ## Frequently asked questions ### Did AMP increase traffic or not? Both happened, on real sites, and neither result generalizes. Independent.ie gained roughly 55% mobile search traffic; Chartbeat and the Daily Beast found only a third of 159 publishers had a statistically clear gain at all. The honest answer is that AMP's effect depended on how slow a site already was, its competitive category and the era it launched in. ### Is AMP still worth implementing in 2026? Google removed the AMP requirement from Top Stories in mid-2021, replacing it with Core Web Vitals thresholds any page can meet. Two of the five cases here, Search Engine Land and Future plc, removed AMP afterward with no measured traffic loss, which is the more current evidence than any adoption-era case study. ### Why did Kinsta's result look so different from the news publisher cases? Kinsta is a hosting company measuring leads and signups, not a newsroom measuring pageviews. AMP's stripped-down template that helps a slow news article load faster can just as easily strip out the trust signals and forms that a B2B site needs to convert a visitor. ## Sources 1. [How AMP Impacts Rank in Google Top Stories, Discover & Organic Search](https://www.searchenginejournal.com/amp-google-top-stories-case-study/403365/) - Search Engine Journal (primary) 2. [Research study: only 1 in 3 publishers see a clear traffic boost from AMP](https://chartbeat.com/resources/research/research-study-1-3-publishers-see-clear-traffic-boost-amp/) - Chartbeat 3. [Google AMP case study: leads dropped by 59% (how to disable it)](https://kinsta.com/blog/disable-google-amp/) - Kinsta 4. [Why we're turning off AMP pages at Search Engine Land](https://searchengineland.com/why-were-turning-off-amp-pages-at-search-engine-land-376228) - Search Engine Land 5. [Why Future waved bye bye to Google's AMP and hasn't looked back](https://digiday.com/media/the-juice-isnt-worth-the-squeeze-why-future-waved-bye-bye-to-googles-amp-and-hasnt-looked-back/) - Digiday 6. [AMP won't be required for Google's Top Stories section](https://searchengineland.com/amp-wont-be-required-for-googles-top-stories-section-335276) - Search Engine Land --- --- title: "Schema.org's vocabulary hit 823 types with version 30.0 in 2026" url: https://seomadman.com/reports/schema-org-vocabulary-growth-2026 section: reports published: 2026-06-04T00:00:00.000Z modified: 2026-06-04T00:00:00.000Z author: Adam Hafez topics: ["Structured data", "Technical SEO"] --- # Schema.org's vocabulary hit 823 types with version 30.0 in 2026 ## The short answer Schema.org's own documentation lists the vocabulary at 823 Types, 1,529 Properties, 19 Datatypes, 96 Enumerations and 535 Enumeration members as of version 30.0, released 19 March 2026. In June 2026, Google and the Schema.org community published a companion usage-statistics dataset covering term adoption across millions of domains, updated monthly on GitHub. ## Key takeaways - Schema.org's schemas.html page states the vocabulary currently consists of 823 Types, 1529 Properties, 19 Datatypes, 96 Enumerations and 535 Enumeration members. - Version 30.0, released 19 March 2026, added equivalence annotations and EU Digital Product Passport examples on top of the existing vocabulary. - On 4 June 2026, Schema.org's blog announced a usage-statistics dataset built with Google, published in CSV and JSON on the project's GitHub repository and updated monthly. - The dataset reports term usage across millions of domains at a high level, not a count of any single domain's markup, and schema.org's post names no specific domain total. - This measures vocabulary size and term-level usage tracking, a different question from what share of pages carry structured data at all. Schema.org's vocabulary is not a fixed list. It is versioned software with its own release notes, and as of version 30.0, released 19 March 2026, schema.org's own count page puts it at 823 Types, 1,529 Properties, 19 Datatypes, 96 Enumerations and 535 Enumeration members. Three months later, Google and the Schema.org community published a second, separate dataset: real usage statistics for those terms across the live web, updated monthly. Together the two answer a question our [Web Almanac piece on structured-data adoption](/studies/structured-data-adoption-web-almanac) does not: not how many pages carry structured data, but how large the vocabulary they draw from actually is, and how its real-world usage is now measured at the term level. ## The vocabulary itself, by the numbers Schema.org's schemas.html page states the count directly: "The vocabulary currently consists of 823 Types, 1529 Properties 19 Datatypes, 96 Enumerations and 535 Enumeration members." Version 30.0, the release that count reflects, shipped 19 March 2026 with equivalence annotations and EU Digital Product Passport examples added on top of the existing schema. The releases.html changelog shows a steady release cadence rather than one big jump: 29.0 in March 2025 added vocabulary for financial incentives, legislation and product shipping; 29.3 in September 2025 expanded recipe-ingredient and marketplace terms; 29.4 in December 2025 covered "many schema and infra updates" before 30.0 landed the following March. Schema.org's public release notes do not publish a type-by-type historical count for older versions, so this piece reports the current, verified snapshot rather than inventing a growth percentage the source does not state. ## The new usage-statistics dataset On 4 June 2026, Schema.org's blog announced a dataset built in collaboration with Google: aggregate usage statistics for schema.org terms across the public web, "available on the official Schema.org GitHub repository in CSV and JSON formats." The post states the dataset is "updated monthly" and "offers a high-level view of term usage across millions of domains," with this first release contributed by Google. That is a term-level view, not a page-level one: it shows how often a given type or property appears across the dataset's domain scope, not whether any single site carries valid markup. Schema.org's own post names no specific domain-count figure beyond "millions of domains," so a publisher using this dataset gets adoption signal at the vocabulary-term level, a different unit than the format-level presence counts a page-crawl study like the Web Almanac reports. ## Why we care **Vocabulary size and page adoption are different measurements, and conflating them misleads.** The Web Almanac's 41% JSON-LD figure counts pages carrying the format; this dataset counts how often specific schema.org terms appear across domains. A publisher deciding which types to implement needs the second number, not the first. **The dataset is new enough that the useful move right now is understanding its shape, not its trend.** Schema.org has published no prior version of this usage data, so there is no year-over- year comparison to report yet. What is verifiable today is that Google backed a monthly-updated, publicly downloadable term-usage dataset, which is itself the news. **The 823-type figure is a snapshot, not a growth rate.** Without a comparable historical count from schema.org's own documentation, any percentage claiming the vocabulary "grew by X%" since an earlier version would be invented. The honest claim is the current count, sourced directly, and the cadence of releases that produced it. ## Sources 1. [Schema.org - full hierarchy, all layers (vocabulary count)](https://schema.org/docs/schemas.html) - Schema.org (primary) 2. [Schema.org release history](https://schema.org/docs/releases.html) - Schema.org (primary) 3. [Announcing the Schema.org Usage Statistics Dataset](https://blog.schema.org/2026/06/04/announcing-the-schema-org-usage-statistics-dataset/) - Schema.org (primary) --- --- title: "The May 2026 core update finished after 11 days, its second this year" url: https://seomadman.com/news/may-2026-broad-core-update-complete section: news published: 2026-06-03T00:00:00.000Z modified: 2026-06-03T00:00:00.000Z author: Adam Hafez topics: ["Core updates", "Technical SEO"] --- # The May 2026 core update finished after 11 days, its second this year ## The short answer Google's May 2026 broad core update ran from 21 May to 2 June, 11 days and 21 hours according to the Search Status Dashboard, and it was Google's second confirmed core update of 2026 after March. Independent analysis from Glenn Gabe of GSQi found early, severe volatility in health, finance and gambling, with commodity-content sites depressed since January staying down. ## Key takeaways - The May 2026 core update started on 21 May and completed on 2 June, a rollout of 11 days and 21 hours per Google's Search Status Dashboard. - It was Google's second confirmed core update of 2026, following the March 2026 core update. - Analyst Glenn Gabe of GSQi reported early, severe volatility in YMYL sectors including health, finance and gambling. - Sites already depressed by January 2026's action against listicle and commodity content stayed down or declined further during the rollout. - A site scaling lower-quality content and AI translations across multiple languages saw significant ranking drops, per Gabe's case review. Google's May 2026 broad core update is finished. The Search Status Dashboard records the rollout as starting 21 May and completing 2 June, 11 days and 21 hours, the second core update Google has confirmed in 2026 after March. That is inside the roughly two-week window Google typically gives for a broad core update, and short enough that a decline showing up after 2 June belongs to something else. ## What a core update does A core update re-scores the index against a revised sense of relevance and quality. Nothing is flagged and nothing is penalized in the way a spam action penalizes a specific practice. A page can lose visibility without anything new having gone wrong on it, and the only real recovery path runs through the content itself, not through a fix-and-resubmit cycle. ## What independent analysis found Glenn Gabe of GSQi, who tracks core updates across a large set of client and public sites, called May "much more like a typical core update" than March, which he described as comparatively mild. His review found early, severe volatility concentrated in health, finance and gambling, the kind of YMYL sectors that tend to move hardest and fastest once a core update starts landing. Sites that had already lost visibility in January 2026's action against listicle and self-serving commodity content mostly stayed down through May, and some declined further. Gabe also documented a case of a site scaling lower-quality content and AI-generated translations across multiple languages, which saw a significant ranking drop once the update reached it. ## How to check your own data **Mark the two dates on your own series first.** 21 May and 2 June are the edges; movement that starts well before the first or persists well past the second is a different problem wearing the update's name. **Segment by content type before concluding anything.** Gabe's cases moved at the level of a content programme, not a whole site. A YMYL section swinging while the rest of the site holds steady is consistent with what this update did elsewhere. **Check whether the page was already depressed.** A page that lost visibility in an earlier update and never recovered is not new evidence about May; it is old evidence still sitting in the data. ## Why we care If your traffic moved between 21 May and 2 June, the diagnostic question is whether the pages that moved sit in a sector this update visibly touched, or carry a content pattern - AI translation at scale, thin commodity pages, YMYL claims without backing - that shows up in the case reviews above. That framing separates a real core-update effect from a coincidence that happened to land in the same eleven days, and it is the same test to apply the next time a core update rolls through. ## Frequently asked questions ### How long did the May 2026 core update take to roll out? 11 days and 21 hours, per Google's own Search Status Dashboard. It started 21 May and completed 2 June 2026, close to the roughly two-week window Google typically states for a broad core update. ### Was this a bigger update than the March 2026 core update? Analyst Glenn Gabe of GSQi described it as behaving like a typical core update where March had been comparatively mild, with more sites and verticals showing measurable movement during the May rollout. ## Sources 1. [Google Search Status Dashboard](https://status.search.google.com/summary) - Google (primary) 2. [Google Search ranking updates documentation](https://developers.google.com/search/updates/ranking) - Google Search Central (primary) 3. [Google May 2026 core update rollout is now complete](https://searchengineland.com/google-may-2026-core-update-rollout-is-now-complete-479119) - Search Engine Land 4. [Core Roars Back With Google's May 2026 Broad Core Update - Interesting Cases, Findings, and Analysis](https://www.gsqi.com/marketing-blog/core-roars-back-google-may-2026-core-update-analysis/) - GSQi (Glenn Gabe) --- --- title: "Merchant Center adds AI Performance Insights for share of voice" url: https://seomadman.com/news/merchant-center-ai-performance-insights section: news published: 2026-05-20T00:00:00.000Z modified: 2026-05-20T00:00:00.000Z author: Adam Hafez topics: ["AI search", "Structured data"] --- # Merchant Center adds AI Performance Insights for share of voice ## The short answer Google is rolling out AI performance insights in Merchant Center, a report on how a brand is discovered on AI Mode, AI Overviews and Gemini. It covers share of voice against similar brands, shopping funnel performance, product term insights, and product attribute gaps. Google announced it 20 May 2026 for the US, Canada, Australia, India and New Zealand. ## Key takeaways - Google announced AI performance insights for Merchant Center on 20 May 2026, alongside conversational product attributes. - Share of voice benchmarks a brand's visibility on AI-driven experiences across Search and Gemini against similar brands. - Shopping funnel performance breaks results into discovery, evaluation and purchase stages of the shopping journey. - Product term insights show popular search terms and the merchant's share of voice for each one. - Product attribute insights flag missing specifications, such as color, style or material, using an attribute completeness score. Merchant Center is getting a dedicated report for the part of shopping search that used to be invisible: what happens when a product shows up inside an AI Mode answer, an AI Overview or a Gemini shopping conversation instead of a standard search results page. Google announced AI performance insights on 20 May 2026, alongside a separate feature for conversational product attributes, and framed both as tools for a shopping journey that increasingly starts as a conversation rather than a keyword. ## The four things the report measures Google's Merchant Center Help documentation defines AI performance insights as four components, each addressing a different blind spot in AI-driven shopping traffic. **Share of voice** shows a brand's visibility on AI-driven experiences across Search and Gemini, benchmarked against brands Google considers similar. It is the headline metric: not raw impressions, but a competitive share. **Shopping funnel performance** breaks results into the stages of a shopping journey Google already uses to classify conversational queries: discovery, evaluation and purchase. A merchant can see whether they show up when someone is exploring options, comparing specifications, or close to buying. **Product term insights** surface the popular product terms searched by users in AI conversations, alongside the merchant's share of voice for each term. This is closer to a conversational-query report than a keyword report. **Product attribute insights** flag the specifications users search for most, such as color, style or material, and identify which products lack that structured data using an attribute completeness score. ## Rollout markets and limits Google's own blog post and Search Engine Land's coverage both describe the rollout as reaching the United States, Canada, Australia, India and New Zealand, arriving "in the coming months" rather than simultaneously. Google's Merchant Center Help page confirms the same five markets and adds two limits worth noting before treating the numbers as complete: the data currently covers English-language queries only, and it is strictly limited to organic AI traffic, such as free listings, with Paid Ads traffic excluded. This is a separate story from the [2026 Merchant Center product data specification update](/news/merchant-center-product-data-spec-2026/), which changed shipping and video attributes and the minimum image resolution. AI performance insights adds a reporting layer on top of the same catalog; it does not change what a merchant is required to submit. ## Why we care Share of voice is the metric that matters here, because it is the first time Merchant Center has offered any competitive visibility number for AI surfaces at all. A merchant can currently see clicks and impressions for their own listings, but not how that compares to similar brands showing up in the same AI Mode or Gemini conversation. Combined with product attribute gaps, the report gives merchants a concrete lever: fill in the missing color, style or material data that AI systems use to match a query, and watch whether share of voice moves. Until the English-only, organic-only limits lift, though, treat the numbers as a partial view rather than the full picture of AI shopping performance. ## Frequently asked questions ### What does share of voice measure in AI performance insights? It measures the percentage of impressions a brand receives on AI-driven shopping experiences, across Search and Gemini, compared to brands Google classifies as similar. It is a relative benchmark, not a standalone visibility count. ### Which countries get AI performance insights first? Google announced the rollout for the United States, Canada, Australia, India and New Zealand on 20 May 2026, describing it as arriving "in the coming months" rather than all at once. Google's own help center confirms the same five markets, currently for English-language queries only. ### Does the report include paid Shopping ads traffic? No. Google's Merchant Center help documentation states the report is strictly limited to organic AI traffic, such as free listings, and does not include Paid Ads traffic. ## Sources 1. [How we're helping retailers thrive with new Universal Commerce Protocol features and AI tools on Google](https://blog.google/products-and-platforms/products/shopping/shopping-updates-google-marketing-live/) - The Keyword (Google) (primary) 2. [About AI performance insights](https://support.google.com/merchants/answer/17200695?hl=en) - Google Merchant Center Help 3. [Google launches AI Performance Insights and Conversational Attributes in Merchant Center](https://searchengineland.com/google-launches-ai-performance-insights-and-conversational-attributes-in-merchant-center-478108) - Search Engine Land --- --- title: "Google's review-fraud scale, and its April 2026 policy tightening" url: https://seomadman.com/reports/google-review-fraud-enforcement-scale section: reports published: 2026-04-17T00:00:00.000Z modified: 2026-04-17T00:00:00.000Z author: Adam Hafez topics: ["Technical SEO"] --- # Google's review-fraud scale, and its April 2026 policy tightening ## The short answer Google's own Maps trust and safety report states it blocked or removed over 292 million policy-violating reviews and 13 million fake Business Profiles in 2025. On 16 and 17 April 2026 Google published an automated spam-response protocol and a Rating Manipulation policy update banning staff review quotas and soliciting reviews that name an employee. ## Key takeaways - Google's own blog post states it blocked or removed over 292 million policy-violating reviews and over 13 million fake Business Profiles in 2025. - These are Google's self-reported totals, with no independent audit behind them; treat them as an attributed claim, not a verified count. - On 16 April 2026, Google documented its automated response to a review-spam spike: remove fake content, pause new reviews, alert the owner, and show a notification banner. - Google's Rating Manipulation policy now bans merchants directing staff to solicit a set number of reviews, or reviews naming a specific staff member. - Google still permits a business to ask a genuine customer for a review; what changed is the ban on quotas and on coaching staff to seed employee names into the request. Google publishes almost nothing about how it enforces its core web spam policy, but it publishes a great deal about how it polices Google Maps reviews. On 16 April 2026 Google put a number on its 2025 review-fraud enforcement, and the following day tightened the Rating Manipulation policy that staff-solicited reviews fall under. Both are traceable to Google's own pages, which is more than can be said for most fraud-enforcement claims that circulate in local SEO forums. ## The 2025 enforcement numbers, as Google reports them Google Group Product Manager Bibek Samantaray's 16 April 2026 post, "New ways we're protecting businesses on Maps," states that in 2025 Google's systems and human reviewers "blocked or removed over 292 million policy-violating reviews," alongside publishing more than 1 billion reviews Google judged helpful. The same post states Google removed "over 13 million fake Business Profiles," placed posting restrictions on "more than 782,000 policy-violating accounts," and blocked 79 million inaccurate or unverified edits to business listings. These are Google's own numbers, stated in Google's own name on Google's own blog, which clears this site's bar for a citable figure. It is not the same as an independently audited count: no outside party has access to Google's review pipeline to confirm 292 million against a raw log, and Google does not publish a methodology for how a "policy-violating" review is flagged versus a genuine negative one caught in the same sweep. Treat the figure as Google's own claimed scale of the problem and its own claimed response to it, not as a number this report can independently stand behind. ## What changed in the Rating Manipulation policy on 17 April 2026 Google's Maps user-generated-content policy - the one Business Profile owners are held to - was updated to add two explicit prohibitions under Rating Manipulation: merchants "requesting that staff solicit a certain number of reviews," and merchants "requesting that staff solicit reviews that include specific content, including content that identifies a staff member." Both practices were common in local business review campaigns before this update; neither was named as a violation in the policy text until it changed. The policy does not ban a customer from naming an employee unprompted, and it does not ban asking a genuine customer for a review at all. What it prohibits is the business directing staff to chase a quota, or to steer the customer's wording toward naming the staff member who served them - the tactic behind a lot of "ask happy customers to mention Jake by name" review-generation advice that circulated before the update. Google's enforcement for a detected violation runs through the same mechanism as any other rating manipulation: content removal and, for repeat violations, restrictions on the profile's ability to collect new reviews. ## The automated response to a detected review-spam spike The same 16 April 2026 post documents what happens when Google's systems detect a sudden surge of fake reviews hitting a single Business Profile: Google states it will "quickly remove" the fake content, pause the profile from receiving new reviews, alert the profile owner, and display a public notification banner telling anyone viewing the listing that reviews are temporarily paused and why. That last step is the one most owners do not expect - the pause is visible to every customer looking at the listing, not just reported quietly to the business. ## Why we care For a Business Profile owner, both changes point the same direction: away from managed review campaigns and toward reviews nobody at the business shaped the wording of. A quota tied to staff incentives and a script that tells customers to name their server are now both named violations rather than gray-area tactics, and Google's own account of its 2025 enforcement - whatever its true precision - says it is actively looking for exactly this pattern at scale. The safer version of asking for reviews is still open: ask a genuine customer to share their real experience, without telling them what to say or who to mention. ## Frequently asked questions ### Did Google really block 292 million reviews in 2025? That is Google's own published figure, from a Google Maps blog post dated 16 April 2026: over 292 million policy-violating reviews blocked or removed, alongside more than 1 billion helpful reviews published. It is Google's self-reported total, not a number any independent auditor has verified. ### Can a business still ask customers to leave a review that mentions a staff member? A customer can still write '[Name] was great' on their own. What Google's April 2026 Rating Manipulation policy update bans is the business directing staff to solicit reviews that name them, or to hit a review quota - both are now explicit policy violations, not just discouraged practice. ## Sources 1. [New ways we're protecting businesses on Maps](https://blog.google/products-and-platforms/products/maps/new-ways-were-protecting-businesses-on-maps/) - Google (primary) 2. [Prohibited & restricted content - Maps User Generated Content Policy Help](https://support.google.com/contributionpolicy/answer/7400114?hl=en) - Google Business Profile Help (primary) 3. [Google tightens Maps review policy: staff names and quotas now banned](https://ppc.land/google-tightens-maps-review-policy-staff-names-and-quotas-now-banned/) - PPC Land --- --- title: "Google's 2026 Merchant Center product spec, three effective dates" url: https://seomadman.com/news/merchant-center-product-data-spec-2026 section: news published: 2026-04-14T00:00:00.000Z modified: 2026-04-14T00:00:00.000Z author: Adam Hafez topics: ["Structured data"] --- # Google's 2026 Merchant Center product spec, three effective dates ## The short answer Google updated the Merchant Center product data specification with three effective dates. New shipping attributes and a video_link attribute for product videos take effect 14 April 2026, video serving and quality validation begin 30 June 2026, and a 500x500 pixel minimum image resolution is enforced from 31 January 2027, after a warning period. ## Key takeaways - New shipping attributes handling_cutoff_time and minimum_order_value, plus loyalty_program_label and loyalty_tier_label under shipping, take effect 14 April 2026. - A new video_link attribute lets merchants submit product video links, with technical validation errors reported from 14 April 2026. - Video serving plus policy and quality validation for video_link begins later, on 30 June 2026. - Minimum image resolution rises to 500x500 pixels for image_link and additional_image_link, with warnings from 14 April 2026 and enforcement from 31 January 2027. - Google says it will auto-optimize some undersized images using high-resolution near-duplicates or AI upscaling rather than rejecting them outright. Google has updated the Merchant Center product data specification, and the changes land on three different dates rather than one. Two new shipping-related attributes and a video attribute take effect 14 April 2026, video serving and content validation follow on 30 June 2026, and a higher minimum image resolution is enforced from 31 January 2027. The staggered rollout is the point: merchants get a validation-only or warning-only period before anything is actually enforced. ## New shipping and video attributes, effective 14 April 2026 Two new product-level shipping attributes: `handling_cutoff_time`, the daily deadline for processing an order before it slips to the next handling day, and `minimum_order_value`, a minimum purchase threshold. Google also adds `loyalty_program_label` and `loyalty_tier_label` as sub-attributes of `shipping`, so a shipping benefit can be tied to loyalty program membership. The same date introduces `video_link`, a new attribute for submitting a link to a product video. From 14 April 2026, Google only runs technical validation on it: malformed or broken links are reported as feed errors. It does not yet check the video's content. ## Video serving and image resolution, on later dates **30 June 2026.** Video serving begins, along with policy and quality validation for whatever a `video_link` points to. Until this date a technically valid link sits in the feed without being shown or checked for content; after it, Google evaluates and can serve the video itself. **31 January 2027.** The minimum resolution for `image_link` and `additional_image_link` rises to 500x500 pixels across all product categories. Google issues warnings for undersized images starting 14 April 2026, the same date as the shipping and video changes, giving merchants roughly nine and a half months before enforcement begins. Google says it will auto-optimize some smaller images itself, using high-resolution near-duplicate images or AI upscaling, rather than requiring every merchant to re-source assets. ## Why we care A three-date rollout for one spec update is unusual, and it matters for how you sequence work: the image resolution warning starts the same day as the new attributes but does not bite for close to a year, while video validation tightens in two separate steps. Treat 14 April 2026 as the date to start feeding the new attributes and clearing image warnings, not the date enforcement lands. ## Frequently asked questions ### Do I need to add the new attributes right away? They become effective 14 April 2026, but Google's own change log treats them as additive rather than as a replacement for existing fields. Add handling_cutoff_time and minimum_order_value where they apply to your shipping setup, and treat video_link as optional until you have real video assets to link. ### What happens to images below 500x500 pixels? Nothing breaks immediately. Warnings start 14 April 2026 so you have time to fix source images, and enforcement does not begin until 31 January 2027. Google also says it will auto-optimize some smaller images using high-resolution near-duplicates or AI upscaling rather than disapproving them outright. ### Why does video_link have two dates instead of one? Google separates the technical check from the substantive one. From 14 April 2026 it validates that a submitted link is well-formed and reports errors on the feed. From 30 June 2026 it starts actually serving the video and applying policy and quality validation to what is shown. ## Sources 1. [Product data specification: Shopping ads and free listings](https://support.google.com/merchants/answer/16989427?hl=en) - Google Merchant Center Help (primary) 2. [Google Updates Some Merchant Center Product Spec](https://www.seroundtable.com/google-updates-some-merchant-center-product-spec-41171.html) - Search Engine Roundtable --- --- title: "AI Overview citations are decoupling from search rank" url: https://seomadman.com/news/ai-overview-citation-rank-decoupling section: news published: 2026-03-02T00:00:00.000Z modified: 2026-03-02T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # AI Overview citations are decoupling from search rank ## The short answer Ahrefs data covering 863,000 keyword SERPs and 4 million AI Overview URLs found that pages ranking in Google's top 10 accounted for 38% of AI Overview citations in March 2026, down from 76% in July 2025. Citation now depends more on passage-level extractability than organic position, so ranking well is necessary but no longer sufficient for AI Overview visibility. ## Key takeaways - Ahrefs analysed 863,000 keyword SERPs and 4 million AI Overview URLs and found top-10 pages fell from 76% of citations in July 2025 to 38% in its March 2026 update. - Pages ranking 11 to 100 and pages absent from the top 100 each now account for roughly 31% of AI Overview citations, splitting the remainder almost evenly. - Ahrefs attributes part of the shift to Google's move to Gemini 3 as the AI Overviews model in January 2026, which relies more on query fan-out than the original SERP. - Google's own May 2026 blog post confirms it now places links "right next to the relevant text" inside AI Overviews rather than grouping citations at the end. - Citation rate and ranking position are now separate metrics worth tracking, since a page can rank on page one and never be cited. Ranking in the top 10 used to be the closest thing to a guarantee of an AI Overview citation. Ahrefs data now puts that guarantee at less than four in ten. ## The numbers Ahrefs first measured the relationship between rank and AI Overview citation in July 2025, analysing 1.9 million citations sourced from 1 million AI Overviews. It found 76.1% of cited pages ranked in the top 10, with the primary citation in each Overview landing at a median organic position of 2. In a March 2026 update, Ahrefs ran the same question against a larger sample: 863,000 keyword SERPs and 4 million AI Overview URLs. Top-10 pages now account for **38%** of citations. Pages ranking 11 to 100 account for 31.2%, and pages that do not appear in the top 100 at all account for 31.0%, meaning nearly two-thirds of citations now go to pages a rank tracker would never flag. Ahrefs ties the shift to Google's January 2026 switch to Gemini 3 as the model behind AI Overviews. Gemini 3 leans more on query fan-out: it splits the typed query into related sub-queries, retrieves across each of those SERPs, and cites whichever pages surface most often across the set, not just the top results for the original query. ## What Google itself has said about citation placement Ahrefs' data describes which pages get cited. A separate change, confirmed directly by Google, describes how a citation is placed once a page is chosen. In a May 2026 post on the Google blog, the company said it would show "more links directly within AI responses, right next to the relevant text," giving the example of a bike-trip guide linked beside the specific bullet point about terrain rather than grouped in a source list at the end of the answer. Google did not publish a ranking-factor formula alongside that change, and neither Ahrefs nor Google has published a study proving passage relevance outweighs backlinks or domain authority in citation selection. What is confirmed, directly from Google, is the placement behavior: citations now attach to the specific claim they support, which only works if a page's content is broken into passages an extraction system can lift on their own. A page whose supporting detail is buried inside a long paragraph has nothing clean to attach a citation to, independent of how well that page ranks. ## Why we care The two data points point at the same practical shift from different directions. Ahrefs shows that rank alone no longer predicts citation with the confidence it did eight months earlier. Google confirms, in its own words, that citations attach to specific passages rather than to a page as a whole. Put together, a page needs to rank well enough to be crawled, trusted and considered, then separately needs a clearly stated, self-contained answer for a citation to actually land, and the number that tells you whether the second half is working is citation rate, not position. Tools that report the two separately, rather than assuming one predicts the other, are now measuring something rank tracking cannot. ## Frequently asked questions ### Does this mean ranking no longer matters for AI Overviews? No. Ranking well still helps a page get indexed, crawled and trusted, and roughly 38% of citations still go to top-10 pages, more than any other single band. What changed is that ranking well no longer guarantees a citation, and a page outside the top 10 now has a real chance at one. ### Why did the share drop between July 2025 and March 2026? Ahrefs points to Google's January 2026 move to Gemini 3 as the AI Overviews model. Gemini 3 leans more heavily on query fan-out, retrieving from the SERPs of related sub-queries rather than only the original query's top results, which pulls in pages that never ranked in the top 10 for the query typed. ### What should a site track instead of just rank? Citation rate as its own metric, alongside rank. Ahrefs' Brand Radar and similar tools report how often a page or domain is cited in AI Overviews independently of its organic position, which is the number this shift makes worth watching. ## Sources 1. [Update: 38% of AI Overview Citations Pull From The Top 10](https://ahrefs.com/blog/ai-overview-citations-top-10/) - Ahrefs (primary) 2. [76% of AI Overview Citations Pull From the Top 10](https://ahrefs.com/blog/search-rankings-ai-citations/) - Ahrefs (primary) 3. [How AI Mode and AI Overviews help you explore the web](https://blog.google/products-and-platforms/products/search/explore-web-generative-ai-search/) - Google (primary) --- --- title: "Penske Media v. Google: the antitrust timeline so far" url: https://seomadman.com/reports/penske-media-google-antitrust-timeline section: reports published: 2026-02-12T00:00:00.000Z modified: 2026-02-12T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # Penske Media v. Google: the antitrust timeline so far ## The short answer Penske Media sued Google for antitrust violations on 12 September 2025, alleging Google coerces publishers into supplying content for AI Overviews without fair compensation. Penske's 12 February 2026 opposition to Google's motion to dismiss cites click-through declines of up to 34.5 percent. The European Publishers Council filed a related EU complaint on 10 February 2026. ## Key takeaways - Penske Media, publisher of Rolling Stone, Variety, Deadline and Billboard, sued Google in US federal court on 12 September 2025. - The complaint frames Google's conduct as coercing publishers into supplying content that Google republishes in AI-generated answers without permission. - Google moved to dismiss in January 2026, calling Penske's claims legally defective in every way. - Penske's 12 February 2026 opposition cites a click-through decline of up to 34.5 percent when an AI Overview appears, and a third of its affiliate revenue lost since 2024. - The European Publishers Council filed a separate EU complaint on 10 February 2026, alleging an Article 102 TFEU abuse of dominance over AI Overviews and AI Mode. Two separate proceedings now put Google's use of publisher content in AI Overviews in front of regulators and a federal court. One is a private antitrust lawsuit brought by Penske Media Corporation, publisher of Rolling Stone, Variety, Deadline, The Hollywood Reporter and Billboard. The other is a competition-law complaint the European Publishers Council filed with the European Commission five months later. Both are real, dated filings, not settled outcomes, and neither has produced a ruling yet. ## The timeline - **12 September 2025** - Penske Media Corporation and 14 affiliated publishing entities file suit against Google LLC in the US District Court for the District of Columbia, Case No. 1:25-cv-03192. The 101-page complaint names Bard, Gemini, Search Generative Experience, AI Overviews and AI Mode, and seeks treble damages under the Sherman Act. - **14 January 2026** - Google moves to dismiss, arguing Penske's claims are, in Google's own words, "legally defective in every way." - **10 February 2026** - The European Publishers Council files a separate antitrust complaint against Google LLC and Alphabet Inc. with the European Commission, alleging abuse of a dominant position under Article 102 TFEU through AI Overviews and AI Mode. - **12 February 2026** - Penske Media files a 56-page memorandum opposing Google's motion to dismiss, backed by traffic and revenue figures it says document the harm. ## What each filing actually alleges Penske's complaint frames the conduct as Google's "abuse of its adjudicated monopoly in General Search Services to coerce online publishers like PMC to supply content that Google republishes without permission in AI-generated answers that unfairly compete for the attention of users on the Internet." Its February opposition memorandum argues the conduct qualifies for per se treatment under tying law, on the theory that Google conditions continued search visibility on publishers supplying content for AI training and AI Overview use, and separately argues monopoly maintenance and coercive reciprocal dealing. To support the harm claim, the memorandum cites a click-through-rate decline of up to 34.5 percent for the top organic result when an AI Overview appears on the results page, and states that organic affiliate revenue across the Penske Media portfolio has fallen by more than a third from its 2024 peak. Google's motion to dismiss, filed the prior month, does not appear in press coverage with a detailed public rebuttal of those figures; it argues the legal theories themselves do not state a viable antitrust claim. The European Publishers Council's complaint is a distinct instrument: not a request for damages but a request that the European Commission investigate Google under EU competition law. EPC chairman Christian Van Thillo characterized the target as "a dominant gatekeeper from using its market power to take publishers' content without consent, without fair compensation," and without a meaningful opt-out. The complaint follows an antitrust investigation the European Commission itself opened in December 2025 into Google's use of publisher and YouTube-creator content to build its AI products, and argues Google has turned Search from a referral service into an answer engine that substitutes for the publisher's own page rather than sending a visitor to it. ## Why we care This site has covered AI Overviews and AI-crawler access mostly as a policy and opt-out question: whether to allow Google-Extended, how to read a robots.txt directive, whether blocking a crawler costs more traffic than it saves. Penske's lawsuit and the EPC's complaint move part of that conversation into a courtroom and a competition regulator's inbox. Neither filing has produced a ruling, and this site is not qualified to predict one. What is now real, and traceable to dated public filings, is that a major publisher has put a number on the traffic cost of AI Overviews inside a formal legal complaint, and a body representing European publishers has asked a regulator to treat the same conduct as an abuse of dominance. Whatever a court or the Commission eventually decides, technical SEO practitioners now have two concrete, citable documents describing how a publisher and a regulator each frame the harm, worth reading alongside the voluntary opt-out guidance covered elsewhere on this site, not instead of it. ## Frequently asked questions ### When did Penske Media sue Google? Penske Media Corporation filed its antitrust complaint against Google LLC in the US District Court for the District of Columbia on 12 September 2025, docketed as Case No. 1:25-cv-03192. ### What is Penske Media's core allegation against Google? That Google abuses its adjudicated monopoly in general search to coerce publishers into supplying content that Google republishes without permission in AI-generated answers, including AI Overviews, that compete with the publishers' own pages for user attention. ### Is the European Publishers Council complaint the same case as Penske's lawsuit? No. They are separate and independent actions filed in different jurisdictions roughly five months apart. Penske's is a US federal antitrust lawsuit seeking damages, while the EPC's is a competition-law complaint asking the European Commission to open or advance an Article 102 TFEU investigation. ### Has a court ruled on Google's motion to dismiss? Not as of this report. Google moved to dismiss in January 2026, Penske filed its opposition memorandum on 12 February 2026, and both sides have since sought oral argument; no ruling on the motion had been reported at the time of writing. ## Sources 1. [Penske Media files antitrust lawsuit against Google over AI content practices](https://ppc.land/penske-media-files-antitrust-lawsuit-against-google-over-ai-content-practices/) - PPC Land (primary) 2. [Penske Media says Google's 'forced choice' broke longstanding web bargain](https://ppc.land/penske-media-says-googles-forced-choice-broke-longstanding-web-bargain/) - PPC Land (primary) 3. [Google Moves to Dismiss Penske Media's AI Antitrust Lawsuit](https://www.digitalmusicnews.com/2026/01/14/penske-media-google-lawsuit-dismissal-push/) - Digital Music News 4. [European Publishers Council files formal antitrust complaint against Google over AI Overviews and AI Mode](https://www.epceurope.eu/post/european-publishers-council-files-formal-antitrust-complaint-against-google-over-ai-overviews-and-ai) - European Publishers Council (primary) 5. [Publishers file complaint to EU over Google AI summaries](https://www.rte.ie/news/business/2026/0210/1557746-google-ai-publishers/) - RTE 6. [PENSKE MEDIA CORPORATION v. GOOGLE LLC, 1:25-cv-03192](https://www.courtlistener.com/docket/71332589/penske-media-corporation-v-google-llc/) - CourtListener --- --- title: "Google ships its first Discover-only algorithm update" url: https://seomadman.com/news/discover-first-dedicated-algorithm-update section: news published: 2026-02-05T00:00:00.000Z modified: 2026-02-05T00:00:00.000Z author: Adam Hafez topics: ["Core updates", "Content strategy"] --- # Google ships its first Discover-only algorithm update ## The short answer Google released the February 2026 Discover core update on 5 February, its first core update scoped to Discover alone rather than riding along with a broader Search update. The rollout took about 22 days and targeted more locally relevant content, less sensational clickbait, and more original, in-depth content from sites with demonstrated topic expertise, applied first to English-language US users. ## Key takeaways - Google's February 2026 Discover core update, announced 5 February, was the first core update the company publicly labeled as Discover-only. - The rollout ran roughly 22 days, finishing 27 February, about eight days longer than Google's original two-week estimate. - Google named three goals for the update, more local content, less clickbait, and more original, in-depth content from sites with demonstrated topic expertise. - Third-party tracking by NewzDash found unique domains in the US Discover top 1,000 fell from 172 to 158 after the update, alongside stronger regional personalization. - Publisher network Raptive found pages draw over 70 percent of their Discover clicks within one day, and heavier republishing correlated with worse Discover performance. Google released the February 2026 Discover core update on 5 February, and for the first time labeled a core update as scoped to Discover alone rather than folding Discover changes into a broader Search update. The rollout ran about three weeks, finishing on 27 February, roughly eight days past Google's own two-week estimate. ## What Google said it changed Google's Search Central Blog post, credited to Search Advocate John Mueller, named three goals for the update: show users more locally relevant content from sites based in their country, reduce sensational and clickbait content in Discover, and surface more original, in-depth, timely content from sites with demonstrated expertise on a given topic. Google was explicit that expertise is judged topic by topic, so a site with a narrow focus and a site with broad coverage both have equal opportunity to show up in Discover if they carry real expertise on the specific subject. The update shipped first to English-language users in the US, with expansion to other countries and languages planned but not scheduled. ## What changed in the data Google's own post said only that some sites would see traffic increases, some decreases, and many no change, which is its standard core-update language. Third-party tracking filled in more detail. NewzDash compared the week before the update to a week during rollout across the top 1,000 domains and articles in the US, California, and New York: unique domains in the US top 1,000 fell from 172 to 158, California showed a similar drop, and regional personalization increased, with New York domains appearing roughly five times more often in the New York feed than in California's. Fewer publishers were holding top placements even as the range of topics covered grew. Publisher network Raptive analyzed Discover performance across the more than 3,000 sites that give it Search Console access. Two figures stand out. First, pages draw over 70 percent of their Discover clicks within a single day of publishing, so freshness at the moment of publication drives most of the traffic a Discover-eligible article will ever get. Second, the more a site republished existing content rather than publishing new material, the more its Discover performance declined over the update period. Among the sites Raptive tracked, travel sites gained 72 percent in clicks, news sites 34 percent, and smaller niche sites across verticals 26 percent, with winners sharing higher publishing volume, younger median content age, and stronger direct-audience signals such as email referral traffic. ## Why we care A Discover-only core update is a new category of Google announcement, and it arrived with a concrete, verifiable number attached: most of an article's Discover clicks land in the first day, so a stale or slow-to-publish workflow has already lost most of the traffic it could have earned before an editor even checks the numbers. The republishing correlation Raptive found points the same direction: refreshing old URLs to chase Discover is not a substitute for new, expert-backed coverage, at least by this update's read of the data. ## Frequently asked questions ### Did this update also change regular Search rankings? No. Google scoped it to Discover only, the first time the company has publicly labeled a core update that way. A drop in Discover traffic does not mean organic Search rankings moved, and the two should be read separately in Search Console. ### Which sites gained from the update? Raptive's data, drawn from over 3,000 Search Console-connected sites in its network, found travel sites up 72 percent in clicks, news sites up 34 percent, and smaller niche sites up 26 percent, with fresh, frequently updated content the common thread among gainers. ### Is republishing old content still worth doing? Raptive's data says heavier republishing correlated with worse Discover performance during this update, consistent with its earlier guidance that empty refreshes underperform genuinely new content. That is one network's data, not a Google statement, so treat it as directional. ## Sources 1. [Google's February 2026 Discover Core Update](https://developers.google.com/search/blog/2026/02/discover-core-update) - Google Search Central Blog (primary) 2. [Google's Discover Core Update Finishes Rolling Out](https://www.searchenginejournal.com/googles-discover-core-update-finishes-rolling-out/568413/) - Search Engine Journal 3. [What we learned from Google's first-ever Discover algorithm update](https://raptive.com/blog/what-we-learned-from-googles-first-ever-discover-algorithm-update/) - Raptive --- --- title: "AI Mode passed 200 countries and territories, and entered the EU" url: https://seomadman.com/news/ai-mode-expands-40-new-areas section: news published: 2025-10-07T00:00:00.000Z modified: 2025-10-07T00:00:00.000Z author: Adam Hafez topics: ["AI search"] --- # AI Mode passed 200 countries and territories, and entered the EU ## The short answer Google expanded AI Mode to more than 40 new countries and territories and more than 35 new languages, taking total coverage past 200 countries and territories. The expansion marked AI Mode's first availability inside the European Union, naming Germany, Italy, Spain and Poland among the new markets Google added. ## Key takeaways - Google added more than 35 new languages and more than 40 new countries and territories to AI Mode, taking total coverage past 200. - This expansion was AI Mode's first availability inside the European Union. - Germany, Italy, Spain and Poland were named among the newly added EU markets. - The announcement predates this site's usual 2026 coverage window and is included here as context for later AI Mode stories. Google pushed AI Mode past 200 countries and territories in one release, adding more than 35 new languages and more than 40 new countries and territories in a single expansion. The most notable addition was not a number: it was AI Mode's first entry into the European Union, with Germany, Italy, Spain and Poland named among the new markets. ## What actually shipped Google's own announcement frames the release as a coverage expansion, not a feature change: the underlying AI Mode experience is the same one already live in the US and other early markets, extended to new languages and regions rather than redesigned for them. The company did not detail market-by-market rollout timing beyond naming the four EU countries explicitly. ## Why the EU entry matters more than the count Language and country counts move often; a first EU launch does not. The EU carries its own regulatory environment for AI-generated search features, including the kind of publisher transparency and compensation questions this site has covered in later 2026 stories about AI Mode reaching France. This October 2025 expansion is the starting point for that later regulatory story, not a separate one. ## Why we care A model or feature expanding into 40 new countries changes very little for any single publisher's own traffic on day one. What it does change is scope: once AI Mode operates inside the EU, every subsequent policy question, being publisher opt-outs, citation transparency, or compensation frameworks, has a live legal jurisdiction to answer to, which is exactly the story that continued to unfold through 2026. ## Frequently asked questions ### Was this AI Mode's first appearance in Europe? Yes. Google's own announcement frames this expansion as AI Mode's first availability inside the European Union, naming Germany, Italy, Spain and Poland among the new markets. ### Why is a 2025 story on a site that mostly covers 2026? Because later AI Mode stories on this site, including its regional and advertising expansions through 2026, build on this as the point AI Mode became a genuinely global product rather than a US-first experiment. ## Sources 1. [AI Mode in Google Search expands to more than 40 new areas](https://blog.google/products-and-platforms/products/search/ai-mode-expands-languages-locations/) - Google (primary) 2. [Google AI Mode Expands To More Countries & Languages](https://www.seroundtable.com/google-ai-mode-expands-40232.html) - Search Engine Roundtable