Learn · Development · Beginner
A launch checklist built from Google's documentation: make sure your pages can be found, crawled and read, then add Search Console so you can see how Google sees them.
By Dean Cruddace · 1 hour to do · Updated · Last reviewed
Before a new website or product site goes live, a small set of technical choices decides whether Google can find, read and index its pages. Google does not give guidance on product strategy; what it documents is how pages are found, crawled, rendered and indexed.
This guide is a launch-day check against that documentation. It makes your site eligible to be found. It does not make anyone want it, and Google promises nothing about indexing or ranking.
Google's SEO Starter Guide says there is no guarantee that any particular site will be added to its index, but that sites following the Search Essentials are more likely to show up. It also says changes can take anything from a few hours to several months to show. Checking the basics before launch avoids mistakes that are hard to see once the site is live. See the SEO Starter Guide.
Add your site as a property, then choose one of the verification methods Search Console lists. Google says you can add more than one method in case one fails, for example if a template change removes a tag. It also says data is collected from the moment a property is added, even before verification. See Verify your site ownership.
You will know it worked when The property shows as verified, and a second verification method is added as a backup.
Google says it can generally crawl a link only if it is an <a> element with an href attribute. Right-click your menu and a few in-page links, choose View page source, and confirm each is written that way. Google also says every page you care about should be linked from at least one other page on your site. See SEO link best practices.
You will know it worked when Each key page is reachable through at least one link written as an anchor with an href.
Google says not to use URL fragments (the part after #, as in https://example.com/#/potatoes) to change a page's content, because Google generally does not support them. If JavaScript changes the content, use the History API instead. Google also recommends readable words rather than long ID numbers, hyphens rather than underscores, and as few parameters as you can. See URL structure best practices.
You will know it worked when Your key pages each have their own plain address, and none relies on a # fragment to show different content.
In Search Console, paste a page address into the inspection bar; Google's starter guide recommends this tool for checking how Google sees a page. Google explains that it reads a page's HTML first and, if the real content only appears after scripts run, must render the page to see it. Rendering can take longer than a few seconds, and Google still recommends server-side or pre-rendering because not all bots can run JavaScript. See JavaScript SEO basics.
You will know it worked when The tool can fetch the page, and the main content is present in what it reports.
Google says a sitemap is optional, but it is a practical launch step. Use full, absolute addresses, list only the pages you want in search results, and stay within 50MB uncompressed or 50,000 addresses per file. Google ignores priority and changefreq. Submit it in the Sitemaps report in Search Console, which shows when Google read it and any errors. See Build and submit a sitemap.
You will know it worked when The Sitemaps report lists your file and shows no processing errors.
Google uses the mobile version of your content for indexing and ranking, and calls responsive design the easiest pattern to maintain. Open the site at phone width and confirm the same main content is there. Google also says not to lazy-load primary content that needs a swipe, click or typing, because it will not load that content. See Mobile-first indexing best practices.
You will know it worked when The phone version shows the same main content and the same titles as the desktop version.
If you add structured data, Google says it must describe the page it sits on, and not information that is not visible to users; it names the Rich Results Test for checking markup. Google also sets Core Web Vitals targets (loading within 2.5 seconds, interaction under 200 milliseconds, layout shift under 0.1) and points to the Core Web Vitals report in Search Console. See structured data and Core Web Vitals.
You will know it worked when The Rich Results Test accepts your markup, and you know where the Core Web Vitals report is.
Go deeper
Describe the platform, the launch date and what you have checked from this list. A review of specifications, staging builds and releases before they reach production is one way consultancy is used.
