What does 'Page with redirect' mean?
It's one of the reasons in Search Console's Page indexing report, listed under Why pages aren't indexed. Google's help page defines it in four short sentences: the URL isn't canonical, it redirects to another page, and so it won't be indexed; the target might or might not be indexed, depending on what Google thinks of it; and a canonical URL with a redirect can be indexed. Nothing in that definition says something's broken. It says Google followed the redirect and judges the page it lands on separately. If you're worried the list hides a page Google should be indexing, the answer sits in a handful of rows, and reading them is where my Search Console indexing help starts.
The report puts these under Not indexed, and that label is what worries people. The same help page says you shouldn't expect every URL on a site to be indexed, only the canonical pages, and it names duplicates, pages blocked on purpose and redirects among the ones that belong outside. Duplicates get their own reason, the Duplicate without user-selected canonical status. A site that's been live for a few years, moved to HTTPS or changed a permalink or two can easily carry hundreds of them, so a big count on its own tells me very little.
What I care about is the kind of redirect. Google's redirect documentation says a permanent redirect, a 301 or a 308, is a signal that the target should be canonical, while a temporary one, a 302, 303 or 307, isn't. So for every pattern in the list I'm really asking two things. Should this old address be out of the index? And does it give Google a clear, permanent answer about where the page lives now?
Which URLs are normal to see under Page with redirect?
Most of the list is WordPress and the server doing their jobs. WordPress has a core function, redirect_canonical, that sends incoming links to the proper URL based on the site's address. It turns ?p=123 links into pretty permalinks, settles trailing slashes and picks between www and non-www. Every one of those redirects can land under Page with redirect on a WordPress site, and each one's correct.
| URL pattern | Why it redirects | What I do |
|---|---|---|
| http:// versions of every page | The server forces HTTPS | Nothing, as long as it's one 301 straight to the https page |
| The www or non-www twin | The site has picked one host | Nothing, if the canonical, the sitemap and the links all use the chosen host |
| A missing or extra trailing slash | WordPress matches the slash to the permalink setting | Nothing |
| ?p=123 and similar query links | WordPress sends them on to the permalink | Nothing |
| Old slugs after a rename or a site move | A redirect rule sends them to the new address | Check the destination is the closest live page, not the homepage |
Old URLs from a move are the healthiest rows of all. When I watch a migration settle, old addresses moving into Page with redirect is the sign Google has found the 301s.
The version that should worry you is the opposite one: old URLs that don't redirect at all. On one WooCommerce store, a redesign without a redirect map dropped daily clicks from 162 to 49. That kind of damage shows up under Not found (404), not here, which is one more reason a long Page with redirect list is usually good news.
How I read the list, step by step
I work by pattern rather than by URL, which keeps this short even when the list runs into the thousands.
- Step 01
Open the reason, not the chart
In the Page indexing report I click Page with redirect and read the example URLs. Google caps that list at 1,000 examples, so on a big site I'm reading a sample, and that's fine for spotting patterns.
- Step 02
Switch the sitemap filter to submitted pages
The filter defaults to All known pages. I switch it to All submitted pages. Anything still listed is a URL my own sitemap is sending Google to, and that's the first real fix on the list.
- Step 03
Group what's left by pattern
http, the other host, trailing slashes, query strings, old slugs. A group with a clear, correct explanation gets a tick and I move on. Anything I can't explain goes on a short list.
- Step 04
Follow a few redirects from each odd group
I request an example or two myself and follow every hop. What I want to see is one hop, a 301 or a 308, ending on a page that answers 200 and names itself as canonical.
- Step 05
Check the destination is indexed
A redirect only helps if the page it lands on is in the index, so I inspect the destination as well. If it's excluded for its own reason, that's the problem to chase, and a destination stuck as discovered or crawled but not indexed has a diagnosis of its own.
Don't remove redirects to shrink the count. Take a redirect away and the old URL usually just comes back as Not found (404), and every outside link and bookmark still using it stops reaching the page.
Rather have me do this? One person, whole job.
Book a call on UpworkWhen does Page with redirect point to a real problem?
Here's where I stop reassuring and start fixing. These are the rows that tell me something's actually wrong.
- i.
A page I want in search is listed
If a live service page, product or post shows up here, it's redirecting when it shouldn't be. On WordPress that's usually a leftover redirect plugin rule, a slug that was changed and changed back, or a rule written for one URL that caught others. I fix the rule so the page answers 200.
- ii.
My sitemap submits redirecting URLs
Google's sitemap guidance is to list the URLs you want in search results, which are the canonical ones. A sitemap carrying http addresses, the wrong host or old slugs keeps sending Google to pages it won't index.
- iii.
Internal links and canonicals name old addresses
Menus, content links and canonical tags that still name a redirecting URL make every visit and every crawl take the extra hop. A canonical pointing at a URL that redirects elsewhere also hands Google two answers that don't agree.
- iv.
The redirect is temporary when it shouldn't be
A 302 that's been in place for months was never meant to be temporary. Google doesn't treat a temporary redirect as a canonical signal, so I change it to a 301 when the move is permanent.
- v.
The destination is the wrong page
An old product sent to the homepage, or a post sent to an unrelated category, throws away the match between the two. I point each one at the closest live page, and let it 404 if there isn't one.
Loops and chains that run too long aren't this status. Google reports them under a separate reason, Redirect error. A shorter chain can still sit under Page with redirect, so if my header check turns up two or three hops, I collapse them to one while I'm in there.
How do I stop WordPress sitemaps and internal links pointing at redirects?
To fix Page with redirect, I fix the source, not the symptom. The redirect stays, because outside links and old bookmarks still use the old address, and Google's advice for moves is to keep redirects for as long as possible, generally at least a year. What changes is everything I control that still names the old URL. Google says as much itself: redirects are slow for users, so update your own links.
- i.
Fix the sitemap first
On WordPress the sitemap is written by core or by the SEO plugin, so a redirecting URL in it usually means the site's address settings are wrong, or the plugin lists a post type it shouldn't. I check WordPress Address and Site Address under Settings, General, then confirm every sitemap URL answers 200 with no hop. When it runs deeper, a sitemap that keeps listing the wrong addresses is a job of its own.
- ii.
Replace internal links where they live
Links typed into post content are stored exactly as written, so an old http or old-slug link stays until someone replaces it. I crawl the site, list every internal link that gets a 3xx response, and fix each one in the menu, widget, template or post. After a domain or protocol change, a database search and replace does most of it, with a backup taken first.
- iii.
Correct canonicals at the source
Canonical tags usually follow the site address on their own. When one doesn't, it's a hardcoded value in the theme or a plugin setting, and I fix it there rather than adding another redirect on top.
- iv.
Resubmit and watch the submitted pages filter
The old URLs will keep appearing under Page with redirect for as long as Google checks them, and that's fine. The submitted pages view is the one that should empty out.
- v.
Should I click Validate fix?
Not for the whole status. Google's help says validation stops when it finds a single remaining instance of the issue, and old URLs are meant to keep redirecting. After cleaning the sitemap, filter the report to that sitemap first, since validation then covers only the URLs in it. Google also updates the count on every recrawl, validated or not.
If the list has grown past what you can explain and you'd rather one person sorted the real problems from the normal ones, that's part of the crawlability and indexing work I do, remotely, inside your own Search Console.
Book a call on Upwork
