WordPress AMP: Enable Automattic's AMP Plugin for Custom Post Types (CPT)

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:

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:

1. Go to WP Admin → AMP → Settings.
2. Scroll to Supported templates.
3. The CPT will now appear as a togglable option. Check the box and save.
4. Visit a post of that CPT and append ?amp=1 or /amp/ to the URL.

The URL form depends on which "AMP mode" you've selected in the plugin's settings:

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:

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:

1. Deactivate the AMP plugin but DON'T delete it yet. The plugin handles redirect logic while installed.

2. Add 301 redirects for the AMP URL patterns. For path-suffix AMP, add to .htaccess (or your Nginx config):

   apacheCopy

   RewriteRule ^(.*)/amp/?$ /$1 [R=301,L]
   RewriteCond %{QUERY_STRING} (^|&)amp=1(&|$)
   RewriteRule ^(.*)$ /$1? [R=301,L]

   These two rules are independent, not a chain. The [L] flag stops rewrite processing as soon as a rule matches, so a /amp/ path-suffix request fires the first rule and a ?amp=1 query-param request fires the second. A path-suffix install only needs the first rule and a query-param install only needs the second, so keep the one that matches how your AMP plugin generated its URLs (and drop the other if it does not apply).

3. 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.

4. Submit a sitemap re-index in Google Search Console so the AMP URL drops are picked up faster than the natural recrawl.

5. 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.

FAQ