Skip to content
ThemesIonic — home
WordPress Tutorials

AMP for WordPress

AMP was a bargain: accept a restricted subset of the web and get a speed guarantee plus preferential placement. The placement went away, the restrictions did not, and that changes the answer.

4 min read intermediate

AMP was a trade, and one side of it has been withdrawn. You accepted a restricted HTML subset, a separate set of templates and a second version of every page, and in exchange got a guaranteed-fast rendering path and preferential placement in mobile search results. The placement advantage no longer exists; the restrictions and the maintenance still do.

That is the whole assessment. What follows is what it means for a site that has AMP, and for one considering it.

What AMP actually enforces

  • No custom JavaScript, beyond a small set of sanctioned components.
  • Inline CSS only, under a strict size budget.
  • Images and embeds with explicit dimensions, which is why AMP pages do not shift as they load.
  • Asynchronous resource loading, controlled by the framework rather than by you.

Every one of those is good practice. That is the uncomfortable part of the assessment: AMP's rules describe a fast page accurately, and you can apply all of them to ordinary pages without adopting the format.

Why the calculation changed

The original argument was not "AMP is fast", it was "AMP is the entry ticket to the mobile carousel". Once eligibility became a page-experience question rather than a format question, the ticket stopped being exclusive.

What remains true:

  • AMP pages are usually fast, because the constraints make slow ones hard to build.
  • The AMP cache can serve pages very quickly from a search result.

What is no longer true:

  • That you need AMP to appear prominently in mobile search.
  • That AMP is a ranking signal in its own right.

So the question is now the ordinary one asked of any technology: does this earn its maintenance? For most sites, a second set of templates does not.

The cost, stated plainly

Cost Detail
Two versions of every page Different templates, different bugs
Restricted design Your theme's layout mostly does not survive
Broken plugins Anything relying on JavaScript degrades or vanishes
Analytics divergence AMP tracking is separate and often mismatched
Ads and consent Both need AMP-specific handling
URL sprawl A second URL per page, needing canonical and redirect discipline

The middle rows are what actually kills AMP projects. Forms, sliders, filters, page builder output and interactive components either need AMP equivalents or simply are not there — so the AMP version of a page is a different, poorer page, and someone has to keep both correct.

Where AMP still makes sense

A narrow case, but a real one: text-heavy publishing at scale, where pages are articles with images and little interactivity, mobile traffic dominates, and the newsroom cannot be trusted to keep ordinary pages light. In that setting AMP acts as an enforcement mechanism, and the restriction is the feature.

For a business site, a shop, or any site with forms and interaction, the maintenance is not repaid.

Doing the same work without AMP

Everything AMP enforces can be done on your own pages:

  1. Give images and embeds explicit dimensions, which removes most layout shift — fixing cumulative layout shift.
  2. Size and compress images properly, per optimising images.
  3. Cut the script count, and defer what remains — render-blocking resources.
  4. Load third-party embeds on interaction rather than on page load.
  5. Serve from a cache, per speeding up a WordPress site.

The result is one set of templates that is fast, and one URL per page. That is a better place to be than two of each.

Removing AMP safely

If AMP URLs are indexed, treat this as a URL migration rather than a plugin deletion.

  1. Inventory the AMP URLs that have impressions, from your search analytics.
  2. Redirect each one to its canonical page with a permanent redirect, before removing anything.
  3. Remove the AMP markup — the amphtml link tags — from the canonical pages.
  4. Deactivate and delete the plugin.
  5. Watch for 404s for several weeks, per fixing 404 errors, and confirm the canonical pages hold their impressions in Search Console.

Skipping step two is how a site loses mobile traffic overnight — every indexed AMP URL becomes a 404, and the symptom looks like a site not showing in Google.

Common mistakes

  • Installing AMP to fix a slow site. It creates a fast second site and leaves the slow one in place.
  • Deleting the plugin without redirects.
  • Letting the AMP version show different content, which is a mismatch between what search indexes and what people see.
  • Forgetting consent and analytics on the AMP side, so the numbers and the compliance both diverge.
  • Maintaining AMP templates nobody reviews, which quietly break as the site changes.

Verify

If you keep AMP: open the AMP version of your three most-visited pages and confirm they contain the same content, working navigation, correct tracking and a consent mechanism. If you remove it: request one old AMP URL and confirm it returns a permanent redirect to the canonical page, then check the canonical page still declares no amphtml link. Either way, measure a real page on a phone — that number, not the format, is what visitors experience.

Frequently asked

Not as a ranking factor and not as a requirement for the top-stories carousel, which is now open to any page meeting the page-experience bar. AMP pages can still be fast, but the structural advantage that justified the work is gone.
If the AMP pages get meaningful traffic, remove them carefully with redirects from every AMP URL to its canonical page. Deleting the plugin without redirects turns every indexed AMP URL into a 404.
Yes, and that is now the better use of the effort. The techniques AMP enforced — sized images, restrained scripts, deferred third parties — all work on ordinary pages, and you keep one set of templates.

Related guides