A new website can be beautifully designed and still invisible to search for weeks because of one setting. It's a common enough failure that we treat technical SEO as a gate in our own launch process: the site doesn't go live until the checks below pass. This checklist is that gate, written so you can run it on any platform.
It's a launch-focused companion to our broader guide to technical SEO for websites, which explains why each item matters. If you need the non-SEO launch items too, such as forms, analytics and legal pages, pair this with our website launch checklist.
What technical SEO should be in place before a new website launches?
Before launch, a new website needs five technical SEO areas confirmed: crawler access, indexing signals, rendering, metadata and structured data. If the site replaces an old one, add a sixth: redirects for every changed URL. Each area is a short list of yes or no checks, so the whole review takes an afternoon.
Area | What must be true | Check with |
|---|---|---|
Access | Production robots.txt allows crawlers; staging is blocked | yourdomain.com/robots.txt |
Indexing | No stray noindex; one canonical per page | Page source, a crawler tool |
Discovery | XML sitemap lists only live, canonical URLs | yourdomain.com/sitemap.xml |
Rendering | Main content is in the server-sent HTML | View source, URL Inspection |
Metadata | Unique titles, descriptions and Open Graph tags | A crawl export |
Schema | Organization, WebSite, Article and BreadcrumbList validate | Rich Results Test |
Redirects | Every old URL 301s directly to its new home | Redirect map and a crawl of old URLs |
Which crawl and access checks come first?
Crawl and access checks come first because they can block everything else. If robots.txt disallows the site or the pages carry noindex, nothing else on this list matters. Run these the moment the production domain points at the new site.
- robots.txt on production allows crawling. Open yourdomain.com/robots.txt and confirm there's no blanket Disallow: / rule left over from staging.
- robots.txt points to the sitemap. Add a Sitemap line with the full URL so every crawler can find it.
- Answer-engine crawlers are allowed. Decide on GPTBot, OAI-SearchBot, ClaudeBot and PerplexityBot deliberately. Our guide to robots.txt and sitemaps has examples for each choice.
- Staging and preview domains are blocked. Use password protection or a noindex header, so a duplicate copy of the site never gets indexed.
- The site resolves to one host. http, https, www and non-www should all 301 to a single version.
- Important pages return 200. Crawl the site and confirm there are no unexpected 3xx, 4xx or 5xx responses on pages you want ranked.
How do you check canonicals, noindex and the sitemap?
Check indexing signals by crawling the live site and exporting the canonical, meta robots and status code for every URL. Every page you want ranked should be indexable, self-canonical and in the sitemap. Anything that disagrees with itself, such as a sitemap URL that canonicals elsewhere, needs fixing before launch.
- Self-referencing canonicals on every indexable page, using the final https URL with your chosen trailing-slash style. Our technical SEO guide explains how canonicals, noindex and redirects work together.
- noindex only where intended: thank-you pages, internal search, login and legal duplicates.
- Sitemap contents match the indexable set: no redirects, no 404s, no noindex pages and no parameter URLs.
- lastmod dates in the sitemap reflect real content changes, not the build date for every page.
- Blog archives and tags follow one rule: index the useful hubs, noindex or skip thin tag pages. Keep the taxonomy small enough that every indexed tag page has real content.
How do you confirm content renders for Google and AI crawlers?
Confirm rendering by checking the raw HTML your server sends, not what your browser shows after JavaScript runs. If the headline, body copy, pricing and FAQ are in the page source, every crawler can read them. If they only appear in the browser's inspector, some crawlers won't see them.
On Webflow and Framer, published pages are static HTML, so the main risk is content loaded by embeds or third-party widgets. On Next.js, the risk is a marketing page that slipped into client-only rendering because of a hook or a data fetch in the browser. Our guide to JavaScript SEO shows how to test this with view-source, curl and Search Console's URL Inspection.
- Headline, body copy and FAQ answers appear in view-source.
- Navigation links are real anchor tags with href values, not click handlers.
- Images have alt text and explicit width and height to avoid layout shift.
- Each page has one H1 and a logical H2 and H3 order.
- Titles are unique, short enough to show in full in search results, and lead with the page's topic.
- Meta descriptions are unique and summarize the page in a sentence or two.
- Open Graph title, description and image are set so shared links look right.
What schema and AI-readiness checks belong in a launch?
A launch needs a small, accurate set of structured data and pages that answer questions clearly. Add Organization and WebSite schema sitewide, Article on blog posts and BreadcrumbList on nested pages, then validate each template once. Don't add schema for content that isn't visible.
AI-readiness is mostly the same work. Answer engines cite pages they can fetch, read and quote, so server rendering and crawler access matter most, followed by clear headings and a direct answer near the top of each page. Studies summarized in 2026, including SE Ranking's analysis of 300,000 domains, found no measurable citation lift from llms.txt, so we treat it as optional. The list of schema types worth the effort is in our schema markup guide.
What our launch schema looks like on a typical marketing site
On a typical startup marketing site we ship four schema blocks as JSON-LD in the server-rendered HTML.
Organization on the home page with name, URL, logo and sameAs links to official profiles. WebSite with the site name, so Google shows the right brand name. Article on each blog post with headline, dates, author and publisher. BreadcrumbList on any page more than one level deep.
If the company sells software, we add SoftwareApplication to the product or pricing page, with only the properties we can fill truthfully. FAQPage goes only on pages with a visible FAQ.
What should you do on launch day and in the first two weeks?
On launch day, verify the domain in Search Console, submit the sitemap and inspect your most important URLs. Over the next two weeks, watch the Pages report for unexpected exclusions and fix them quickly, while Google is still forming its view of the new site.
Verify Search Console and Bing Webmaster Tools
Use a domain property in Search Console so every subdomain and protocol is covered. Import the property into Bing Webmaster Tools, which also feeds some AI search products.
Submit the sitemap
Submit the sitemap URL in both tools and confirm it was read without errors.
Inspect your top five URLs
Run URL Inspection on the home page, pricing and three key pages. Check the rendered HTML and the canonical Google selected, then request indexing.
Test old URLs if you replaced a site
Run every old URL from your redirect map through a crawler and confirm a single 301 hop to the right page.
Watch the Pages report
Check daily for the first week, then twice in the second. Investigate any jump in noindex, duplicate or not found statuses.
Check Core Web Vitals once field data arrives
Field data takes time to collect. When it appears, fix the templates with the most traffic first.
If pages still aren't indexed after a few weeks, our guide to pages not indexed by Google explains each Search Console status and what to do about it. For a replaced site, the website migration SEO checklist covers benchmarks and monitoring in more depth.
How is this built into our launch process?
We build these checks into the project rather than running them at the end. Rendering, canonicals, sitemap and schema are decided when we set up the codebase, so every new page inherits them. The launch review then confirms nothing changed between staging and production.
The handover matters too. You should own the domain, the Search Console property and the hosting account, not your agency. Before you sign off, confirm each one is in your company's name and that you have admin access. If the launch is part of a rebrand, add the brand-name checks too: update the WebSite and Organization schema, social profiles and any directory listings so the new name is consistent everywhere from day one.
