If your WordPress blog ever ran an AMP plugin, every post had a second address. Usually /post-name/amp/ or /post-name/?amp=1. Those URLs are still in Google's index and in old shares, and once you move to a host without AMP the /amp/ ones start returning 404.
Google's steps for removing AMP pages while keeping the canonical page are short: take the rel="amphtml" link off the canonical page, and answer each AMP URL with a 301 or 302 to that canonical page.
The hard part is knowing which AMP URLs exist. I read the source of the two main AMP plugins to find out, and wrote a small script to list them. Everything below was checked on October 18, 2026.
Which format your site used
It depends on the plugin and one setting. I downloaded the current releases from WordPress.org and read the code that builds each URL. Examples assume /%postname%/ permalinks and AMP enabled for that content type.
| Plugin and setting | Post | Page |
|---|---|---|
| AMP 2.5.5, Query parameter (default for new installs) | /post-name/?amp=1 |
/about/?amp=1 |
| AMP 2.5.5, Path suffix | /post-name/amp/ |
/about/amp/ |
| AMP 2.5.5, Legacy transitional | /post-name/?amp |
/about/?amp |
| AMP 2.5.5, Legacy reader | /post-name/amp/ |
/about/?amp |
| AMP for WP 1.1.19, default with pretty permalinks | /post-name/amp/ |
/about/amp/ |
| AMP for WP 1.1.19, "Change End Point to ?amp" on | /post-name/?amp |
/about/?amp |
The official AMP plugin lists 300,000+ active installs and was last updated in April 2025. AMP for WP lists 70,000+ and was updated on October 13, 2026.
Legacy reader is the one that surprised me. It uses /amp/ for posts but falls back to ?amp for pages, attachments, and any URL that already has a query string... so one site can carry both shapes. If you switched the setting at some point, both shapes may also be indexed from different years.
Fastest way to tell: open any post's HTML source on the old site and search for amphtml. The link it prints is the exact AMP URL for that page.
List every AMP URL while WordPress is still up
The amphtml link is the best inventory you'll get, and it only exists while WordPress is serving pages. This reads one sitemap, fetches each URL, and writes the AMP address next to the canonical one:
#!/usr/bin/env bash
# Usage: ./amp-map.sh https://old-blog.example.com/wp-sitemap-posts-post-1.xml > amp-map.csv
curl -s "$1" | grep -o '<loc>[^<]*' | sed 's/<loc>//' | while read -r page; do
amp=$(curl -s "$page" | grep -o '<link[^>]*rel="amphtml"[^>]*>' \
| sed -E 's/.*href="([^"]+)".*/\1/' | head -1)
[ -n "$amp" ] && echo "$amp,$page"
done
I ran it against five posts on ampforwp.com, the AMP for WP plugin's own site, and every row came back the same shape, e.g. https://ampforwp.com/the-change/amp/,https://ampforwp.com/the-change/.
Run it once per post sitemap. WordPress core lists them at /wp-sitemap.xml, Yoast at /sitemap_index.xml. If AMP was on for pages, categories or the home page, run those sitemaps too.
It only sees pages that print the link today. For posts where AMP was turned off earlier but the AMP URL is still indexed, the AMP status report in Search Console lists the AMP URLs Google knows about.
Optional: let the plugin redirect before you move
If WordPress stays up for a few weeks before the DNS change, the official AMP plugin can do Google's two steps for you. In its code, when a URL is requested with the AMP endpoint but AMP isn't available for that content, it redirects to the non-AMP URL and prints an HTML comment in place of the amphtml link. So you leave the plugin active, turn AMP off for your content types under Supported Templates, and the old AMP URLs start redirecting while the posts are still on WordPress.
Two things to know when you test it:
- It sends a 302 to anyone with
manage_optionsand a 301 to everyone else. Test logged out, or with curl. - A path-suffix URL can take two hops. With AMP off for posts I saw
/post-name/amp/301 to/post-name/?amp=1, which then 301'd to the post. Crawlers follow both, but the redirects you add on the new host should go straight to the final URL.
I didn't check whether AMP for WP does the same.
Redirect the /amp/ paths on the new host
After the cutover, WordPress isn't answering anymore, so the redirects have to live wherever the posts went. The two shapes behave very differently there.
The query forms (?amp=1, ?amp) often just load the normal post, because many hosts ignore query parameters they don't use. That's what I got testing on JustBlogged, the blog host I run: 200, the normal post, canonical pointing at the clean URL. Google asks for a redirect, so this isn't an exact match, but I'm fine with it. The page isn't AMP, has no amphtml link, and its canonical names the clean URL, which is the same signal Google uses to consolidate duplicate URLs like tracking-parameter variants.
The path forms (/post-name/amp/, /post-name/amp) are the real problem. They 404, and a 404 drops whatever links and indexing those URLs had. Each one needs a 301.
Point the redirect at the post's new path, not its old WordPress URL. If the old permalink was /2023/05/post-name/ and the post now lives at /post-name, the redirect is /2023/05/post-name/amp/ to /post-name. One hop instead of two.
Google warns against one shortcut: emptying the AMP file instead of redirecting it. An empty document is invalid AMP, and Google keeps serving the oldest valid version it has.
Check every AMP URL after DNS moves
cut -d, -f1 amp-map.csv | while read -r u; do
curl -s -o /dev/null -w "%{http_code} $u -> %{redirect_url}\n" "$u"
done
Every path-form row should be a 301 to the new post URL, and that URL should be 200. A 404 is a missing or mistyped redirect. A redirect to the old WordPress URL is a chain you can shorten.
After that, the AMP status report's count of indexed AMP pages should drop as Google recrawls them, and the redirected AMP URLs should show up under "Page with redirect" in the Page indexing report
Top comments (0)