On this page
Redirects are not inherently bad for SEO. They help people and search engines reach the appropriate destination when a URL changes. Problems arise when the destination is irrelevant, the move is misclassified, a chain or loop gets in the way, or important links and indexing signals remain inconsistent.
Use redirects for a real move, test the complete path and update the references you control. Do not treat them as a guarantee of preserved rankings or assume that every hop loses a fixed percentage of ranking value.
Reviewed October 3, 2026.
What redirects do
A redirect sends a request for one URL to another location. Server-side HTTP redirects provide a response status and a destination. Browser-side mechanisms can redirect after the page is received or rendered.
Google’s redirect documentation distinguishes permanent redirects, which signal the destination should be canonical, from temporary redirects, which do not provide that same signal. Choose based on the actual move.
- 301 or 308: permanent HTTP redirects.
- 302 or 307: temporary HTTP redirects.
These are not interchangeable choices for every request. When a workflow includes submitted forms or other non-GET requests, review the method-handling implications with the implementation owner. An SEO checklist is not a substitute for testing application behavior.
Server-side and browser-side redirects
For permanent URL changes, prefer a server-side redirect where possible. Browser-side methods introduce different processing requirements. For example, a JavaScript redirect depends on successful rendering.
Do not describe every browser-side redirect as invisible to search engines. Google documents how it interprets instant and delayed refresh redirects, and recommends JavaScript redirects only when better-supported alternatives are unavailable. Inspect the actual implementation rather than relying on the label alone.
What can go wrong
- Irrelevant destination: a retired article sends readers to a generic homepage that does not answer their question.
- Wrong permanence: the response describes a reversible move as permanent or a lasting move as temporary.
- Chain: the old URL redirects through intermediate locations instead of the current destination.
- Loop: one location eventually redirects back to itself or an earlier location.
- Broken destination: the final page fails, is blocked or has incompatible indexing instructions.
- Stale references: internal links, navigation, sitemaps or other maintained references still point to obsolete URLs.
Extra hops can add request work and latency, but the observed effect depends on the environment. Measure the path rather than claiming each hop has a universal speed penalty or a fixed loss of link equity.
A seven-step redirect audit
- Inventory the old URLs. Include meaningful traffic sources, internal links and important externally linked pages.
- Map the intended destination. Choose the relevant replacement. If none exists, review the appropriate removal behavior rather than redirecting everything to the homepage.
- Classify the move. Document whether it is permanent or temporary and why.
- Inspect the response. Check the status and Location destination, including the full chain.
- Test the final page. Confirm the actual content, response, accessibility and indexing instructions.
- Update maintained references. Link directly to the current destination where possible and review the sitemap and canonical configuration.
- Monitor after launch. Check unexpected errors, user journeys, Search Console evidence and the specific traffic paths that matter.
Keep a rollback plan and the previous mapping. A redirect rule can affect more URLs than intended, especially when it uses patterns or interacts with a CDN, application router or other server rules.
Worked example: shorten an obsolete chain
Suppose an old article at /old-guide/ redirects to /revised-guide/, which redirects again to /current-guide/. The final page is the relevant lasting replacement.
Update the old mapping to point directly to /current-guide/ and update internal links to that current URL. Test the old and intermediate URLs separately, then check that the final page returns the intended content.
Also test any required campaign parameters and anchors in the actual journey. Preserve approved attribution data when needed, without copying sensitive or unnecessary parameters indiscriminately. A working page redirect does not automatically prove the analytics attribution survived.
This change reduces unnecessary steps. It does not prove that a specific quantity of ranking value has transferred or that search traffic will increase.
Redirects during a larger site move
Use a reviewed old-to-new map rather than a blanket destination. Check the new content, links and indexing configuration before launch. Keep the redirect paths working and monitor both old and new URLs.
Expect processing and observed search performance to vary. Do not promise that the new URLs will immediately inherit identical positions, clicks or indexing states. Separate technical implementation checks from the later evidence about search visibility.
Review the content behind the destination in RankWell
A technically correct redirect still needs a useful replacement page. Use RankWell to prepare or review the article that should satisfy the original question.
- Define the replacement page’s reader and purpose.
- Open or prepare the draft and review its facts and sources.
- Check the links, media, headings and metadata in preview.
- Approve publishing through the configured destination.
- Have the appropriate website owner implement and test the redirect separately.
This is an editorial workflow, not a claim that RankWell configures server redirects or performs an automatic migration.

Frequently asked questions
Does a 301 pass exactly 90–99% of link equity?
No fixed percentage is established here. Avoid assigning an unsupported numeric transfer value to a redirect.
Is a 302 always bad for SEO?
No. It is a temporary redirect. Use the status that fits the actual move rather than claiming it inherently destroys rankings.
How many redirects should I allow?
Prefer a direct path to the intended destination. There is no useful universal safe chain length established here; test your actual path and remove unnecessary hops.
Should every deleted article redirect to the homepage?
No. Review whether there is a relevant replacement and choose the appropriate behavior for the specific removed content.
Does a successful redirect prove a migration succeeded?
No. Check the destination content, important journeys, maintained links and later indexing and search evidence as well.
Explore RankWell to review the content that makes the new destination useful.
Reviewed and updated October 3, 2026.


Julia McCoy