Website Redirect Map: What to Include Before URLs Change

A website redirect map is the finished list you complete before any address changes: each old URL, the new URL that should replace it, and a one-hop 301. Google's site-move documentation puts that mapping ahead of the moment you configure the server to send visitors from the old addresses to the new ones [1]. The map is not a sitemap, not a set of spot checks after launch, and not a question of who controls the domain. It is the record of where each current address goes, written while those addresses still answer as themselves.

What the map is, and what it is not

A redirect tells a browser or a crawler that a page has a new location. People rarely notice which status code did the work. Search systems do. Google's redirects documentation says a permanent redirect is the kind that can show the new target in search results, and a temporary redirect is the kind that can keep showing the source page [2]. For a permanent address change, the status we record is a server-side 301. That documentation describes both 301 and 308 as codes that mean the page has permanently moved [2].

Order matters more than the file format. Google's guide for changing URLs says to prepare a URL mapping from the current URLs to the new format, and only then start the move by configuring redirects from the old URLs to the new ones [1]. Once the old addresses start responding with redirects, bookmarks, ads, and links on other sites follow whatever you published. The website redirect map is the decision list you finish first.

A sitemap is a different file. Google describes it as a place where you provide information about the pages, videos, and other files on your site, including which ones you consider important and details such as when a page was last updated [6]. It does not pair an old URL with a new one, and it does not name a status code. During a move, Google does say to save a sitemap of the new URLs that came out of the mapping, because submitting a sitemap can help discovery [1]. That sitemap is an output of the map. Keep it separate so nobody pastes redirect rules into it.

Which old URLs belong on it

Google draws a line between a pattern and a list. If you are only changing the domain and every path stays the same, a wildcard server-side redirect can cover the move, and you may not need a generated row for every old URL [1]. Write the pattern down anyway: old host, new host, permanent status, one hop.

Path changes need rows. Google's examples of a URL change include HTTP to HTTPS, a domain or hostname change, and a path change such as a script-style URL becoming a clean path [1]. If more than the host is changing, do not assume one pattern still fits. When new paths come from a rebuild, including a web design project, finish the rows for the old paths before those new paths replace them.

Start with URLs that already matter. The guide says to look in your sitemaps, check server logs or analytics for the URLs that get the most traffic, and check pages that have internal and external links [1]. A content system can usually list the URLs that host content, and server logs can show URLs visited at least once in a recent period [1]. Pick that period with seasonal traffic in mind [1].

Do not stop at HTML pages. Include videos, images, JavaScript, and CSS files, and move them the same way as the rest of the site [1]. Downloads you host, such as PDF files, belong on the list too, because they may already receive visits or links [1]. Treat lookalike addresses as different rows when both are requested. `http` and `https`, a `www` host and a bare host, a trailing slash and no trailing slash, and `index.html` versus the directory are different URLs. If the logs show both, both point at the single new URL you intend to keep.

The three fields on every permanent row

Every permanent row needs three fields before anything is switched.

The old URL is the address that will actually be requested: scheme, host, path, and query string when one is in use. A rule written for the path alone can miss the version that still receives visits.

The new URL is the final address, not a stepping stone. Google advises redirecting to the final destination directly. Crawlers can follow up to 10 hops in a chain, but the guide says to avoid chains, and if a chain cannot be avoided, to keep it low, ideally no more than 3 and fewer than 5, because chains add latency and not every user agent supports a long one [1]. Google's crawler documentation states the same limit: by default, crawlers follow up to 10 redirect hops, content from the redirecting URL is ignored, and the final target's content is what gets processed [3]. If an old URL already redirects somewhere, the new row replaces that path with one hop to the final new URL.

The status for a normal permanent move is a server-side 301. Google recommends HTTP permanent redirects when they are possible, and it names 301 and 308 [1]. Client-side redirects are a last resort when no server-side setup exists [1]. Use a JavaScript redirect only when you cannot do a server-side redirect or a meta refresh, because rendering can fail and Google might never see the script [2].

The code is also a promise about the response header. RFC 9110, published in June 2022, says a 301 means the target resource has been assigned a new permanent URI and future references ought to use one of the enclosed URIs [4]. The server should send a Location header with a preferred URI reference for that new URI [4]. For a 3xx response, Location is a single URI reference and the preferred target for the automatic redirect [4]. Write that value in absolute form. A relative Location is resolved against the target URI of the request, which can keep the visitor on the old host when you meant the new one [4]. If Location has no fragment, the user agent must treat the redirect as if it inherited the fragment from the original reference [4]. Leave the fragment off unless the new page has that anchor.

When a row should not be a 301

A 301 is the default because the address change is permanent. It is the wrong code for a temporary move, for a POST that must keep its method, or for a page with no replacement.

RFC 9110 defines 302 as a temporary residence under a different URI [4]. The client ought to keep using the original URI for later requests, because the redirection might change [4]. Google's redirects guide says a temporary redirect shows the source page in search results, which can help keep the old URL there [2]. A 302 is a weak signal that the target should be processed, and 307 is equivalent to 302 [3]. Use 302 or 307 only when you expect to restore the old address [4]. Put the date you expect to restore it on the row.

Permanent codes split on the request method. For historical reasons, a user agent may change POST to GET on the request that follows a 301 [4]. If you do not want that, RFC 9110 says to use 308 [4]. A 308 also means a new permanent URI, and the user agent must not change the method on an automatic redirect [4]. Google treats 308 as equivalent to 301 for its own processing, while noting the codes are still semantically different [3]. The June 2022 standard notes that 308 is much younger (June 2014) and might not be recognized everywhere [4]. For ordinary pages opened with GET, we record a one-hop 301. For a form whose POST must survive, mark the row 308 and say why.

Some old URLs should not redirect. If you are not bringing the content across, Google says those URLs should return 404 or 410 [1]. A 404 means the server did not find a current representation, or will not say that one exists, and it does not by itself say whether the gap is temporary or permanent [4]. Prefer 410 when the absence is likely permanent, and use 404 when you do not know [4]. A 410 tells recipients the resource is intentionally unavailable and that remote links to it should be removed [4]. Google does not index URLs that return a 4xx status code, and URLs already indexed are removed from the index when they return one [3]. If the page is gone and nothing similar replaces it, return 404 or 410 [5].

Do not point many old URLs at one irrelevant destination, such as the new home page. Google says that can confuse users and might be treated as a soft 404 [1]. A soft 404 is a URL that tells the user the page does not exist, or that has no main content, while also returning 200 [5]. Those pages are excluded from Search [5]. Consolidation is the exception. If several old pages were combined into one new page, you can redirect the older URLs to that new page [1]. Mark the rows "consolidated" and name the page that holds the content.

A permanent redirect is not, by itself, a loss of link credit. Google's site-move guide says a 301 and other permanent redirects do not cause a loss in PageRank [1]. That is not permission to aim unrelated URLs at a popular page. Choose the same content at a new address, a real consolidation, or an honest 404 or 410 [1].

Extra columns that keep the list usable

Three fields are what the server needs. A few more columns keep the list readable months later, and they should be filled before the addresses change.

Note where the old URL came from: sitemap, content system, logs, analytics, or a page other sites link to. That is the set of places Google tells you to look [1]. When sources disagree, show both. A URL in the logs but missing from the content system is often an old campaign path. It still needs a decision.

Add a coarse traffic note from logs or analytics, using the same seasonal window as the URL list, so "high" still means something later [1]. Add content type (page, image, video, script, stylesheet, or download) so embedded files are not skipped [1]. Add a short disposition: same page at a new address, consolidated into a named page, removed with 404 or 410, or temporary with 302 or 307 and a restore date [4]. If you cannot write the disposition, the row is not ready.

Record the canonical URL you want on the new page, and internal links that still point at the old one. Each new URL should have a self-referencing canonical link, and internal links should change from old URLs to new ones using the mapping [1]. If you use hreflang, update those annotations to the new URLs [1]. If you do not, leave that column blank. Redirects are slow for users, so the same list is how you update your own links, and high-volume links from other sites, instead of sending every click through a hop [1].

Record retention. Keep redirects for as long as possible, generally at least 1 year, so signals can move to the new URLs, including links on other sites that still point at the old ones [1]. Consider keeping them indefinitely for users [1]. A redirect file with no owner and no keep-until date is the one that gets deleted in a cleanup.

Finish the map before the addresses change

Preparing the mapping comes before starting the move. The start is when you turn the redirects on [1]. Change only one thing at a time. A new domain, a new content system, and a new layout should be sequenced, not done together [1]. For a small or medium site, Google recommends moving the URLs together. A large site can move one section at a time so problems are easier to see [1]. The rows in that scope should be complete. A partial map is fine only when you have named what moves now and what stays. It is not a reason to turn on a catch-all.

Name the server-side mechanism, or say it is not available yet. Check which server-side redirects the host can run, such as rules on an Apache server or functions in the content system [1]. If the platform cannot send a real 301, write the method it can send. Google treats an instant meta refresh as permanent and a delayed meta refresh as temporary [2]. Do not label a meta refresh as a 301.

There is a caching reason to settle the rows first. A 301 is heuristically cacheable unless cache controls say otherwise, and the same is true of a 308 [4]. A wrong permanent redirect can stick with clients that stored it. Fixing the map after that is harder than writing the final URL now.

What you can finish before any address changes is the list: old URL, final new URL, one hop, the real status code, and a disposition that is a true replacement or an honest 404 or 410 [1]. Turning rules on and watching traffic are later work. They go better when nobody has to guess the target.

Practical takeaways

• Finish the website redirect map before any address changes. Each permanent move is an old URL, a final new URL, and a one-hop 301.
• Include pages, images, videos, scripts, stylesheets, and downloads that people or crawlers already request, including host and scheme variants that show up in logs.
• Use 302 or 307 only for a temporary move [4]. Use 308 when a POST must keep its method [4]. Use 404 or 410 when there is no replacement, and do not send unrelated URLs to the home page [1].
• Add the source of each old URL, a coarse traffic note, a disposition, the new canonical, internal links to update, and how long the redirect must stay.
• If only the host changes, one written pattern can be the whole map. If paths change, use one row per old URL.

How we can help

Have more questions or want to get in touch? If a new address structure is coming, our team can help you assemble the old-to-new list before anything moves. Reach us on the contact page.

Citations

1. Google Search Central, "How to move a site" (2026-08-20)
2. Google Search Central, "Redirects and Google Search" (2026-04-14)
3. Google Crawling Infrastructure, "How HTTP status codes affect Google's crawlers" (2026-02-04)
4. IETF, "RFC 9110: HTTP Semantics" (2022-06)
5. Google Search Central, "Troubleshoot Google Search crawling errors" (2025-12-18)
6. Google Search Central, "Learn about sitemaps" (2025-12-10)