Short answer: "Page with redirect" is a status, not an error. It means Google found a URL that redirects somewhere else, so it does not index that URL and indexes the destination instead. After a migration, a pile of old URLs landing here is expected. It only becomes a problem when the destination pages are not indexable, when the redirects are chains or loops, or when your sitemap still lists the old URLs.
What does "Page with redirect" actually mean?
In the Page indexing report, Search Console groups URLs under "Why pages aren't indexed". A URL with this reason answered with a redirect (301, 302, 307 or 308) when Google requested it. Google does not index a redirecting URL. It follows the redirect and considers the target.
So after you move a site from old.example to new.example, or change permalinks, every old URL that Google still knows about will show up here until Google drops it. That can be hundreds of rows. It does not mean the pages have been lost.
How do I tell a harmless one from a real problem?
Pick three or four URLs from the report and check each with a command. This is the quickest test:
curl -sIL https://old.example/services/ | grep -iE "^(HTTP|location|x-robots-tag)"A healthy result looks like this:
HTTP/2 301
location: https://new.example/services/
HTTP/2 200One hop, a 301, then a 200 with no x-robots-tag: noindex. That is fine. Compare it with what to look out for:
| What you see | Meaning | Action |
|---|---|---|
| 301 then 200, one hop | Normal migration | Nothing to fix |
| Two or more hops | Redirect chain | Point the old URL straight at the final URL |
| 302 on a permanent move | Wrong status code | Change to 301 or 308 |
| Redirect ends on the home page | Lazy catch-all | Redirect to the matching page instead |
| Final URL has noindex or a robots.txt block | Deindexing risk | Remove the block on the new site |
| Redirect loop or 404 at the end | Broken redirect | Fix the rule |
The last two rows are the dangerous ones, because the report looks the same as in the harmless case. Staging settings often come across in a migration, so check that the live destination pages are indexable with the noindex checker. A common case: a site goes live with the WordPress "Discourage search engines from indexing this site" box still ticked, or with a staging robots.txt that disallows everything. Google then follows the redirects and lands on pages it is told to ignore.
What are the fix steps on a WordPress client site?
- Confirm the redirects are 301s and one hop. Google explains the options in its redirects documentation. Permanent moves should use a permanent status code.
- Check the new pages are indexable. In WordPress go to Settings, Reading and make sure "Discourage search engines" is off. Check your SEO plugin's per-page settings, then the live
robots.txtand response headers. - Update the sitemap. It should list only the new, final URLs that return 200. Old URLs in a sitemap keep "Page with redirect" rows alive. Google's guidance is in build and submit a sitemap.
- Update internal links and canonicals. Menus, buttons and in-content links that still use old URLs force an extra redirect on every click. A search-and-replace on the database fixes most of it. WordPress covers the URL change process in Moving WordPress.
- If the domain changed, follow the site move steps. Google lists them in site moves with URL changes. Keep the old domain's redirects in place for at least a year.
- If the redirects live at Cloudflare, check them against the origin. A bulk redirect list can silently shadow a page rule or a server rule. See Cloudflare Bulk Redirects.
- In Search Console, use Validate fix only for reasons that are real problems. There is nothing to validate for a healthy redirect.
What do I tell the client?
Keep it short and honest. Something like: "Search Console lists the old addresses as 'Page with redirect'. That is Google telling us it found the old URL and followed it to the new one. It is expected after a move and will shrink over the next few weeks. We checked a sample, the redirects are single 301s, and the new pages are open to indexing."
If you have not checked the last part, do not say it. The real conversation is about the destination pages. Give the client the sample curl results and the date you checked, so you are not asking them to take your word for it.
One more thing to set expectations on: the report does not clear overnight. Google recrawls old URLs on its own schedule, so rows can stay for weeks or months. A falling count is a good sign. A rising count after the migration has settled usually means something is still linking to old URLs.
How does quietwatch catch this daily?
quietwatch checks each client site every day for the things that quietly remove pages from Google: noindex tags, robots.txt blocks, X-Robots-Tag headers, Cloudflare bot settings, broken sitemaps and expired certificates, along with the response status of key URLs (see what quietwatch checks every day). That covers the real risk behind this report, a migrated site whose new pages are blocked. The free noindex checker above is the place to start.