WordPress AMP: Worth It or Not?

AMP — Accelerated Mobile Pages — was pitched as mobile speed salvation and adopted by WordPress sites in waves; then the ecosystem moved: Google removed AMP's special carrot (the Top Stories carousel no longer requires it, page-experience signals judge any fast page equally), and the framework's costs (a parallel constrained page set, plugin complexity, analytics and monetisation friction) stopped buying anything ordinary speed work doesn't. The honest current answer for most WordPress sites is no — and if you're running it, a careful exit. Here's the reasoning and both procedures.

The case, present tense

What AMP still is: a restricted HTML subset that enforces fast pages by forbidding slow patterns, cached and served by Google's infrastructure. What changed: the ranking system now rewards measured speed (Core Web Vitals field data) framework-agnostically — a fast ordinary page and an AMP page compete equally, and the WordPress speed stack reaches green Vitals without a parallel page set. What AMP costs on WordPress: maintaining two versions of every post (the AMP plugin's transformed variant — components breaking silently as themes and plugins update), the variant-management layer (paired URLs, canonicals — handled by the plugin, audited by you), analytics/ads limitations, and the debugging tax of a second rendering pipeline. Who still has a case: news publishers with legacy AMP infrastructure already stable (exit costs vs. zero remaining benefit — a genuine judgment call), and effectively nobody starting fresh.

Running it anyway: the maintenance rules

For sites keeping AMP deliberately: the plugin's modern modes matter — Standard mode (the site is AMP — one page set, no variants: the only mode without the duplication tax, viable on simple sites) versus Transitional/Reader modes (the paired-variant versions carrying the full cost above); validation monitored in Search Console's AMP report (component breakage lands there); parity audited (the AMP variant must carry the content, markup and links of the canonical — impoverished variants are what mobile users and crawlers actually receive); and monetisation/analytics verified per update.

The exit procedure (the guide most readers need)

Removing AMP without SEO damage: (1) confirm the replacement is ready — the ordinary mobile pages passing field Vitals, because the exit trades AMP's speed for yours (do the speed pass first); (2) deactivate the plugin so AMP URLs stop being generated; (3) 301 the /amp/ variant URLs to their canonical pages (pattern rule in the redirect manager — never leave them 404ing: they hold indexed positions and the Google-cache references); (4) watch Search Console through the settling — AMP URLs draining from the index, canonicals absorbing their traffic over the standard recrawl weeks, mobile positions holding (they do, when step 1 was honest — the documented exits show neutral-to-positive outcomes for sites that were fast without it).

Frequently asked questions

Will removing AMP hurt our mobile rankings?

Not if the ordinary pages are genuinely fast — the ranking inputs are the field metrics either way, and the exit case studies (news sites included) consistently show flat-to-improved outcomes post-removal when speed was solved first. Slow pages losing their AMP crutch is the one bad exit; step 1 exists for it.

Does Top Stories/news visibility still need AMP?

No — eligibility opened to non-AMP pages meeting the experience thresholds; publishers compete on the same Vitals as everyone. Legacy publisher AMP persists on infrastructure inertia, not requirement.

What should we do with the AMP-plugin time we save?

The unglamorous winners this silo keeps ranking: the caching-and-images pass that made the exit safe, the maintenance queue, and the work no framework ever supplied — content and earned authority (our framework).