Why do most launch problems come from the staging site?
A staging site is a private copy where you build and test before going live. It is sensible to keep crawlers off it, and the usual ways are a Disallow: / in robots.txt, a noindex tag on every page, or a password. The trouble starts when the finished files are copied to the live server with those settings still in them. The live site then tells crawlers to stay away or to leave every page out, and search engines do as they are told.
Nothing looks wrong to a visitor. The pages load, the links work, and the only sign is that the site never appears in search. Weeks can pass before anyone notices. A password on staging is the safest choice, because it cannot be copied by accident with the HTML and it keeps people out as well as crawlers.
What should you check in the files before launch?
These are the checks the lab can show you, and they cover the most common launch mistakes. Go through them on the files that will actually be on the live server.
robots.txtallows crawling of every public page, has noDisallow: /left from staging, and lists the live sitemap with a fullSitemap:address.- No page carries a leftover
noindexrobots meta tag unless you want it out of search. sitemap.xmllists only live, indexable addresses on the real host, withhttps://, and an honest<lastmod>if you use one.- Every page has a viewport tag, its own
<title>and its own meta description. - Every internal link works, with no links to planned pages that do not exist yet.
- Canonical tags, if you use them, point at each page's own live address, not at staging and not at the home page.
- Missing pages answer 404, not 200 with the home page.
- Old addresses from any previous site redirect with a 301 to the matching new page.
What needs checking on the live server itself?
Some things only exist once the site is on its real domain. Open the site with https:// and confirm the padlock appears without warnings. Then type the http:// address and the www. version, and check each one redirects to the single address you chose. If both versions answer separately, search engines see two copies of every page.
Load a few pages on a real phone, on mobile data rather than office Wi-Fi. Open View Source in the browser and look at the head of the home page: it should be the live version, with no staging leftovers. Request an address that does not exist, such as /no-such-page, and use the Network panel in the browser's developer tools to confirm the status is 404.
Check the certificate too. It should cover the bare domain and the www. name, and it should renew by itself; many hosts use Let's Encrypt certificates that last 90 days, and an expired one puts a full-page warning in front of every visitor. Then look for mixed content: an image, font or script still loaded over http:// on an https:// page. Browsers block most of it, so a photo or a stylesheet goes missing, and the Console panel in developer tools names each file.
# robots.txt on the live site
User-agent: *
Disallow:
Sitemap: https://you.example/sitemap.xmlHow do you set up Search Console on launch day?
Add the site in Google Search Console. A Domain property covers every version of the domain, including http, https and any subdomain, and is verified by adding a TXT record at your domain registrar or DNS host. A URL-prefix property covers one exact starting address and can be verified with an HTML file or a meta tag instead. Bing Webmaster Tools can import a verified site from Search Console, which saves repeating the steps.
Once verified, open the Sitemaps report and submit the full sitemap address. Use URL Inspection on the home page and click Test live URL to see what Googlebot gets from the live server, then Request indexing if the test looks right. You only need to do that for a handful of key pages. Requesting the same page again and again does not speed anything up.
If the new site replaces an old one on a different domain, there is one more step. Keep the old domain registered, redirect every old address with a 301 to its matching new page, and then use the Change of Address tool in the settings of the old property. The tool works only when both properties are verified in your account and the redirects are already live, and it is meant for whole-domain moves, not for renaming a few pages.
What should you expect in the first few weeks?
Not much, at first, and that is normal. A brand new site may take days or a few weeks to be crawled and indexed. Search Console data arrives with a delay of a couple of days and is thin for a new property. The Pages report will fill in gradually, and a few pages listed as "Discovered, currently not indexed" in week one usually move on their own.
Watch for a few specific signs. If the Pages report shows "Blocked by robots.txt" or "Excluded by 'noindex' tag" for pages you meant to publish, go back to the checklist. If the Sitemaps report says it could not fetch the file, check the address. And if nothing at all has been crawled after two weeks, inspect the home page and read what URL Inspection says. None of this predicts positions in results; it tells you whether the site is eligible to appear.
What does the lab check, and what does it leave out?
The lab can test the file side of a launch: robots.txt, noindex tags, sitemap entries and hosts, titles, descriptions, viewports, broken links, canonical tags, soft 404s and redirects. It reads all of it in one crawl, at once, so you see the result straight away. A real launch plays out over days.
It cannot test the server. There is no real HTTPS certificate, no DNS, no X-Robots-Tag header, and http:// and www. variants are treated as the same page with a note, where a real server needs those redirects set up by hand. It also reads the sitemap as if you had submitted it. On a real site, the Search Console steps above are what tell search engines the sitemap exists.
What do AI tools get wrong about launching a site?
AI-written launch checklists often include steps that do nothing: "submit your site to 100 search engines", "resubmit your sitemap every week", "add meta keywords to every page". Others promise that following the list will get the site to the top of Google within a month. A checklist can make a site crawlable and indexable; it cannot promise where anything appears.
Generated deployment scripts and templates also copy staging settings to production, especially a noindex set in a shared header or a robots.txt that blocks everything. If an AI tool wrote your build or deploy setup, search the output for noindex and Disallow: / before you go live, and check the live site again afterwards.
Field notes
- Staging sites often carry noindex tags or a block-everything robots.txt that must be removed at launch.
- Check titles, descriptions, canonicals and the sitemap point at the live domain.
- On the live server, confirm HTTPS, redirects from old addresses and correct status codes.
- Add the site to Search Console and submit the sitemap, then expect indexing to take days or weeks.
Easy to get wrong
A staging rule copied to the live site blocks every page from being crawled. An empty Disallow: allows everything, and the Sitemap: line points crawlers at the live sitemap.
Sitemap entries must be full addresses on the site's own host. Entries on a staging host are ignored, and you would not want them crawled anyway.
A password cannot be copied across with the HTML, and it keeps out people as well as crawlers. Noindex tags travel with the files and switch off the live site.
Questions people ask
How soon after launch will my site show up in Google?
It varies from a day to a few weeks. Submitting the sitemap and inspecting the home page in Search Console help Google find it. Once it is indexed, where it appears for any search is up to Google.
Should I launch with every page finished?
Launch with every page you link to finished. It is fine to add pages later. Avoid publishing empty "coming soon" pages, which tend to be left out of the index anyway.
Do I need to do this again after every update?
Not all of it. After a big redesign or a move to a new domain, run through the whole list again. After an ordinary edit, check that page in URL Inspection if it matters to you.
Do I need a Domain property or a URL-prefix property?
A Domain property is the more complete choice if you can add a DNS record, because it covers every protocol and subdomain. A URL-prefix property is quicker to set up if you cannot change DNS.