Key takeaways
- Remove every staging blocker. noindex, Disallow and password protection are the classic launch bugs.
- Map old urls to new ones with permanent redirects before the switch.
- Audit the live site the hour it launches, not the staging copy.
- Monitor daily for the first weeks. Most launch problems show up after real traffic arrives.
Before launch
Content and templates
- Every page type has a unique title, a meta description and one H1. Check a sample with the meta tag checker.
- Social sharing shows the right image and text. Preview it with the Open Graph checker.
- Images carry alt text, and decorative images an empty
alt="". - Structured data is valid on the home page and the main templates.
- A real 404 page answers with HTTP 404.
The url plan
- List every url of the old site from its sitemap and analytics.
- Map each old url to its new equivalent. Redirect permanently with a 301 or 308, in a single hop.
- Redirect pages with no equivalent to the closest relevant page, not all to the home page.
- Update internal links to the new urls, so they never rely on redirects.
Launch day
- Remove the staging blockers. The noindex tag or header, the
Disallow: /in robots.txt, the password protection. - Pick one host and one protocol. https only, with or without www, the other redirecting. Confirm with the redirect checker.
- Publish the sitemap and declare it in robots.txt.
- Run a full audit on the live home page, then a standard audit to sample the site. Fix anything critical or high immediately.
- Verify indexability of the five most important pages with the indexability checker.
- Submit the sitemap in Google Search Console and Bing Webmaster Tools, and request indexing for the key pages.
The first weeks
- Watch for 404s in Search Console and in your server logs. Add redirects for old urls you missed.
- Watch the coverage report. Pages that drop out or are excluded point at template problems.
- Measure speed with real visitors once field data arrives, about four weeks in.
- Monitor daily. Set up a monitor with alerts, so a hotfix that reintroduces a noindex or breaks HTTPS is caught the same day.
Redesigns and migrations
A redesign on the same domain needs the url plan above. A domain change needs more:
- Redirect every old url, on every old hostname, to the matching new url.
- Keep the old domain and its certificate active, so the redirects keep working.
- Use the change of address tool in Search Console.
- Update the profiles and directories that link to you.
Check your own site
The SEO Checker runs the checks from this guide on any public page, free and without an account.
Open the SEO CheckerFrequently asked questions
Should I audit the staging site or the live site?
Both. Audit staging to fix content and templates, then audit the live site right after launch, because hosting, CDN and DNS settings differ.
How long should I keep old redirects?
At least a year, and ideally for good. Links from other sites keep pointing at old urls for a long time.
My staging site is password protected. Can I audit it?
No. Aback Audit never sends credentials. Audit a public preview url, or audit the live site right after launch.
When should traffic recover after a redesign?
With correct redirects, most sites see search traffic settle within a few weeks. Big drops that persist point at missing redirects, changed content or indexing problems.