Redirect Maps Before Changing Service URLs

A website redesign often cleans up messy paths: /services.php?id=3 becomes /services/web-design, or three overlapping offer pages collapse into one clear service landing. That cleanup is good for visitors who land on the new structure. It is harmful for everyone still holding an old bookmark, a printed QR code, or a Google result that points at yesterday’s URL—unless you plan the redirects before the switch.

Google Search Central’s documentation on moving a site with URL changes treats a URL mapping as a required preparation step, not an afterthought. MDN’s guide to HTTP redirections explains the mechanism those mappings become: permanent 301 or 308 responses that tell browsers and crawlers the resource has a new location. Together they define a practical redesign discipline: inventory the old URLs, decide each destination, implement server-side permanent redirects, then monitor.

---

Why URL changes without a map break inquiries

Google’s site-move overview covers path changes as clearly as domain changes: moving from example.com/page.php?id=1 to example.com/widget, or renaming file extensions, is still a move that needs careful handling. During any significant change, rankings can fluctuate while Google recrawls and reindexes. For medium-sized sites, Google notes that it can take a few weeks or more before new URLs largely replace old ones in results—longer for larger sites.

Service firms feel that lag as missed calls. A past client bookmarked /commercial-cleaning. After launch, that URL returns 404 or lands on a generic home page that does not answer their question. Google Search Central explicitly warns against redirecting many old URLs to one irrelevant destination such as the new homepage: it confuses users and may be treated as a soft 404. Page-to-page mapping is more work; it is also the path that keeps intent intact.

MDN frames the same problem as “keeping links alive.” You control your own internal links; you do not control external ones. Redirects from old URLs to new ones preserve those inbound paths and the visitors they bring.

---

What a redirect map is

A redirect map is a deliberate list: each important old URL paired with the single best new URL that should replace it. Google’s preparation section walks through how to build that list—start with sitemaps and high-traffic URLs from analytics or server logs, include pages with inbound links from Search Console’s “Links to your site” data, pull a full inventory from the CMS, and do not forget images, videos, JavaScript, and CSS that also receive traffic or links.

Once the list exists, you decide destinations. One-to-one matches are ideal. When content is consolidated, several old service pages may correctly redirect to one new, stronger page. When content is retired, the old URL should return a proper 404 or 410 rather than a misleading soft success. The map is the artifact that makes those decisions reviewable before anyone flips a server switch.

A brief analogy: the map is a forwarding address book. The post office does not guess which apartment should receive last year’s mail; you supply the match. Guesswork—especially “send everything to reception”—is how packages go missing.

---

How permanent redirects should work

MDN sorts redirects into permanent and temporary families. Permanent responses (301 Moved Permanently, 308 Permanent Redirect) mean the original URL should no longer be used; crawlers update the resource’s address. Temporary codes (302, 303, 307) are for downtime or short-lived alternate locations and should not be how you retire a renamed service page.

Google’s redirects documentation aligns with that distinction. Permanent redirects signal that the target should be treated as canonical in search results; temporary redirects keep the source more likely to remain the result. For a redesign that intentionally retires old paths, Google recommends permanent server-side redirects—301 or 308—whenever they are technically possible. Client-side meta refresh or JavaScript location redirects are fallbacks with lower reliability for crawlers; MDN notes that HTTP redirects execute first and should be preferred when you control the server.

Method handling is the main difference between 301 and 308. MDN explains that some user agents historically change non-GET methods to GET after a 301; 308 was introduced so method and body stay unchanged. For typical service-site GET traffic from bookmarks and search results, either permanent code works; Google lists both as preferred permanent server-side options.

Google also stresses direct destinations. Googlebot can follow up to 10 hops in a redirect chain, but the guidance is to redirect straight to the final URL—or keep chains ideally no more than three and fewer than five. Chains add latency for people and fail in some clients. MDN adds a related performance note: even for internal links, fix the markup when you can; relying on redirects for every in-site click costs an extra round trip.

Step	What to decide	What Google / MDN emphasize
Inventory	Old URLs that still matter	Sitemaps, logs, CMS, inbound links, media assets
Map	Old → closest new equivalent	Avoid irrelevant homepage dumps; consolidate only when content truly merges
Implement	Server-side permanent redirects	Prefer 301/308; avoid long chains
Update	Canonicals, internal links, new sitemap	Self-referencing canonicals on new URLs; submit the new sitemap
Retain	How long redirects stay live	Google: generally at least 1 year; update high-volume external links when you can

---

Limits, monitoring, and common mistakes

Google states that 301 and other permanent redirects do not cause a loss in PageRank—an important reassurance, not a license to skip mapping quality. Rankings can still wobble while discovery catches up. Capacity matters too: after a migration Google may crawl the new site more heavily because old URLs redirect into it, so the new host needs enough headroom.

Keep redirects as long as possible—Google’s site-move guide says generally at least one year—so signals and external links have time to transfer. From a user’s perspective, indefinite retention is often reasonable; from a performance perspective, updating your own and high-volume third-party links to the new URLs still helps.

Common failures Google calls out in troubleshooting include leaving noindex or robots.txt blocks that were meant only for staging, pointing redirects at non-existent new paths, under-provisioned servers, and forgetting to refresh sitemaps. Test with Search Console’s URL Inspection tool for samples and with a crawler for bulk checks before declaring the redesign “done.”

MDN’s warning on redirect loops is the other hard stop: misconfigured rules that bounce between hosts or HTTP/HTTPS variants never resolve a page. Fix those before launch traffic arrives.

---

Practical takeaways for your next website

1. Build the map before launch day. List old service URLs and assign each a final destination while the redesign is still reviewable.
2. Prefer page-to-page permanent redirects. Use server-side 301 or 308 to the closest matching service page—not a blanket homepage redirect.
3. Update internal links and canonicals on the new site. Do not leave the new templates pointing at retired paths.
4. Submit a sitemap of new URLs and monitor both properties. Watch crawl errors, indexed URL counts, and inquiry traffic as old hits decline and new ones rise.
5. Leave the redirects in place for at least a year. Update high-traffic external links when owners will cooperate; keep the safety net for everyone else.

---

Ready to Discuss Your Website?

If you are planning a new website, a service redesign, or custom development for your business, we’re here to help shape the work—including URL mapping and redirect plans that protect existing inquiries when paths change.

• Explore Our Services: Web Design · Web Development · Website Redesign
• Start a Conversation: Tell us about your project via our Contact Form or email us directly at [email protected].