AMP Cache - WordPress Plugin

How to Configure AMP Cache for Faster WordPress AMP Pages

AMP Cache is not meant to re-explain what AMP is. Its practical job is to make AMP versions of pages on an AMPforWP site faster, more predictable, and easier to verify. In this guide, we'll look at where to enable AMP Cache, which settings are worth adjusting right away, how not to confuse it with Google AMP Cache, how to verify the outcome in the browser, and what to do if changes still do not appear after caching is enabled.

This article is written for a site owner, editor, or technical administrator who already runs WordPress, has AMPforWP enabled, and needs to speed up mobile AMP delivery without creating accidental conflicts with other cache plugins. That is why the guide includes a lot of verification steps. It is not just "turn on the toggle," but also how to confirm that the cache is actually being generated, when to clear it, and how to handle it alongside a CDN, WP Rocket, LiteSpeed Cache, hosting-level cache, and a service worker.

It is important to separate two similar terms up front. AMP Cache as an AMPforWP extension runs on your WordPress site and helps serve AMP pages faster from your own domain. Google AMP Cache and Bing AMP Cache are external caches in the AMP ecosystem, where valid AMP documents may be stored after those platforms discover them. These layers are related through performance, but they solve different problems, and that distinction is what often creates false expectations.

What the Plugin Does and Where It Fits in the AMP Stack

AMP Cache is a premium extension in the AMPforWP ecosystem. The official product page states that it requires the base AMP for WP plugin, and the documentation shows it as a separate item in the AMP dashboard: AMP option panel -> AMP Cache. In other words, it is not a standalone AMP engine, not a general-purpose cache for all of WordPress, and not a tool for purging Google's external cache. Its scope is narrower: AMP page versions generated by AMPforWP.

In practice, the plugin is useful when your AMP page is already valid and looks acceptable, but loads more slowly than you would like when opened directly from your domain or when users move through the site. The extension creates a cached layer for AMP output and gives you a few control settings: enabling the cache, automatic cache clearing on an interval, a numeric clearing interval, and a manual purge option through a separate checkbox. The official instructions also emphasize that an administrator will not see normal cache behavior while still logged in to WordPress in that same browser.

The main benefit of AMP Cache is not that it "magically fixes" every speed issue. Its value is reducing the repeated work WordPress has to do when serving an AMP document. Without caching, the server has to build the page each time: fetch the post, apply the AMPforWP template, inject settings, metadata, ads, analytics, styles, and component markup. With caching enabled, a repeat request may receive a ready-made version faster. For users, that usually shows up as faster rendering above the fold and more consistent load times on repeat visits.

The official AMP Cache page highlights First DOM Render, AMP validation, and before-and-after benchmarks. Those numbers should not be treated as guarantees for every site, because performance depends on hosting, theme, the number of AMPforWP extensions, ads, analytics, images, and other cache layers. But the testing approach is correct: do not start with a generic marketing score. Start with how quickly the document appears and whether it remains valid AMP.

Why Standard WordPress Caching Does Not Always Solve This

Regular cache plugins are often designed for full WordPress pages, minification, CSS optimization, deferred JavaScript loading, and CDN rewriting. AMP pages operate under stricter rules: arbitrary JavaScript is not allowed, CSS is limited, many elements must be converted into AMP components, and the document has to pass validation. Because of that, an aggressive optimization that helps a regular page can break the AMP version.

WP Rocket explains this directly in its documentation: some optimizations are disabled for AMP pages because AMP uses its own components and does not allow arbitrary scripts. The AMP for WordPress documentation also warns that multiple caching systems can conflict, and that some optimization features such as additional lazy loading are unnecessary on AMP URLs because AMP already controls resource loading. That does not mean AMP Cache cannot be used alongside other tools. It means your testing has to be deliberate.

Who This Plugin Is For

AMP Cache is worth considering if your site already has a working AMPforWP setup, the mobile AMP version brings traffic or is used for fast internal navigation, and the administrator is ready to verify results not just by feel but through DevTools, AMP Test, and before-and-after load comparisons. The extension is especially reasonable to test on content-driven projects: blogs, media sites, directories, informational sites, pages with AMPforWP ad units, and sites where editors regularly change AMP design settings.

The plugin may not be a good fit if AMP is enabled only formally, but the pages are actually invalid, the AMP design falls apart because of the theme or page builder, there is already a strong server-side cache with careful AMP compatibility, and the site owner does not want to deal with multiple cache layers. Another poor use case is expecting the extension to solve indexing problems, ad issues, or the external Google AMP Cache with a single click. Caching can speed up delivery of a finished AMP document, but it does not replace validation, correct AMPforWP configuration, or Search Console checks.

How AMP Cache Differs from Google AMP Cache

The most common question sounds like this: if Google can already cache AMP pages, why would you need a separate plugin? The answer depends on the user's path. External AMP Cache works as a proxy CDN for valid AMP documents discovered by platforms. Google, Bing, and other AMP ecosystem participants may serve a copy of a page from their own cache domain structure if the document is valid and has been discovered. But not every visit goes through that external cache.

A user may open an AMP URL directly, follow an internal link from an AMP page that is already open, arrive from social media, a messenger, an email, or an app. In those cases, the request may hit your origin server. If the origin rebuilds the AMP document on every request, speed depends on WordPress, the database, the theme, installed extensions, and the current load. AMP Cache works exactly at that part of the chain: it helps your site serve the AMP version faster from the origin.

The AMP Project documentation describes external AMP Cache as a proxy network that accepts only valid AMP pages, allows safe preloading, and applies additional optimizations. But it does not say site owners can ignore origin performance. The official AMP plugin for WordPress documentation separately explains that page caching still matters on an AMP site because visitors are not always served from an external AMP Cache.

The practical conclusion is simple: do not test AMP Cache only through URLs like cdn.ampproject.org. When configuring the extension, it is more important to open your site's own AMP URL, such as a page with the AMP suffix or AMP parameter used by your AMPforWP setup. If you see a speed improvement on the origin URL, the extension is doing its primary job. If the only issue is that Google's external cache is not updating, you need a different approach and possibly a dedicated tool for purging AMP CDN Cache.

What Happens When Content Changes

Cache always involves a tradeoff: it speeds up delivery of a finished page, but it may temporarily show an older version. That is why the official AMP Cache documentation calls out manual purging and also notes that after changing AMPforWP Core settings, you should clear the cache so updates appear immediately. This matters most for design, ads, analytics, menus, logos, colors, enabling additional extensions, and switching AMP modes.

External AMP Cache updates on its own rules. The AMP Project documentation describes how Google AMP Cache updates through caching directives and separate update mechanisms, but that is a different system. Clearing AMP Cache inside WordPress does not mean the platform's external cached copy updates instantly. In day-to-day workflow, it is better to keep two checks: first confirm that your origin AMP URL serves the new version, then see how the page appears in Google Search or AMP Test.

What to Check Before Installation

Before enabling any cache, it helps to capture the baseline state. That saves hours later, because once several optimizations are enabled, it becomes hard to tell what actually sped up the page or broke an element. For AMP Cache, preparation matters even more: the plugin works with the AMP version, and AMP is sensitive to markup validity, ads, analytics, forms, menus, and third-party components.

First, confirm that AMP for WP - Accelerated Mobile Pages is installed and active. The official AMP Cache page explicitly lists this as a requirement, and the installation guide for the base AMPforWP plugin shows the standard path through Plugins -> Add New, searching for the plugin, then Install Now and Activate. If the base AMPforWP plugin is not working, AMP Cache has nothing to accelerate.

Next, open several AMP URLs of different types: a regular post, a page, a category, or an archive, if those are enabled in AMPforWP. Do not limit testing to the homepage. On content-heavy sites, problems often appear only in one template type: for example, a single post may validate correctly, while an archive uses an extra component; a page with a form may open fine, while a post with ads throws a validation error.

Minimum Checklist Before Enabling It

• AMP pages open from your own domain and do not show a blank screen, endless loading, or broken layout.
• Your main AMP URLs pass Google AMP Test or AMP Validator without critical errors.
• You know which mode AMPforWP is using: standalone mode or compatibility mode with AMP by Automattic.
• The site is not already running several full-page cache systems that conflict with each other.
• You have access to clear hosting cache, CDN cache, and your main cache plugin, if they are enabled.
• You can open the page in Incognito or in a browser where you are not logged in, to test normal visitor behavior.

Also check your SEO integration. AMPforWP publishes compatibility cards, for example for Rank Math SEO, showing support for the title, description, canonical, meta tags, and ld+json data. This matters not because AMP Cache manages SEO fields, but because it will store the AMP document exactly as it is generated. If canonical tags or structured data are already wrong before caching, caching will simply preserve the incorrect output until you purge it.

When It Makes Sense to Delay Installation

Do not start with AMP Cache if your AMP version is still unstable. First fix validation, disable incompatible elements, get the design into a working state, and make sure the site actually needs the mobile AMP version. On WordPress.com, sites with heavy page builders, custom forms, complex ad setups, or a lot of custom JavaScript, AMP may require separate tuning. In that environment, caching should come last, once you already understand exactly what it is speeding up.

Working rule: if an AMP URL fails validation or looks visually broken before you install AMP Cache, caching is not the fix. First make the AMP page valid and usable, then optimize how it is served.

Install It Without Unnecessary Risk

Installing AMP Cache starts the same way as most AMPforWP extensions: you need the extension file, then you upload it to WordPress, activate it, and open the AMPforWP settings panel. This article does not cover purchasing, licensing, or obtaining the premium version. The point of this section is to enable a plugin you already have in a safe way and keep control over the outcome.

Before installation, create a site backup using the standard method you already trust. That is not a special AMP Cache requirement. It is simply good practice before adding caching and optimization. If the site runs on managed hosting, it also helps to know where server-side cache is cleared. On larger projects, it is better to install the extension on a staging copy first, or at least enable it during a low-traffic window.

Recommended Sequence

1. Make sure the base AMPforWP plugin is active and AMP pages open correctly.
2. Go to Plugins -> Add New -> Upload Plugin, upload the AMP Cache ZIP file, and activate the plugin.
3. Open the AMPforWP panel: AMP option panel -> AMP Cache.
4. Do not enable any automatic purge settings yet if you have not recorded baseline speed measurements.
5. Open 2-3 AMP URLs in Incognito and save your baseline observations: first render, full load time, console errors, menu visibility, and ad visibility.
6. Enable Enable AMP Cache and save the changes with Save Changes.
7. Repeat the test on the same pages in a browser where you are not logged in.

Do not combine installation with bulk optimization. A common mistake is enabling AMP Cache, updating AMPforWP, turning on minification, changing the CDN, switching the AMP theme, and adding a new ad block all at once. If the menu breaks or ads disappear after that, finding the source becomes almost impossible. For a controlled rollout, change one layer at a time and record which action changed the behavior.

Best Pages for the First Test

The best test set is not the prettiest set of pages. It is a mix of different load patterns. Use one standard article with no complex blocks, one page with images, one post with ads or analytics, and one archive if AMPforWP outputs archives. On each URL, check three things: the page opens, the markup is valid, and reopening it in Incognito is either faster or at least more consistent.

If the site uses mobile redirection to AMP, test both the direct AMP URL and the behavior with a mobile user agent. If AMP is enabled only for certain post types, do not draw conclusions from the homepage, which may not be served by the extension at all. Critical expected state after installation: the AMP URL opens for a normal visitor, remains valid, and shows the same content it was supposed to show before caching.

The Main Settings Screen: What to Enable Right Away and What to Leave for Later

The official AMP Cache guide shows a compact set of options, and that is a plus: the plugin does not force site owners to design a complicated exclusion strategy on day one. But that simplicity is exactly why you need to understand what each switch actually does. With caching, the risk is not only mistakes. It is also enabling a setting too confidently before confirming the site is ready for it.

Enable AMP Cache

This is the main switch. Once you turn it on and save, the plugin starts caching AMP pages. For the first rollout, enable only this setting and leave automatic clearing off unless you already have a reason to define an interval. That makes the effect easier to isolate: the extension is on, the AMP URL exists, there is a repeat request, and there is something you can measure. If the page breaks right after enabling it, you know exactly which setting changed.

After saving, open the page as a non-admin user. The official AMP Cache troubleshooting guidance explicitly says that cache is not generated when the same logged-in user is testing the site in the same browser. That is normal protection against caching an administrative session. This is why testing from an admin tab often leads to the false conclusion that "nothing works." Use Incognito, a second browser, or log out of WordPress completely.

Auto clear cache?

Automatic clearing is useful when the site changes regularly and you do not want to manually purge the cache after every edit. But it should not be enabled "just in case" with a very short interval. If the cache is cleared too often, you lose much of its benefit: pages have to be rebuilt more often, and users reach the ready-made copy less frequently. If the interval is too long, you create the opposite problem: outdated AMP design, ads, or settings remain in place longer than they should.

For a typical blog that does not publish updates every minute, it makes sense to start with a moderate interval and then adjust based on the editorial rhythm. For a site that frequently changes AMP design, ad placements, or menus, it is better to combine automatic clearing with manual purging after important changes. For a stable reference-style site, you can even start without automatic clearing and enable it later, once you know which elements tend to go stale.

Set the Time Interval

The official guide describes this field as a numeric interval in hours, with no AM/PM format. That small detail matters: the field expects a number, not text. If you enter a value in an unclear way, the administrator may wait for a purge that does not happen the way they expected. For your first test, use a simple numeric value, then verify that the page updates as expected once the interval has passed.

The right interval is not based on a universal formula. It depends on how often the site changes and how much stale content you can tolerate. A news site where headlines, ad inserts, and recommendation blocks change frequently needs a more cautious schedule. A site with evergreen articles can usually tolerate a longer cache lifetime. If AMPforWP global settings are changed often, do not rely on the timer alone. Use manual purging after each of those changes.

Clear Cache

Manual clearing is the most useful setting for troubleshooting. The official documentation states this directly: if you changed AMPforWP Core settings, clear AMP Cache so the changes appear immediately. That applies when you update the AMP logo, color scheme, ad positions, SEO integration, analytics, compatibility mode, menus, PWA settings, or any extensions that affect AMP markup.

After manually clearing the cache, do not test only by refreshing the admin tab. Open the same AMP URL in Incognito, then inspect DevTools Network. If the first request after purging is slower and the next one is more stable, that is normal: the cache has to be regenerated first. If both requests are equally slow and nothing changes in Network, move into troubleshooting mode: you may be testing as a logged-in user, the URL may not actually be an AMP URL, another cache may be conflicting, or the page may be failing AMP validation.

How to Measure the Outcome Properly Instead of Arguing with PageSpeed

The official AMP Cache page specifically points out that standard performance tools do not always "understand" AMP the way site owners expect. For example, they may recommend removing cdn.ampproject.org/v0.js, even though that script is fundamental to an AMP document. So your final validation should not turn into a chase for an abstract score of 100.

A proper AMP Cache test revolves around three questions. First: does the page remain valid AMP? Second: does the first useful render appear faster for a regular visitor? Third: did anything important on your site break - menus, ad units, analytics, forms, related posts, images, buttons, or internal navigation?

Testing with DevTools Network

The official AMP Cache speed-check instructions recommend opening Developer Tools, going to the Network tab, reloading the page, and watching how long the document and its elements take to load. For a realistic test, use Incognito and disable unnecessary browser extensions that may affect requests.

1. Open the AMP URL in Incognito before enabling cache and do a hard reload.
2. In the Network tab, find the initial document request, not just images and fonts.
3. Record the response time, the first visible render point, and the total load time.
4. Enable Enable AMP Cache, save the settings, and open the same URL again.
5. Repeat the request several times, because the first visit may only generate the cache and the next one may show the repeat-delivery behavior.
6. Compare a series of identical requests, not one random measurement.

If the site uses a CDN or hosting cache, the outcome may be uneven. One request may hit one cache layer, the next may hit another. So do not draw conclusions from a single page refresh. It is better to test several URLs, in the same browser mode, on the same network, and with the same state of other caches. If possible, also capture the response headers: they may reveal which cache layer responded, although the exact headers depend on your hosting and plugins.

Checking AMP Validity

AMP Cache should speed up a valid AMP page, not hide errors. After enabling the extension, run your key URLs through Google AMP Test or AMP Validator. The AMP Project documentation lists common issues: forbidden tags, arbitrary JavaScript, invalid attributes, missing required AMP components, and CSS limit violations. For a WordPress site owner, that translates into a simple rule: if a validation error appears after caching is enabled, do not look only at AMP Cache. Also inspect any optimizations that may have altered the HTML, CSS, or scripts in the AMP document.

In practice, validity should be checked both before and after enabling caching. If errors already existed before it was enabled, AMP Cache is not the cause. If the document was valid before and becomes invalid after, first clear AMP Cache, then disable additional optimizations from other cache plugins for AMP URLs, and test again. Pay special attention to pages with forms, embedded video, ads, custom CSS, and non-standard editor blocks.

What Counts as a Good Result

A good outcome is not necessarily a perfect PageSpeed score. On an AMP site, what matters more is that above-the-fold content appears noticeably faster or more consistently, the server spends less time rebuilding the AMP document on repeat requests, and neither validity nor functionality gets worse. If metrics improve only on one test page while other AMP URL types remain unchanged, verify that those pages are actually being served by AMPforWP and are not excluded by another cache.

Check the full chain: the origin AMP URL, a repeat request from a logged-out visitor, AMP validity, key page elements, and only then external speed-scoring tools.

Implementation Example: Speeding Up an AMP Article After a Design Change

Let’s walk through a realistic example. The site publishes informational articles, mobile visitors regularly open AMP versions, and the editor has changed the AMP template design in AMPforWP Core: the logo, headline colors, recommendation block, and ad placement. The goal is to enable AMP Cache so the updated version appears quickly and does not get stuck in its old form.

Goal

Get a cached AMP page that reflects the latest design settings and loads faster on repeat visits. In this workflow, speed metrics are not the only thing that matters. You also need to avoid stale output. If the user still sees the old logo or previous ad placement, the cache is working against the editorial team.

Preparation

Before you begin, check the article's base AMP URL. Open it in a normal browser window and in Incognito, confirm that the AMP version exists, contains the expected content, and does not show critical errors. Then create a short list of elements that are supposed to change after the edit: logo, header color, ad placement, menu appearance, related posts. That list becomes your verification checklist after the cache is cleared.

Steps

1. Make the changes in AMPforWP Core settings and save them.
2. Go to AMP option panel -> AMP Cache.
3. If Enable AMP Cache is still off, enable it and save the changes.
4. Check Clear Cache or use the manual AMP cache purge available in the interface.
5. Open the article's AMP URL in Incognito. Do not use a tab where you are logged in as an administrator.
6. Load the page once, then load it again to observe repeat-request behavior.
7. Check the visual changes, menu, ad units, and AMP validity.

Verification

After the cache is cleared, the updated version should be visible on the origin AMP URL. If the changes appear in Incognito but not in your normal browser session, the issue may be local browser cache or logged-in user state. If the changes do not appear anywhere, go back to AMPforWP Core settings and confirm they were actually saved. If the updates appear on the regular page but not on the AMP URL, check the AMPforWP mode and the specific AMP template in use.

In DevTools Network, do not look only at the full page load. Watch the initial document as well. If the first load after purging is slower and the next one is faster, that is expected: the cache is being rebuilt first. If the page gets faster after caching is enabled but the menu or ads disappear, do not count that as a successful optimization. AMP functionality matters more than a pretty benchmark number.

Common Pitfall

If the site sits behind a CDN or hosting cache, stale output may live outside AMP Cache as well. In that case, the purge order has to be intentional: first AMPforWP settings, then AMP Cache, then hosting cache or CDN if needed, then verification of the origin AMP URL. Do not purge everything on every change if the site is large. For a high-volume editorial workflow, it is better to know in advance which cache layer actually holds the stale fragment.

Automatic Purging vs. Manual Clearing: How to Choose the Right Mode

Automatic cache clearing may seem like the obvious answer: turn it on and the cache never goes stale. In real-world use, though, the right choice depends on the content. Cache is useful only when pages have time to serve enough repeat requests between purges. If you clear it too often, the site keeps paying the rebuild cost. If you clear it too rarely, editors start hearing complaints that "the AMP version is still showing the old content."

For a Stable Content Site

If articles rarely change, comments are not a critical part of the AMP version, the ad layout is stable, and AMPforWP design changes happen only occasionally, you can start with manual clearing plus a moderate automatic interval. In that setup, the administrator clears cache after major changes, while the schedule acts as a safety net. That works well for reference sites, blogs with evergreen content, and sites where AMP pages do not need hourly updates.

For a News Site or Frequently Updated Site

If the editorial team actively revises content, pushes urgent updates, frequently reshuffles ad blocks, or changes the AMP template appearance, automatic clearing should be enabled deliberately. The interval needs to be short enough that old versions do not linger too long, but not so short that the cache is constantly reset. In this case, it helps to compare several page types: fresh posts, popular older content, category pages, and pages with ads.

For a Site Using an External CDN

If WordPress sits behind a CDN, do not confuse clearing AMP Cache with clearing the CDN. A CDN may cache HTML, images, CSS, fonts, or other assets according to its own rules. AMP Cache controls one layer, the CDN controls another. When troubleshooting stale output, follow this sequence: open the origin URL, test in logged-out mode, clear AMP Cache, then clear the CDN or hosting cache if needed. If the CDN rewrites assets, keep AMPforWP compatibility in mind. The official CDN Enabler compatibility card shows that AMPforWP can work with CDN-hosted images within supported setups, but that is not a blanket guarantee for every CDN configuration.

Decision Map for Different Types of Sites

The same AMP Cache setup rarely works equally well for every site. On one site, the AMP page may be a short news item with an image and ads. On another, it may be a long tutorial with several images, embedded video, tables, and a related-content block. On a third, it may be a commercial landing page where not just above-the-fold speed but also accurate analytics matter. That is why, after the basic setup, it helps to think in terms of a decision map rather than a checklist of "best settings."

The decision map starts with one question: what exactly needs to become faster without going stale? If the goal is repeat visits to popular AMP articles, the key factor is stable storage of ready-made documents. If the goal is making updated ad placements appear quickly, manual purging after changes to AMPforWP Core settings matters more. If the goal is reducing server load during traffic spikes, look not only at average load time but at how the site behaves under a series of logged-out requests to several AMP URLs.

Informational Blog

For a blog with infrequent content edits, AMP Cache can usually be enabled with confidence, but testing should go beyond the latest post. Use one popular older article, one new post, and one page with a large number of images. Blogs often accumulate different historical content blocks: old galleries, outdated shortcodes, embedded videos, subscription forms. Caching can make repeat delivery faster, but it does not fix a block that fails AMP validation from the start.

Automatic clearing here should follow the editorial cycle. If articles rarely change after publication, you can choose a calmer mode and clear cache manually after global updates. If the editor often changes headlines, ads, or recommendation blocks in already published material, the interval should be shorter. In any case, after enabling the plugin, confirm that a fresh article appears in AMP exactly the way the editorial team expects it to.

Media or News Project

For a news site, the main risk is stale information. Technically, the cache may work perfectly, but the editorial team will still be unhappy if a corrected headline or updated copy does not appear on the AMP URL. Here, purge discipline matters. After urgent edits, the editor or technical administrator should know which layer to clear and where to verify the result. AMP Cache with manual purging becomes part of the publishing workflow, not a one-time setup.

A second nuance is ads and analytics. News sites often use multiple ad slots, consent blocks, counters, and A/B changes. AMP restricts scripts, and cache locks in the finished markup. After changing the ad setup, check AMP Test, DevTools Network, and the actual visibility of the blocks. If speed improves but the ad slot stops rendering, that is not a successful rollout.

Reference Site or Evergreen Content Library

For a reference site, AMP Cache can deliver more value because content changes less often and repeat visits to popular pages may be common. In that case, a longer automatic clearing interval may be fine if there are no dynamic elements that need to update quickly. But even on a reference site, do not forget about global changes: a new logo, new color scheme, menu update, or SEO integration change still requires a manual purge.

A useful practice for this kind of site is maintaining a control set of AMP URLs. Put together a list of 8-12 pages of different types and check them after updates. The list should include a short article, a long article, a page with multiple images, a page with video, a page with internal links, and an archive. That set quickly shows whether caching has led to inconsistent behavior across templates.

Site with Forms, Ads, or Personalized Blocks

AMP Cache should not cache anything that depends on a specific visitor, if that kind of behavior exists in the AMP version. Classic AMP content usually has less personalization, but many sites still add forms, consent prompts, ad solutions, newsletter blocks, and analytics. Before enabling cache, identify which elements are static and which depend on visitor state. If an element is questionable, it is better to find an AMP-compatible implementation first and test caching only after that.

For forms, the test should be practical: open the AMP URL as a visitor, submit a test entry, confirm that the success or error message appears, verify that the email or system record is received, then repeat the same test after clearing the cache and enabling it. If the form does not support AMP or depends on arbitrary JavaScript, AMP Cache will not solve the issue. You need a compatible AMP component or a dedicated extension instead.

Post-Install and Post-Update Verification Routine

A one-time test on installation day becomes outdated quickly. WordPress updates, AMPforWP releases new versions, ad networks change their code, hosting providers may enable an extra cache layer, and editors update templates. That is why AMP Cache benefits from a short routine that can be repeated without deep technical analysis. This matters even more when the site is managed by more than one person.

Control URLs

Create a list of control AMP URLs. It should include pages that differ in markup type and business importance. Do not choose only the easiest pages. The list should reflect real risks: long-form content, an image above the fold, an ad block, a form, a table, a video, an archive, and a page with menus and internal links. If all of those URLs still work after AMP Cache is enabled, the chance of a hidden conflict is lower.

For each URL, note the expected outcome: which logo should appear, which ad placements should be present, how the menu should open, what the canonical should be, whether a form or video is present. This keeps the review from becoming a vague "looks fine." When something changes after an update, you immediately know what to inspect and where to look for the cause.

Steps After an Update

1. Update WordPress, AMPforWP, or a related extension through the normal process.
2. Clear AMP Cache if the update affects AMP output, design, ads, analytics, or compatibility.
3. Open the control AMP URLs in logged-out mode.
4. Check AMP validity at least on the pages with the most complex mix of elements.
5. Compare Network loading on one or two popular URLs.
6. If a problem appears, temporarily disable the most recently changed layer, not the entire system at once.

This routine does not require complex automation, but it protects against a common situation: the site runs fine for months, then after an update an AMP validation error appears, while the cache keeps serving part of the older documents. If the team knows the purge and testing order, the issue is much easier to isolate.

How to Record Results

A short table in a working document is enough: URL, page type, check date, AMP Test status, visibility of key elements, speed note, and any follow-up action after a problem. Do not store passwords, keys, private admin URLs, or user data in that document. The point of the log is not to hold secrets. It is to preserve technical memory: which settings worked, which purge interval was chosen, and which cache plugin caused conflicts.

If you work with a contractor, this kind of log makes the task much easier to describe precisely. Instead of saying "AMP Cache is not working," you can say: "on the control post, after clearing AMP Cache, the old ad block is still visible in Incognito, the CDN has been cleared, AMP Test passes, and the issue reproduces only on archive URLs." That cuts troubleshooting time dramatically.

Compatibility with WP Rocket, LiteSpeed, CDN, and AMPforWP Extensions

AMP Cache is often installed not on a clean site, but inside an already complex system: WP Rocket or LiteSpeed Cache, Cloudflare or another CDN, hosting-level server cache, Rank Math, Site Kit, AMPforWP ad extensions, PWA for AMP, forms, and page builders. This is where the real risks appear. Not because AMP Cache conflicts with everything by itself, but because several layers may end up modifying the same AMP document.

WP Rocket and Similar Cache Plugins

WP Rocket's AMP documentation explains an important principle: page cache can work for AMP URLs, but many optimizations are disabled on AMP pages because AMP does not allow arbitrary JavaScript and uses its own component model. If WP Rocket is active alongside AMP Cache, check whether AMP URLs are being affected by minification, deferred scripts, CSS removal, or any other behavior that changes AMP markup.

If the page becomes invalid after AMP Cache is enabled, temporarily exclude AMP URLs from aggressive optimizations in the main cache plugin and test again. WP Rocket documentation gives an example of excluding AMP paths through Never Cache URL(s). The exact pattern should match your AMP URL structure: a /amp suffix, a ?amp parameter, or any other format your site uses.

LiteSpeed Cache and Server-Side Cache

LiteSpeed Cache works closely with the server-side LSCache component. Its documentation makes clear that actual cache features depend on a LiteSpeed server or QUIC.cloud, while the plugin passes rules and controls purging. If that layer is already active, AMP Cache adds yet another caching level for AMP documents. That can be useful, but it requires checking headers, exclusions, and purge order.

In practice, do not run two full-page caches "blindly" on the same URLs. First determine which layer is actually serving the AMP document. If LiteSpeed already caches AMP URLs reliably without breaking validation, AMP Cache should be tested as an additional specialized layer, not treated as a mandatory replacement. If LiteSpeed is not available at the server level or is used only for optimization features, AMP Cache may be the more direct tool for AMPforWP pages.

PWA for AMP and the Service Worker

The official AMP Cache page mentions integration with PWA for AMP and a service worker. A service worker can help with fast repeat visits and offline behavior, but it also adds another cache layer inside the user's browser. So after changing AMP design or page behavior, do not check only the server-side cache. Also check the client-side state. If the user still sees the old page while Incognito shows the new one, the cause may be closer to the browser than to WordPress.

To test the PWA layer carefully, use a separate workflow: first with browser cache disabled or cleared, then with a normal repeat visit, then with a second browser for comparison. Do not draw conclusions from one device alone. If the site has critical forms, ads, or analytics on AMP, test them after every service-worker-related change.

SEO, Analytics, and Ad Units

Rank Math, Site Kit, AdSense, analytics, and ad extensions shape the AMP page before it is ever cached. AMP Cache should not become the place where you try to "fix" broken metadata or missing ad code. First confirm that AMPforWP correctly outputs the title, description, canonical, structured data, ads, and analytics on the uncached page. Then enable caching and verify that the output remains correct.

If an ad unit appears right after clearing AMP Cache but disappears later, do not assume the issue is inside AMP Cache alone. Possible causes include ad network restrictions, AMP component errors, external script delays, Consent/GDPR behavior, or a conflict with another cache plugin's optimization layer. The AMP document must remain valid, otherwise external platforms may refuse to cache it or show it in an AMP context.

When Speed Improves but Business Outcomes Do Not

AMP page speed matters, but by itself it does not guarantee more leads, more ad views, or deeper reading. AMP Cache improves the technical side of AMP document delivery, but the user-facing outcome still depends on what is actually on the page. If the top of the page loads faster but the headline does not answer the query, the menu is awkward, ads cover the content, or internal links send users to slower non-AMP pages, the overall impact will be limited.

Review the User Journey, Not Just the Document

For a content site, it helps to follow the path the way a visitor would. Open an AMP article in Incognito, inspect the top of the page, scroll to the middle, open the menu, follow an internal link, open a related article, and check the ad placements and subscription form if present. Then repeat the same journey after enabling cache. If the initial document becomes faster but the next click is still slow, only part of the AMP URL set may be cached, or internal links may be leading users back to the regular version.

Do Not Optimize Against AMP Rules

Sometimes a site owner sees a recommendation from a speed tool and tries to remove something AMP depends on. The official AMP Cache page gives the example of cdn.ampproject.org/v0.js: a generic tool may treat the external script as a problem, but for AMP it is a required foundation. The same applies to AMP components for images, video, forms, and ads. If an optimization produces a nice score at the cost of invalid markup, it is a bad optimization.

Brief Takeaway for the Editorial Team

AMP Cache works best when treated as part of the editorial workflow. After changing the AMP template or ad layout, the editor should know the routine: save the settings, clear AMP Cache, open the page as a visitor, verify the updated appearance, run AMP Test, and do several repeat loads. That is faster and more reliable than debating each time whether WordPress, the CDN, Google Cache, or the browser is to blame.

Common AMP Cache Issues and How to Diagnose Them

Most post-cache problems look similar at first: "the page did not get faster," "changes are not showing," or "something broke." But the causes differ. Below is a practical troubleshooting guide specifically for AMP Cache and AMPforWP, focused on symptoms, validation steps, and safe rollback options.

The Cache Is Not Being Generated, or the Plugin Seems to Do Nothing

Symptom: after enabling Enable AMP Cache, speed does not change and reopening the page looks exactly the same as before installation.

Possible cause: you are testing in a browser where the user is logged in to WordPress. The official AMP Cache troubleshooting guide says the cache is not generated for that current view in this state.

What to check: open the same AMP URL in Incognito, another browser, or after logging out of the admin area. Confirm that it is actually an AMP URL, not the regular page. Reload it several times, because the first request may only generate the cache.

How to fix it: test as a logged-out visitor. If cache works in Incognito, nothing needs fixing. If it still does not work there, temporarily disable other cache plugins for AMP URLs and test again.

The Site Still Shows the Old Version After AMPforWP Settings Change

Symptom: the color, logo, ads, or menu have been changed in the admin panel, but the AMP page still shows the previous version.

Possible cause: AMP Cache is serving an older cached copy. The official instructions specifically say to clear the cache after changes to AMPforWP Core settings.

What to check: run a manual purge through Clear Cache, then open the page in Incognito. If the old version is still there, clear your hosting cache or CDN as well, if present. If the new version appears only after disabling the CDN, the stale layer is above WordPress.

When to roll back the setting: if repeated purges still do not lock in the new version, or if the page alternates between old and new versions, temporarily disable AMP Cache and define a clear purge order for all cache layers.

The AMP Page Becomes Invalid After Optimization

Symptom: Google AMP Test or AMP Validator starts showing an error after cache is enabled or after you change optimization settings.

Possible cause: a third-party cache plugin or optimizer is altering AMP HTML: minifying the wrong fragment, moving scripts, combining CSS, injecting a forbidden tag, or changing required attributes. The AMP Project documentation lists exactly these classes of errors: forbidden JavaScript, missing required attributes, CSS limit violations, and invalid AMP components.

What to check: compare validity before and after enabling the questionable optimization. Disable deferred JavaScript, aggressive minification, CSS removal, and CDN rewriting for AMP URLs if they are being applied. Restore validity first, then turn AMP Cache back on.

How to fix it: keep AMP Cache enabled only after the AMP URL is valid. If the conflict comes from another cache plugin, use AMP URL exclusions or disable the problematic features for those URLs.

Menus, Links, or Interactive Elements Stop Working

Symptom: the AMP page opens quickly, but the menu no longer expands, a link goes to the wrong place, a form does not respond, or an ad unit behaves differently.

Possible cause: AMP restricts custom JavaScript, and cache may preserve a page that was already assembled incorrectly. Questions about menus and links after enabling AMP Cache have appeared in comments on the official guide, and AMP for WP forums also contain discussions about conflicts between AMP and builders or non-standard elements.

What to check: open the page without AMP Cache, then with AMP Cache. If the element breaks only after caching, clear the cache and check whether another optimizer is modifying the AMP HTML. If the element is broken even without cache, the problem is in AMPforWP, the theme, the builder, or the extension behind that element.

How to fix it: replace the non-AMP-compatible element with an AMP-compatible version, disable the problematic block on the AMP version, or configure a compatible AMPforWP extension. Do not add arbitrary JavaScript as a quick fix.

PageSpeed Does Not Show the Expected Improvement

Symptom: after enabling AMP Cache, the site feels faster, but the tool's overall score barely changes.

Possible cause: the tool evaluates more than page cache alone. It also factors in images, fonts, ads, third-party requests, AMP runtime, server delay, network conditions, and the test methodology itself. The official AMP Cache page explicitly warns that AMP performance tests need to be interpreted correctly.

What to check: compare the initial document in Network, First DOM Render, repeat-load behavior, and validity. Do not remove required AMP scripts just to improve a score. Check whether ad networks, analytics, or heavy images are still slowing the page.

How to fix it: keep AMP Cache as the HTML delivery layer, and address other bottlenecks individually: optimize images, remove unnecessary ad slots, review font loading, configure the CDN properly, and make sure the AMP page remains valid.

A Site Behind a CDN Shows Different Versions of the Page

Symptom: one browser shows the new AMP page while another still shows the old one, or the result does not change immediately after AMP Cache is cleared.

Possible cause: AMP Cache may be cleared, but the CDN, hosting cache, or browser cache is still holding an older copy. The reverse can happen too: the CDN is cleared, but AMP Cache is still serving the old version.

What to check: open the origin AMP URL, temporarily bypass the CDN in a safe hosting-panel-supported way if such a method exists, and compare response headers. Do not change DNS or disable protective services on a live site without a rollback plan.

How to fix it: define a purge order: AMPforWP settings -> AMP Cache -> server cache -> CDN. Then document that sequence as an internal instruction for the editorial team.

How to Use AMP Cache as Part of the Site's Day-to-Day Workflow

After the initial setup, the plugin should not turn into a "black box" that no one touches. Caching lives alongside publishing, design changes, ads, SEO settings, and WordPress updates. The clearer the workflow is, the fewer random complaints you will get from editors and users.

After Publishing a New Article

If AMPforWP automatically creates an AMP version for new posts, open the new article in AMP format as a logged-out visitor. The first load may generate the cache, and the second should show more stable behavior. Then check internal links, the featured image, ad placements, and validity. If the publication is time-sensitive, do not rely only on the automatic interval. Use a manual purge after the final edits.

After Changing the Template or Ad Layout

Any change to the global AMP template affects many pages at once. After changes like that, clear AMP Cache and test several URL types. Do not limit testing to the main post. If the ad network uses AMP components, verify that the code has not become invalid. If SEO settings were changed, inspect the AMP page source or a validation tool to confirm the canonical and metadata are still correct.

After Updating WordPress, AMPforWP, or Extensions

Updates can change AMP markup output, component compatibility, and settings behavior. That is why, after plugin updates, you should clear AMP Cache, open your control set of pages, and check validity. If everything works, keep the extension enabled. If an error appears, do not roll back the entire site immediately. First disable only the most recently enabled optimization or temporarily disable AMP Cache so you can isolate the source of the problem.

Document the Settings in a Simple Log

For a small site, a short note is enough: when AMP Cache was enabled, which purge interval was chosen, which URLs were tested, what other caches exist, and what to do after changing AMPforWP Core. For a larger project, keep a simple change log. It will help explain why the page was fast yesterday but became slower today after new ads or a new block were added.

FAQ About Configuring and Testing AMP Cache

Does AMP Cache speed up the entire WordPress site?

No. According to the official materials, this is an extension for AMP pages used together with AMPforWP. Regular WordPress pages, the admin dashboard, the WooCommerce cart, the REST API, and other parts of the site need their own optimization approach. If you want overall performance improvements, also look at page cache, object cache, CDN, image optimization, and hosting.

Why can't I see the cache when I test the site from the admin area?

The official AMP Cache troubleshooting guide explains that the cache is not generated when you are logged in to WordPress and checking the page in the same browser. Open the AMP URL in Incognito, a different browser, or after logging out. This is one of the most common false symptoms behind the claim that "the plugin doesn't work."

Do I need to clear the cache after every article edit?

Not always. If you are changing the post content itself, behavior depends on how AMPforWP and the cache react to page updates. But after changes to AMPforWP Core settings, the official instructions explicitly recommend clearing AMP Cache so the updates appear immediately. For important publications and design changes, manual clearing is safer than waiting for the interval.

Can AMP Cache be used together with WP Rocket or LiteSpeed Cache?

It can be tested with them, but you should not enable multiple layers without verification. The AMP for WordPress documentation warns about conflicts between multiple page caches, and WP Rocket specifically disables some optimizations on AMP pages. Check AMP URLs, exclusions, validity, and response headers. If stale pages or validation errors appear, simplify the setup.

Does AMP Cache update Google AMP Cache?

No, those are different layers. AMP Cache works with AMP pages on your WordPress site, while Google AMP Cache updates according to the rules of the external AMP platform. Clearing your internal cache helps the origin URL show the latest version, but it does not guarantee instant refresh of the external cached copy.

Which pages should I test after enabling it?

Test at least several types of AMP URLs: a regular post, a page with images, content with ads or analytics, and an archive or category page if those are enabled. One URL may work perfectly while another breaks because of a specific block, form, shortcode, or template.

What should I do if the menu or form breaks after I enable it?

First check whether they break without AMP Cache. If they do, the root issue is AMP compatibility in the theme, page builder, or extension. If the problem appears only after caching, clear AMP Cache, disable aggressive optimizations from other cache plugins for AMP URLs, and verify AMP validity. Do not inject arbitrary JavaScript as a quick fix: AMP may make the page invalid.

Should I chase the highest possible PageSpeed score?

No. For AMP, validity, stable first render, correct behavior of page elements, and the real user path matter more. Some recommendations from general-purpose tools may conflict with required AMP components. Compare the same URLs, in the same browser mode, before and after enabling AMP Cache.

When AMP Cache Is the Right Choice

AMP Cache is worth using when you already have working AMP pages on AMPforWP, a clear set of URLs for testing, access to clear other cache layers, and a willingness to measure the results carefully. The extension's main strength is its specialized handling of AMPforWP output: enabling cache inside the native AMP panel, manual clearing after Core settings changes, interval-based automatic purging, and straightforward validation in logged-out mode.

You should not expect the plugin to solve every AMP problem. It does not replace validation, it does not make incompatible JavaScript compatible, it does not guarantee updates to the external Google AMP Cache, and it does not remove the need for solid hosting. If an AMP page is slow because of heavy ads, large images, or broken markup, caching can help only partially. But if the AMP document is already clean and the origin response is inconsistent, AMP Cache becomes a sensible candidate to test.

The practical order is simple: prepare a set of control AMP URLs, verify validity, enable Enable AMP Cache, test in Incognito, configure Auto clear cache? and Set the Time Interval only after you understand the editorial rhythm, clear cache after AMPforWP Core changes, and do not forget about your CDN or server cache. That approach turns AMP Cache from a random speed button into a controlled tool inside your site's broader performance strategy.