Not every redirect is a problem. Adding www., moving from http:// to https://, or dropping a trailing slash are all standard address cleanup, and a single redirect that does exactly one of these is often best practice, not a mistake. Crawl Cove reports it separately from a real redirect chain so it never gets mixed in with hops that actually need fixing.
What this finding means
Crawl Cove's redirect-normalisation check looks at every single-hop redirect in the crawl and flags the ones where the destination is the same page at a cleaned-up address: the hostname matches once www. is stripped from both sides, the port is unchanged, the path matches once a trailing slash is stripped, and the query string is identical. Anything that changes more than that, such as a path segment, is not normalisation and is left for the redirect-chain and status-code checks to cover instead.
A real finding looks like this:
http://example.com/blog/post -[301]-> https://www.example.com/blog/post
One finding per redirecting URL, showing exactly what changed and the status code used.
Why it matters
This kind of redirect is already correct and needs no fix. It still costs one extra request, though: a browser or crawler that requests the old address has to follow the redirect before it reaches the real page. Pointing internal links, canonical tags and any external references straight at the final address saves that hop for every visitor and every crawl.
How to fix it
- Find every internal link still pointing at the old address. Crawl Cove's finding names the exact
fromandtoURLs; search your templates, navigation and content for thefromaddress. - Update those links to the
toaddress directly. This is a find-and-replace across templates or content, not a server change. - Leave the redirect itself in place. It is still needed for old bookmarks, external backlinks and anyone who types the un-normalised address by hand.
- Re-crawl afterwards to confirm the finding clears once internal links point at the final URL.
False positives and edge cases
- A multi-hop chain is never reported here, even if every hop normalises the address. Two or more redirects landing on the same final page is a redirect chain, reported by that check instead, because collapsing several hops into one is worth doing regardless of what each individual hop does.
- A redirect that changes anything beyond www, scheme or a trailing slash is not normalisation. A path change, a different query string, or a move to a different page entirely is a real redirect and is covered elsewhere, not by this check.
- This is a low-severity, "tidy when convenient" finding, not a defect. Nothing is broken while it is open; fixing it saves a request rather than fixing an error.
Related reading
For the check that covers redirects that need real attention, chains of two or more hops, see Redirect Chains and Loops.
Google documentation: Redirects and Google Search
Frequently asked questions
- Should I remove a www-to-non-www redirect entirely?
- No, keep the redirect. Removing it would let both versions of the URL serve content, which risks duplicate-content confusion. The fix here is pointing internal links at the final URL directly, not removing the redirect itself.
- Does this kind of redirect hurt rankings?
- A single, permanent (301) redirect passes ranking signal to the destination URL and is standard practice; Google has said a reasonable number of redirect hops causes no meaningful loss. It is not a ranking problem, it is a small efficiency one.
- What is the difference between this and a redirect chain?
- This check only fires on a single hop that does nothing but clean up the address (www, http/https, or a trailing slash). Two or more hops, even if every one of them is a normalisation redirect, are reported as a redirect chain instead, because collapsing several hops into one is worth fixing regardless of what each hop does.
- Why does the recommendation say to update internal links instead of doing nothing?
- The redirect itself is correct and needs no fix. But every internal link still pointed at the old address costs visitors and crawlers an extra request they did not need to make, so tidying those links is free performance, not a defect fix.