Pre-Launch SEO Checklist for Any New Website
A new website launches. Weeks pass. Google Search Console shows zero impressions - not declining impressions, zero, like the site doesn't exist to Google at all. The pages load fine. The design looks right. Nothing is visibly broken.
The cause, when someone finally finds it, is almost always the same file: robots.txt, still carrying the staging server's Disallow: / rule, copied straight to production during deploy. Staging environments block search engines on purpose, so an unfinished site doesn't show up in results before it's ready. That same blocking file making the jump to the live domain is one of the most common launch mistakes in web development, and one of the easiest to prevent with a two-minute check before going live.
This checklist covers that check and the others worth running before a new site goes public, in the order they actually need to happen - not alphabetical order. It starts with the decision that's hardest to undo later and ends with the polish that can wait until launch day itself.
Quick Navigation
- 1. Decide Your URL Structure First
- 2. Connect Google Search Console and GA4 Before You Launch
- 3. Get SSL and HTTPS Active Site-Wide
- 4. Check Robots.txt for a Staging Leftover
- 5. Confirm Canonical Tags Point to Production
- 6. Confirm Mobile-Friendliness
- 7. Check Basic Page Speed
- 8. Submit Your XML Sitemap
- 9. Set Up Custom 404 Handling
- Connect GSC and GA4 in About 2 Minutes
- Frequently Asked Questions
1. Decide Your URL Structure First
URL structure decisions made in the first week of a build outlive the redesign that replaces them years later, because changing URLs after launch means redirects, lost link equity, and a wait for search engines to recrawl every new path.
Before writing a single page of copy, settle how the site's folders and slugs will work: flat structure or nested categories, dates in blog URLs or not, trailing slashes or none. Brass-SEO's guide to URL structure decisions walks through the specific trade-offs and the questions worth answering before the first URL goes live. For the broader question of how a site's pages and internal links fit together, see the content architecture guide.
2. Connect Google Search Console and GA4 Before You Launch
Search Console and Google Analytics 4 only report data from the moment they start collecting it, so connecting either one after launch means the first days or weeks of real traffic and indexing behavior are gone for good. There's no way to reconstruct them later.
Search Console verification doesn't require the site to already be public. Domain-level verification through a DNS TXT record works before a single visitor arrives, and the GA4 tracking snippet can ship in the same deploy as the rest of the site. Set up both while the site is still in staging, so the moment the domain goes live, both tools are already recording. Both Search Console and GA4 are required for a complete picture of a launch: one shows what Google sees and clicks on, the other shows what happens once someone lands on a page.
3. Get SSL and HTTPS Active Site-Wide
A site serving any page over plain HTTP sends a mixed signal to browsers and search engines alike. Chrome marks unsecured pages as "Not Secure," and Google confirmed HTTPS as a ranking signal back in August 2014.
Check that every URL resolves to https://, not just the homepage - old staging links, image assets, and redirect chains included. A single unsecured resource loaded on an otherwise secure page can still trigger a browser warning. Confirm the certificate covers both the www and non-www versions of the domain, and that plain HTTP requests redirect to HTTPS with a 301, not a 302.
4. Check Robots.txt for a Staging Leftover
The file at [domain]/robots.txt is the fastest launch check available and the easiest one to skip, because a blocking rule doesn't throw an error anywhere visible on the site itself.
Visit the live production robots.txt directly in a browser and read it. Don't assume the deploy pulled the correct version. A production robots.txt should not contain Disallow: / unless blocking the entire site is genuinely the intent - Google's Search Central documentation explains exactly which rules block what. If a staging block did make it to production, removing it doesn't retroactively recover lost time. Search Console's URL Inspection tool can request a recrawl once the fix is live, which speeds up recovery.
5. Confirm Canonical Tags Point to Production
A canonical tag tells search engines which URL is the authoritative version of a page. When a staging environment stays reachable after launch, canonical tags left pointing at the staging domain tell Google to index the wrong version entirely.
This goes wrong most often when a staging subdomain - staging.example.com, or a platform's default preview domain - stays live and crawlable after the production domain launches. Check the canonical tag in the page source of a handful of key pages, such as the homepage and a product or service page. Confirm each one points to the production URL. If the staging environment is still reachable at all, block it from indexing directly with a sitewide noindex tag or password protection, rather than relying on the canonical tag to sort it out on its own.
6. Confirm Mobile-Friendliness
Google has used the mobile version of a site as the default for indexing and ranking since completing its shift to mobile-first indexing, so a site that looks fine on a desktop monitor but breaks on a phone screen is being judged on the broken version.
Test the site on an actual phone, not a resized desktop browser window. Tap target size and font legibility look different on a real device than in a simulator, and horizontal scrolling shows up in ways a resized browser tab won't catch. Google Search Console's mobile usability reporting flags the most common problems: text too small to read without zooming, clickable elements placed too close together, and content wider than the screen.
7. Check Basic Page Speed
Google's Core Web Vitals threshold for Largest Contentful Paint is 2.5 seconds. Pages that load slower than that on real user connections see measurably lower scores in Google's page experience signals.
Run the homepage and one or two key inner pages through PageSpeed Insights before launch, not after. The report combines lab data (a simulated test run) with field data (real user measurements, once enough traffic accumulates) - lab data is the only signal available before launch, so treat it as a baseline rather than a final grade. The most common pre-launch speed problems: unoptimized hero images, render-blocking scripts loaded ahead of visible content, and web fonts that aren't preloaded.
8. Submit Your XML Sitemap
An XML sitemap doesn't guarantee indexing. It gives Google a direct list of every URL the site wants crawled instead of leaving discovery entirely to internal links and external mentions.
Once Search Console is connected (step 2) and robots.txt allows crawling (step 4), submit the sitemap URL - usually /sitemap.xml - under Search Console's Sitemaps report. Most platforms and frameworks generate this file automatically. Confirm it lists the actual production URLs rather than staging paths, and that it excludes any page that's intentionally set to noindex.
9. Set Up Custom 404 Handling
A default server error page tells a visitor the link is broken and offers no way forward. A custom 404 page keeps them on the site with a search box, a link back to the homepage, or a pointer to the pages people actually want.
This matters more at launch than it will later, because early inbound links - old bookmarks, social shares, third-party directory listings - are more likely to point at URLs that shifted during development. Confirm the 404 page returns an actual 404 HTTP status code, not a 200. A soft 404 that returns success without saying so can leave broken pages sitting in Google's index long after they should have dropped out.
Connect GSC and GA4 in About 2 Minutes
Brass-SEO connects to both Google Search Console and Google Analytics 4 through Google's own OAuth flow, with read-only access. Setup takes about two minutes from signup to first connection.
Step 2 on this checklist, connecting both before launch, is the exact gap Brass-SEO's onboarding closes. Sign up. Connect GSC. Connect GA4. The dashboard is ready to answer questions about the new site's performance starting day one instead of starting cold weeks later. Start a free trial from the dashboard and have both accounts connected before the DNS change even finishes propagating. For a deeper look at reading that data once it's flowing, see the Search Console guide and the GA4 traffic report guide.
Frequently Asked Questions
Do I need to do these steps in this exact order?
The order reflects when each task is easiest to do and when skipping it costs the most. URL structure and canonical tags belong early because they're expensive to change after pages are indexed. Robots.txt and SSL are go-live checks - run them right before flipping the site public. Sitemap submission depends on Search Console already being connected, so it has to come after step 2. Custom 404 handling can technically happen anytime, but launch day is when the first broken links start arriving.
What if my site already launched and I skipped some of these steps?
Every item on this list can still be fixed after launch - the cost is time, not impossibility. Check robots.txt and canonical tags first, since those directly control whether Google can see and correctly index the site. Connect Search Console and GA4 immediately if they aren't already running; the data gap for the missed period can't be recovered, but every day connected from here forward starts building a record. Then work through the rest of this list in whatever order fits the site, starting with whichever gap seems riskiest.
How soon after launch should I submit my sitemap?
As soon as Search Console is verified and robots.txt allows crawling. There's no benefit to waiting, and submitting early gives Google a complete list of URLs to work through instead of relying only on internal links to find new pages. If the site is still adding pages regularly after launch, most sitemaps regenerate automatically, so there's nothing further to do beyond the initial submission.
Does a custom 404 page affect SEO rankings directly?
Not directly - Google doesn't rank sites higher for having a nicer error page. What it affects is indirect: a 404 that returns the correct 404 status code (instead of a soft 404 that returns 200) keeps broken URLs out of Google's index, and a 404 page that helps visitors find what they were looking for reduces the chance they leave the site entirely after hitting a dead link.
Can Google Search Console be set up before the domain has any content on it?
Yes. Domain-level verification through a DNS TXT record only requires access to the domain's DNS settings, not a live website. This is what makes connecting Search Console before launch possible in the first place - verification and data collection can both be in place before the first page goes public.