Website not showing on Google: what to do

Search Console: the reason behind each missing page

The Page indexing report, open only to the site's owner and the people they add, gives a reason for every URL left out of the index. Some of those reasons point to a setting on your site: a URL marked noindex, blocked by robots.txt, returning an error, redirected, a soft 404, or a duplicate for which Google chose a different canonical. Those are fixed on your side.

Others are Google's own decisions: a URL discovered but not crawled yet, or crawled and left out of the index. No setting forces those. A manual action, decided by a Google reviewer, has its own report in Search Console.

For a single URL, URL inspection tells you whether Google knows it, and which URL it kept instead. That is what showed that both home pages of our own site were unknown to Google.

Google also says not to expect every URL on a site to be indexed: duplicates and pages without meaningful information aren't, and that is normal. What matters are the pages you want people to find.

An instruction that keeps Google out

While a site is being built, it is common to ask search engines not to index it. If that instruction survives the launch, Google reads the pages and drops them, exactly as it was told. It takes one of these forms.

• A noindex rule, in the page (the robots meta tag) or in the server's response headers (X-Robots-Tag). Google reads the page and keeps it out of the index.
• The robots.txt file, which blocks crawling but not indexing: a disallowed URL can still appear in results without a description, and a disallowed page never shows Google its noindex rule. The guide on what robots.txt actually blocks covers that trap.
• A password or an access denial: a page that answers Google with a 401 or 403 is not indexed. That is the point on a customer area, not on a page you want people to find.
• A rule added or removed by a script. Google's JavaScript SEO documentation warns that when it finds noindex in the page as served, it may skip running the JavaScript, so a script that removes the rule afterward may have no effect. The guide on SEO for sites rendered with JavaScript compares what the server sends with what the browser displays.

A noindex rule isn't always a mistake, and you can only tell page by page. In the sample report on an online store, seven pages carry one: five hiking and trail running pages, a selection of bikes, and a product page. The report treats the listing pages as a defensible editorial choice. The product page is something else: an item for sale that search engines don't show.

A different URL kept instead of yours

When the same page is served at several URLs, Google keeps it once. It groups duplicate pages and picks the one it considers most representative. To Google, a canonical tag, which names the URL to keep, is a strong signal, not an order; so is a redirect; being listed in a sitemap is a weak signal. When these signals disagree, Google decides.

Your pages can then lose out to another URL: the http version, the non-www address, an old domain, a working copy. The canonical tag itself can push them out: if every page on a site names the home page as the URL to keep, or a URL that redirects or no longer exists, Google gets a strong signal, page after page, pointing away from the pages you want in results.

Then there is the soft 404: a URL that doesn't exist but answers "page found" (status 200). Google judges by the content: according to its documentation on HTTP errors, an empty page or an error message served as a success shows up in Search Console as a soft 404, and is not indexed. A real page that looks empty to Google can be classified the same way. The guide on soft 404 errors explains what a server should answer.

A new site Google hasn't found yet

Google says so in its overview of how Search works: it doesn't guarantee that it will crawl, index or show a page, even one that follows its guidelines. It finds URLs mainly through links on pages it already knows, and through sitemaps.

For a new site, that takes time. Google says crawling can take anywhere from a few days to a few weeks, and that requesting a crawl doesn't guarantee a page will make it into results. A new site that no other page links to is found slowly, without any setting being at fault.

Our own home pages, listed as "unknown to Google"

Our own site ran into this. It has two home pages, /fr/ and /en/. Its root, the address with no language folder, served a copy of the English home page with a 200 status, and a script sent French-language browsers on to /fr/. No internal link pointed to that root, and it wasn't in the sitemap.

The current version of the site went live on September 29, 2026. Three days later, URL inspection in Search Console showed most pages indexed, but both home pages listed as "unknown to Google." The root was indexed in their place. Clicks and impressions couldn't have shown it: a page missing from the index leaves no row in those reports. Only checking URL by URL brought it to light.

On October 2, 2026, we changed the server's response: the root now sends visitors, with a temporary (302) redirect, to the home page in their browser's language. It no longer serves a copy, and each home page has a single URL. Everything else already pointed to /fr/ and /en/, so removing the copy was enough. Whether Google keeps both home pages is still Google's call: the fix removes the duplicate, it doesn't dictate the index.

From the outside, you can see that the same page answers at two URLs. You can't see which one Google kept: only Search Console tells you that. That is why the two readings go together.

Access, leftover rules, one URL per page: where to start

Each step is access to get, a question to ask or a decision to make. The fixes themselves belong to whoever runs your site.

1. Get access to your site's Search Console in your own name, then read the reason Google gives for each missing page. It is the only place where Google says what it did with your pages. If your agency set it up for you, ask to be added as an owner: the site is yours, and so is its data.
2. Ask your developer or agency to confirm, for each of your important pages, that no do-not-index instruction from the build is still in place: a checked box in the content management system, a noindex tag, a disallow rule in robots.txt, a password. It is the simplest fix, and Google picks it up the next time it reads the pages.
3. Have one version of the site chosen, on https, with or without www, and one URL per page. Every other address (an old domain, the http version, a copy of the home page) should redirect to it, and the canonical tag, the sitemap and internal links should all point to it.
4. Have someone check that no working copy of the site is public. A staging site left public and indexed competes with the real site using the real site's own content.
5. If the site is new, give Google ways to reach it: a sitemap submitted in Search Console, and links from pages Google already knows, such as your partners' sites or your professional profiles. Then give it time.
6. If you can't find the cause, or want to check the answer you were given, have the site reviewed by someone who didn't build it. The guide on checking whether an SEO agency is doing its job covers what you can ask an agency for.

A forgotten noindex rule, an overly broad robots.txt line or a missing sitemap is fixed in one place, and Google takes it into account the next time it reads the pages, not instantly. The job is bigger when the same content lives at several URLs: an old domain, the http version, a staging copy, a root that duplicates a page, language versions. You have to decide which URL carries each page, then line up redirects, canonical tags, the sitemap and internal links behind it. Ask for it as a piece of work in its own right, with a deliverable: the list of URLs handled and what happens to each one.

There is no such thing as guaranteed indexing: Google itself doesn't promise it for any page. And if your pages are indexed but rank too low to be seen, that is no longer a settings problem. It comes down to your content, against the pages ranking above yours.

From outside, page by page, without Search Console

These percentages cover about 30 websites we audited between August 14, 2026 and September 24, 2026. Each one counts only the sites where the point could be checked. Many were audited because a defect showed up quickly, so these figures describe our audits, not websites in general.

Neither defect keeps a site out of Google on its own. Without robots.txt, Google treats everything as allowed; without a sitemap, it only has links to find pages. A soft 404 leaves Google to sort out, by itself, pages that don't exist.

The audit reads your site from the outside, in a browser, the way a visitor does, with no access to your hosting or your Search Console. It goes past the home page: on every page analyzed, it looks for whatever stops Google from reading the page, indexing it, or keeping the right URL. When Search Console gives a reason that points to a setting on the site, the report shows where that setting is.

• The noindex rules on every page analyzed, in the robots meta tag and in the response headers. On an important page, the rule is reported; on a page left out on purpose, it is normal, and the report doesn't count it as a defect.
• On the site's reference page, usually the home page, the version the server sends and the one the browser displays after scripts run. A canonical tag or noindex rule that exists in only one of the two is reported.
• The robots.txt file: rules that close the whole site to all crawlers or to Google's, and lines a crawler ignores.
• The canonical tag on every page: present, and leading straight to a page that responds, with no redirect and no noindex. A deep page that names the home page as the URL to keep is reported.
• The sitemap: present, readable, and actually listing pages.
• The response to a made-up URL: the server should answer 404. A 200 response is a soft 404.
• The entry addresses, over http and https, with and without www: only one should serve the site, and the others should redirect to it.
• The subdomains teams most often give a working copy: a public, indexable copy of the site is reported.

Reading a site from outside has limits, and the report writes them down instead of papering over them. In the store's report, every request that announces itself as a search engine crawler, Googlebot included, gets a refusal (403), while the same server answers a browser normally at the same moment. The report doesn't conclude that Google is blocked: the test doesn't come from Google's own addresses, and the site's presence in search results indicates the real crawler is served. What Googlebot itself receives, only Search Console can tell you.

The report names the pages behind each finding and what was observed on them, so whoever fixes them knows where to work, and you can check afterward that it was done. Every limit of the review is stated in the report. A point we could not verify is never presented as compliant.