What to Set Up Before Launching a New Website for Search

When you launch a website, search engines need to find its pages, fetch them, and decide whether to include them in search results. Fetching a page is called crawling; storing and organizing its content for possible results is called indexing. Neither step guarantees that a page will rank for a particular search.

Before launch, set the preferred public URLs, make sure search engines can access the pages, link important pages to one another, and set up monitoring. These checks remove common technical barriers and help you spot problems after publication. They do not guarantee indexing, traffic, or rankings.

Make the public version of each URL clear

Choose the public URL people and search engines should use, such as https://example.com or https://www.example.com. Redirect other versions, including HTTP and the nonpreferred host, to it. Check that redirects reach the right page without looping.

A canonical URL is the version you want search engines to treat as the main one when similar pages exist at multiple URLs. Keep canonical tags and internal links consistent with your choice. Make sure redirects and sitemap entries use the same version. Google treats a canonical tag as a signal rather than a command, so it may select a different URL when other signals disagree. Its canonicalization guidance explains how those signals work.

Before launch, test the homepage and important page types using both the preferred and alternate URL versions. Confirm that each preferred page loads publicly and returns a successful response. Also check that a preview or staging site is not exposed as a duplicate public version.

Remove barriers to crawling and indexing

Check the live website for settings that prevent search engines from accessing or indexing public pages. A staging site may have a noindex instruction, which tells a search engine not to include a page in results. The same instruction left on the public site blocks indexing.

A robots.txt file serves a different purpose: it tells search engine crawlers, automated programs that fetch pages, which URLs they may request. If a page is blocked there, Google may not be able to read its noindex instruction. And because robots.txt does not protect private information, use access controls or authentication to keep staging content private. Google explains the distinction in its guides to robots.txt and robots meta tags.

Check the live robots.txt file, page-level indexing settings, and response headers. Confirm that intended public pages do not require a login and return the content you expect. These checks should include hosting and content delivery settings as well as the site’s publishing platform.

Help crawlers find the pages that matter

Link important pages from the site’s navigation or from other relevant pages. Search engines use links to discover URLs and understand how pages relate to one another. Use standard links with a destination URL, and write link text that helps visitors understand where it leads. Google describes the format it can reliably crawl in its link best practices.

A sitemap is a file that lists URLs you want search engines to know about. It can help a new site with few links from other websites, but it does not replace internal links or guarantee that search engines will crawl or index every listed page. If you publish one, include preferred public URLs and remove entries that redirect, are blocked, carry noindex, or should not appear in search. Google’s sitemap guidance explains when a sitemap can help.

Check what visitors and crawlers receive

Give each important page a title that describes its subject and a clear main heading. Make sure the page’s useful text and links appear in the version a crawler can process. If JavaScript creates the main content or navigation, inspect the rendered page rather than relying only on what you see in your browser.

Google can generate a search result’s title from several page signals, so the title you provide does not dictate exactly what will appear. A meta description can help describe a page, but Google may select other page text for the search snippet. Treat titles and descriptions as useful summaries for people, not as guarantees of a particular result display. See Google’s guidance on title links.

Structured data is code that labels information on a page, such as a product or organization’s details. Add it when a supported search feature fits the page and the marked-up facts match what visitors can see. Valid structured data can make a page eligible for certain enhanced results, but it does not guarantee that Google will show them. The structured data policies cover these requirements.

Set up Search Console and read its signals carefully

Verify your site in Google Search Console, a free service for checking how Google crawls and indexes a site. A Search Console property is the site or domain you track. A Domain property covers the domain across protocols and subdomains; a URL-prefix property covers only addresses that begin with the specified URL prefix. Choose the property that fits your site and make sure the right owner can access it. Google explains the options in its property setup guidance.

After launch, inspect the homepage and representative pages from each page type. Use URL Inspection to compare Google’s information about an indexed page with a live test of what Google can access now. Submit your sitemap there if you have one, then check for processing or indexing issues as reports become available.

Read each result as evidence about one stage of search, not proof of overall success. A successful live test shows that Google can access a page at the time of the test. A submitted sitemap confirms a submission, not that every listed URL will be indexed. An indexed page can still be absent for a particular query because indexing and ranking are separate. Google also does not guarantee when it will crawl or index a new page, so an empty report immediately after launch does not by itself identify a fault. Its URL Inspection documentation describes what the tool can and cannot establish.

Check usability without treating scores as ranking promises

Test key pages on mobile, check that the site uses HTTPS, and fix loading, interaction, or layout problems that make pages difficult to use. Core Web Vitals are measures of loading performance, responsiveness, and visual stability. Google uses them in its ranking systems, but good scores do not guarantee high rankings; relevance and other factors still matter. A new site may not yet have enough real-visitor data for field reports, which measure how visitors experience pages. A lab test can help find technical problems, but it does not replace measurements from real users. Google explains the limits in its page experience guidance.

What SEO setup means for AI search

Google says the same SEO fundamentals apply to its AI features, with no additional technical requirements or special files to add. A page still needs to be accessible and eligible to appear in search. Those conditions do not guarantee that an AI feature will select, cite, or link to it. Google’s AI features guidance describes the relationship between search eligibility and those features.

Key Takeaways

• Choose one preferred URL version: Redirect alternate versions and keep canonical tags, internal links, and sitemap entries consistent.
• Remove launch barriers: Check the live site for crawl blocks, noindex instructions, login requirements, and error responses.
• Link important pages: Use crawlable navigation and internal links; treat a sitemap as an additional discovery aid, not a guarantee.
• Verify and monitor: Set up Search Console and inspect representative pages, while separating access, indexing, and ranking evidence.
• Set realistic expectations: Technical eligibility supports discovery, but does not promise rankings, traffic, rich results, or AI citations.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com