Scan after a site redesign at four points: on staging before launch, on the day of launch, again 7 to 14 days after launch once content has settled, and on a recurring schedule afterward. A redesign rewrites templates, components, and content structures, so prior scan history is no longer a reliable baseline.
| Phase | What the Scan Covers |
|---|---|
| Pre-launch (staging) | Evaluates new templates and components before they reach production, allowing fixes before public release. |
| Launch day | Confirms the production environment matches what was scanned on staging and catches deployment-related issues. |
| Post-launch (7 to 14 days) | Identifies issues introduced by content edits, third-party scripts, and CMS-driven elements added after go-live. |
| Recurring | Monitors for regressions as new content, templates, and integrations are added over time. |
Why a Redesign Resets Your Scan Baseline
A redesign typically changes the underlying HTML, CSS, and ARIA structures across the site. Even when visual design appears similar, the markup behind it is often new. That means previous scan reports describe a site that no longer exists.
Treating a redesign as a fresh starting point produces more accurate data. The scan after site redesign work serves as the new baseline against which future scans are compared.
Scanning on Staging Before Launch
Pre-launch scans on a staging or preview environment are the most useful point in the redesign timeline. Issues identified here can be remediated before the public ever sees the new site.
Focus the staging scan on representative templates: home, primary landing pages, product or service pages, article templates, forms, checkout or signup flows, and authenticated views. Authenticated areas require a scanner that can operate inside an active session.
Scanning at Launch
Conduct a scan on the production site within 24 hours of launch. Deployment can introduce differences between staging and production: missing assets, altered scripts, content management system overrides, and third-party tags that were not present in staging.
The launch-day scan confirms that what was evaluated on staging actually shipped to production.
Scanning 7 to 14 Days After Launch
Most redesigns continue to change in the first two weeks. Editors add content, marketing teams adjust landing pages, and integrations are tuned. A scan in this window captures issues that did not exist at launch.
This is also when authoring patterns become visible. If editors are inserting images without alternative text or building tables without proper headers, the post-launch scan surfaces those patterns early.
Setting a Recurring Cadence Afterward
After the post-launch scan, move to a recurring schedule. Common cadences include weekly for high-change marketing sites, monthly for stable sites, and after every significant release for product-driven sites.
Recurring scans are a monitoring layer, not a full evaluation. They catch regressions in templates and content but cover only about 25 percent of WCAG criteria. The rest requires manual evaluation by a trained accessibility professional.
Pairing Scans with a Manual Audit
A redesign is the strongest moment to pair scanning with a thorough audit. Scans flag a portion of issues across many pages. An audit identifies the deeper issues that scans cannot detect: keyboard operability, screen reader announcements, focus management, and complex component behavior.
Together, the two produce a complete picture of the new site’s accessibility posture and a defensible baseline for the design moving forward.
A redesign is the cleanest opportunity to establish accurate accessibility data. Scanning at staging, launch, and post-launch, then settling into a recurring cadence, keeps that data current as the site evolves.