
Site Architecture
Part of SEO during website changes
Recording important URLs before a redesign
Build a pre-redesign URL inventory with each page’s purpose, proposed treatment, destination and owner.
Before a redesign replaces the current site, record the URLs whose content, visitors or links need a deliberate outcome. The inventory identifies addresses that stay, move, are consolidated or end. Save it before the old navigation and CMS structure disappear.
Collect URLs from several sources
Start with a CMS export and the current XML sitemap, then compare them with site navigation, Search Console page data, site analytics and server logs where available. Each source shows a different slice. A page absent from the sitemap may still receive visits or have links pointing to it. Include important PDFs, images or other assets if their URLs will change.
Record generated variants, such as filter and tracking-parameter URLs, separately so they do not obscure pages with distinct reader tasks. Keep each exact address, including its host and path. A page title is not enough to identify a redirect source.
Record the page’s job and intended treatment
A useful inventory row needs more than a URL and a traffic total:
| Field | What to record |
|---|---|
| Current URL | Exact address and whether it is live, redirected or unavailable. |
| Reader task | The question or action this page supports. |
| Page type | Service, category, product, guide, download or another role. |
| Evidence for review | Relevant visits, links, enquiries or other signals, with period and source. |
| Planned treatment | Keep, move, consolidate, retain as a reference or retire. |
| Proposed destination | Exact new URL when one exists, and why it answers the old task. |
| Owner and uncertainty | Who confirms the decision and what still needs checking. |
Traffic helps prioritise review, but it should not be the sole deletion rule. A narrow page may answer a consequential customer question despite few visits. An address can also attract visits while its content is outdated or its task is handled elsewhere.
Compare the old and proposed answers
For every important page, inspect the old answer and its proposed replacement. Has a service condition, useful detail or enquiry route been lost? If several pages will be consolidated, confirm that the new page covers each material task. If a page keeps its address, record that explicitly; a visual redesign does not require changing URLs.
Mark a destination unresolved when the new page is not ready or its relevance is uncertain. Do not use the home page merely to fill the cell. For removed content without a similar replacement, record that decision so the implementation team can plan the appropriate response.
Old Page vs. Proposed Replacement
- Original URL
- https://www.example.com.au/services/consulting
- Reader task preserved?
- Yes
- Key content retained?
- Yes
- Enquiry route maintained?
- Yes
- Redirect set up?
- Yes
Hand over a testable inventory
Save a dated version for the release plan and note later changes. The redirect owner needs exact source and destination addresses. Editors need the page-purpose notes.
Release testers need representative URLs from each template and every exception. After launch, compare the implemented route and final answer with the record. A missing or misdirected page should be identifiable by URL, owner and intended outcome.



