Skip to content

"Page with redirect" in Search Console: what it means on a WordPress site, and which ones to fix

"Page with redirect" lists addresses that answered Google with a redirect. The address is not indexed. The page it leads to can be. On a WordPress site the list is usually old and alternative addresses that WordPress forwards by itself, and they need nothing. A few can be wrong.

By
WP Ministry
Published
Tested on
WordPress 7.1.3, PHP 8.3.35

In short

  • The status is a list of addresses that redirect. Google does not index such an address. It can index the page the address leads to.
  • An address in the list is correct whenever the redirect is one you meant. It is the record that an old or alternative address leads somewhere, and WordPress makes several such redirects by itself.
  • WordPress redirects many forms of an address by itself. A missing final slash, a ?p= address, a renamed post's old slug and www against the bare name are four.
  • Read the list by where each address ends. One loop prints the first answer, the number of redirects and the final address.
  • Worth fixing are a redirect listed in a sitemap, your own links to an old address, a chain, a 302 on a permanent move, and a page that should not redirect at all.
  • Validation is for a status you have removed. An address that is meant to redirect goes on redirecting.

"Page with redirect" in Search Console's Page indexing report is a list of addresses that answered Google with a redirect. Google does not index an address that redirects. It can index the page the address leads to. An address in this list is correct, and needs nothing done, whenever the redirect is one you meant: it is the record that an old or alternative address leads somewhere. WordPress makes several such redirects by itself, and the table below shows them.

A WordPress site makes many such redirects by itself, which is why the list can be long on a healthy site. This page shows which redirects those are, then how to find the few that are wrong.

What Google says the status means

Google's help for the report files this status under "Not indexed", a group it introduces as pages that are not indexed "but not necessarily because of an error". Of this status it says the listed address is "a non-canonical URL that redirects to another page" and will not be indexed. Whether the page it leads to is indexed depends on what Google thinks of that page.

Three more things from the same help page:

  • The list is a sample. It is an example list, limited to 1,000 rows, and does not necessarily show every address with the status.
  • "Website" as the Source is not a verdict. The help says the Source shows whether a reason is probably something you can fix. It does not say that you should.
  • "Redirect error" is a different status. The help gives it four causes: a redirect chain that was too long, a redirect loop, a redirect address that grew past the maximum length, and a bad or empty address in the chain. There, Google could not follow the redirect to an end. Under "Page with redirect" it could. A loop that browsers report too is covered in how to fix ERR_TOO_MANY_REDIRECTS.

The redirects WordPress makes by itself

This is what a WordPress site answered to each form of an address. It was on "Post name" permalinks with the bare domain in its settings, and one post's slug had been changed from summer-sale to june-offer. The last column is the X-Redirect-By header of the answer, which names what sent it.

Asked forAnswerSent by
/hello-world, a post without its final slash301 to /hello-world/WordPress
/?p=123, a post by its number301 to the post's addressWordPress
/?page_id=2, /?cat=1, /?author=1301 to the page, the category archive, the author archiveWordPress
/summer-sale/, the post's slug before it was changed301 to /june-offer/WordPress
www.example.com/hello-world301 to example.com/hello-world/, host and slash in one hopWordPress
/feed, /feed/rss2/, /feed/rss/, /rss/, /?feed=rss2301 to /feed/WordPress
/index.php/hello-world/301 to /hello-world/WordPress
/hello-world/2/, page 2 of a post that has only one page301 to /hello-world/WordPress
/page/1/301 to /WordPress
/sitemap.xml, with no such file on the server301 to /wp-sitemap.xmlWordPress
/admin, /dashboard302 to /wp-admin/WordPress
/login302 to /wp-login.phpWordPress
/wp-admin/, not logged in302 to the login pageWordPress
/wp-admin301 to /wp-admin/No header. The web server sent it

Not every other form is forwarded. /feed/, /feed/atom/ and /comments/feed/ answered 200, because they are feeds. /Hello-World/ in capitals answered 200 as typed. /page/2/, on a site with one page of posts, answered 404.

Google learns these addresses from links, and WordPress supplies one kind itself. A post carries its ?p= address in its <head>, as a shortlink, and sends it again in a Link header. www or non-www covers the host, and shows that WordPress does not send a page from http to https: where that redirect exists, the server or the host makes it. Changing permalinks covers which old addresses WordPress forwards after a change of structure.

To see what one address answers, follow it to its end:

bash
curl -s -o /dev/null -L -D - https://example.com/summer-sale/ | grep -i -E "^(HTTP|location|x-redirect-by)"
text
HTTP/1.1 301 Moved Permanently
X-Redirect-By: WordPress
Location: https://example.com/june-offer/
HTTP/1.1 200 OK

Each hop prints its status, what sent it and where it leads. The last line is the page that answers. Without a terminal, the redirect checker shows each hop, its status code and where it leads.

If the list is longer than you can read by hand, WP Ministry's SEO audit looks at what each address answers with, redirects that chain or loop included.

What causes it

How to fix it

Read the whole list, and leave what is right

  • Takes care
  • No risk
  • About 15 minutes
  • Steps tested on WordPress 7.1.3

  1. Step 1: Export the list

    Open the status in the report and export its table of addresses, or copy them out. Put the addresses in a file named redirects.txt, one to a line.

  2. Step 2: Ask every address where it ends

    bash
    while read -r url; do
  first=$(curl -s -o /dev/null -w '%{http_code}' "$url")
  last=$(curl -s -o /dev/null -L -w '%{num_redirects}  %{http_code}  %{url_effective}' "$url")
  printf '%s  %s  %s\n' "$url" "$first" "$last"
done < redirects.txt

  3. Step 3: Read each line

    After the address come its first answer, the number of redirects curl followed, the last answer, and the address it ended at.

    text
    https://example.com/?p=123  301  1  200  https://example.com/june-offer/
https://example.com/hello-world  301  1  200  https://example.com/hello-world/
https://example.com/sale/  301  2  200  https://example.com/june-offer/
https://example.com/promo/  302  1  200  https://example.com/june-offer/
https://example.com/services/web-design/  301  1  200  https://example.com/
The line showsIt meansWhat to do
301 or 308, one redirect, 200, at the page that replaced the addressThe redirect is rightNothing
Two redirects or moreA chainShorten it, below
302 or 307 first, on a move that is for goodA temporary redirectMake it permanent, below
It ends at the home page, or at a page about something elseThe wrong destinationSee the next paragraph
404 lastThe redirect leads to a page that is gonePoint it at a page that exists, or remove it
The address is one you want in GoogleIt should not redirectFind what sent it, below

One form of the wrong destination is a rule that sends a whole section to the home page. Google's guide to moving a site says many old addresses sent to one irrelevant page "might be treated as a soft 404 error". WordPress can also choose the destination: asked for /hello, which no page has, this site answered 301 to /hello-world/, a guess from the start of a slug. Traffic dropped after a redesign runs both cases and has the cure, and the redirect map builder turns a list of old and new addresses into rules.

Take redirecting addresses out of the sitemap

  • Easy
  • Low risk
  • About 10 minutes
  • Steps tested on WordPress 7.1.3

Google's sitemap documentation says to include the addresses you want to see in its search results. An address that redirects is not one of them.

WordPress's own sitemap needs no attention. After the slug changed, the post's file listed the new address and not the old one:

bash
curl -s https://example.com/wp-sitemap-posts-post-1.xml | grep -o '<loc>[^<]*</loc>'

A sitemap file written by hand or by a tool outside WordPress is not updated when a slug changes. This asks for every address in one sitemap file and prints what each answers:

bash
curl -s https://example.com/sitemap.xml | grep -o '<loc>[^<]*' | cut -c6- | while read -r url; do
  printf '%s  %s\n' "$(curl -s -o /dev/null -w '%{http_code}' "$url")" "$url"
done

Every line should begin 200. Where a line begins 301, replace that address with the one it leads to, in the file or in the settings of whatever made it. Give the command the address of a file that lists pages. An index, such as /wp-sitemap.xml, lists other sitemap files. The sitemap WordPress makes explains which sitemap a site serves.

To undo it: Put your copy of the old sitemap file back.

Shorten a chain to one redirect

  • Takes care
  • Back up first
  • About 15 minutes
  • Steps tested on WordPress 7.1.3

Here .htaccess held Redirect 301 "/sale/" "/summer-sale/", written before the post was renamed. Asked for /sale/, the site answered twice:

text
HTTP/1.1 301 Moved Permanently
Location: https://example.com/summer-sale/
HTTP/1.1 301 Moved Permanently
X-Redirect-By: WordPress
Location: https://example.com/june-offer/
HTTP/1.1 200 OK

The first hop has no X-Redirect-By line, so the server sent it. The second is WordPress forwarding the old slug.

Google's page on status codes says its crawlers "follow up to 10 redirect hops" by default. Its guide to moving a site advises redirecting to the final destination directly.

Change the rule's target to the address the chain ends at. The line belongs above # BEGIN WordPress.

.htaccess
Redirect 301 "/sale/" "/june-offer/"

Asked again, /sale/ answers once and the next line is 200. How to set up redirects in WordPress covers rules kept in a plugin or in nginx.

To undo it: Put your copy of the old .htaccess back.

Change a 302 to a 301 where the move is for good

  • Takes care
  • Back up first
  • About 10 minutes
  • Steps tested on WordPress 7.1.3

Google's page on redirects says a permanent redirect is used as a signal that the target should be canonical, and that the target is shown in results. For a temporary one it says the redirect is not used as that signal and the source page is shown. So a 302 is right for a page that will come back, and wrong for a move that is for good.

Two ways to get a 302 without choosing one:

  • A Redirect line with no status. Apache's documentation says that with no status given the redirect is temporary, a 302. Redirect "/promo/" "/june-offer/" answered HTTP/1.1 302 Found.
  • wp_redirect() with no status. WordPress's code reference gives 302 as its default. A snippet that calls it with an address and nothing else answered 302, and with 301 as the second value it answered 301.

The first line the hop command prints shows which one an address sends. In .htaccess, write the status into the rule:

.htaccess
Redirect 301 "/promo/" "/june-offer/"

WordPress's own 302s in the table, from /admin and /login, lead to pages that are not for search results. Leave them.

To undo it: Put your copy of the old .htaccess back.

Find what redirects a page that should load

  • Takes care
  • Low risk
  • About 20 minutes
  • Steps tested on WordPress 7.1.3

Run the hop command on the page that should load, and read the first hop.

The first hop showsSent byLook in
X-Redirect-By with another nameThe plugin that gave that name. WordPress lets a plugin name itself thereThat plugin's list of redirects
X-Redirect-By: WordPress, and Location is wp-login.php with redirect_to=Something that requires a login for the pageA membership or privacy plugin's settings
X-Redirect-By: WordPress, any other LocationWordPress, or code that did not name itselfThe table above, then your plugins. Finding a plugin conflict has the method
No X-Redirect-By lineSomething other than WordPress's redirect function.htaccess above # BEGIN WordPress first, then the host's and the CDN's redirect settings

Each row was produced on a WordPress site: by a plugin that named itself, by code that called WordPress's login check, and by a Redirect line in .htaccess. With each one removed, the page answered 200 at once.

A site still showing a holding page is a different case. See coming soon pages and SEO.

To undo it: Put the rule back, or switch the plugin on again.

Let Google see the change

  • Easy
  • No risk
  • About 10 minutes

A corrected sitemap, link or chain needs no request. Google's help says it updates the count whenever it crawls a page with a known issue, whether or not validation was requested.

Validate fix asks Google to confirm that a reason is gone from the addresses it listed. The help says to fix all of them first, because validation stops at "a single remaining instance", and that it typically takes up to about two weeks and sometimes much longer. An address that is meant to redirect is still an instance. On a list that is mostly correct redirects there is nothing to validate.

URL Inspection is for one address. For a page that redirected by mistake and now loads, inspect it and request indexing. The help says a request does not guarantee that the page will appear in the index. Two notes from the same help: the indexed result is for the address you typed, not for the redirect's target, and the live test follows a redirect without saying that it did.

When to get help

If the list holds pages that should be live, or it grew after a redesign and the old addresses do not lead where they should, the site needs a map of every old address, what it answers and where it ought to lead. A redirect added outside WordPress, at the host or at a CDN, takes access to those accounts to find.

Common questions

Is "Page with redirect" bad for my site?

Not by itself. Google's help lists it among reasons that are not necessarily errors. The address that redirects is left out of the index, which is what a redirect is for. The pages to care about are the ones the redirects lead to.

Should I delete old redirects to bring the number down?

No. Google's guide to moving a site says to keep redirects "for as long as possible, generally at least 1 year". An old address with its redirect removed answers 404 and moves to another reason in the same report.

Why does an address I redirected still show in Google?

Google's page on redirects says it keeps track of both addresses, and that the old one may appear in results as an alternate name when a search suggests the searcher trusts it more. If the redirect is a 302, the same page says the source is the one shown.

The page my redirect leads to is not indexed either. Why?

That is a separate question about that page. Inspect the target's own address in Search Console and read the reason given for it. WordPress site not showing up on Google has the checks in order.

More on this subject

Would you rather we fixed it?

SEO audit is $249. A written audit, each finding with its source, and up to 2 hours of fixes done and tested again. It starts with a free diagnosis.

Get a free diagnosis