How to Build and Test a Complete 301 Redirect Map

A redirect map is the migration source of truth: every known public URL receives an explicit, evidence-led decision before launch. That may be “keep the same URL at 200,” “move permanently to a genuine replacement,” “return a real 404/410,” or “hold for investigation”—with implementation and test evidence recorded separately.

A 301 redirect map: the short answer

A redirect map is the migration control record for every old public URL. It does not mean every row receives a 301. Each URL receives an evidence-based outcome: keep the same address and return 200, move permanently to a genuine replacement, remain temporarily elsewhere, return a real 404 or 410, or be investigated before launch. The map must also record the final destination, content and metadata action, owner, test result, and post-launch evidence.

Decision	HTTP outcome	When it is correct
Keep	`200`	The preferred public URL and page purpose remain valid
Move permanently	`301` / `308`	A true replacement exists at a new URL
Move temporarily	`302` / `307`	The source should remain the long-term preferred URL
Remove	`404` / `410`	The content is gone and no relevant replacement exists
Hold for investigation	No release yet	Ownership, replacement, traffic, links, policy, or status is unclear

First identify the kind of migration

Change	Do public URLs change?	Redirect-map role
Hosting or CDN move only	No	Record status parity and legacy redirect preservation; do not invent URL moves
CMS, framework, or design change	Maybe	Keep existing paths where possible; map only genuine changes
HTTP to HTTPS or hostname normalization	Yes, by protocol or host	Use predictable rules and verify every valuable path reaches the same final resource
Path or information-architecture change	Yes	Create explicit old-to-new decisions before launch
Domain, subdomain, merge, or split	Yes	Map every important URL and coordinate properties, links, sitemaps, and monitoring

Do not combine a domain move, new CMS, redesign, new content strategy, and unnecessary URL cleanup simply because they share a launch date. Google recommends changing one major dimension at a time where practical. Separating change types makes failures easier to diagnose and rollback.

Freeze the migration scope and ownership

Control	Decision required
Launch boundary	Domains, subdomains, directories, locales, platforms, assets, and environments included
Source-of-truth file	One controlled map, unique URL key, version, date, owner, and approval state
Change control	Who can add, edit, approve, implement, test, or roll back a row
Release gate	What must be complete before redirects or DNS are changed
Communication	Who receives launch notices, incidents, decisions, and evidence

Build the old-URL inventory from multiple sources

Source	URLs it can reveal	Limit
CMS or database export	Published, draft, private, attachment, taxonomies, custom types	May omit routes created by code, plugins, or the server
XML sitemaps	URLs previously declared for discovery and indexing	May be stale, incomplete, or include only preferred URLs
Full crawl	Linked pages, assets, status codes, Canonicals, metadata, alternates	Cannot find unlinked or inaccessible URLs by itself
Search Console	Indexed, crawled, linked, sitemap, and performance URLs	Reports are sampled, delayed, grouped, and not a complete inventory
Analytics and conversion systems	Visited landing pages, campaigns, conversions, and historical journeys	Untracked, blocked, or zero-visit URLs will be absent
Server and CDN logs	Real requests from users, bots, apps, and legacy links	Retention, bot verification, privacy, and access vary
Backlink and mention tools	Linked pages, media, PDFs, old campaign URLs	Every provider has a different and incomplete index
Ads, email, social, QR, apps, and business profiles	Destinations outside the organic-search inventory	Often owned by separate teams and accounts

No single export is the complete website. Merge the sources, preserve their provenance, and investigate disagreements rather than letting the latest crawl overwrite history.

Normalize URLs without losing evidence

Normalization workflow

Store the raw discovered URL exactly as found.
Parse scheme, host, port, path, query, fragment, and encoding separately.
Create a normalized comparison key using documented hostname, case, slash, and parameter rules.
Keep fragments for link QA even though they are not sent in the HTTP request.
Do not drop parameters until their function, traffic, links, campaigns, and duplicate behavior are understood.
Deduplicate only after retaining all source, performance, backlink, and ownership evidence.

Use a decision-ready redirect-map schema

Field group	Required columns
Identity	Unique row ID, raw old URL, normalized old URL, source systems, page type, locale
Evidence	Current status, indexability, canonical, traffic, conversions, backlinks, internal links, owner
Decision	Keep, redirect, remove, merge, investigate; reason; approver; approval date
Destination	Proposed URL, expected status, final URL, destination status, destination canonical, relevance proof
Content and SEO	Title, description, H1, content, media, schema, hreflang, metadata, date, internal-link action
Implementation	Rule owner, platform, pattern or explicit rule, release, dependency, rollback
Testing	First response, hops, final status, final canonical, body relevance, mobile, locale, test date, tester
Monitoring	Launch response, Google-selected canonical, clicks, errors, log activity, incident, next review

Keep decisions separate from implementation state

Dimension	Example values	Why separate it
Approved outcome	KEEP, REDIRECT, REMOVE, HOLD	Represents the business and SEO decision
Implementation state	NOT_STARTED, BUILT, STAGED, LIVE, ROLLED_BACK	Shows what has actually happened
Test result	NOT_TESTED, PASS, FAIL, BLOCKED	Prevents “configured” from being mistaken for “working”
Post-launch status	HEALTHY, WATCH, INCIDENT, RESOLVED	Preserves monitoring and incident history

Prioritize risk without deleting the long tail

Priority evidence	Why it matters
Revenue, qualified leads, or assisted conversions	Protects commercially useful journeys
Search clicks, impressions, and indexed history	Identifies established organic entry points
Relevant external links and referral traffic	Protects discovery, trust, and visits from outside the site
Navigation, internal links, and campaign dependence	Reveals URLs embedded in important journeys
Legal, support, account, checkout, or product function	A low-traffic URL may still be operationally critical
Unknown but repeatedly requested legacy URL	Logs may reveal value that current reports missed

Priority determines review order and monitoring depth, not whether a URL deserves a decision. Every known public URL still needs an explicit outcome.

Keep valuable URLs unchanged whenever possible

A redesign does not require new slugs. If the audience task, preferred address, language, and ownership remain valid, keep the URL and record 200 KEEP. Then compare the old and new page through the controls in Canonical URLs and redirects and SEO site architecture.

A KEEP row still requires parity checks

HTTP status, indexability, preferred hostname, and self-Canonical.
Title, description, H1, primary content, media, dates, and structured data.
Internal links, breadcrumbs, pagination, related content, and navigation.
Hreflang, language switcher, Open Graph, feeds, sitemaps, and API references.
Forms, conversions, consent, analytics, ads, and third-party integrations.

Use a permanent redirect only for a genuine replacement

Replacement test	Question
Audience	Would the same visitor reasonably want the destination?
Task and intent	Does it complete the same job or provide the nearest complete substitute?
Subject and scope	Does it cover the essential topic, product, service, location, or policy?
Language and market	Is it appropriate for the same locale and commercial availability?
Evidence and next action	Can the user verify the same claim and continue the journey?

A similar keyword is not enough. Record a short relevance explanation in the map so an approver can challenge weak matches before code is written.

Consolidate only when one destination can own the combined task

Consolidation pattern	Safe when	Unsafe when
Several overlapping articles to one guide	The guide preserves the useful questions, evidence, and internal journey	The target is a generic category or loses distinctive value
Old service pages to a redesigned service owner	The offer, audience, location, and next action remain equivalent	Different services are forced into a broad overview
Legacy category to a maintained hub	The hub genuinely helps users discover the migrated resources	The hub is empty, noindex, or unrelated

Choose permanent and temporary status codes deliberately

Code	Meaning for the migration	Use
`301`	Moved permanently	Preferred server-side choice for most permanent URL moves
`308`	Moved permanently while preserving the request method	Useful where platform behavior and non-GET requests require it
`302`	Found; temporary move	Source should remain the long-term preferred URL
`307`	Temporary move while preserving the request method	Temporary routing where request-method handling matters

Google treats server-side 301 and 308 as permanent redirect signals. Use a temporary redirect only when the source truly remains the intended long-term URL. Do not switch codes to chase an assumed ranking advantage.

Use real 404 or 410 responses when nothing replaces the page

Outcome	Correct situation	User experience
`404 Not Found`	The resource is unavailable and no relevant replacement exists	A branded helpful error page with real 404 status
`410 Gone`	The owner intentionally removed the resource and wants to state it is gone	A clear explanation and useful navigation with real 410 status
Relevant 301	A replacement genuinely serves the same user need	Immediate arrival at the final useful destination

Google recommends 404 or 410 when content is removed and no similar replacement exists. The custom error design may contain helpful navigation, but the server response must still communicate failure. A friendly page returning 200 is a soft 404, not a successful migration.

Do not send every retired URL to the homepage

Old URL	Better decision
Old About page	Redirect to the current About page if it is the true replacement
Discontinued product with a direct successor	Redirect only if the successor genuinely satisfies the same need; explain the change
Expired event with an evergreen event hub	Keep an archive or redirect when the hub preserves the expected task
Removed article with no useful substitute	Return 404 or 410 rather than an irrelevant homepage redirect

Use patterns only when the transformation is provably consistent

Rule type	Suitable case	Control
Exact one-to-one rule	High-value, exceptional, merged, renamed, or irregular URLs	Explicit source and final target in the map
Pattern rule	A stable transformation such as old host to new host with unchanged paths	Enumerate matched URLs and test exclusions before release
Fallback rule	Rarely justified	Never let it hide unmapped URLs or create homepage soft 404s

Pattern-rule safety test

List all known URLs the rule will match.
List protected exceptions and higher-priority exact rules.
Test encoded characters, uppercase, trailing slash, parameters, files, and locale paths.
Prove that the generated target exists and is relevant for every matched source.
Prevent the rule from redirecting the destination back into itself.

Redirect directly to the final destination

Failure	Example	Correction
Chain	`A → B → C`	`A → C`
Protocol and host chain	`http → https → www → final`	Combine normalization when the platform safely supports it
Loop	`A → B → A`	Fix rule precedence and exclude final targets
Redirect to error	`A → B (404)`	Repair or choose a valid relevant destination
Redirect to another redirecting parameter variant	`A → B?x=1 → B`	Point to the final canonical URL unless the parameter is required

Googlebot can follow redirect chains, but Google advises pointing to the final destination directly and keeping unavoidable chains low. Every extra hop adds latency and another failure point for users, crawlers, campaigns, applications, and analytics.

Handle protocols, hosts, ports, slashes, files, and parameters explicitly

URL dimension	Migration decision
HTTP and HTTPS	Choose the secure preferred version and preserve certificates on redirecting hosts
www and non-www	Choose one public host and send every path directly to its equivalent
Default ports and staging hosts	Keep them out of public Canonicals, links, sitemaps, and indexing
Trailing slash and index.html	Choose one final convention; avoid creating chains for every request
Case and encoding	Preserve or normalize according to server behavior and real URL ownership
Query parameters	Keep required function and campaign data; remove duplicate or obsolete parameters only with evidence
Images, PDFs, and downloads	Map important indexed or linked assets to real replacements

Update all canonicalization signals together

Destination signal alignment

The old URL returns the approved permanent redirect directly to the final URL.
The final URL returns 200 and is not blocked or noindex.
The final page has a self-referential Canonical using the preferred protocol, host, path, and locale.
Internal links, breadcrumbs, navigation, and feeds use the final URL.
The current sitemap lists the final indexable URL rather than the redirecting source.
Structured data, Open Graph, API references, and campaign destinations use the intended final URL.

Rebuild multilingual mappings as complete clusters

When any URL in a language cluster changes, update self-Canonicals, reciprocal hreflang, language switchers, internal links, and sitemap alternates for every member. Never redirect Malay or Chinese pages to English merely because a translation was missed. Use the locale controls in multilingual SEO for Malaysia.

Preserve content and metadata, not only addresses

Layer	Compare before approval
Purpose and visible content	Audience task, primary answer, service or product scope, proof, FAQs, CTA
Search presentation	Title, description, H1, image, publication and modified dates
Index control	Status, robots, Canonical, hreflang, pagination, sitemap inclusion
Meaning and entities	Structured data, author, organization, product, service, location, identifiers
Media and files	Image URLs, alt text, captions, video, PDFs, downloads, ownership and rights
Journeys and measurement	Internal links, forms, WhatsApp, phone, checkout, consent, analytics and events

Protect staging without copying the block to production

Staging control	Launch risk
Authentication or network restriction	Can block external QA tools; production must not inherit it
Noindex on test pages	Must be removed from indexable production templates
Disallow in staging robots.txt	Robots blocking prevents crawlers from seeing page-level noindex and must not replace production rules
Temporary hostname	Must not appear in Canonicals, hreflang, structured data, feeds, or sitemaps after launch

Test two views of every redirect

Test view	What it proves
Do not follow redirects	The first response has the expected status and Location header
Follow the complete journey	The destination, hop count, final status, Canonical, language, content, and functionality are correct

Automated row test

Request the exact old URL without automatically following.
Compare actual first status and Location with the approved row.
Follow with a bounded hop limit and detect loops.
Confirm the final URL, status, content type, locale, Canonical, robots, and meaningful body.
Store timestamp, environment, tester or script version, and evidence.
Fail the release on loops, unexpected chains, irrelevant destinations, 5xx, or blocked critical pages.

Run representative journey tests, not status checks alone

Journey	What to verify
Search landing page	Old result reaches the right final page, answer, language, and CTA
Navigation and breadcrumbs	No link depends on a redirect and hierarchy remains coherent
Form, WhatsApp, call, booking, or checkout	Conversion works and source/campaign/language context is retained
Images, PDF, feed, app, and API consumer	Assets resolve, content types are correct, and clients do not break
404 and removed content	Real error status, helpful interface, no accidental indexable soft 404

Choose rollout strategy according to risk and size

Situation	Practical approach
Small or medium site with one coordinated move	Google generally recommends moving the URLs together after complete preparation
Very large site or high operational risk	Pilot a stable section, learn, then roll out in controlled groups
Hosting move without visible URL changes	Focus on infrastructure parity, crawl access, capacity, TLS, DNS, and legacy redirects
Domain move plus redesign desired	Separate changes where possible so Search and incident signals are interpretable

Use Change of Address only for qualifying domain moves

Move	Use Search Console Change of Address?
example.com to example.net	Yes, after redirects and verification are ready
a.example.com to b.example.com	Yes, for the verified domain/subdomain move
HTTP to HTTPS only	No
www to non-www on the same domain	No
Moving paths within the same domain	No
Hosting or CDN change without public URL changes	No

Verify the relevant old and new properties with the same account, preserve verification files or tags, and review manual actions, removals, settings, and legacy controls before a domain move. The tool supplements correct redirects; it does not replace them.

Use a controlled launch sequence

Launch order

Freeze the approved map, backup configuration and content, and name the release owner.
Deploy final pages, assets, certificates, robots rules, analytics, and verification controls.
Remove staging-only noindex, access blocks, and temporary hosts from production output.
Enable approved redirects and immediately run the automated old-URL list.
Validate key journeys, final Canonicals, hreflang, structured data, internal links, and sitemaps.
Submit or update sitemaps; use Change of Address only when the move qualifies.
Record the release time, evidence, known exceptions, and rollback decision window.

Monitor both old and new URLs after launch

Window	Primary checks
First minutes and hours	Availability, TLS, DNS, 5xx, loops, key redirects, forms, analytics, robots, noindex
First days	Full mapped-list recrawl, logs, 404/410, unexpected chains, sitemap processing, URL Inspection samples
First weeks	Old-versus-new Search Console coverage and performance, selected Canonicals, traffic, conversions, backlinks and referral errors
Following months	Signal transfer, lingering old URLs, seasonal comparison, content quality, redirect demand, domain and certificate renewal

Temporary visibility fluctuation can occur while Google recrawls and processes a move. That does not justify ignoring errors or promising a recovery date. Segment by page group and diagnose technical, content, demand, tracking, and business changes separately.

Define incident triggers and rollback boundaries before launch

Incident signal	Immediate response
Critical pages return 5xx, loop, block, or noindex	Stop the release path, restore access or the last known good configuration, and retest
Large unmapped or irrelevant redirect cohort	Disable the faulty rule, preserve exact exceptions, correct the map, and redeploy
Tracking or conversions fail	Restore the customer path first; mark reporting gaps and avoid false performance conclusions
Google selects unexpected Canonicals	Compare status, content, internal links, sitemap, redirects, locale, and Canonical signals as one system

Use business-specific thresholds based on normal error rates, traffic, conversion volume, and critical journeys. There is no universal percentage drop that proves a migration failed.

Keep redirects long enough and maintain the old infrastructure

Google recommends keeping site-move redirects for as long as possible and generally at least one year so signals and links can be reassigned as URLs are recrawled. From a user perspective, useful redirects may deserve indefinite retention. Keep old domains, DNS, certificates, and redirect hosting operational while requests still arrive, and update internal and high-control external links to reduce dependence on redirects.

A verified SEOWithJack migration example

The SEOWithJack WordPress-to-static migration uses a 53-row status map rather than a blanket redirect rule. The current automated preservation audit verifies 27 original article URLs: 26 remain matched at their original paths and one older SEO URL redirects permanently to its consolidated beginner guide. It also retains the source Rank Math evidence, tests 301, 404 and 410 decisions, and keeps production DNS outside the migration step until staging and host checks are approved.

Verified control	Current evidence
Redirect-map rows	53
Original article URLs preserved	27
Original article paths matched directly	26
Original article consolidated through permanent redirect	1
Production DNS changed by the build	No

A compact row template you can copy

Old URL	Decision	Destination	Why	Expected	Actual	Owner
/old-service/	REDIRECT	/services/current/	Same service and audience task	301 → 200	Pending test	SEO + Dev
/useful-guide/	KEEP	/useful-guide/	Stable preferred URL	200	Pending parity check	Content
/obsolete-no-replacement/	REMOVE	—	No useful substitute	410	Pending test	SEO
/unknown-legacy/	HOLD	—	Needs log and backlink review	No release	Open	Owner needed

Final release gate

Do not launch until

Every known public old URL has one approved outcome or an explicit blocked state.
All permanent redirects point directly to relevant final 200 URLs.
Removed pages return real 404 or 410 status rather than homepage or soft-404 responses.
Canonical, robots, hreflang, links, sitemaps, schema, metadata, media, and conversions pass comparison.
Staging controls cannot leak into production and production hosts cannot leak into staging evidence.
Automated list tests and representative user journeys pass in the release environment.
Monitoring, incident ownership, backup, and rollback decisions are ready.

What a redirect map cannot guarantee

A complete map cannot guarantee unchanged rankings, traffic, indexing speed, conversion rate, or a fixed recovery date. Google processes moves per URL and temporary fluctuation is normal. A redirect is one canonicalization signal; content, internal links, crawl access, sitemaps, site quality, demand, competition, platform behavior, and business operations still matter. The responsible promise is controlled implementation, verified evidence, rapid diagnosis, and documented decisions.

301 redirect map FAQ

Does every old URL need a 301?

No. Every known public URL needs a decision, not necessarily a redirect. Keep valid URLs at 200, redirect genuine moves, return 404 or 410 when no relevant replacement exists, and hold unclear cases for investigation.

Are 301 and 308 both permanent?

Yes. Google treats both as permanent redirect signals. A 308 also preserves the request method. Choose according to platform and application requirements, not a ranking myth.

Should removed pages redirect to the homepage?

Only in the rare case that the homepage truly replaces the same task. Google warns that redirecting many unrelated old URLs to one page can confuse users and may be treated as soft 404s. Use a relevant replacement or a real 404/410.

Is 404 worse than an irrelevant 301?

No. When no useful replacement exists, a real 404 or 410 is the honest technical outcome. An irrelevant redirect damages the user journey and can be interpreted as a soft 404.

Should I change URLs during a redesign?

Not unless the existing address or architecture has a genuine user, business, security, or maintenance problem. Preserving valid URLs removes migration risk and lets the redesign focus on the experience.

Can I create redirects with JavaScript?

Google can process some client-side redirects, but recommends server-side permanent redirects when possible. JavaScript adds rendering and failure dependencies and should be a fallback, not the default migration method.

How many redirect hops are acceptable?

Design for one: old URL directly to the final destination. Google can follow chains and advises keeping unavoidable ones low, but a crawler limit is not a performance target.

How long should redirects remain?

Google recommends keeping site-move redirects as long as possible and generally at least one year. Keep useful redirects longer while people, bots, links, campaigns, or applications still request the old URLs.

When should I use Search Console Change of Address?

Use it after redirects are ready for a qualifying move from one domain or subdomain to another. Do not use it for HTTP-to-HTTPS, www normalization, same-domain path changes, or a hosting move with unchanged public URLs.

How do I know the migration is complete?

There is no single instant. Confirm old requests reach approved outcomes, final pages are healthy and selected appropriately, Search Console and logs show expected transfer, key journeys convert, incidents are resolved, and redirect infrastructure remains maintained.

Official references

Planning a redesign or migration?

Share the old website and proposed structure before URLs are changed. Redirect planning is easier before launch than after traffic starts falling.

Discuss the migration on WhatsApp