Launching a Product Site: Search Basics

Teams building a web app or a marketing site spend most of their time on what the product does. Search usually arrives late, as a question after launch: why is nothing showing up? Many of the answers are decided in the build.

One thing to say plainly first: Google has no guidance on MVPs or product strategy. What it documents is how pages are found, crawled, rendered and indexed, and that is what this article covers. Where we give our own reading, we label it.

Content in the HTML, and what JavaScript changes

Google’s JavaScript SEO basics says Google processes JavaScript web apps in three phases: crawling, rendering and indexing. Googlebot fetches the URL, checks robots.txt, parses the response for links in href attributes, and queues pages with a 200 status for rendering. A headless Chromium then runs the JavaScript, and Google uses the rendered HTML to index the page.

Some JavaScript sites use an app shell, where the initial HTML does not contain the real content and Google must execute JavaScript to see it. The page says rendering can take longer than a few seconds, and it recommends server-side or pre-rendering anyway, because it makes a site faster for users and crawlers and not all bots can run JavaScript. Our reading is that content in the HTML is the sensible default, and client-side rendering a decision with a cost.

Status codes matter for apps too: a 404 for a missing page, a 401 for a page behind a login. Where client-side routing makes that impractical, the page suggests redirecting to a URL that returns a 404, or adding a noindex robots meta tag to error pages, to avoid soft 404s.

Links need the same care. Google’s link best practices say Google can generally crawl a link only if it is an a element with an href. Links that work through script events alone cannot be reliably extracted, although links inserted by JavaScript are fine if they use that markup. We cover the failure in more detail in why script-built links can be invisible to crawlers.

URLs that can stay put

Google’s URL structure guidance opens with requirements. Do not use fragments to change the content of a page, because Google generally does not support them; its example is https://example.com/#/potatoes, and it says to use the History API if JavaScript changes content. Use the common encoding for parameters, with an equals sign between key and value and an ampersand between pairs.

Its best practices are softer: readable words rather than long ID numbers, hyphens instead of underscores, as few parameters as possible, and awareness that URLs are case sensitive. It warns that complex URLs with multiple parameters can create unnecessarily large numbers of URLs for similar content.

If URLs do change later, our article on redirect chains and site moves sets out what Google says about redirects. Our reading is that a URL scheme you will not need to replace is the cheapest redirect plan there is.

Sitemaps and mobile-first indexing: two launch-day checks

The SEO Starter Guide says Google primarily finds pages through links from other pages it has already crawled, and that submitting a sitemap is optional. Its page on how to build and submit a sitemap adds the practical limits: 50MB uncompressed or 50,000 URLs per file, absolute URLs, and only the URLs you want to see in search results. Google ignores priority and changefreq, and uses lastmod only if it is consistently and verifiably accurate.

Mobile matters because of how indexing works. Google’s mobile-first indexing guidance says it uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking. It recommends responsive design as the easiest pattern to implement and maintain. Where the mobile version differs, it says to keep the same robots meta tags, structured data, titles and meta descriptions, and equivalent primary content. It also says not to lazy-load primary content on user interaction, because Google will not load content that needs swiping, clicking or typing.

Core Web Vitals and page experience, as Google frames them

Google’s Core Web Vitals page defines three metrics and the targets it wants: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint under 200 milliseconds and Cumulative Layout Shift under 0.1. It highly recommends good Core Web Vitals for success with Search, and points to the Search Console report for how your pages perform.

The page experience page keeps this in proportion. It says There is no single signal. Core Web Vitals are used by Google’s ranking systems, but other aspects, such as HTTPS, mobile display and intrusive interstitials, do not directly help a site rank higher, though they make a site more satisfying to use. It also says good scores do not guarantee a top ranking and that chasing a perfect score for SEO reasons may not be the best use of your time.

Structured data and Search Console before launch

Google’s introduction to structured data describes it as a standardised format that gives Google explicit clues about a page, and it can make a page eligible for rich results. The rule that matters at launch is that markup describes the page it sits on: do not add structured data about information that is not visible to users. It names the Rich Results Test for validating markup.

For ownership, Search Console’s help page on verifying your site ownership says you choose from the listed verification methods, that you can add more than one in case one fails, and that data is collected from the moment a property is added, even before verification. The starter guide also points to the URL Inspection tool for checking how Google sees a page.

Where Google’s guidance stops

None of these pages tells you what to build, who for, or in what order. They also promise nothing: the starter guide says there is no guarantee any site will be indexed, and that changes can take hours to months to show. Our reading is that a checklist built from them makes a site eligible to be found, not wanted.

Where this fits at Cultured Digital: product launches that search can read

Our Web Development work puts search in the architecture from the first template: logical, stable, human-readable URLs, semantic HTML with real headings, content in the HTML with JavaScript kept minimal, structured data designed with the content model, and performance budgeted rather than hoped for. For founders, the path runs from concept to MVP to live product to organic search, launching with indexing, structure and tracking in place. Simple projects stay simple, with no six-month engagement for something that should ship in weeks.

The detail is on our products guide, which covers MVPs, custom tools and digital products. We can lead the build, join your team, or specify the SEO requirements and review the result. There are no price tables; scope is agreed after a conversation, and we do not promise rankings or traffic numbers.

Launching a product site: the search basics Google documents