The Technical SEO Checklist: What to Check Before and After Launch

Why does technical SEO matter most at launch?

A new site or a redesign is the single riskiest moment in a website's search life. Every URL may change. Templates change. Hosting changes. One forgotten setting can remove a site from Google faster than a year of good work built it.

Google's technical requirements set the floor. For a page to be eligible for indexing, three things must be true:

1. Googlebot is not blocked from it.
2. It works, meaning Google receives an HTTP 200 (success) status code.
3. It has indexable content in a supported format that does not break Google's spam policies.

Google is clear that meeting these makes a page eligible, not guaranteed. But failing any of them guarantees the opposite. Almost every launch problem we are called in to fix traces back to one of these three. The checklist below is built around them.

Before launch: are crawling and indexing set up correctly?

Staging sites are usually hidden from search, which is correct. The danger is that the hiding comes with the site to production.

1. Remove staging blocks. Check for a sitewide noindex meta tag or X-Robots-Tag header, a Disallow: / rule in robots.txt, and password protection. Any one of these left in place at launch can wipe you out of results.
2. Know what robots.txt does and does not do. Google's robots.txt introduction says the file tells crawlers which URLs they can access, mainly to avoid overloading your site, and that it is not a mechanism for keeping a page out of Google.
3. Use noindex for pages that should stay out of results. Thank-you pages, internal search results, filtered duplicates. Google's noindex documentation warns that the page must not also be blocked by robots.txt, or the crawler will never see the noindex rule and the page can still appear in results.
4. Check status codes. Every page you want indexed should return 200. Pages that no longer exist should return 404 or 410, or redirect. A missing page that returns 200 with a "not found" message is a soft error that wastes crawling.
5. Make sure content is in the HTML Google can see. If key text or links only appear after scripts run, test that Google renders them. On the hand-coded static sites we build, the content is in the HTML from the start, which removes this risk.

Before launch: are URLs, redirects and canonicals clean?

This is where redesigns lose the rankings they spent years earning. Old URLs have links, bookmarks and history attached. If they return 404 after launch, that equity is gone.

Build a redirect map

Export every indexed URL from the old site, from Search Console, your analytics and a crawl. Then map each one to its closest new equivalent.

Rules of thumb: redirect one-to-one, not everything to the homepage. Avoid chains where A redirects to B which redirects to C. Update internal links to point straight at the new URLs.

Pick one version of every page

Your site should resolve to one protocol and one host: https, and either www or non-www, with the others redirecting. Then set a self-referencing canonical tag on each page.

Google's canonicalization guide treats redirects and rel="canonical" as strong signals and sitemap inclusion as a weak one. It also makes clear that Google can choose a different canonical if your signals conflict. So make them agree: the canonical tag, the internal links, the sitemap and the redirects should all point to the same URL.

Before launch: does the site work on mobile and load fast?

Mobile parity

Google uses the mobile version of a site's content for indexing and ranking. Its mobile-first indexing best practices ask that the mobile version carry the same content as desktop, including the same structured data, titles, meta descriptions, headings, image alt text and robots meta tags.

Common failures:

• Text or sections hidden on mobile "to save space" that do not exist anywhere else.
• Structured data present on desktop templates only.
• A noindex added to a mobile template by mistake.
• Images or menus that only load after an interaction Google does not perform.

Core Web Vitals

Core Web Vitals measure loading, responsiveness and visual stability. Per web.dev, the targets for a good experience are:

• Largest Contentful Paint (LCP): 2.5 seconds or less.
• Interaction to Next Paint (INP): 200 milliseconds or less.
• Cumulative Layout Shift (CLS): 0.1 or less.

These are assessed at the 75th percentile of page loads, separately for mobile and desktop. Lab tools are useful before launch, but they are a simulation. The real score comes from field data after real visitors arrive. The usual pre-launch fixes are compressed, correctly sized images; fewer third-party scripts; reserved space for images and embeds; and fonts that do not block rendering. More on why this matters commercially in how website speed affects revenue.

Before launch: are titles, descriptions and structured data in place?

These are on-page items, but they are template-driven, so they break at the template level and are best checked at launch.

• Unique title on every page. Google builds its title links from several sources, starting with the title element. Its title link guidance asks for descriptive, concise titles, no keyword stuffing, no repeated boilerplate, and concise branding with a delimiter.
• Unique meta description on every page. Google mostly builds snippets from page content but may use the meta description when it describes the page better. Its snippet documentation says there is no length limit but snippets are truncated to fit, and recommends page-specific descriptions over sitewide copy.
• One clear H1 per page that matches what the page is about.
• Structured data that describes what is actually on the page: LocalBusiness for a location, Product for a product, Article for a blog post. Validate it before launch. See how schema helps search engines.
• Descriptive image alt text on images that carry meaning.
• Internal links as normal HTML links, so every important page is reachable within a few clicks of the homepage.

Launch day: what should you check in the first hour?

Do these the moment DNS points to the new site. Not the next morning.

1. Load robots.txt in a browser and confirm it is the production version, not staging.
2. View source on the homepage and two key templates and confirm there is no noindex.
3. Test a sample of redirects from your map, including your highest-traffic old URLs. Confirm each returns a single 301 hop to the right page.
4. Verify the property in Google Search Console if it is a new domain, or confirm access if it is not.
5. Submit your XML sitemap. Google's sitemap documentation says to use absolute URLs, limits each sitemap to 50,000 URLs or 50MB uncompressed, and accepts submission through Search Console or a Sitemap line in robots.txt. It ignores priority and changefreq, and uses lastmod only when it is consistently accurate. Include only canonical, indexable URLs that return 200.
6. Run the URL Inspection tool on key pages. Google's URL Inspection help page explains it shows index status and the Google-selected canonical, and offers a live test and a request-indexing option. Requesting indexing does not guarantee the page will be indexed.
7. Submit every form and place a test call from the click-to-call links. A site that ranks but cannot capture a lead is not finished.
8. Confirm analytics and conversion tracking are firing on the new templates.

After launch: what should you monitor for the next 90 days?

Some movement after a migration is normal while Google recrawls and reprocesses the site. Your job is to tell normal settling from a real problem.

• Page indexing report. Watch for spikes in pages excluded as "blocked by robots.txt," "excluded by noindex," "not found (404)" or duplicates where Google chose a different canonical than you did.
• Performance report. Compare clicks and impressions for your top queries and pages against the weeks before launch. A sharp drop on specific pages usually points to a missing redirect or a content change on that page.
• Core Web Vitals report. Search Console's Core Web Vitals report uses real-world field data and groups similar pages. A new site may show no data at first, because there is a minimum amount of traffic required.
• Crawl the live site with a crawler of your choice. Look for broken internal links, redirect chains, missing titles and orphan pages.
• Server logs or 404 monitoring to catch old URLs that people and bots still request but your redirect map missed.

Keep the old site's URL list and the redirect map. You will refer back to them more than once.

The checklist at a glance

If you are planning a redesign and want a second set of eyes before you flip the switch, our website design team builds every site against this list, and the free audit on our contact page will flag what your current site is getting wrong.

Frequently asked questions