Guide Website migration · 2 of 7
How to Create a URL Inventory Before a Website Migration
Build a website migration URL inventory from multiple sources. Record status, evidence, owners, and gaps before choosing destinations or testing redirects.
Key takeaways
- Combine more than one source of existing URLs.
- Keep the original address and its discovery source.
- Separate observed status from future decisions.
- Assign owners and record gaps before mapping destinations.
A website migration URL inventory is a record of the addresses and assets your team must account for before a move. Build it from more than one source, keep the evidence for each row, and assign someone to resolve gaps. Finish the list before you approve new destinations.
The website migration SEO guide covers the whole move. This article has a narrower deliverable: a usable list of what exists, how it was found, and who will review it. It does not choose replacement pages or test redirect rules.
Define what belongs in your website migration URL inventory
Write a scope note at the top of the file. Name the domains, sections, languages, and asset types included. Add the date of the snapshot. If the move concerns only the blog, say whether its images and downloads are included too.
List what is outside the current review and why. A separate shop may belong to another team. A retired subdomain may still need an owner. An explicit gap is easier to resolve than a blank space everyone assumes someone else covered.
Use one main record for the team. Separate tabs can hold source exports, but reviewers should not have to guess which of five spreadsheets is current. Name the file owner and agree on how changes will be recorded.
Collect URLs from sources that see different parts of the site
Google’s site-move guidance identifies several useful sources: sitemaps, the CMS, logs or analytics, and link records. It also calls out assets. Combine what your team can access rather than treating one export as a full picture.
A crawl shows what the tool reached under its settings. A CMS export shows records in that system. Neither proves that every older public address was found. Keep a source label so a reviewer can explain where a row came from.
Ask the business for important URLs used in emails, printed materials, support replies, and customer bookmarks. Record those as supplied leads until checked. A page that matters to customers may not appear in the latest list of top visits.
Save the date range and filters for each data export. “No clicks” over a short period is not the same as “never used.” The SEO metrics guide explains how to read search evidence; here, use it to add context to the list.
Keep raw addresses before cleaning the working list
Preserve the raw exports in a read-only copy for reference. In the working file, add a stable row ID and a full address. This gives reviewers a way to refer to an item even if the notes or future plan change.
Group exact duplicates without losing their source labels. Avoid making silent changes to case, query strings, or trailing slashes. If two addresses look similar, record that relationship and ask the technical owner whether they behave the same way.
Keep separate fields for the requested address and the address reached during a check. An old campaign link can still matter even when it already sends visitors elsewhere. Do not replace it in the record with only the final page.
Use columns that separate facts from decisions
Flag pages with no proposed match for a separate keep, combine, rebuild, or retire decision. Do not remove them from the list by default.
A small file can start with the fields below. Add detail only when someone needs it for a decision or test. A large set of empty columns can hide the few gaps that block the handoff.
| Field | What to record |
|---|---|
| Row ID and original URL | A stable reference and the full source address. |
| Type and purpose | Article, service page, image, download, or other useful role. |
| Source and date | Where the item was found and when the record was made. |
| Observed response | What happened when checked, plus the check date. |
| Evidence and limits | Known use, business need, links, or missing data. |
| Owner and review state | Who resolves the row and what remains open. |
Reserve space for a later destination decision, but do not fill it with guesses just to make the file look finished. Use “not reviewed” when that is the truth. A blank target must not be read as approval to remove the page.
Check pages, files, and URLs that are easy to miss
Use those rows later in the before-and-after CMS content check so assets and unusual blocks get reviewed too.
Review older links, translated versions, downloads, and pages reached outside the main navigation. Ask whether a page family has special variants. Record which variants need review rather than making a separate plan for every possible address without evidence.
Check a sample from each source and page type. If the CMS lists an article that the crawl missed, investigate the gap. If a source is unavailable, name it and record who can supply it. Do not label a partial list complete.
The crawling and indexing guide helps explain discovery and index status. Keep those observations distinct in the sheet. Being listed in the inventory is not proof that a search engine has indexed the URL.
Example: reconcile a small business blog list
Imagine a catering business preparing to change its blog platform. This is a hypothetical planning example. The CMS lists an event guide, the sitemap lists a menu PDF, and a support email contains an older checklist link.
The reviewer adds three rows with their sources. The event guide opens. The PDF needs the menu owner’s approval because its prices may be old. The checklist link reaches another page, so the reviewer records both addresses and asks who owns that route.
No row is removed just because it came from an unusual source. Each gets a purpose, an observation, and an owner. The result is a list ready for decisions, not a claim that the migration has been tested or that rankings are protected.
Hand the reviewed inventory to the mapping owner
Give the same scoped list to the owner of the rollback plan so return checks cover the pages the business relies on.
Check that required rows have owners and that unresolved gaps are visible. Save a dated version for the next stage. Note any pages added or changed after that snapshot so they do not disappear from the release plan.
Next, use the separate guide to map old URLs to new pages. That step decides which destination serves the original need. Once approved, the map becomes input for migration redirect testing.
DEX Health can review the SEO quality of public pages, including on the free plan. Keep its findings beside the relevant inventory rows when useful. It does not prove the inventory is exhaustive or replace the technical checks. Close this stage when the list, gaps, evidence, and ownership are clear enough for the team to make the next decisions.
FAQ
Is a sitemap a complete migration inventory?
+
Treat it as one source. Compare it with CMS records and other available evidence before calling the list complete.
Should I remove every URL with no recent clicks?
+
No. Check business purpose, links, seasonality, and the limits of the data before deciding what to keep.
Does the inventory choose redirect destinations?
+
It supplies the existing URL list. Destination approval belongs to the next mapping step.
Sources
- How to move a site · Google Search Central
Dex SEO is an AI SEO agent for small businesses. Every article here is planned from search data, drafted by Dex, fact-checked against the sources it cites, and reviewed by the team before it is published.
How this article was made: planned and drafted by Dex from search data, fact-checked by Dex (5 claims checked), then approved by the Dex SEO team.