The Automattic AMP plugin won't expose a custom post type as AMP-eligible until you opt the CPT in via the amp_supportable_post_types filter (or its predecessor add_post_type_support() in older plugin versions). The mechanics are short, but in 2026 the bigger question is whether enabling AMP at all is the right call. This post answers both.
How do I enable AMP support for custom post types in WordPress?
Use the Automattic AMP plugin and add this filter to your theme's functions.php or a custom plugin:
add_filter( 'amp_supportable_post_types', function( $post_types ) {
$post_types[] = 'resources';
$post_types[] = 'news';
return $post_types;
} );resources and news are example CPT slugs — replace with your own as registered via register_post_type(). After enabling the filter, the AMP plugin's Settings → AMP → General screen will list your CPT as a togglable post type. In the older "Classic" AMP plugin versions (pre-1.0), the same outcome was achieved with add_post_type_support( 'resources', 'amp' ) inside an init action hook. Both forms still work in the current plugin, but the filter is the supported public API going forward.
Jump to:
- The state of AMP in 2026
- When AMP still makes sense
- Enable a CPT via amp_supportable_post_types
- The legacy add_post_type_support approach
- Validate the AMP version
- Common pitfalls
- Migration path: switching AMP off cleanly
- What to do next
- FAQ
The state of AMP in 2026
AMP's strategic value has collapsed since this article was originally written in 2016. The honest summary:
- Google deprecated the AMP-only Top Stories carousel in June 2021. Top Stories now accepts any page that meets Core Web Vitals, AMP or not. The biggest historical reason to invest in AMP — automatic placement in the Top Stories carousel — no longer exists.
- The AMP Project moved to "maintenance mode" within Google in 2024. Active feature development stopped; the project is now a stewardship effort rather than a roadmap.
- News Showcase favors normal pages. Google News Showcase ranks publisher content based on signals other than AMP markup.
- Core Web Vitals tooling matured. Everything AMP solved (preloading, optimized images, predictable rendering) is now achievable with standard Next-gen image formats,
loading="lazy", font-display swap, INP optimization, and a decent CDN. You don't need a separate document fork. - The Automattic AMP plugin is still maintained. Version 2.x remains compatible with modern WordPress and ships fixes, but the velocity is much lower than 2018-2020.
If you're about to add AMP to a new project in 2026, stop and ask whether you have a specific business reason. For most sites, the answer is no.
When AMP still makes sense
There are a few residual reasons to keep or add AMP:
| Scenario | Why AMP is still relevant |
|---|---|
| Existing AMP site with traffic to preserve | The cost of removal (redirects, sitemap cleanup, audit of inbound links) exceeds the cost of keeping it working |
| Regulated content distribution | Some news syndication contracts (specifically with regional partners that surface AMP cache content) still require AMP variants |
| Partnership-mandated formats | Specific publishing partnerships (legacy Apple News + AMP bridges, some aggregator deals) require AMP markup |
| Extremely slow underlying server | If you genuinely cannot fix the source site's TTFB and a CDN-hosted AMP cache is faster than your origin will ever be |
| Restricted-device markets | Some emerging-market browsers still prefer AMP cache delivery over origin pages on flaky 3G connections |
If none of those describe your situation, the engineering hours you'd spend wiring AMP into a new CPT are better spent on Core Web Vitals for your existing pages.
Enable a CPT via amp_supportable_post_types
The current Automattic AMP plugin (v2.x) exposes the amp_supportable_post_types filter for declaring which post types are AMP-eligible. The filter receives the current list and returns the modified list:
/**
* Make 'resources' and 'news' AMP-eligible.
*
* Drop in functions.php or a custom plugin file.
*/
add_filter( 'amp_supportable_post_types', function( $post_types ) {
$post_types[] = 'resources';
$post_types[] = 'news';
return array_unique( $post_types );
} );array_unique() is defensive — if another plugin already added one of these CPTs, we don't get duplicates that confuse the AMP plugin's UI.
After the filter is in place:
- Go to WP Admin → AMP → Settings.
- Scroll to Supported templates.
- The CPT will now appear as a togglable option. Check the box and save.
- Visit a post of that CPT and append
?amp=1or/amp/to the URL.
The URL form depends on which "AMP mode" you've selected in the plugin's settings:
| Mode | URL pattern |
|---|---|
| Standard | Single URL; no AMP-specific path. The HTML is AMP-valid for every request. |
| Transitional (formerly "paired") | https://example.com/resources/whitepaper/?amp=1 — query parameter |
| Reader (legacy) | https://example.com/resources/whitepaper/amp/ — path suffix |
Reader mode is being phased out. Most new installs default to Transitional.
The legacy add_post_type_support approach
The original 2016 approach still works as a fallback for older Automattic AMP plugin versions (pre-1.0 era) where the filter didn't exist yet:
add_action( 'init', 'te_cpt_enable_amp', 20 );
function te_cpt_enable_amp() {
if ( ! defined( 'AMP_QUERY_VAR' ) ) {
return; // bail if the AMP plugin isn't loaded
}
add_post_type_support( 'resources', AMP_QUERY_VAR );
add_post_type_support( 'news', AMP_QUERY_VAR );
}AMP_QUERY_VAR is the constant the plugin exports for "this post type supports AMP". The priority 20 on the init hook ensures it runs after register_post_type() for theme-registered CPTs (which usually fire at priority 10).
If you're on AMP plugin v1.0+ (effectively any install set up since 2019), prefer the amp_supportable_post_types filter. The two approaches can coexist on a site mid-migration, but the filter is the documented public API.
Validate the AMP version
AMP validation must pass for the page to be served as AMP (Google's AMP cache and most consuming surfaces reject invalid AMP outright). Three layers to check:
1. Chrome DevTools console
Load the AMP URL and open DevTools. AMP runtime errors print to the console with the prefix Powered by AMP ⚡ HTML. Common errors: disallowed-tag, disallowed-attribute, mandatory-tag-missing.
2. The AMP plugin's own validator
The plugin runs a built-in validator on every AMP request. Go to WP Admin → AMP → Validated URLs. Each URL is graded valid or invalid with a per-rule breakdown. Click any URL for a per-element diff showing which plugin output broke validation.
3. The AMP project's online validator
validator.amp.dev accepts a URL or pasted HTML and reports validation errors with line numbers. Use this when the in-WordPress validator's output is too vague.
For programmatic checks in CI, the amp npm package ships a command-line validator: npx amphtml-validator https://example.com/resources/whitepaper/?amp=1.
Common pitfalls
The recurring problems when you wire up AMP for a CPT:
| Symptom | Cause | Fix |
|---|---|---|
CPT post returns 404 at ?amp=1 | Permalinks need flushing after registering the CPT | Go to Settings → Permalinks and click Save (no changes needed) |
| AMP page renders but is "invalid" | Third-party plugin output uses disallowed HTML | Find the offending plugin in AMP → Validated URLs, sandbox it via the per-template settings |
| Custom JS in your theme breaks AMP | AMP forbids author-written JS | Remove the JS from AMP-served templates, or wrap with if ( ! is_amp_endpoint() ) |
| Inline styles over 75KB | AMP's CSS budget is 75KB | Audit wp_head() output, dequeue heavyweight theme CSS for AMP requests |
| Custom font missing on AMP page | Font wasn't whitelisted in the AMP runtime | Use amp-font or load via amp-custom inline within budget |
| Featured image missing | CPT doesn't support thumbnail | Add 'supports' => array( 'title', 'editor', 'thumbnail' ) to register_post_type() |
Most of these track back to third-party plugin output. If you're heading into AMP for a CPT, audit your active plugins first; expect to disable a few on AMP-served URLs.
Migration path: switching AMP off cleanly
If you've decided AMP isn't worth keeping, removing it cleanly matters more than how you added it. A bad removal leaves dead ?amp=1 URLs returning 200 with empty content, which hurts SEO worse than keeping AMP would have.
The clean removal sequence:
-
Deactivate the AMP plugin but DON'T delete it yet. The plugin handles redirect logic while installed.
-
Add 301 redirects for the AMP URL patterns. For path-suffix AMP, add to
.htaccess(or your Nginx config):apacheRewriteRule ^(.*)/amp/?$ /$1 [R=301,L] RewriteCond %{QUERY_STRING} (^|&)amp=1(&|$) RewriteRule ^(.*)$ /$1? [R=301,L] -
Regenerate the XML sitemap to drop AMP URLs. Most SEO plugins do this automatically once AMP is deactivated. Verify via
https://example.com/sitemap.xml. -
Submit a sitemap re-index in Google Search Console so the AMP URL drops are picked up faster than the natural recrawl.
-
Monitor Search Console's AMP report for 30 days. Once it shows zero AMP URLs, delete the plugin.
For administrative access during the migration, see how to change a WordPress password if you need a fresh admin session, and how to increase the PHP memory limit if the sitemap regeneration runs into memory issues on a large site.
What to do next
For continued WordPress optimization where AMP is no longer the answer:
- How to use ElasticPress with WP_Query — push search load off MySQL onto Elasticsearch for faster page render.
- wp_insert_post memory deep-dive — relevant if a large content import is part of your AMP-removal or re-platforming work.
- PHP memory limit reference — for site-wide PHP tuning that handles modern Core Web Vitals workloads.
- Change a WordPress password — admin recovery during platform migrations.
- WPScan usage and man page — security audit your WordPress install before and after a major plugin change like an AMP removal.
- WordPress: moderate comments using regular expressions — if AMP-served pages still accept comments, regex moderation is the lightweight defense.





