A redirect map records what should happen to each old website address after a redesign. The useful work is deciding where the visitor should go, what content must survive and how the team will verify the result.
This guide provides an original mapping method and a fictional six-row CSV. It covers the URL decision itself; use the broader SEO website redesign checklist for the full migration programme. No website has been crawled or migrated as part of this resource.
Check your redirect map
The checker processes pasted CSV in this browser. It does not upload the map, fetch its URLs, save it to local storage or change your website. Keep credentials and confidential notes out of the input. Other site analytics remain subject to your cookie choices.
Use the old site's HTTP or HTTPS origin to resolve paths beginning with /. Leave blank only when every URL is absolute. Use absolute destination URLs for a different domain.
Required columns: old_url, new_url, status, notes. Use 301 or 308 for redirects, 200 for an unchanged URL, and 404 or 410 with a blank destination for retirement. Maximum 5,000 data rows and 1 MB. Query strings and path case remain significant.
Paste a map or load the fictional example to begin. No URLs have been checked online.
Start with addresses people still use
Collect old URLs from the current site inventory, historical redirect rules and records of customer use. Ask the people maintaining campaigns, proposals and support materials which addresses they distribute. A QR code on a printed brochure can outlive the page that originally displayed it.
Google's site-move guidance includes URL mapping and specifically calls out images and downloads. Its suggested discovery sources include sitemaps, content-management records, links and usage records. Read Google's site-move guidance.
Keep one record per distinct old address. Decide how your project will handle hostnames, query parameters and trailing slashes before combining exports. Do not silently remove a parameter that identifies a product, language or required document. Put uncertain cases in a review queue with an owner.
Compare purpose before comparing slugs
For each old page, write one sentence explaining the visitor's task. Then open the proposed replacement and check whether that task can still be completed. Similar filenames, navigation labels or keywords do not establish equivalent content.
Suppose an old service page explains commercial equipment maintenance, but the new page with a matching slug only advertises equipment sales. That is a content gap, not an approved redirect. Ask the content owner to supply an appropriate destination or make a deliberate retirement decision.
| Decision | CSV values | Review question |
|---|---|---|
| Keep | status 200; new_url equals old_url. | Will the same address retain the required content and functionality? |
| Move | status 301 or 308; a different destination is required. | Does the destination fulfil the old purpose, and is the move intended to be permanent? |
| Retire | status 404 or 410; leave new_url blank. | Is removal intentional, with no appropriate replacement and an accountable owner? |
Google identifies 301 and 308 as permanent server-side redirects. The developer should choose the appropriate implementation for the host and request behaviour, rather than treating the CSV as executable configuration. See Google's redirect documentation.
For removed content, an error page must return the intended error status. A friendly "not found" message served with 200 is not the same thing. Google explains how successful and error responses affect processing and indexing. Read its HTTP status guidance.
Use the four columns as a decision record
Download the fictional redirect-map example
The header is old_url,new_url,status,notes. The example uses same-site paths. The status column expresses planned behaviour; it is not a response collected from a server. Use notes for the purpose, evidence reference, reviewer and unresolved decision. Keep credentials, private customer links and access tokens out of exported files.
The six fictional rows contain a direct page move, a PDF move, an unchanged contact page, an intentionally retired workshop and two deliberately incomplete consulting mappings. They are teaching data, not North Star routes or deployment-ready rules.
The last pair sends /old-consulting/ to /interim-consulting/, while the latter is also marked for redirection but has no destination. There are two separate review findings: a chain relationship and a missing target. Supplying a final destination requires a content decision. Do not invent one just to make a structural warning disappear.
Once a suitable final page is approved, revise the affected rows to reach it directly. Google advises avoiding redirect chains and warns against sending unrelated old pages to a common destination such as the homepage. See its migration checks.
Give old documents their own decisions
Inventory PDFs, product sheets, images and other downloads separately from the pages that link to them. A replacement web page may not satisfy someone who needs a specific manual or an approved specification. For Canadian businesses maintaining English and French material, preserve the intended language and document purpose in the review.
Check whether a dated document is supposed to remain an archive. A newer edition is not automatically an equivalent replacement for an older agreement or specification. Record who approved the keep, replace or retire decision. Check references inside documents and printed materials as well as website links.
Separate file review from release evidence
A CSV-only review can identify inconsistent entries and relationships in the supplied rows. It cannot confirm that a destination exists, inspect its content, observe an HTTP status, test canonical tags or prove that a live redirect works. A clean file is still a proposal.
- Approve: resolve missing destinations and content questions; name the business approver and technical owner.
- Prepare: save the previous routing configuration and deployment reference; agree a change window and rollback authority.
- Implement: have the developer translate the approved decisions into the host's routing rules and check rule precedence.
- Verify separately: test the actual old addresses, destinations, downloads and user tasks against the intended behaviour.
- Recheck: inspect the public host after release and again after relevant platform changes; record failures and their owners.
Agree what would pause the release before starting: an important document disappearing, a quote route failing or a broad rule redirecting unrelated pages. A rollback decision should identify which configuration to restore and how its behaviour will be checked. Do not assume reverting an application deploy also restores separate routing settings.
Keep the approved map, change reference and observed results together. An HTTP success response does not guarantee indexing, rankings or business results. Use the website migration checklist and launch checklist for the surrounding work. For help resolving content and routing decisions, see website design services or contact North Star.