Google Now Sends AMP Search Visits Directly to Publisher Hosts
Google now sends AMP Search visits directly to publisher hosts. Audit performance, analytics, signed exchanges, canonicals, and whether AMP still earns its maintenance cost.
Published August 9, 2026: Google’s July 2026 Search documentation update says AMP visits from Search now go directly to publisher hosts. Publishers no longer need to maintain AMP Cache delivery or signed exchanges for those visits.
This is a delivery change, not an AMP ranking bonus or a requirement to remove AMP. AMP pages can continue to appear when they meet the same eligibility and quality requirements as other pages. The operational decision is whether the direct publisher response is fast, stable, measurable, and worth maintaining beside any canonical page.
What changed
The earlier AMP Search path could involve a Google AMP Cache URL and, for publishers that implemented it, a signed exchange designed to preserve the publisher URL in supported contexts. Google now states that Search sends users straight to the publisher host. That removes a Google-controlled delivery detour and makes the publisher’s own infrastructure the immediate response path.
The visible URL, canonical relationship, and analytics setup still need verification. Direct delivery can simplify attribution and cache troubleshooting, but it also means origin and CDN performance are no longer masked by a separate Search cache path.
A publisher migration checklist
- Map current AMP URLs. Save the canonical, AMP alternate, sitemap, internal-link, and redirect relationships.
- Test direct performance. Measure the publisher-hosted AMP response on mobile under realistic network conditions.
- Verify analytics. Confirm pageviews, consent behavior, campaign parameters, referrers, and conversions on direct visits.
- Audit signed-exchange maintenance. Identify certificates, packagers, cache rules, monitoring, and renewal jobs that exist only for the old Search path.
- Inspect search rendering. Check representative AMP and canonical URLs, structured data, images, titles, and status codes.
- Choose a maintenance policy. Keep, consolidate, or retire AMP according to reader experience and operational value—not because the cache disappeared.
Run the release through the technical SEO launch checklist. If AMP and canonical templates have drifted into competing reader jobs, use the page-job framework before merging.
Should you keep AMP?
| Evidence | Keep when | Consolidate when |
|---|---|---|
| User experience | The AMP template is fast, accessible, complete, and actively maintained | The canonical template matches or exceeds it with less duplication |
| Editorial parity | Content, media, links, schema, and consent remain aligned | AMP is stale, partial, or expensive to keep synchronized |
| Measurement | Direct visits and outcomes are accurately captured | Split reporting obscures decisions and cannot be repaired economically |
| Operations | The team has a documented owner and test suite | Legacy cache or signed-exchange work has no remaining reader value |
A retirement needs normal migration discipline: redirect old AMP URLs where appropriate, remove obsolete alternate references, update sitemaps and internal links, preserve canonical destinations, and watch crawl and indexing behavior.
What the update does not prove
- Direct hosting does not guarantee faster pages; the publisher must deliver them well.
- The change does not create an AMP ranking advantage.
- Removing signed exchanges does not automatically make analytics correct.
- Keeping AMP does not require keeping every legacy cache-specific component.
- Retiring AMP does not justify deleting URLs without redirects or canonical planning.
Annotate the change before comparing traffic or Core Web Vitals. A platform delivery change and a template migration can occur together; the data must keep those events distinct.
Ask a question or join the discussion