Google asked for an address on your site, got redirected, and filed the old address here. That’s normal, and harmless on its own: a URL that redirects isn’t indexed, and Google judges the page it lands on separately. The real question is who keeps sending Google the old address. Often it’s your own links or your sitemap, and those are yours to fix.
Do your own links still point at the old URL?
More often than you’d guess. On November 14, 2026, we checked 291 startup sites, a random sample of active B2B companies from a public copy of Y Combinator’s directory. From each site we requested up to 30 links on the homepage and up to 25 URLs in the sitemap, without following redirects. 68 of the 255 homepages with links to check, 27%, linked to at least one of their own addresses that redirects. Sitemaps did it less often: 24 of 241.
Nearly half of those redirects changed the path. On the 68 homepages, the first link that redirected went to a different path on the same site 31 times, to another host 21 times, and only added or dropped a trailing slash 14 times.
To trace one row, inspect the URL in Search Console and read Referring page in the indexed result. Google calls it “a page that Google possibly used to discover this URL,” and it may be a few links away from the page that holds the link, so it’s where you start looking, not proof. Then change the link to the final address. Google’s advice is to link “to the canonical URL rather than a duplicate URL.” We start with the nav and the footer, because they’re on every page.
Is the old URL still in your sitemap?
Your sitemap is the list of pages you hand Google, and Google “will attempt to crawl your URLs exactly as listed.” So list the address the redirect lands on, the one you want in search results. Of the 5,060 sitemap URLs we requested, 159 redirected, spread across those 24 sites.
For a single row, the Sitemaps field in URL Inspection names any sitemap you submitted, or listed in robots.txt, that includes the URL. Read it in the indexed result: the live test doesn’t check sitemaps or referring pages. When your framework or CMS builds the sitemap, fix it where it’s built, or the old address comes back on the next deploy.
Is your host sending a temporary redirect?
Google reads two kinds of redirect. A permanent one, a 301, a 308 or an instant meta refresh, shows the new page in search results. A temporary one, a 302, 303 or 307, shows the old one. Google recommends a permanent server-side redirect wherever you can, and JavaScript only when nothing else works, because Google might never see a JavaScript redirect if the page fails to render.
Some redirects your host adds on its own. Here’s what each one sends by default:
| Host | Redirects you set | Redirects the host adds |
|---|---|---|
| Next.js on Vercel | 308, or 307 when the rule says permanent: false | 308 for a trailing slash when trailingSlash is false, and for .html when cleanUrls is true |
| Netlify | 301, unless you set another status | – |
| Cloudflare Workers static assets | – | 307 for a trailing slash or .html |
From each host’s docs: Next.js redirects, Vercel’s project settings, Netlify redirects and Cloudflare’s HTML handling. A dash means the page we read gives no default.
We have one of these ourselves. firstindex.com runs on Cloudflare’s static assets, so firstindex.com/guides/ answers with a 307 to /guides. Our sitemap and links use the address without the slash, so Google never gets sent through it. One stray link to the slash version would change that, and stray links to temporary redirects are common: 30 of the 255 startup homepages we checked had at least one.
Keep each redirect to one hop, too, so no redirect leads to another redirect. 19 of the 255 linked to a chain of two or more. Googlebot follows up to 10 hops, and a chain longer than that lands in a different row: Redirect error.
What if the old address comes from somewhere else?
Then keep the redirect and leave the row. Another site’s link, an old bookmark or an address Google crawled years ago all end up here, and the redirect is what gets them to the right page. Google keeps track of both URLs, and one of them “becomes an alternate name” of the other.
That includes the homepage listed three times. A site owner on Reddit posted exactly that and asked if it explained a drop in traffic. Google’s John Mueller answered that it didn’t, because “these wouldn’t be indexed anyway,” that someone, “perhaps you, perhaps your sitemap file,” was likely linking to those versions, and that otherwise “you can just leave them like this.” Our own report has the same kind of row: www.firstindex.com is listed as Page with redirect, and Google’s chosen URL is firstindex.com. That’s the setup working.
Don’t wait for these rows to clear. Google’s Validate fix is meant for errors and warnings. A redirect you’re keeping is neither, so it stays listed. A row you did fix can stay until Google crawls the URL again: the crawl date in URL Inspection tells you whether it has.
Related rows in the same report: Google chose different canonical, Alternate page with proper canonical tag and Soft 404, or the whole Page indexing report at once.
Pointing every link and sitemap entry at the final address is one of the fixes our plan covers for software companies, at $2,000 a month. See what’s in the plan.
Questions
Why is my page redirecting?
Because a rule on your host or in your site’s settings sends it on: a trailing-slash or .html rule the host adds, a redirect from http to https or between www and the bare domain, or one someone set when a page moved. To see which, run curl -I on the URL: the first line shows the status code and the Location line shows where it goes.
Should I request indexing for a redirected URL?
No. Inspect the page it redirects to instead. URL Inspection reports on the exact URL you enter and ignores the redirect, so use the Inspect button in its Page indexing section to see the page Google indexed.
What’s the difference between Page with redirect and Redirect error?
Page with redirect means the redirect worked. Redirect error means Google couldn’t finish it: the chain ran too long, looped, grew past the maximum URL length or hit a bad or empty URL. That one you fix.