"Page with redirect" in Search Console: usually nothing is broken. Here's how to be sure.

You were in Search Console’s page report, in a table headed Why pages aren’t indexed — a heading that already assumes something needs explaining. One of the rows read Page with redirect. You clicked it, the way the layout invites you to, and landed on a page that repeats the reason’s name and puts one sentence directly beneath it:

The line under the reason name, as Search Console shows it

These pages aren’t indexed or served on Google

Read cold, that is an accusation in two parts: these pages aren’t in Google, and Google won’t show them to anyone. And it hangs under a word you may never have touched — you didn’t set up a “redirect”; you may not be sure what one is. (If what sent you into the report in the first place was Google’s email about new reasons, that message has its own article.)

Two things take most of the sting out. First, that sentence is not about redirects at all: the identical line sits under reason after reason in this report — I checked four different ones on my own site, and it was word-for-word the same under each. It is the page’s boilerplate, not a diagnosis. Second, for this particular reason, the sentence is usually just true, and fine: these addresses aren’t listed separately because they were never meant to be, and nothing of yours is missing. The rest of this article is me earning that claim.

What a redirect actually is

A redirect is an old address that sends visitors on to a current one. Type it — or follow an old link from another site, an old social post, a bookmark — and instead of a dead end you arrive at the page’s present address, usually without noticing anything happened. That is the whole device. It is not a fault; it is the mechanism that keeps old links from breaking. The alternative to a redirect is not “everything works” — it is a “page not found” error for every person still holding the old address.

So why is it in a report about problems?

Because the table’s job is to be complete. It lists every reason an address isn’t in Google’s index, and faults, deliberate choices and plain bookkeeping all sit in it side by side, listed the same way. “This address forwards somewhere else” is bookkeeping. Google’s own help page for the Page indexing report opens its definition of the reason with two short sentences:

Google’s help page, defining “Page with redirect”

This is a non-canonical URL that redirects to another page. As such, this URL will not be indexed.

“Non-canonical URL” is jargon for a simple thing: an address that is not the main copy of a page. A forwarding address never is — its entire job is to point at the main copy. So of course it “will not be indexed”: Google keeps one entry per page, and for a working forward that entry is the destination’s. Being forwarded takes nothing out of search — the page lives at the address the forward points to, and that address is judged on its own merits. If it ever has a problem of its own, it gets its own row under its own reason. This row is only ever about the forwarder.

Most reasons in that table describe something a person once set. “Excluded by ‘noindex’ tag” is a switch somebody ticked, and finding the somebody is that article’s whole story. A redirect row is different: usually nobody did anything at all. My own report happens to be a clean demonstration, so let me use it.

The three addresses in my own report

My site currently shows this reason with three affected pages. I went through all three, and between them they cover most of what lands in this row.

The one that looks like a real page. https://kovalweb.com/core-web-vitals — no odd characters, the clean address of a real article. Why would that forward anywhere? I asked the server directly — the same question a browser asks invisibly every time — and its answer was code 301, “moved permanently”, pointing at https://kovalweb.com/core-web-vitals/. The same address with one added slash, which then answers normally. That is the entire event. WordPress settled on the spelling with the slash as the page’s real address and quietly forwards the other spelling to it. Where Google learned the slashless spelling I couldn’t establish — but it read it, was told “moved”, and filed it, correctly, under “Page with redirect”. A row in a table headed “Why pages aren’t indexed” was describing a slash.

The page nobody made. https://kovalweb.com/uk/author/myhalchakmyhajlyna — an author archive. WordPress builds a page like this for every author on its own; nobody sits down and writes one. Google read it last July and filed it here as a forward. When I asked the server today, it didn’t forward anywhere — it answered “not found”. So this row is Google’s memory of a forward that has since stopped existing. Nothing broke, and nothing was ever meant to be found there.

The fossil. https://kovalweb.com/core-web-vitals#! — the same article again, wearing #! at the end: an old style of web address from years back, long obsolete. It forwards to the clean address, which is exactly what should happen to it. Where Google picked this spelling up, I couldn’t establish either — and didn’t need to.

The #! spelling also exists with the slash — …/core-web-vitals/#! — and that one is not in this report at all. It sits in a different one: “Alternate page with proper canonical tag”. The split tracks the slash exactly. The slashless spelling forwards, so it is a page with redirect; the slashed spelling answers normally and names its main copy, so it is an alternate. One missing slash and one obsolete #!, and Search Console shows two alarming-looking rows in two different reports. Neither one is trouble.

Three addresses, nothing for a person to do. That matches the wider pattern. The usual residents of this row:

• Nothing to do Old http:// addresses — a site that moved to secure https:// forwards every old spelling to its secure twin. Expected: the forward is the fix, already made.
• Nothing to do www. and the bare name — two spellings of the same site; one forwards to the other so there aren’t two copies of everything.
• Nothing to do Slash and no-slash — the same thing at the level of a single page, as above.
• Nothing to do An address you changed on purpose — you renamed or moved a page, and the old address forwards. That is the redirect doing its one job: old links don’t break.
• Nothing to do Addresses your platform invented — author archives, machine-made listings, retired address styles. Nobody chose them, so nobody has to answer for them.
• Look closer A forward you can’t explain, on a page you care about — the minority, and the next section.

The minority worth a look

Three shapes deserve a person’s attention:

• The forward lands somewhere unrelated. An old services address that forwards to your home page instead of the new services page loses every visitor who held the old link — they arrive somewhere, just not where they were going.
• An important page forwards and you moved nothing. If an address in the list is one you would type yourself — your home page, your services, a product — and you don’t remember changing anything, find out today where it sends people.
• The forward passes through several addresses. A site that moved more than once can end up with old → older → current, each move only knowing about the previous address. Visitors still arrive, but every extra hop is one more thing that can quietly go wrong later.

The test for the first two costs nothing and needs no tools: paste the listed address into your browser and watch where you land. Then ask one question — is this where a person holding that old link should end up? If yes, the row is settled. Landing on the address you typed, with nothing seeming to happen, counts as yes: that is a slash-or-www forward doing its job invisibly.

If the answer is no — you land somewhere generic, or nowhere useful — then you have found the rare version, and the useful thing is not to guess at the cause but to write down two addresses: the one you pasted and the one you ended up on. That pair is the whole problem, and it is what whoever manages your site needs. The forward was set somewhere — your platform’s redirect settings, a plugin, or the server itself — and the pair says which one is misdirected.

The third shape, the chain of hops, a browser won’t show you: the jumps happen in milliseconds and the address bar settles before you can see them. That one needs the check in the next section.

Check it the way Google checks it

The browser told you what a visitor gets; Search Console will tell you what Google gets. At the top of it sits URL Inspection: paste the destination address — the one your browser settled on — and read the verdict. For a page that is in Google’s list, it opens with URL is on Google. Expand the Page indexing section beneath it and the details are questions you now know how to read — one of them literally labelled Indexing allowed?, which is the thing you came to find out, answered in a word. And the TEST LIVE URL button reads the page as it exists this second, not as Google last saw it. That distinction matters more than it sounds, and the last section is why.

Two things not to worry about while you are in there. If the destination comes back URL is not on Google, that is a separate matter with its own reason somewhere in the report — it is not what this row was telling you. And the issue’s page offers a Validate fix button: you don’t need it here. It asks Google to re-check a fault, and a working forward isn’t one.

The report is a memory, not a live view

One more column on the issue’s page repays a look. Its Examples list shows each affected address next to a date, in a column labelled Last crawled — Google’s phrase for sending its reading program to a page, so in plain words: when Google last read this address.

Mine are worth quoting. The author archive was last read this past July. Both spellings of the article — the slashless one and its #! fossil — were last read in March and April of 2025: more than a year before the morning I opened the report.

Sit with that for a second, because it is the most useful fact in this whole story. A row in this report can describe a page Google has not looked at in over a year. The row does not mean Google keeps finding a problem; it means Google once filed an address under a reason and has had no cause to revisit. So “the report still shows it” and “something is still wrong” are two different statements — the first is about Google’s records, the second is about your site, and a year can sit between them.

Which is also your permission slip. If every address in your list lands where a visitor should end up, you are done — not “done for now”, done. Nothing gets worse while the rows sit there: the addresses they name were never going to be listed separately in the first place. The report will go on remembering your old addresses, because keeping records is its job. And the forward will go on doing its job too — invisibly, which is the only way it ever worked.

Written by Oleh Koval at Specia1ne, who reads these reports for a living.