Google AMP Case Study - Leads Dropped by 59% (How to Disable It)

Most published AMP case studies come from vendors who sell AMP implementations, which makes them worth roughly what you paid for them. This one is different. The managed WordPress host Kinsta ran the experiment on its own marketing site, measured what happened to its funnel, and then documented the removal procedure it used to unwind the implementation. A measured loss paired with a working runbook is far more useful to a practitioner than another anecdote about improved load times.

The headline figure is blunt: mobile leads fell 59.09%. Two supporting metrics moved the same direction, with newsletter signups down 16.67% and account creations down 10.53% on mobile devices. Those are the numbers reported in the source case study, and the important caveat is that they describe one site with one funnel. Treat them as directional evidence about a mechanism rather than as a universal coefficient you can apply to your own traffic.

Initial Situation

The context is what makes this case legible. Kinsta is a hosting company, not a news publisher, and its marketing site exists to generate trials, demos and account signups. That single fact removes the largest historical benefit of AMP, because the Top Stories carousel that AMP unlocked was a publisher surface. A hosting company was never going to appear there regardless of markup.

The second relevant fact is that the site was already well optimised for mobile before AMP was introduced. AMP is a performance intervention, and performance interventions only pay when there is slack to recover. On a template that already renders quickly, the marginal speed gain from AMP approaches zero while the constraints remain fully in force. You keep all of the cost and lose most of the benefit.

Those constraints are the actual cause of the conversion damage. AMP forbids author written JavaScript, which means multi step forms, chat widgets, pricing calculators, dynamic pricing tables and any custom validation logic either break, get replaced with a degraded AMP component, or silently disappear. AMP pages have also historically been served from a Google cache domain, which splits analytics attribution and puts a Google branded frame between the reader and the site. For a business whose entire mobile page objective is a form submission, removing the form and diluting the brand context is not a subtle regression.

Strategy and Approach

The strategic question is narrower than it looks. AMP is not a ranking factor and has not been an eligibility requirement since 2021, so the decision reduces to a single trade: does the rendering speed AMP buys you exceed the funnel functionality it takes away? For most sites in 2026 the answer is no, but the honest version of the answer is template dependent.

Before committing, confirm the precondition that made removal safe for Kinsta: the canonical mobile templates must already be fast. If AMP is currently masking a genuinely slow mobile site, removing it exposes the underlying problem. Establish where your canonical templates stand on Core Web Vitals first, and understand the gap between lab scores and the field data Google actually uses by reviewing field data versus lab data. Fix the canonical page, then retire AMP.

Implementation

The source documents two routes. Both work, and the difference is mainly how aggressively you want Google to drop the AMP URLs.

Route A, the softer path. Use a find and replace layer to strip the AMP discovery link from your canonical pages, matching the pattern for the amphtml link tag and replacing it with nothing. Then add a noindex directive to the AMP pages themselves through the AMP plugin settings, using content set to noindex with follow so any equity on those URLs still flows. Critically, the AMP plugin stays active throughout, because the AMP pages must remain reachable long enough for Google to recrawl them and process the noindex.

Route B, the redirect path. Create 301 redirects from the AMP paths to their canonical equivalents, then deactivate the AMP plugin once the redirects are confirmed live. At the server level the same rule expressed for Apache is RedirectMatch 301 with a pattern capturing the path before the AMP suffix and rewriting it to the captured group.

Route A is gentler on sites with a large indexed AMP footprint because it lets Google process a signal rather than a hard redirect. Route B is faster and simpler, and it is the better choice when AMP traffic is already negligible. What you must not do is invert the sequence in either route. Deactivating the plugin before the discovery links and redirects are in place converts every indexed AMP URL into a 404 at once, which is a self inflicted crawl problem.

One nuance worth stating plainly: do not touch your canonical tags during this work. The canonical on the AMP page points at the desktop or responsive original, and that relationship is what lets Google consolidate the two. Changing canonicals mid migration is a common way to turn a clean removal into an indexing mess. If you want the underlying directive behaviour clear in your head first, the meta robots and X-Robots-Tag reference covers exactly how noindex with follow is processed. It is also worth checking that your AMP canonicals are not already broken before you start, since a canonical pointing at a non indexable URL will distort your baseline measurements.

Results and Learnings

The reported outcome is the reversal of the losses that prompted the removal. The value for other practitioners is not the specific percentages, which belong to one site with one funnel, but the mechanism they expose: AMP costs you conversion functionality, and that cost is constant, while AMP delivers speed, which is a benefit that shrinks to nothing as your canonical templates improve. Any site that has invested in mobile performance over the last few years has quietly been eroding its own reason to run AMP.

Three measurement lessons transfer cleanly. First, segment by device and by template, because a site wide conversion average will hide a mobile only collapse. Second, remember that AMP pages served from a Google cache can be attributed differently in analytics, so a naive comparison may understate or overstate the gap. Third, give the change a full measurement cycle. Index level changes take days to weeks to settle, and reading conversion data during the transition tells you very little.

What Has Changed Since This Case Study

The strategic backdrop has moved decisively since AMP removal was a contested decision, and every change points the same way.

• June 2021, Page Experience. Google removed the AMP requirement for Top Stories eligibility. Non AMP pages became eligible, which retired the single strongest argument for maintaining an AMP codebase.
• The AMP badge disappeared. The lightning bolt icon that marked AMP results in the mobile SERP was dropped, removing the visual differentiation some publishers valued.
• Core Web Vitals became the currency. The criteria shifted to measurable field performance on your own pages, which is a target you can hit without a parallel template.
• March 2024, INP replaced FID. Interaction to Next Paint became a Core Web Vital, which rewards genuine interaction responsiveness rather than the restricted scripting model AMP enforced.
• Governance moved. The AMP project transitioned to OpenJS Foundation governance in 2019, a signal that it had become one open source framework among many rather than a Google search prerequisite.

A Pre-Removal Audit You Can Run in Twenty Minutes

Before you change anything, answer five questions with data rather than intuition. How many AMP URLs are actually indexed, and how many clicks do they earn? What is mobile conversion rate on AMP templates versus canonical templates, measured over the same window? Do your canonical mobile templates currently pass Core Web Vitals in field data? Which conversion elements exist on the canonical page but are missing or degraded on the AMP variant? And do any external sites, newsletters or syndication partners link directly to your AMP paths?

That last question is the one teams forget, and it is the reason the redirects stay in place permanently rather than being cleaned up a quarter later. If the answers show low AMP click volume, healthy canonical Core Web Vitals and a visibly degraded AMP funnel, you have the same profile Kinsta had, and the removal is a maintenance task rather than a gamble.

Frequently Asked Questions

Source: https://kinsta.com/blog/disable-google-amp/