amp-wp: the WordPress plugin that picks your AMP template mode for you

AMP on WordPress without rebuilding the theme

The problem this plugin addresses is not performance tuning in general. AMP pages have their own markup rules, and a WordPress site's existing themes and plugins may produce markup that does not satisfy them. The official AMP plugin's claim is that it automates as much of the AMP markup generation as it can, so editors keep the publishing workflow they already use and the site keeps its existing theme and plugins.

That framing has a consequence worth stating plainly. The plugin is not a drop-in guarantee of valid AMP. It generates AMP markup, then reports what is left over, and the difference between a site that works and a site that spends weeks in the validation tab is how much of the theme and plugin stack is already AMP-compatible. The README splits the audience in two on purpose: developers who will fix validation errors, and everyone else, who gets invalid markup removed where possible and incompatible plugins suppressed on AMP pages.

Three template modes, three different maintenance bills

The central decision is the template mode, and the README is direct about the trade-off: the modes differ in how many themes are used, one or two, and how many versions of a page exist.

Standard Mode serves only the AMP version from a single theme. The README calls this the ideal option because there is one theme to maintain and one version of the site, which cuts development and maintenance cost. It is the right fit when the theme and plugins are fully AMP-compatible, or when the site owner has the resources to fix the ones that are not.

Transitional Mode still uses one theme, but each URL can have both an AMP and a non-AMP version, served by the same active theme. That suits a theme that is not fully AMP compatible as long as the functional differences between the two versions are acceptable, relying on graceful degradation.

Reader Mode is the third option, and it is the one that pulls in a second theme, presenting a lighter AMP rendering of content. The README's excerpt truncates before it describes Reader Mode in the same detail, so the practical details of its second-theme requirement are not laid out in what is available here.

Suppressing an incompatible plugin is also removing its feature

This is the failure mode that most deserves a warning, because it succeeds quietly. For non-developer users, the plugin's stated approach is to remove invalid AMP markup where that is possible, or to suppress AMP-incompatible plugins on AMP pages. A site that relies on, say, a contact form plugin or a membership gate can go live in AMP mode with that plugin simply not running on AMP views, and nothing in the front end announces it.

The validation tools are the counterpart: the plugin identifies, contextualizes and helps resolve validation errors, so the work is visible if you go looking for it. But there is no automatic guarantee that a suppressed plugin was unimportant. If you adopt this plugin, budget for reviewing which of your active plugins execute on AMP pages.

Mobile redirection, AMP-to-AMP linking and the PHP AMP Optimizer

Beyond markup generation, the plugin handles serving: mobile redirection, AMP-to-AMP linking between pages, and optimized AMP generation by default via a PHP port of the AMP Optimizer. AMP-to-AMP linking is the part that matters for large sites, since it lets a reader move from one AMP page to the next without passing through a full non-AMP load.

Worth noting for scope: the README pushes back on the idea that AMP is a mobile-only technology, stating that it does not stand for Accelerated Mobile Pages anymore and is a fully responsive web component framework serving both mobile and desktop. That framing is the project's own argument, and it is the reason the template modes are not split by device in the way the name suggests.

Install is a WordPress plugin, the build is a Node and Grunt project

For site owners there is no command to run: the plugin is distributed through the WordPress plugin directory at wordpress.org/plugins/amp, where the listing shows a stable tag of 2.5.5 and "Tested up to" 6.9. Installing and activating it from the plugin directory is the whole setup path.

For developers working on the plugin itself, the repository is a different kind of project. package.json names it amp-wp, marks it private, and declares the engine requirements:

"engines": {
  "node": ">= 20",
  "npm": ">= 10"
}

The frontend is a React 18.3.1 application built on WordPress packages, including @wordpress/components, @wordpress/editor and @wordpress/block-editor, with classnames and uuid among the plain dependencies. The build is driven by Grunt alongside webpack, babel, postcss and stylelint, and there is a.wp-env.json for the WordPress environment. The PHP side is analysed with phpstan against phpstan-baseline.php and checked with.phpcs.xml.dist.

"license": "GPL-2.0-or-later",
"keywords": [
  "amp",
  "amphtml",
  "wordpress",
  "wordpress-plugin"
]

The licence identifier matches the README's "GPLv2 or later". Organisations that build on the plugin's source rather than just installing it should consider that licence.

Two years of commits after the last tagged release

The maintenance picture needs reading carefully, because the two signals disagree. The last push to the repository was on 2026-10-11, and the default branch is develop, which is where ongoing work lands. The tagged releases tell a different story: 2.5.5 on 2024-11-12, 2.5.4 on 2024-07-15, 2.5.3 on 2024-03-20.

What that means for you depends on where you install from: the directory gives you stable tags, while the develop branch gives you newer commits with a correspondingly higher chance of breakage. Neither the README nor the listed files explain the release criteria for promoting develop to a tag, so that question is worth asking before tracking a development branch in production.

Contributors listed in the README include teams at google, xwp, rtcamp, automattic and wordpress, which tells you the maintenance is distributed across several organisations rather than resting on one maintainer.

Building AMP markup by hand as the alternative

The alternative to this plugin is writing your own AMP templates: a parallel set of templates under templates/ that emit valid AMP markup and route requests to it, with no help identifying the markup your existing theme gets wrong. You keep full control and no plugin dependency, but validation work becomes your problem, including reconciling existing theme output with AMP rules.

The plugin takes the opposite position, keeping one theme and reusing the normal WordPress rendering path, then stripping or suppressing what does not fit. The README's third key feature is the middle ground that is easy to miss: developer tooling for building AMP-compatible ecosystem components, so compatibility gets designed in rather than retrofitted. If you are shipping components that other sites consume, that direction is where this project puts its effort.

Editorial conclusion

amp-wp suits WordPress publishers who already have an AMP-compatible theme or can fix their plugins, and Standard mode is the one to start from if your stack is clean. Do not pick it to rescue a theme full of incompatible plugins, because the plugin's own fallback is to suppress those plugins on AMP pages, which silently removes functionality you may depend on. Before enabling anything, check whether the version in the WordPress directory matches what you need, since the last tagged release is 2.5.5 from 2024-11-12 while repository commits continue on the develop branch.

Frequently asked questions

Official sources

1. ampproject/amp-wp on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases