Google on July 10, 2026 updated its canonicalization troubleshooting guide with a detail that had previously gone unstated in the company's documentation: after a publisher fixes the content issues behind a duplicate-page cluster, Google's systems can still take up to two weeks to recognize the change and split the pages apart. The clarification sits inside a broader batch of documentation updates that Google Search Central published across the preceding two months, covering AMP routing, Merchant Center structured data, and site migration guidance.

What changed in the canonicalization guide

According to Google's documentation changelog, the update to the canonicalization troubleshooting guide added clarifications on re-evaluation time. Google's stated reason for the change was to provide better expectations about how long it takes for canonicalization changes to take effect.

The underlying guide, titled "Fix canonicalization issues," addresses one of the more persistent frustrations in technical search engine optimization. When Google's systems detect that multiple URLs serve substantially similar content, they cluster those pages together and select one as the canonical, or primary, version to show in search results. Site owners can express a preference through a rel="canonical" element, but Google's own documentation states plainly that even an explicit designation does not guarantee the outcome. Google might choose a different canonical for various reasons, such as the quality of the content, according to the guide.

That gap between stated preference and system behavior has long pushed publishers toward the Search Console URL Inspection tool, which shows which page Google actually considers canonical for a given cluster. Before troubleshooting, the guide advises site owners to consider whether the Google-selected canonical makes more sense than the preferred canonical URL for users arriving from Google Search. It is a subtle instruction, and one that reframes the entire troubleshooting exercise: not every mismatch between preference and outcome is a bug.

Where the July 10 update adds new precision is on timing. The guide now states, under a bolded heading reading "Re-evaluation takes time," that even after fixing content issues, Google might hold pages in a duplicate cluster for up to two weeks. A second bolded point, "Content difference matters," clarifies that pages will generally split out faster if the difference between the new content and the other clustered pages is clear and significant. Together, the two statements give publishers a rough operating model: the fix has to be substantial, and even a substantial fix takes time to register.

For site owners running audits under deadline pressure, that two-week window carries practical weight. A content team that revises a page and expects an overnight correction in Search Console has, according to Google's own documentation, no basis for that expectation. The guide's advice for accelerating the process is narrow. Once content issues are fixed, site owners can use the Request Indexing feature inside the Search Console URL Testing Tool to ask Google to re-evaluate the clustered pages. But the guide adds an important caveat: because this feature is subject to quotas, it should be reserved for a site's most important URLs, not applied indiscriminately across every page in a cluster.

The six common causes Google documents

The guide catalogs six recurring reasons why Google's selected canonical differs from a site owner's preferred URL, and the categorization matters because each implies a different fix.

Language variants without localized annotations top the list. Sites that serve substantially the same content, localized for different regions, risk having Google treat those regional variants as duplicates rather than distinct pages, unless hreflang annotations are in place to help the correct regional page surface for users in each area. The example Google gives in its own documentation involves English-speaking users in the United States, the United Kingdom, and Australia, each served by a separate site with identical underlying content.

Incorrect canonical elements describe a technical failure mode rather than a content problem. Some content management systems, or CMS plugins, can misuse canonicalization techniques and point to unintended URLs. Google's guidance directs site owners to check their HTML using browser developer tools, and if an unexpected canonical preference appears, perhaps through incorrect rel="canonical" markup or a 3xx redirect, to report the error to the CMS provider directly.

Misconfigured servers cover a narrower but stranger set of cases. Google's documentation gives two examples: a server that is misconfigured to return content from one domain in response to a request for a URL on an entirely different domain, and two unrelated web servers that return identical soft 404 pages that Google fails to identify as error pages. Both scenarios point toward hosting-level issues rather than anything a site owner can fix through on-page markup alone.

Malicious hacking is treated separately from ordinary misconfiguration. Some attacks introduce code that returns an HTTP 3xx redirect, or inserts a cross-domain rel="canonical" annotation into a page's head or HTTP header, usually pointing toward a URL hosting malicious or spammy content. In these cases, Google's algorithms may end up selecting the malicious or spammy URL instead of the URL on the compromised website, which the guide notes explicitly, describing the original site as compromised.

Syndicated content raises a different kind of problem, one rooted in a common misunderstanding. Google's guide states that the canonical link element is not recommended for those who want to avoid duplication by syndication partners, because the pages are often very different from the original. The most effective solution, according to the guide, is for partners to block indexing of the syndicated copy altogether, and the documentation points toward separate guidance on avoiding article duplication in Google News for more detail on blocking syndicated content from search.

A copycat website is the sixth and final category, covering situations where an external site hosts a publisher's content without permission. In rare situations, Google's own algorithm may select a URL from that external site as canonical rather than the original. The guide's advice here shifts from technical remediation to legal recourse: site owners who believe another site is duplicating their content in violation of copyright law can contact the infringing site's host to request removal, or file a request under the Digital Millennium Copyright Act to have Google remove the infringing page from its search results directly.

One consequence of this last scenario is easy to overlook. If a canonical URL sits inside a Search Console property that a site owner does not control, the guide warns, that site owner will not be able to see any of the traffic data for their own duplicate page. Ownership of the canonical, in other words, carries a visibility cost for whoever does not hold it.

AMP documentation gets simplified as caching model changes

The same July batch of documentation updates addressed a separate and, in practical terms, larger change: how Google Search handles Accelerated Mobile Pages. Dated July 1, 2026, the update simplified Google's AMP documentation by removing outdated references to the AMP viewer, the AMP Cache, and signed exchange.

According to Google's own explanation for the change, starting July 1, Google Search began updating how it connects users to AMP pages, taking users directly to a publisher's own AMP host pages rather than routing them through a Google-hosted cached copy. Google frames the change as a simplification that reduces maintenance effort for publishers creating AMP content, since they no longer need to update the AMP cache or configure signed exchanges. The documentation adds that AMP content will continue to rank just like any other web page.

The shift closes out a design choice that dates back to AMP's earliest years, when Google's caching layer was intended to make mobile pages load faster by serving them from Google's own infrastructure rather than a publisher's servers. That original caching model had long limited how publishers could track and monetize AMP traffic, since analytics and monetization tools had to work around a Google-hosted intermediary layer rather than the publisher's own server. Coverage published July 2, 2026 documented the same routing change alongside a separate Google Ads bidding update, noting that early testing surfaced at least one page-load error under the new direct-routing scheme.

Merchant listing structured data gains dual category support and sale-duration fields

Two further documentation updates, both dated July 7, 2026, focused on Merchant listing structured data rather than crawling or indexing mechanics.

The first update detailed how the Product.category property can now be used with both Text and CategoryCode types. According to Google's documentation, this alignment matches the Google Merchant Center feed specifications for the product_type and google_product_category attributes, and the stated purpose is to help merchants provide both merchant-defined and Google-defined category information within schema.org markup, enhancing product information for Google Search and Shopping.

The second July 7 update added a new "Sale duration" section to the Merchant listing guide, explaining how the validFrom, validThrough, and priceValidUntil schema.org properties can be used to set the effective range for sale prices. The guidance includes best practices and examples for placement on either Offer or PriceSpecification nodes. Google's stated reason for the addition was to align schema.org usage with the Merchant Center feed attribute sale_price_effective_date, giving merchants clearer instructions and best practices for structuring sale pricing data.

Both updates sit inside a broader pattern of Merchant Center attribute expansion that has continued through 2026, as Google has worked to align structured data requirements with the feed specifications merchants already submit through Merchant Center directly, and, increasingly, with the data needs of AI-driven shopping surfaces built on top of Google's Shopping Graph.

Site moves, llms.txt guidance, and the FAQ rich result's final removal

The June and May entries in Google's documentation changelog fill out a picture of steady, incremental change across search infrastructure guidance rather than a single dramatic announcement.

On June 17, 2026, Google updated its site move guide to require the Change of Address tool for all subdomain variantsduring domain migrations, including both www and non-www versions of a domain. Google's stated rationale was direct: domain migrations work best when all variants of a site are migrated properly.

On June 15, 2026, Google added a note to its AI optimization guide clarifying its usage of llms.txt files, stating that while these files are not needed for Google Search, and will not negatively or positively affect visibility or rankings, site owners are free to maintain them for other services or systems that make use of them. That clarification lands against a data point reported separately, showing that llms.txt adoption across more than 3 million monitored websites grew 8.8 times over twelve months, from 4,088 instances in June 2025 to 36,120 by May 2026, even as evidence that AI systems actually read the files has remained close to zero.

The same June 15 update removed documentation for the FAQ rich result feature, following its formal deprecation. Google's stated reason cited the changelog entry from May 2026, noting that the FAQ rich result feature is no longer shown in Google Search results.

Earlier updates addressed the rollout of preferred sources to AI Mode and AI Overviews on May 27, the addition of a hasAdultConsideration property to Merchant listing and Product variant documentation on May 20, and a new guide on optimizing for generative AI features on May 15, which included guidance on non-commodity content, local and shopping content tips, and clarification that Google's spam policies apply to generative AI responses in Search just as they apply to conventional results.

Why the documentation cadence matters for marketers

Google Search Central's documentation changelog rarely generates headlines on its own, and most individual entries describe narrow, technical adjustments rather than product launches. The value of tracking the changelog systematically lies elsewhere: in aggregate, these updates describe how Google's search infrastructure actually behaves, filling gaps that would otherwise leave practitioners guessing at system behavior based on observed outcomes alone.

The two-week re-evaluation window documented in the July 10 canonicalization update is a useful illustration. Before this clarification, a site owner troubleshooting a duplicate-content cluster had no official timeframe to reference when deciding whether a fix had failed or was simply still processing. That ambiguity has practical consequences: without a documented baseline, teams risk making repeated, unnecessary changes to already-correct fixes, mistaking normal processing delay for failure.

The AMP routing change carries a different kind of significance, one tied to advertising and monetization rather than technical SEO process. Publishers who built AMP pages under the original cached-serving model did so with the understanding that some analytics and monetization capability would be constrained by Google's infrastructure sitting between the page and the reader. Routing traffic directly to publisher-hosted pages removes that constraint, though it also means AMP pages built years ago, potentially with outdated assumptions about caching behavior, now serve directly from publisher infrastructure without Google's cache as an intermediary layer.

The Merchant listing updates reflect a narrower but still meaningful concern for retail advertisers: structured data accuracy increasingly determines whether product listings surface correctly, not just in traditional Shopping results, but across newer AI-driven shopping surfaces that draw on the same underlying feed data. Aligning schema.org markup more precisely with Merchant Center feed attributes, as both July 7 updates do, reduces the risk of mismatched or incomplete product representation across those surfaces.

Taken together, the July 2026 documentation batch does not announce a new feature or a policy reversal. It documents, with more precision than before, how existing systems already behave, giving site owners, developers, and marketers a firmer basis for the operational decisions built on top of that behavior.

Timeline

  • May 15, 2026 - Google adds a new guide on optimizing for generative AI features, including guidance on non-commodity content and clarification that spam policies apply to generative AI responses.
  • May 20, 2026 - Google adds the hasAdultConsideration property to Merchant listing and Product variant documentation.
  • May 27, 2026 - Google updates the preferred sources documentation to include availability in AI Mode and AI Overviews.
  • June 15, 2026 - Google clarifies that llms.txt files are not required for Google Search and removes documentation for the deprecated FAQ rich result feature.
  • June 17, 2026 - Google updates its site move guide to require the Change of Address tool for all subdomain variants during domain migrations.
  • July 1, 2026 - Google simplifies its AMP documentation, removing references to the AMP viewer, AMP Cache, and signed exchange, as Search begins routing users directly to publisher-hosted AMP pages.
  • July 7, 2026 - Google updates Merchant listing documentation to detail Product.category support for both Text and CategoryCode types, and adds a new Sale duration section covering validFrom, validThrough, and priceValidUntil properties.
  • July 10, 2026 - Google updates the canonicalization troubleshooting guide, clarifying that re-evaluation can take up to two weeks after content fixes.

Summary

Who: Google Search Central, the division responsible for Google's official documentation for website owners, developers, and search engine optimization professionals.

What: Google published a series of documentation updates spanning May through July 2026, most significantly a July 10 clarification stating that canonical re-evaluation after content fixes can take up to two weeks, alongside a July 1 simplification of AMP documentation tied to a change in how Google Search routes users to AMP pages, and July 7 updates to Merchant listing structured data covering product category types and sale price duration fields.

When: The most recent update was published July 10, 2026. Earlier entries in the same documentation batch date to July 7, July 1, June 17, June 15, May 27, May 20, and May 15, 2026.

Where: The updates appear on Google Search Central's official documentation site, accessible to website owners, developers, and marketers globally.

Why: According to Google, the canonicalization update aims to provide better expectations about how long canonicalization changes take to register. The AMP change is intended to simplify and reduce maintenance effort for publishers. The Merchant listing updates align schema.org markup with existing Merchant Center feed specifications, supporting both traditional Shopping listings and newer AI-driven shopping surfaces.