Page with redirect

Where you see it: Search Console → Indexing → Pages → Why pages aren’t indexed

This URL redirects somewhere else, so Google indexed nothing at this address and judges the destination on its own instead. That is what a redirect is for: old slugs, http versions and merged posts are meant to end up here. Most URLs under this status are fine as they are.

Usually leave it; tidy your own links that still use the old address.

Look closer only if the listed URL is one you want in search, if it lands on the wrong page, or if your site still points at it from internal links, the sitemap or a canonical tag. Those references don’t block the destination, but each adds a hop and mixes your signals.

Check a URL now Can RankHive fix it? Nothing to fix

Check the URL Search Console listed

Paste the old address Search Console lists, not the page you expect it to reach. The checker follows every hop and reports where the chain ends, how many redirects it took, and whether any hop is temporary, loops or ends on an error.

Redirect report

Enter a URL to see every hop it passes through, with the status code at each step.

Reading the result

Redirect chain looks healthy, one Permanent hop, Final status 200: working as designed. Update only your own links to it.
Protocol and hostname changed in two separate hops: an http→https rule and a www rule are stacked. Merge them at your host or CDN.
A Temporary hop: a 302 or 307 lets Google keep the old URL as canonical. Use a 301 for a permanent move.
Final URL is your homepage or an unrelated page: Google may count that as a soft 404. Aim the rule at the closest match.
Chain complete reads No, the chain loops, or No, hop limit reached: that belongs under Redirect error. Find the two rules undoing each other.

The same tool with its full guide: Redirect Checker

Why it happens on WordPress

WordPress sends more redirects than most owners realise, and each can put an address on this list. Nearly all are correct; what matters is whether your own site still points at the old address.

Core’s own housekeeping redirects

WordPress 301s requests to the hostname in Settings → General, adds or strips the trailing slash to match your permalink structure, sends ?p=123 links to the pretty permalink, and forwards an edited post slug to the new one. Every original address can show up here, and all are fine.

Old http:// links saved inside posts

Moving to HTTPS changed your Site Address, not the text already saved in old posts. Links, image URLs and buttons written as http://example.com/… each cost a hop, and Google keeps finding them. Links missing www on a www site do the same.

A redirected post that is still published

You merged two posts and added a redirect, but left the old post published. Your SEO plugin keeps listing it in the XML sitemap, the redirect sends Google away, and the address comes back here every time the sitemap is read.

A canonical field naming an old address

A URL typed into a post’s canonical field in Yoast SEO, Rank Math or SEOPress before the target moved still names the old address. The canonical points one way and the redirect another, which leaves Google to choose.

Attachment pages sent to the file

Since WordPress 6.4, new sites redirect attachment pages to the media file, and Yoast SEO and Rank Math can do the same on older sites. Old links to /?attachment_id=123 then land here, as intended.

Redirects nobody chose on purpose

When a URL would 404, core tries to guess the post you meant, by default with a loose match on the start of the slug, and 301s there. Redirect plugins can add rules by themselves when a slug changes. If the destination is the wrong page, that is a real problem.

How to fix it

Confirm the destination is right first. Then remove the old address from everything your site controls.

1. Check where a few examples land
Run a handful of listed URLs through the redirect checker. One permanent hop to the page you meant is healthy. To see which layer sent a hop, run curl -sI on the URL and read X-Redirect-By: core sends WordPress, many redirect plugins send their own name, and host and CDN rules usually send nothing.
2. Repoint internal links at the final address
Search Posts → All Posts for the old slug, or run the internal link checker on key pages, and replace each link with the destination. After an HTTPS move, a database search-and-replace from http:// to https:// fixes every post at once; take a backup first.
Internal link checker
3. Update links that live outside posts
Menus, widgets and buttons don’t change when you edit posts. Check Appearance → Menus or the Navigation block in the Site Editor, footer widgets, header buttons built in your page builder, and links stored in theme options.
4. Keep only final URLs in your sitemap
Google’s sitemap guidance is to list canonical URLs only. Paste your sitemap into the sitemap checker, or open /sitemap_index.xml (Yoast SEO, Rank Math) or /wp-sitemap.xml (core), and test entries that look old. A redirecting entry usually means a published post sits behind a redirect rule: trash it or set it to draft, and the redirect rule keeps working.
Sitemap checker
5. Correct canonicals that name an old address
Open the post, find the canonical field in your SEO plugin’s advanced settings, and clear it or enter the final URL. Cleared, the plugin falls back to the page’s own address.
Canonical checker
6. Shorten chains and swap temporary hops
Edit the first rule of a chain so it points straight at the final page. Google follows up to 10 hops but recommends redirecting to the destination directly. Change 302s to 301s for moves you won’t undo.

When the listed URL is the one you want in Google

Sometimes the listed address is the page you meant to rank, and an unintended redirect is sending Google away. Look for a leftover rule in your redirect plugin, a core slug guess, or a language or membership plugin that redirects visitors it doesn’t recognise.

Remove the rule in the layer that sends it, confirm the URL now answers 200, and request indexing in URL Inspection.

Check the fix in Search Console

A working redirect isn’t an error, so there is usually nothing to validate. Check the cleanup from Google’s side instead.

Inspect a destination page in URL Inspection. It should be indexed, with the Google-selected canonical pointing at itself, not at the old address.
The live test on an old address silently follows the redirect and reports on the final page; that doesn’t make the old URL indexable.
Switch the Page indexing report from All known pages to All submitted pages. Any sitemap URL still listed under Page with redirect is worth chasing.

Can RankHive fix this?

Usually there is nothing to fix: this status means a redirect worked as intended. Where your posts and pages still point at a redirecting address, RankHive can repoint those links, or a canonical field, to the final URL.

What it writes, once you approve

Internal links in post and page content repointed from the old address to the destination.
A post or page canonical corrected in the Yoast SEO, Rank Math or SEOPress field.

What it can’t do here

Edit your XML sitemap, or unpublish, trash or noindex a post a redirect has replaced.
Change links in menus, widgets, theme templates or WooCommerce products.
Merge http→https and www rules at your host, CDN or .htaccess, or edit other plugins’ redirect rules.
Write a canonical through All in One SEO or on a site with no SEO plugin.

Every change is drafted next to the current value and waits for your approval. Each one written is logged in the Change Log, with Revert.

Check the rest of your site while you’re here

The free site check reads your public pages for titles, meta descriptions, headings, canonical tags and schema, and shows what needs fixing. If you sign up, RankHive reads your Google Search Console data every week, drafts the fixes, and writes the ones you approve to WordPress. Nothing changes on your site until you say yes.

Related issues

Common questions

Is “Page with redirect” an error?

No. Google is confirming that the URL redirects and that nothing was indexed at that address. The destination is judged separately and may or may not be indexed.

Should I remove redirects to clear this list?

No. Deleting a working redirect turns the old address into a 404 for every bookmark and outside link that still uses it.

Why is my homepage listed under Page with redirect?

Usually it is a variant, such as http:// or the version without www, redirecting to your real homepage. Inspect your actual homepage address; if that is indexed, all is well.

Why does a URL from my sitemap have a redirect?

Because the sitemap lists an address that no longer answers 200. On WordPress that is usually a published post with a redirect rule on it, or an old static sitemap.xml file still submitted.

Do redirects lose rankings?

Not a 301 to the right page: Google treats it as a strong signal that the destination replaces the old URL. A redirect to an unrelated page is what costs you.

Sources

Checked against these pages on 17 October 2026.