A polished site can be live, fast, and full of thoughtful copy while being effectively absent from the market. The failure is rarely that nobody wants what the company sells. More often, the launch has broken the route between the business, search engines, and the channels that should send people in.
“You launched and nobody came” is usually a discovery problem before it is a demand problem. The first response should not be redesigning the homepage, publishing more articles, or debating campaign creative. It is proving that the real domain is reachable, crawlable, indexable, measurable, and connected to a real distribution path.
Across B2B launches, the mistake we see most often is checking analytics before checking whether Google has been told where the company actually lives. Analytics can confirm a visit. They cannot repair a blocked crawler, a broken redirect, or a canonical tag pointing to a preview environment.
TL;DR
- Start by checking whether every version of the domain resolves to one real production home.
- Then check whether crawlers are allowed in:
robots.txt, meta robots, and server-level indexing directives. - Confirm that the sitemap and canonical tags name the production domain, not a preview or legacy host.
- Use Google Search Console to compare the canonical you declare with the canonical Google selects.
- If searching your brand returns zero owned pages, treat that as a launch fault, not a patience problem.
- Only after those checks should you worry about analytics, campaigns, or more content.
The diagnosis: a live website can still be pointing search elsewhere
A staffing company serving EU institutions made this failure painfully clear. Its public site had launched, yet searching the company’s name returned zero pages it owned. The issue was not brand awareness alone. Its XML sitemap and page-level canonical tags pointed to a preview hosting domain instead of the real production domain. At the same time, the bare production domain returned 404 pages.
Google was being told that the real company lived somewhere else. The browser-facing site looked present, but the signals that matter for discovery contradicted the business’s intent. A prospective buyer, candidate, or partner searching by brand name had no reliable route to the production site.
That is why we would treat the first-hour checklist as a business-critical launch control, not an SEO tidy-up. Discovery is a business function. If a company cannot be found when someone searches directly for it, every sales asset, partnership, launch post, and piece of authority-building content is working with a broken destination.
The important term here is canonical. A canonical tag tells a search engine which URL should represent a page. Canonicalization is the search engine’s process of deciding which version is the preferred one. If your sitemap, redirects, and canonical tags disagree, Google has to choose among conflicting signals. In the staffing-company case, those signals were not merely messy. They were actively pointing away from the business’s real home.
What to have ready before you begin
This is not a broad site audit. It is a focused handover check designed to establish whether the production site is capable of being discovered. Bring together the person who can change domain and deployment settings, the person responsible for the site’s content and marketing, and access to the systems that show search and analytics status.
- The intended production domain and preferred public version of it.
- A short list of revenue-critical pages: homepage, core service pages, job or product pages, and contact or conversion pages.
- Access to the site’s domain configuration, sitemap, robots settings, and deployment environment.
- Access to Google Search Console and the analytics property used by the production domain.
- A named owner who can make a decision and resolve a fault immediately.
Those inputs matter because the first hour is not for theory. It is for checking whether the same answer appears everywhere. When a browser, a crawler, and a search engine ask where the company lives, they should all arrive at the same production domain. If one person sees the right homepage while Google is being handed a preview host, the launch is not healthy.
Do not turn this into a committee exercise. The goal is to make the production domain internally consistent. Every technical signal should reinforce the same answer when a crawler asks: “Which version of this page is real?”
The first-hour checklist, in the order we would run it
Start with reachability and domain consolidation
Open the public site through every common variation of the domain: the bare version, the secured version, and any version using a www host. They should resolve to a single preferred public host through permanent redirects, rather than loading duplicate versions or failing altogether.
What you want to see is consistency. The homepage and critical commercial pages should load from the intended production host, and alternate versions should support that choice rather than compete with it. A healthy launch gives a crawler one clear route. An unhealthy launch makes the same company appear to live in several places at once.
The homepage and critical commercial pages must return a successful server response and display the real production content. A public-looking page that sends visitors to a placeholder, staging banner, login wall, or error page is not live in the only sense that matters.
The staffing-company example shows why this goes first. The bare domain returned 404 pages. Even if the preferred host loaded correctly, that missing root-level route weakened the clarity of the entire launch. Domain variants are not a cosmetic detail; they are competing statements about where the business exists.
That is also why a founder should take the symptom seriously when brand search returns zero owned pages. If one path to the site breaks at the root while another path works in a browser, the team may assume the launch is basically fine. Search engines do not grade on that curve. They read the conflicting signals as evidence that the site is not fully settled.
Common mistake: accepting temporary redirects or allowing multiple versions of the site to load independently. That fragments signals and makes the search engine’s canonical choice less predictable. Choose the production host deliberately, then make every other route support it.
Remove crawl and index blocks before looking at traffic
Next, inspect robots.txt on the live domain. It should load publicly and allow crawlers to reach the sections that matter to the business. A staging-era block such as Disallow: / can survive a launch even when every page looks correct in a browser.
Then inspect the homepage and key page templates for noindex directives. Check both page-level meta robots settings and server-delivered X-Robots-Tag headers. Teams often remove a visible staging banner and assume the environment is production-ready, while a hidden noindex instruction remains active upstream.
For a B2B company, protect the paths that create commercial discovery: service pages, job listings where relevant, expertise pages, and the pages used in sales outreach. If those routes are blocked, the site may technically exist while the market has no dependable way to find it.
What you should see here is absence of contradiction. The live domain should not say “index me” in one place and “keep out” in another. If the brand search symptom is zero owned pages, crawl blocks are among the first explanations to clear. Until they are ruled out, low traffic numbers do not tell you much.
This is the point where teams often lose time because the site feels finished. The copy is approved. The design is approved. Internal stakeholders can click around and reach the pages they expect. None of that proves those pages are eligible to appear in search. The first-hour checklist is meant to separate human visibility from search visibility.
Make the sitemap describe the production business, not the preview build
The XML sitemap is one of the clearest machine-readable declarations of what the company wants indexed. It should be reachable on the production domain and contain only production URLs that are intended to appear in search and load successfully.
Do not treat a sitemap as a box to tick. It is a distribution instruction. In the staffing-company case, the sitemap listed preview-hosting URLs. That sent Google toward a version of the company that the business did not intend prospects to see.
What you want to see is that the sitemap reads like a clean inventory of the public business. The homepage URL should be on the production host. So should the major service pages, contact pages, and any other indexable assets that matter commercially. Preview URLs, redirected URLs, error pages, and blocked pages do not belong there.
This section matters more than many teams realize because the zero-owned-pages symptom can persist even when a site looks polished. If the sitemap names the wrong host, you are effectively publishing a map to somewhere else. Submitting that sitemap quickly does not solve the problem. It simply accelerates the wrong instruction.
Add the sitemap location to robots.txt, then submit the production sitemap through Google Search Console and Bing’s webmaster tools. Submit only after the URLs are correct. A fast submission of the wrong sitemap simply accelerates the wrong instruction.
Check canonical tags on the pages that carry commercial intent
A canonical tag tells search engines which URL should represent a page. On a unique, indexable production page, the canonical should point back to that same page using an absolute production-domain URL.
Check the homepage first, then inspect the major templates: service pages, job pages, resource pages, and any landing pages tied to active sales or marketing activity. The declared canonical should not point to a preview host, a legacy domain, a generic category page, or a different page in a chain.
What you should see is self-consistency. A unique page should name itself on the production domain. If several important pages point their canonicals elsewhere, the site is effectively arguing against its own discoverability.
This is the highest-leverage check in a launch that looks live but cannot be found. In the staffing-company example, the canonical tags reinforced the sitemap error. Together, they gave Google repeated evidence that the preview host — not the production domain — was the authoritative home of the company.
That is the exact sort of fault that produces the strange but revealing result founders describe as, “The site is up, but searching our name shows nothing we own.” When the declared canonical and the production domain disagree, search can follow the declaration instead of the team’s assumption.
Do not use canonicals to compensate for messy domain management. Redirects, internal links, sitemap URLs, and canonical tags should all agree. A canonical is a strong signal, but a consistent site-wide pattern gives Google far less room to choose a different version.
Use Search Console to confirm what Google sees
Once the public routes, crawl rules, sitemap, and canonical tags are aligned, inspect the homepage and priority pages in Google Search Console. Confirm that the inspected URL belongs to the intended production property, then compare the user-declared canonical with the canonical Google selected.
This is the moment where opinion gives way to diagnosis. If your declared canonical and Google’s selected canonical match on the production domain, that is a healthy sign. If Google selects a different domain or an unrelated URL, treat that difference as evidence that another signal is still out of line.
If Google selects a different domain or an unrelated URL, do not dismiss it as a reporting quirk. It is a diagnosis. Recheck the page canonical, internal links, sitemap entry, redirect behaviour, and any surviving preview-domain references. The Page Indexing report can also expose blocked pages, soft errors, and cases where Google has chosen a different canonical.
For the staffing-company pattern, this is where the invisible launch becomes legible. A browser may show the right site, but Search Console can reveal that Google has clustered trust around a different host. That helps explain why a brand-name query yields zero owned pages even though internal teams insist the site is live.
Request indexing only after the production signals agree. New sites can take time to appear, but waiting is not a strategy when the site is blocked, broken, or declaring the wrong domain as canonical.
Prove brand-name discoverability
Run a direct search for the company brand name, both quoted and unquoted. Then run a diagnostic search using site:your-production-domain.com brand name. The immediate objective is simple: establish whether any page from the production domain is appearing for the company’s own identity.
This is not a vanity check. It is a practical answer to a basic launch question: when someone actively looks for the company, do they reach the company? A healthy result is not necessarily perfect ranking breadth on day one. It is evidence that the production domain has entered the index as the company’s real home.
Zero owned results is not a normal launch metric to rationalise away. It is a signal to revisit indexing and canonicalisation before investing further in search content or paid distribution. A company should not need to outspend competitors to be found for its own name.
In the staffing-company case, that zero-owned-pages result was not a mystery once the technical signals were reviewed. It was the market-facing symptom of a sitemap and canonical setup that kept naming the preview host, combined with a bare domain that failed at the root.
Verify measurement, then create a real path into the site
Confirm that analytics records visits on the production domain. Use a genuine visit from a separate device or network and verify that the visit appears in the correct property. This proves measurement, not discoverability. A working analytics setup can record a handful of direct visits while Google still cannot index the site correctly.
That distinction matters because founders often see a few sessions and conclude the launch is broadly functioning. It may only prove that people with the exact URL can arrive. It does not prove that search engines understand the site, or that anyone searching the brand will be led to owned pages.
Then make sure an owned channel links to the live domain. Update founder and employee email signatures, the company LinkedIn page, the existing mailing list, sales decks, proposal templates, directories, job platforms, and relevant procurement profiles. Replace every preview or legacy URL.
This is where distribution starts. Search visibility compounds over time, but a new launch should not depend on search alone for its first discovery. Owned channels create immediate routes for customers, partners, candidates, and existing contacts — while also reinforcing that the production domain is the place the business intends to send people.
For teams facing near-zero visitors, this is also the point to check for the “zero owned pages, zero owned links” combination. If search cannot find you and none of your existing channels point cleanly to the new domain, the issue is not weak demand. It is that the routes into the business were never fully connected.
Where launch teams waste time
- Refreshing analytics repeatedly: analytics cannot tell you whether canonical tags point to a preview domain.
- Blaming the site’s age immediately: newness can delay indexing, but crawl blocks, error responses, and wrong canonicals are more urgent explanations.
- Fixing only the homepage: broken templates can leave service, jobs, resources, or campaign pages invisible even when the homepage looks healthy.
- Running paid traffic to an uncertain destination: paid clicks do not repair a broken technical handover and can send expensive attention to the wrong host.
- Leaving legacy and preview links in commercial materials: every outdated link trains partners and prospects to use a destination the company no longer controls.
These mistakes share the same underlying flaw: they treat discoverability as a promotion problem before it has been validated as an infrastructure problem. In the first hour, the job is not to generate demand. It is to verify that the company has a single reachable, indexable, publicly signposted home.
The better move: turn launch checks into a distribution system
The durable answer is not a heroic launch-day scramble. It is a release gate that treats production-domain clarity as a requirement for publishing. Before any major release, confirm the preferred host, redirects, robots directives, sitemap URLs, canonical tags, analytics property, and owned-channel links.
Give every check a named owner, a trigger, and a next action. If a page returns an error, someone owns the correction. If Google selects the wrong canonical, someone owns the investigation. If a deck still links to a preview URL, someone owns the replacement. Systems outperform memory, especially once a company has multiple campaigns, contributors, domains, and releases in motion.
That is the wider strategic lesson. Authority is not only what a company publishes. It is also the reliability of the routes that let buyers discover, verify, and return to that company. Content cannot compound when the underlying domain signals are fragmented.
What a healthy launch looks like
Done right, the site has a single clear production home. Its redirects, sitemap, canonical tags, internal links, crawl rules, and external links all point to that same destination. Google Search Console sees the intended pages, analytics measures visits to the correct domain, and owned channels give real people a direct route in.
The essential sequence is straightforward: establish reachability, remove index blocks, correct sitemap and canonical signals, confirm Google’s interpretation, prove brand discoverability, then activate owned distribution. That order prevents the most expensive launch mistake of all: building visibility on top of a site that search engines have been told not to trust.
If you launched and nobody came, assume nothing. Check whether the market can actually reach the company you think you published. In many cases, as the staffing-company example shows, the site is not failing because demand is absent. It is failing because the business has accidentally told search that it lives somewhere else.
Leave a Reply