A website redesign should leave an evidence trail that can answer three questions: what changed, whether users can still complete important tasks, and how the previous version can be restored. Screenshots alone are not enough because they do not preserve URLs, form behavior, accessibility, or search signals.
Preserve the old site's operating baseline
Before release, save a dated inventory of public URLs, page titles, canonical URLs, important downloads, forms, analytics tags, robots directives, and sitemap entries. Record the most-used landing pages and critical journeys such as contact, checkout, sign-up, or account recovery. Save representative screenshots at desktop and mobile widths, but pair them with text exports or source-controlled files so content and settings remain inspectable.
If URLs will change, create an explicit old-to-new mapping. Google's site-move guidance recommends preparing a URL mapping, updating internal links and annotations, using permanent server-side redirects where possible, testing redirects, and monitoring both old and new traffic. Preserve that mapping as a release artifact rather than rebuilding it from memory after errors appear.
Keep test evidence, not just a launch checklist
For each critical page, record the test URL, browser or device, date, expected result, actual result, and evidence location. Include navigation, keyboard operation, visible focus, form labels and errors, heading structure, image alternatives, zoom, color contrast, and reduced-motion behavior where relevant. W3C's Easy Checks covers page titles, alternative text, headings, contrast, text resize, keyboard access, focus, forms, and basic structure, while warning that these quick checks are not a complete accessibility evaluation. Keep failures and limitations in the record instead of treating a short checklist as proof of conformance.
Also preserve automated test output, broken-link reports, HTTP status checks, and a sample of completed form submissions using harmless test data. For analytics, record the baseline period, filters, timezone, and known test traffic so post-launch comparisons are meaningful.
Record the release and rollback boundary
Store the approved design version, content freeze time, deployment identifier, DNS or hosting changes made by an authorized owner, and the exact rollback procedure. Keep copies of the previous deployable assets and configuration in a protected location. Do not place credentials, private form submissions, or customer data in the public release archive.
After launch, recheck redirects, error logs, search indexing reports, analytics tags, forms, and critical accessibility paths. Google's guidance notes that ranking can fluctuate while moved URLs are recrawled and reindexed, so preserve dated measurements rather than interpreting a single day's change as a permanent result. Close the redesign only when the evidence shows the new site works and the rollback materials are still usable.
Sources
- Site Moves and Migrations — Google Search Central
- Easy Checks - A First Review of Web Accessibility — W3C Web Accessibility Initiative