Redirects for SEO: 301s, Redirect Chains, and Stopping the Slow Leak of Link Equity

# SEO Redirects: What They Actually Do, Which Kind to Use, and How Sloppy Practice Quietly Leaks Your Rankings If you run a service business — HVAC, plumbing, electrical, law, dental, shuttles, contracting — your website has probably changed more times than you remember. Pages get renamed, services get merged, the site moves to HTTPS, a redesign cleans up messy URLs. Every one of those changes means an old web address stops working, and every one of them is a moment where **SEO redirects** either protect the ranking strength you've spent years building or quietly throw part of it away. Redirects are one of those topics that sounds boring and technical until you understand what's actually at stake. A redirect is simply a instruction your server sends when someone (or a search engine crawler) requests a URL that no longer exists: *"That page moved — go here instead."* Done right, the visitor lands on the right page and search engines transfer the old page's accumulated authority to the new one. Done wrong, you leak signals at every hop, waste crawl budget, frustrate real customers, and wonder months later why a page that used to rank stopped showing up. This guide covers what a redirect actually does, which status code to use in which situation, the specific mistakes that drain ranking strength from local service business websites, and the maintenance habits that keep your redirect setup clean for years. This is not a full site-migration guide — a redesign checklist is its own topic — and it's not about canonical tags, which deal with choosing between live duplicate pages. This is about the moment a URL dies and what you do next. ## Why URLs Change in the First Place Before you can manage redirects well, it helps to recognize the situations that create them. In service businesses, URL changes almost always come from one of these scenarios: - **A page gets renamed to target a better keyword.** Your old page lived at `/ac-repair-services` and your research (or your SEO tool) suggests people actually search for "air conditioning repair." The slug changes to `/air-conditioning-repair`, and the old URL needs to point to the new one. - **Two thin service pages get merged into one stronger page.** You had `/drain-cleaning` and `/clog-removal`, each with three paragraphs of thin content. Combining them into a single comprehensive page at `/drain-cleaning` gives search engines something substantial to rank — but the retired URL needs a redirect. - **A discontinued service's page comes down.** You stopped offering commercial refrigeration repair. The page can't just vanish; whatever links and rankings it earned need somewhere to go. - **The site moves from HTTP to HTTPS.** Every single URL technically changes, and every old `http://` address needs to redirect to its secure `https://` equivalent. - **The www vs. non-www version gets consolidated.** If both `www.yourbusiness.com` and `yourbusiness.com` serve the same content without redirecting, search engines see two versions of every page. One version needs to permanently point to the other. - **A slug gets cleaned up during a redesign.** The old site had URLs like `/index.php?id=24&cat=7`. The new site uses readable slugs like `/furnace-installation`. Every legacy URL needs a mapping to its modern equivalent. Notice the pattern: in almost every case, the old URL has *history*. It may have been live for years. Other websites may link to it. It may appear in old blog posts, directories, Yelp listings, printed flyers with vanity URLs, or a customer's browser bookmarks. All of that history is ranking strength, and a redirect is the mechanism that carries it forward. ## What a Redirect Actually Does When a browser or a search engine crawler requests a URL, your server responds with a status code — a three-digit number that tells the requester what happened. A normal, healthy page returns **200 OK**. A missing page returns **404 Not Found**. A redirect returns a code in the 3xx range along with a new destination URL. The requester then goes to that destination. That's the mechanical part. The part that matters for SEO is what the status code *communicates*. The code is a signal about intent and permanence. Search engines read these codes to decide: 1. Whether to replace the old URL with the new one in their index, or keep the old one around. 2. How much of the old page's accumulated ranking signals — from years of links, engagement, and topical relevance — to apply to the new destination. 3. Whether to keep spending crawl effort on the old URL. In other words, a redirect is not just plumbing for visitors. It's a message to Google about the *relationship* between two pages. Get the message right and the change is mostly invisible to your rankings. Get it wrong and you can watch a page that held position for years slide out of the results. One more thing a redirect does that people forget: it serves real humans. A homeowner who bookmarked your emergency plumbing page two years ago, or clicked a link in a directory listing you can no longer update, is counting on that old URL to take them somewhere useful. A redirect is often the difference between a lead and a 404 page. ## The Status-Code Decision: 301, 302, 307, and 410 This is where most redirect mistakes are made. There are several redirect status codes, but for a service business website the decision tree is short. ### 301 Permanent — the default for every legitimate URL change A **301 redirect** tells browsers and search engines: *"This URL has permanently moved. Update your records. Everything this page earned now belongs to the destination."* Use a 301 for: - Renamed pages and updated slugs - Merged pages (point the retired URL at the surviving page) - Discontinued services (point at the closest related service page) - HTTP to HTTPS migrations - WWW to non-WWW (or vice versa) consolidation - Domain changes - Trailing slash and capitalization variants When people talk about a redirect "passing signals" to the new page, they're talking about the 301. Google treats 301s as a strong, persistent signal that the old page's relevance and link authority should be consolidated into the destination. It may not happen instantly — crawlers need to rediscover the old URL and process the change — but the 301 is the correct long-term instruction. The practical rule: **if the change is permanent and the old page is never coming back, it's a 301.** For a service business, that covers roughly 95% of real-world situations. ### 302 and 307 Temporary — reserved for genuinely temporary situations A **302** (and its HTTP/1.1 sibling, the **307**) tells search engines: *"This URL has moved for now, but it's coming back. Keep the original URL indexed."* Legitimate uses are rare but real: - A seasonal page swap — say, a shuttle company temporarily points its summer "whale watching tours" page at a winter "holiday lights tours" page, then reverses it in spring. - Short-term maintenance or a limited-time promotion landing page. - An A/B test running for a defined period. **The classic mistake:** a developer or a plugin uses a 302 for what is actually a permanent change — often because it's the default in some platform settings, or because someone thought a "temporary" redirect was somehow safer. The consequences are quiet and frustrating: search engines keep the old URL indexed, don't fully consolidate the old page's signals into the new destination, and you end up with two URLs competing for the same query. Months later, the new page ranks worse than it should, and nothing looks broken when you click around the site manually. If you inherit a site or you're auditing one, checking whether "permanent" redirects are actually 301s (not 302s) is one of the highest-value checks you can run. Many platforms and redirect plugins let you choose the code per redirect — make sure the right one is selected. ### 410 Gone — for content that is deliberately gone A **410 status code** isn't a redirect at all — it's a response meaning *"This content has been intentionally and permanently removed, and there is no replacement."* When would you use it instead of a redirect? When a page truly has no sensible destination: - A one-off blog post about a promotion that ended years ago - An event page for a trade show that's over - Content removed for legal or accuracy reasons The 410 tells search engines to drop the URL from the index faster than a 404 does, because it removes any ambiguity — a 404 *might* be a temporary glitch, but a 410 is a deliberate statement. You lose the page's signals either way; there's no destination to pass them to. That's why the better move, whenever a remotely related page exists, is still a 301 to the closest match. A landscaping company deleting its page for a service it stopped offering, for instance, is better served redirecting that URL to its general services page than serving a 410 — the old page's relevance still partially applies. ## Redirect Chains and Loops: The Slow Leak Nobody Notices ### What a chain is A **redirect chain** is exactly what it sounds like: - URL A redirects to URL B - URL B redirects to URL C - URL C redirects to URL D (the final, live page) A visitor asking for A gets bounced three times before landing on real content. A crawler follows the same path. Every hop is a separate request, a separate server round trip, and a separate point where signals get interpreted and diluted. ### How chains form naturally over years Here's the insidious part: chains almost never get created on purpose. They accumulate. Imagine a dental practice over ten years: 1. In 2015, `/teeth-whitening-special` was a promotion page. 2. In 2018, the promotion ended, so it was redirected to `/cosmetic-dentistry`. 3. In 2021, the practice consolidated cosmetic services into `/smile-solutions`, so `/cosmetic-dentistry` got a redirect. 4. In 2024, a redesign renamed it to `/cosmetic-smile-treatments`. Nobody did anything wrong at any step — each redirect pointed at what was then the live page. But the original URL from 2015 now passes through three hops before reaching content. Multiply this pattern across a site with dozens of pages that have been renamed two or three times, and you have a site-wide problem. ### Why chains hurt - **Signal dilution at each hop.** Each additional redirect gives search engines another interpretation to make and can weaken the transfer of ranking signals. A single clean hop transfers strength well; a four-hop chain is a much murkier signal. - **Load time for real visitors.** Each hop adds a full request-response cycle before the browser can even begin loading the actual page. On a mobile connection, that's real seconds — and page speed affects both user experience and rankings. - **Crawl waste.** Search engines allocate a limited crawl budget to your site. Every hop consumes it. If your most important service pages sit behind chains, crawlers spend their budget following redirects instead of discovering and refreshing your actual content. - **Fragility.** Every extra URL in a chain is another URL that can break during a future migration or redesign. ### What a loop is A **redirect loop** is the terminal version of this problem: A redirects to B, B redirects back to A. The browser eventually gives up and shows an error — "This page isn't redirecting properly" — and the crawler abandons the URL entirely. Loops usually appear after a migration when old and new redirect rules conflict, and they take pages completely out of commission until found and fixed. ## How to Find Chains and Loops on Your Site You can't click through your own site and find these by hand — the chains live in URLs that may not be linked from anywhere anymore. The reliable method is a **site crawl**. 1. **Run a full crawl of your site** using a crawler tool (Screaming Frog, Sitebulb, and similar tools all do this; many SEO platforms include it too). Include the list of old URLs you know about — URLs from your previous sitemap files, URLs in your analytics from prior years, and URLs from backlink reports. 2. **Filter for every URL that returns a 3xx status.** Your crawler will report the redirect type (301, 302, 307) and, crucially, the number of hops and the final destination. 3. **Check the final status of every redirecting URL.** For each chain, confirm the last URL in the sequence returns a 200 OK. If anything ends in a 404, 410, or loops back on itself, flag it immediately — a redirect to a dead page is worse than no redirect at all. 4. **Identify every chain with more than one hop.** These are your fixes. 5. **Fix by re-pointing every hop directly at the final destination.** This is the key move. Don't just delete the middle redirect — other sites and old links may point at *any* URL in the chain. Instead, edit the rule for the original URL so it targets the final live page directly, bypassing the intermediate hops. A → B → C → D becomes A → D and B → D (if B is still a URL anyone might request). Your redirect table shrinks to a single hop from anywhere to the right page. How often should you crawl? A quarterly pass is a reasonable rhythm for most service businesses, plus an immediate crawl after any site change. If you're using a platform like [SEO Done](https://seodone.ai), redirect and error monitoring is built into the ongoing site audit, so chains and loops surface as they form rather than months later. ## The Redirect-Everything-to-the-Homepage Mistake This is the single most common redirect failure on small business websites, and it's worth its own section. The scenario: a redesign launches, old URLs break, and whoever set up the redirects takes the shortcut — point *every* old URL at the homepage. Done. One rule. Job finished. Except it isn't. Here's why a blanket homepage redirect throws away exactly what you're trying to preserve: - **Relevance doesn't transfer to a mismatched destination.** Your old `/water-heater-repair` page had accumulated links from local directories, blog mentions, and forum posts — all anchor text and context about water heater repair. Redirecting it to the homepage tells search engines that all of that relevance now applies to... a homepage about everything. The signal gets scattered and largely lost, because the homepage is about a dozen topics, not one. - **Visitors bounce.** A homeowner searching for water heater repair who lands on your homepage now has to figure out where to go next. Many won't. They'll hit the back button and call the next plumber in the results. - **Search engines may treat it as a soft 404.** When redirects consistently point at pages with no matching content, Google can start treating them as not-found, and the old URL's signals evaporate. **The fix: page-specific redirects to the closest matching page.** Go through your old URLs one by one and map each to the most relevant live page: - `/water-heater-repair` → `/plumbing-services/water-heater-repair` (or wherever the equivalent page now lives) - `/emergency-ac-service` → `/hvac-services/emergency-ac-repair` - A discontinued service → the parent category page or the closest remaining service - A retired blog post → a related post or the blog index if nothing matches It's more work up front — a 40-page site might mean 40 individual rules — but it preserves the relevance match that makes redirects work at all. For a law firm, that means the old `/dui-defense` page points at the new DUI defense page, not the firm's homepage. The whole value of the redirect is in the match. ## Meta Refresh and JavaScript Redirects: Why Server-Side Wins Not all redirects are created equal, and some barely work at all. - **Meta refresh redirects** are an HTML tag placed inside a page (`` — often the ones that display "You will be redirected in 5 seconds..."). They require the browser to fully load the old page first, they're slower, and search engines handle them less reliably than server-side redirects. They're occasionally used for legitimate UX purposes (a countdown on a moved page), but they are not a substitute for a proper redirect. - **JavaScript redirects** use code running in the browser to send the visitor elsewhere. Search engines *can* render JavaScript and follow these, but it adds uncertainty and delay: the crawler has to render the page, execute the code, and then follow the destination. It's an extra layer of "maybe" that server-side redirects don't have. - **Server-side redirects** (the 301s, 302s, and 307s configured in your server configuration, your platform's redirect manager, or your hosting panel) fire before any page content loads. They're fast, universally understood, and read directly from the HTTP response — no rendering required. The rule is simple: **use server-side redirects for anything SEO-related.** Meta refreshes and JavaScript redirects have narrow, legitimate UX uses, but they are the wrong tool for URL changes. If a developer proposes a JavaScript redirect "because it's easier," push back. If your platform's theme injects a client-side redirect for old URLs instead of a proper server rule, that's a problem to fix, not a quirk to live with. ## How Long to Keep Redirects in Place A question that comes up constantly: "The redirect has been live for a year — can we delete it now?" The answer is **indefinitely for any URL that earned links**, and here's the reasoning: other websites never get updated. That local news article from 2019 linking to your old service page? Still live, still linking. The industry directory listing? Still linking. The forum post recommending your business? Still linking. You have no way to reach most of the people linking to your old URLs, and even if you did, most wouldn't bother updating. Every one of those old links is a pathway. Delete the redirect and the pathway leads to a 404 — and the ranking strength that flowed through it stops flowing. There's essentially no penalty for keeping redirects. They cost a tiny amount of server configuration and nothing in rankings. The cost asymmetry is enormous: - **Keep a redirect you no longer strictly need:** near-zero cost. - **Delete a redirect that was still receiving links:** you silently cut off authority, referrals, and possibly conversions, with no error message telling you it happened. Practical guidance: - **Keep forever:** URLs that ever earned external links, URLs that appeared in print or advertising, URLs from before any major redesign. - **Safe to eventually clean up:** internal-only redirect hops you've already collapsed (once you've re-pointed the original directly at the destination, the middle hop may eventually be removable if nothing external points at it — verify with a crawl and your backlink data first). - **Never let expire:** HTTP→HTTPS and www→non-www redirects. These are structural and should live in your server configuration permanently. Treat your redirect file like the deed to your property, not a scratch pad. Old redirects are not clutter; they're the recorded history of where your site's authority lives. ## The Post-Launch Redirect Audit Any time your site changes — redesign, migration, platform switch, bulk URL cleanup — the work isn't done at launch. The **redirect audit** is what tells you whether the change actually protected your rankings. Here's the process: 1. **Build your old URL list before launch.** Crawl the old site and export every URL. This list is your checklist; after launch it's too late to reconstruct it. 2. **Crawl your old URLs after launch.** Feed the old URL list into a crawler configured to run against the live site (or use a crawler that accepts a URL list). Confirm every single one returns a redirect. 3. **Confirm each returns a single hop to a live, relevant page.** Check three things per URL: the status code is 301 (not 302), the hop count is exactly one, and the destination is a live page (200 OK) that's topically relevant — not the homepage, not a 404. 4. **Spot-check the internal links on the new site.** Your new site shouldn't link to old URLs and rely on redirects. Internal links should point directly at final URLs. Redirecting your *own* internal links adds hops for users and crawlers for no reason. 5. **Watch Search Console for spikes in not-found errors.** In the weeks after launch, monitor the Pages (indexing) report and the not-found error list. A sudden cluster of 404s for old URLs is the signal that a redirect rule was missed. Also watch for "Page with redirect" entries climbing without the corresponding new URLs getting indexed — a sign that redirect destinations or signals aren't resolving as intended. 6. **Compare rankings and organic traffic for the affected pages over the following weeks.** Some short-term fluctuation after a URL change is normal. What you're watching for is recovery — and for specific pages that *don't* recover, which usually points to a redirect problem on those specific URLs. The audit typically surfaces a handful of misses even on carefully planned launches. That's normal. What matters is catching them in days, not discovering them six months later when the traffic report shows a slow slide. ## The Maintenance Habit: Keep the Redirect Map a Table, Not an Archaeological Dig The final piece isn't technical at all — it's a habit. Every time a URL changes on your site, from that day forward, one thing should happen without exception: **the new redirect gets added to your redirect map.** A redirect map is exactly what it sounds like — a simple, maintained table (a spreadsheet works fine) with two columns: old URL, new destination. Optionally a third column for the date and a note on why it changed. Sites without this habit end up with what you might call an archaeological record: a redirect file with hundreds of rules in no particular order, many of them chained, some pointing at pages that no longer exist, assembled by three different people over six years, with no one knowing which rules still matter. Every future migration starts with an investigation instead of a checklist. Sites *with* the habit maintain a tidy one-hop table: any old URL → its final live destination, directly, no intermediate stops. When the next redesign comes, the map *is* the migration plan. You already know every URL that ever mattered and where it should land. The habit in practice: - **One entry per URL change, added the day it happens.** Not batched for later. Later never comes. - **Record the destination, not the next hop.** If `/old-page` now goes to `/new-page`, the map says so — and if `/new-page` is renamed next year, you *update* that row so it points at the newest URL. One hop, always. - **Review the map quarterly.** Crawl the old URLs on the map, confirm each still resolves in one hop to a live page, and correct anything that drifted into a chain. - **Keep the redirect file and the map in sync.** The map is documentation; the server rules are the implementation. When they diverge, you have invisible redirects nobody remembers creating — the raw material of future chains. For a busy service business owner, this is a five-minute task per change. For your future self during the next redesign, it's the difference between a smooth launch and a ranking emergency. ## Quick Reference: The SEO Redirects Checklist - **Use 301 for every permanent URL change** — renames, merges, removals with a close match, HTTP→HTTPS, www consolidation. - **Use 302/307 only for genuinely temporary moves** — seasonal swaps, short maintenance windows. Check that your platform isn't defaulting to temporary codes. - **Use 410 only for content deliberately removed with no sensible replacement.** - **Never blanket-redirect to the homepage.** Map each old URL to its closest relevant live page. - **Eliminate chains** by re-pointing the original URL directly at the final destination. - **Check for loops** after any migration or rule change. - **Use server-side redirects,** not meta refresh or JavaScript redirects. - **Keep redirects in place indefinitely** for any URL that ever earned links. - **Audit after every launch:** crawl old URLs, confirm one hop to a live relevant page, watch Search Console for 404 spikes. - **Maintain a redirect map** and update it the same day any URL changes. ## Frequently Asked Questions **Do redirects pass full ranking value to the new page?** A properly implemented 301 is treated as a strong signal for consolidating the old page's relevance and link authority into the destination. Rather than fixating on whether "100%" of value transfers, focus on the things you control: using 301s, keeping one hop, and matching destinations by relevance. Those choices preserve far more than any alternative. **How many redirects in a chain are too many?** One is the target. Two happens and isn't catastrophic, but should be fixed. Three or more is a real problem for both signal transfer and load time. The fix is always the same: point the first URL directly at the final destination. **Will redirecting a page hurt my rankings?** A well-executed redirect is designed to *protect* rankings through a URL change. What hurts rankings is the failure modes: temporary codes used for permanent changes, chains, homepage blanket redirects, and redirects pointed at dead or irrelevant pages. The redirect itself is the solution, not the problem. **How long until search engines process my redirects?** There's no fixed timeline — it depends on how quickly crawlers discover and revisit the old URLs. You can speed things up by updating internal links to point directly at the new URLs, submitting an updated sitemap, and requesting indexing of key new pages in Search Console. **I found 302s where I expected 301s. What do I do?** Change the code to 301 wherever the move is permanent. Most platforms, hosting panels, and redirect plugins let you set the code per rule. Then re-crawl to confirm. **Should I redirect a discontinued service page or just let it 404?** Redirect it to the closest related page — usually the parent service category or the nearest remaining service. A 404 (or 410) throws away all the page's accumulated signals; a relevant redirect keeps a portion of them working for you and keeps visitors who followed old links on your site. **Do I need redirects if I changed my domain?** Yes — every URL on the old domain should 301 to its corresponding URL on the new domain, page by page, not to the new homepage. Domain redirects also need to stay in place long-term, since old links across the web point at the old domain indefinitely. **What's the difference between a redirect and a canonical tag?** They solve different problems. A redirect is for a URL that no longer serves content — it sends visitors and crawlers somewhere else. A canonical tag is for pages that *do* exist and are similar — it tells search engines which version to prefer. If the old page is gone, you want a redirect. If both pages are live and overlapping, that's a canonical question. ## The Bottom Line Redirects are unglamorous, and that's exactly why they go wrong. Nobody notices a 302 that should be a 301. Nobody feels a three-hop chain load. Nobody sees the authority draining out of an old service page redirecting to a homepage that has nothing to do with it. The damage shows up months later as "our rankings just slowly dropped and we don't know why" — one of the most common and most preventable complaints in local SEO. The good news is that the discipline required is small: the right status code, one hop, a relevant destination, kept forever, documented as you go. Run a crawl today and see what's actually happening on your site — you may find a few quiet leaks worth fixing this week. Tools like [SEO Done's site auditing features](https://seodone.ai/features) surface redirect chains, temporary-code mistakes, and error spikes automatically, so leaks get caught while they're small. And if you want to go deeper on the broader picture, the guides in the [SEO Done blog](https://seodone.ai/blog) cover the rest of the local SEO stack. Your website's ranking strength took years to build. Redirects are how you keep it when things change. Explore SEO Done at https://seodone.ai