To troubleshoot a website redesign with a change log, capture the last known good release, separate visual defects from content and URL problems, change one variable at a time, and record the result before another deployment. The change log should make every check repeatable and every risky change reversible.
Capture a useful baseline
Record the release identifier, deployment time, template or theme version, browser and device, affected URL, expected result, observed result, and a screenshot. Add a small set of critical journeys such as opening the home page, finding a service, submitting a form without sending real customer data, and reaching the confirmation page. Test the same journeys before and after each change.
If the redesign changed URLs, preserve an old-to-new URL map. Google's site-move guidance recommends mapping old URLs to their corresponding new destinations, updating internal links and canonical annotations, and preparing a sitemap of the new URLs. That map belongs in the log because it distinguishes a missing page from a broken redirect or an incorrect destination.
Test one layer at a time
Classify the symptom before editing: layout, navigation, content, form behavior, performance, analytics, or search discovery. Disable or roll back one recent change, then rerun the smallest failing check. Do not combine a theme upgrade, domain move, navigation rewrite, and form replacement in one experiment.
For permanent page moves, Google recommends server-side permanent redirects such as 301 or 308 when possible. Test the response code and final destination, not just what appears in a browser. Avoid sending many unrelated old pages to the home page. Check the canonical URL, internal links, sitemap entry, and any campaign link that targets the changed page.
Use an evidence table
Give each entry a time, owner, hypothesis, action, expected result, actual result, affected URLs, and rollback. Include a cache state and test from a private browser window so an old asset does not hide the current release. If the defect appears only on one device width or browser, record that boundary rather than calling the whole site fixed.
Keep accessibility and form checks in the acceptance set. Confirm keyboard focus, labels, error messages, text resizing, and contrast on the changed components. For a form, use an authorized test destination and verify both the visible confirmation and the receiving system without exposing a real visitor's information.
Close the incident cleanly
After a fix, repeat the critical journeys, scan mapped redirects, and watch error logs and search monitoring for a defined period. Google's site-move documentation advises monitoring traffic on both old and new locations while the move is processed. Mark the result resolved and retested, contained with a workaround, or unresolved with the prior release preserved.
A good redesign change log does more than list edits. It connects one symptom to one controlled change and one observed result, while retaining the URL map and rollback needed to undo a bad release.
Sources
- Site Moves and Migrations — Google Search Central
- Redirects and Google Search — Google Search Central