A redesign changes what a team sees every day. It can also change the places where useful information lives. Before the project begins, build a working record of the current website that the team can use during planning and after release. The purpose is practical: when a question appears later, someone should be able to compare the new behavior with a clear starting point.
This record is useful even when the redesign keeps the same URLs. It becomes especially important when the project changes addresses, templates or navigation. Begin by asking which changes are actually in scope. A visual refresh, a content restructuring and a domain move are different jobs. Naming those jobs early helps the team assign responsibility and choose checks that match the work.
Agree on the scope in writing
Write a short scope statement before collecting files. Identify the website, the environments involved and the intended release. List the kinds of changes the team expects to make. If a question remains open, record who will decide it. A short unresolved question with an owner is more useful than a confident assumption buried in a planning document.
The scope statement should be understandable to the people reviewing the release. A designer may describe a template change differently from a developer or consultant. Put one example beside each important change. That example gives everyone something concrete to discuss and helps reveal where the project plan still contains different interpretations.
Create a URL working list
Collect a list of current URLs from the sources the team already uses. Keep the source of each entry so that an unfamiliar address can be investigated later. The list should distinguish pages the team intends to retain, combine, replace or remove. Give uncertain cases a review status instead of forcing an early answer.
Do not treat the list as a complete model of the business. Ask the people responsible for important sections to review it. A page with little recent activity may still support a customer task, an external reference or a legal obligation. The working list becomes more useful when the team records why a URL matters, rather than relying on a single metric to decide its future.
Preserve representative examples
A full export can be helpful, but a smaller set of explained examples is often easier to use during a meeting. Select representative pages from the main templates and important user journeys. Record the address, page type, visible purpose and any behavior the team wants to preserve. Include an example of an unusual case rather than collecting only the cleanest pages.
Screenshots can support the record, especially for interactions and mobile layouts. Pair each screenshot with its date, environment and a short note explaining what it demonstrates. Without that context, an image can become a puzzle after the design has changed. The goal is a usable reference, not a large folder that nobody can interpret.
Map changed addresses deliberately
When URLs will change, give the mapping its own review. Google's site move documentation describes preparing the new website, mapping old URLs to new destinations, setting redirects and monitoring the move. Use that guidance for the search-specific work, alongside the team's own user and operational requirements.
In the working record, each old address should have an intended outcome. A destination needs to make sense for someone following the old link. If several pages become one, explain the content decision so a reviewer can assess it. Keep unresolved mappings visible before release, with a person responsible for choosing the final treatment.
Record template behavior
Templates can repeat a small mistake across many pages. Choose a few pages from each main template and record the behavior relevant to the redesign. This might include navigation destinations, forms, important metadata or the content that should remain available. Ask the developer which parts are shared and which are page-specific so the check list reflects the actual implementation.
A record should say what to inspect, where to inspect it and what the team expects to find. “Check product template” is too broad for a reliable handoff. A short sequence with an example address gives the next reviewer a way to reproduce the check. It also makes a failed result easier to discuss without arguing over what the original instruction meant.
Separate defects from decisions
During a redesign, teams often discover existing behavior they would like to change. Keep those discoveries separate from defects introduced by the new work. Both may deserve attention, but they have different implications for the release. A clear record helps the team decide whether to fix an old problem now, plan it later or preserve the current behavior intentionally.
The same applies to content decisions. If a page is removed deliberately, record the reason and the intended treatment for visitors reaching its old address. If it disappears accidentally, record the defect and the correction. Calling both cases a missing page loses the distinction the release team needs.
Plan the checks after release
The pre-redesign record should lead to a post-release review. Assign the checks before launch so the team knows who will compare representative pages, inspect address changes and watch for unexpected behavior. Leave room for the reviewer to record what they actually observed, including the date and environment. A planned check is a useful intention; a completed observation is the evidence.
Google also recommends sequencing major changes rather than combining a domain move, a new system and a new layout at once. Its guidance notes that search results can fluctuate while a move is processed. Bring those points into planning where they apply, without treating a timetable as a promise. The team still needs its own release plan and a clear way to respond to problems.
Keep the record small enough to use
A useful baseline does not need to capture every possible detail. Start with the decisions and examples the team will actually review. Make deeper exports available through clearly named links. If a document becomes too large to scan, add a short index organized by the questions people ask during the project.
After the release, retain the record with the completed checks and the decisions made along the way. It can help the next person understand why an address changed or why a template behaves as it does. That continuity is often the most durable result of the preparation: a team can explain its own website without relying on someone's memory of a busy launch week.