Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
To disable Google AMP in WordPress, first identify what is generating AMP, then turn it off at that layer, remove rel="amphtml" discovery links, and redirect each former AMP URL to its matching canonical page. Deactivating a plugin stops new AMP output but does not resolve AMP URLs that Google has already crawled, bookmarked, cached, or indexed.
The safest migration keeps the non-AMP page live, uses a one-hop HTTP 301 or 302 redirect for each retired AMP address, and verifies the result before expanding the change across the site.
Recommended Free Tools
What disabling AMP actually changes
Google AMP (Accelerated Mobile Pages) is an alternate rendering path for WordPress content. Depending on the implementation, a post may have an AMP representation at a path such as /amp/, through a query-string variant, or through a template that serves AMP markup at the same public URL. Disabling AMP removes that alternate representation; it does not delete the ordinary WordPress post or page.
There are three separate jobs in a clean shutdown:
- Stop generation: disable the plugin, theme integration, or CMS feature that produces AMP.
- Stop discovery: remove
rel="amphtml"from the canonical page source so crawlers are no longer told that an AMP version exists. - Resolve old addresses: redirect retired AMP URLs to the corresponding non-AMP URL, or return a deliberate error when the underlying content itself has been permanently removed.
These jobs are related but not interchangeable. A plugin can be off while old AMP URLs still return 404 errors, and canonical pages can continue advertising AMP if cached or theme-generated markup remains. Search visibility also changes gradually as Google recrawls; there is no universal number of days for that process.
#1 Best Overall
Choose the right shutdown scope
Decide whether AMP should disappear everywhere or only from selected content. The choice affects the settings you record, the redirect map you build, and the amount of crawl monitoring required.
| Approach | When it fits | AMP generation | URL treatment | Operational risk |
|---|---|---|---|---|
| Full-site removal | You no longer want an AMP version for any supported content. | Deactivate and, after recording settings, uninstall the AMP implementation. | Redirect every known legacy AMP pattern to its matching canonical page. | Small sites can usually change once; large sites should stage and monitor batches. |
| Selective removal | You need AMP for some posts, pages, or content types but not others. | Use the plugin’s per-post or per-page controls, supported-template settings, or a conditional filter. | Redirect only the AMP URLs belonging to content that is being retired. | More complex rules and testing because both AMP and non-AMP outputs coexist. |
| Content deletion | The canonical post or page is gone and there is no useful replacement. | Remove AMP along with the content. | Return a deliberate 404 (or another status appropriate to your content policy) instead of redirecting unrelated traffic to the home page. | Broken links and coverage reports require review; there is no replacement page to preserve. |
Do not redirect every retired URL to the home page. Preserve the original path and slug wherever a relevant canonical page still exists; that gives visitors and crawlers the closest equivalent destination.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteInventory the current AMP implementation before changing it
WordPress sites often accumulate AMP settings from a plugin, a theme, a host-level integration, or an older migration. Record the current behavior before disabling anything so you know which URLs need treatment.
Check plugins and integration points
- In the WordPress dashboard, open Plugins > Installed Plugins and identify the AMP implementation. Note whether it is active, network-activated, or accompanied by a cache, SEO, or redirect extension.
- Open the AMP settings screen and record the current template mode: Standard, Transitional, or Reader. These modes determine whether AMP replaces the normal template, shares it, or uses a separate reader-style template.
- Record which content types are supported—such as posts, pages, or custom post types—and whether mobile redirection is enabled. A mobile redirect can hide the AMP URL pattern during desktop testing.
- Inspect a representative post, page, archive, and custom content type while logged out. Look for an AMP link in the HTML source and test likely URL forms, including an
/amp/suffix and any query variant used by your site. - Write down cache layers that could keep old HTML alive: page cache, object cache, CDN, or reverse proxy. You will need to purge the appropriate layers after the change.
The settings screen and URL tests tell you whether AMP is a separate URL, a same-URL rendering mode, or a mixture. That distinction determines whether you need a large redirect map or mainly a markup and template change.
Disable AMP across the whole site
Use this sequence when no AMP output should remain.
1. Capture settings and create a rollback point
Export or copy the AMP settings, supported content types, template mode, and mobile-redirection choice. Take a database and file backup according to your normal WordPress procedure. Keep the notes outside the dashboard; uninstalling a plugin can remove its stored settings.
2. Deactivate the AMP implementation
In Plugins > Installed Plugins, click Deactivate for the AMP plugin. If it is network-activated on multisite, make the change from the network administrator area and confirm which sites inherit it. Deactivation is the first shutdown step recommended in WordPress support guidance, but it only prevents the plugin from generating new AMP responses.
3. Uninstall after confirming no dependency
Once the site serves the ordinary template correctly, choose Delete for the plugin if you want it removed. Do not delete files manually. Check the theme, SEO plugin, and custom code for AMP hooks before removal; otherwise another component may continue emitting discovery links or handling AMP requests.
4. Purge caches
Clear WordPress page and object caches, then purge any CDN or reverse-proxy cache that stored AMP HTML. Test while logged out in a private browser window so an administrator session or a warm browser cache cannot hide the new behavior.
Disable AMP selectively when some content must keep it
The official AMP for WordPress implementation supports per-post and per-page controls. Use those controls when only particular entries or content types should leave AMP, and keep a written list of the affected URLs for redirect testing.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPer-entry controls
Edit the post or page in WordPress and use the AMP settings panel to disable AMP for that entry, then update it. The exact panel position depends on the editor and plugin version. Confirm the entry’s canonical page no longer advertises an AMP alternative and that its former AMP URL follows the redirect rule you intend to use.
The amp_is_enabled filter
When the plugin is network-activated, the amp_is_enabled filter controls whether AMP functionality runs. A global filter can disable AMP execution:
add_filter( 'amp_is_enabled', '__return_false' );Place custom code in a maintained site-specific plugin or the theme’s appropriate child-layer file, not in a parent theme that updates overwrite. A global return value affects every request handled by the AMP plugin, so use conditional logic if only certain post types, IDs, taxonomies, or environments should be excluded. Test the condition on both included and excluded content before deploying it.
Remove AMP discovery links from canonical pages
Google’s removal guidance is explicit: remove the rel="amphtml" link from the canonical non-AMP page source. This is separate from disabling generation. A stale theme hook, SEO integration, or cached document can keep the link visible even after the AMP plugin is inactive.
- Open a canonical page while logged out.
- View the raw source, not only the rendered DOM, and search for
amphtml. - Confirm that no link element points to an AMP URL. Do not remove the ordinary canonical link that identifies the page itself.
- Clear page and CDN caches, then repeat the source check from more than one representative template.
If rel="amphtml" returns after a theme update or cache purge, locate the code that adds it rather than repeatedly editing generated HTML. The source may be a theme template, a plugin integration, or a custom action.
Redirect former AMP URLs to their canonical pages
For every AMP address whose underlying content remains live, configure an HTTP 301 or 302 redirect to the matching non-AMP URL. Google documents either status for removed AMP pages. A 301 communicates a permanent migration; a 302 is useful when the change is intentionally temporary or being evaluated. Use one redirect hop, preserve the post or page path, and avoid sending unrelated URLs to the home page.
Build the redirect map
- Export AMP URLs from your analytics, server logs, Search Console URL reports, XML sitemaps, and any historical documentation.
- Group addresses by pattern: trailing
/amp/, a query-string form, or another site-specific path. Include uppercase, trailing-slash, and old slug variants only when your logs show they were used. - Match each source to the exact canonical permalink. If a slug changed, map to the current replacement, not merely the old non-AMP path.
- Separate entries whose canonical content was deleted. Those should follow your 404 policy rather than being redirected to an unrelated page.
Do not assume that one rule covers every site. Some installations use a trailing /amp/; others use query parameters or a custom rewrite. Test each observed pattern and preserve meaningful query parameters only when the destination needs them.
Choose where the redirect runs
| Control layer | Best use | Advantages | Watch-outs |
|---|---|---|---|
| WordPress redirect plugin | Editors need a dashboard-managed map or the host does not expose server rules. | Easy to review, import, and change without editing server files. | WordPress must load before the redirect, so very high traffic or unavailable PHP can reduce reliability. |
| Web server or CDN rule | You control Apache, Nginx, a reverse proxy, or edge routing. | Redirects happen before WordPress, reducing application overhead and working even when WordPress is unhealthy. | Syntax and deployment process vary by host; a broad pattern can redirect valid non-AMP URLs accidentally. |
WordPress support guidance recognizes both a redirect plugin and hosting/server configuration as valid implementation points. Pick one authoritative layer for each pattern. Running overlapping rules in several layers makes loops and extra hops harder to diagnose.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Rank #4
Preserve one-hop behavior
Request a former AMP URL and inspect the response chain. The ideal result is a single 301 or 302 directly to the canonical URL, followed by a 200 response. Avoid AMP-to-http-to-https-to-canonical chains; update the rule so the first response targets the final HTTPS permalink.
Verify the migration before broad rollout
Use a representative test set before changing every URL. Include at least one item from each supported content type, each historical AMP pattern, a URL with a changed slug, and a page that should remain AMP-enabled if you chose selective removal.
- Request as a logged-out visitor: use a private browser window or an HTTP client without WordPress cookies.
- Test on mobile and desktop: mobile-redirection settings can produce different responses, so check both user-agent contexts.
- Check status and hops: every retired AMP URL should produce the intended 301 or 302, then the canonical URL should return 200 when the content is live.
- Check the final content: confirm title, main content, structured data, images, and navigation are present on the canonical page.
- Inspect source HTML: verify that
rel="amphtml"is absent from canonical pages that no longer have AMP. - Check for loops and false matches: test ordinary non-AMP URLs, feeds, files, and admin paths so the rule does not capture them.
- Review logs: look for spikes in 404 responses, redirect loops, unexpected query strings, or AMP requests that bypass the intended rule.
Large sites should release the change in batches grouped by URL pattern or content type. Fix a bad rule on a small batch before it affects the entire historical AMP inventory.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What to expect in Google Search and Search Console
Google does not discover removal instantly. AMP pages already crawled may remain in reports, caches, or search results until Googlebot revisits them. During that interval, Search Console can show temporary errors or a mixture of old AMP and new canonical URLs.
Monitor the migration rather than trying to force a fixed deadline:
- Track indexed AMP URL trends and the corresponding canonical pages.
- Inspect representative former AMP URLs with URL Inspection as Google recrawls.
- Watch indexing, page-experience, and crawl-error reports for patterns that identify a faulty redirect or missing canonical page.
- Keep the redirect rules active for as long as visitors and crawlers continue requesting the old addresses.
Do not interpret a short-term report spike as proof that the shutdown failed. First verify the live HTTP response, the final 200 page, and the absence of the discovery link; then allow recrawling to update Google’s records.
Best Value
Troubleshooting common failures
AMP URLs return 404 immediately after plugin deactivation
The plugin stopped serving AMP, but no replacement mapping exists. Restore or add redirects for AMP URLs whose canonical content is live. For deleted content, confirm that a deliberate 404 is the intended outcome.
Google still shows AMP results
Check that canonical pages no longer contain rel="amphtml", that old URLs return the documented 301 or 302, and that caches are purged. Google may still display previously discovered AMP URLs while recrawling; use Search Console to observe the transition rather than changing rules repeatedly.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Some templates still advertise AMP
Compare source HTML across posts, pages, archives, and custom post types. A theme hook or secondary plugin may add the link for only one template. Remove that integration and retest after clearing every cache layer.
Redirects loop or add multiple hops
Review rules in the CDN, web server, WordPress redirect plugin, and WordPress itself. Make one layer authoritative, target the final HTTPS canonical URL, and remove overlapping AMP rules. Re-test with cookies disabled and with both mobile and desktop user agents.
Selective disabling affects the wrong content
Inspect the conditional logic around amp_is_enabled and test an included and excluded item from every relevant post type. A global __return_false filter disables AMP for all requests, so replace it with narrowly scoped conditions when coexistence is required.
Quick Recap
Final operational checklist
- AMP mode, supported content types, mobile redirection, and URL patterns are documented.
- A backup or rollback point exists before deactivation or uninstall.
- The plugin or integration is disabled at the correct site or network level.
- Canonical pages no longer contain
rel="amphtml". - Each live former AMP URL maps to its matching canonical page with one 301 or 302.
- Deleted content follows a deliberate 404 policy rather than an irrelevant redirect.
- Caches and CDN content are purged.
- Logged-out, mobile, desktop, and representative-template tests pass.
- Search Console and server logs are monitored while Google recrawls.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
