Why Is My Website Not Showing Up on Google? Diagnose It

Search why is my website not showing up on google and you get a list of fourteen reasons. Then a list of ten. Then a Reddit thread, two Quora threads, and an AI Overview that cites the Reddit thread alongside Google's help page. We pulled that SERP from Ahrefs on 17 September 2026, ten positions deep, and three of the ten slots are forums.

Forums win here for a reason. A listicle answers "what could be wrong with a website". The person searching wants to know what is wrong with their website, and a list of fourteen candidates does not narrow anything down.

So this article is not a list of reasons. It is a diagnostic: four branches, a check that tells you which branch you are in, and a fix for that branch only. Everything here comes from Google's own documentation, quoted and dated, because the reason strings you are about to read are not opinions. They are the literal text Search Console prints.

The question hides four different problems

"Not showing up on Google" is one sentence covering four situations that have nothing in common:

1. Google has never fetched the page. It does not know the URL exists, or it knows and has not got round to it.
2. Google fetched the page and declined to index it. It has the content. It decided the content does not earn a slot.
3. You blocked it yourself. A robots rule, a noindex tag, or an auth wall is doing exactly what you configured it to do.
4. The page is indexed and ranking somewhere you never looked. Position 43 is invisible, and so is position 8 for a query nobody searches.

Each branch has a different fix, and three of the four fixes do nothing for the other three branches. Writing more content will not help a page blocked by robots.txt. Removing a noindex will not help a page Google crawled and judged thin. Rebuilding your sitemap will not help a page that is already indexed at position 43.

The listicles that rank for this query flatten all four into one bucket. That is why they read as plausible and leave you no further along than you started.

Step 1: stop using site: as your diagnostic

The first thing almost everyone does is search site:yourdomain.com. Google's own help page on missing pages does recommend it, with the syntax site:example.com, so it is a legitimate first look. The problem is what you can do with the answer.

A site: search returns results or it does not. When it returns nothing, you have learned that something is wrong, which you already knew. When it returns your homepage but not your pricing page, you still do not know whether the pricing page was blocked, skipped, crawled and refused, or simply not reached yet.

Search Console answers the question site: cannot. The URL Inspection tool gives, in Google's words, "information about Google's indexed version of a specific page", and that is a different class of answer: it names the state.

One trap in that tool catches almost everyone. The panel that opens by default is not a live fetch. Google states it plainly: "This is not a live test. The results shown are from most recently indexed version of a page, not the live version on the web." If you removed a noindex tag an hour ago, the default panel will still show you the old verdict. The "Test live URL" button is the one that fetches the page now.

Read both. The difference between the indexed version and the live test is itself a diagnosis: it tells you your fix landed but has not been recrawled yet.

Step 2: read the exact status string

The Page Indexing report and the URL Inspection tool print a fixed vocabulary. These are the strings Google documents, and each one maps cleanly to one of the four branches:

Write down your string before you do anything else. The rest of this article is organised by branch, and you only need to read yours.

Branch 1: Google has never fetched the page

The string is "Discovered - currently not indexed", and Google's explanation is more specific than most people expect: "The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl."

That sentence changes the fix. Google is not ignoring you out of indifference in this state. It reached your server, formed an opinion about how much load it could take, and backed off. A slow or flaky host produces this status on sites with perfectly good content.

So the first checks are server-side, not content-side. Time your own page from a cold cache. If your time to first byte sits in seconds rather than hundreds of milliseconds, that is the lever.

curl -s -o /dev/null -w 'ttfb=%{time_starttransfer}s total=%{time_total}s code=%{http_code}\n' \
  https://yourdomain.com/the-missing-page

The second check is discovery. A URL Google has never seen cannot be scheduled at all. Three mechanisms put it on the list, and they are not equivalent:

• A sitemap declares the URL exists. It is the cheapest and the weakest signal.
• An internal link from a page Google already crawls tells it the URL matters to you. This is the strongest of the three for a new page.
• An external link from any site Google crawls often gets a URL found fast.

An orphan page, one with no internal links pointing at it, sitting only in a sitemap, is the classic Branch 1 case. Check your own navigation before blaming Google. If your blog index paginates and the post is on page 4, Google has to walk four hops to reach it, and it may not bother for a while.

There is a fourth mechanism people forget: the URL Inspection tool's "Request indexing" button. Use it once. Google is explicit that "Submitting a request does not guarantee that the page will appear in the Google Index", and there is "a daily limit to how many index requests you can submit". Pressing it every day is not a strategy, and nobody can guarantee a result from it.

Branch 2: Google fetched it and said no

The string is "Crawled - currently not indexed", and the official gloss is the most honest sentence in the whole Search Console vocabulary: "The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling."

Read the last clause. Google is telling you the resubmit button will not help. Most advice for this status is "request indexing again", which is directly contradicted by the documentation for the status itself.

This is a quality verdict, and Google backs it up elsewhere with a line worth keeping: "Google doesn't guarantee that all pages everywhere will make it into the Google index." The web is bigger than the index. Being crawled is not a promise of entry.

What actually moves a page out of this state is narrower than "write better content". In practice it is one of four things:

• The page is a near-duplicate of another page on your site. Google is deciding it already has this. Check for a template page where only a city name or a product attribute changes.
• The page is thin against what ranks. Not thin in word count, thin in answers. If the top results resolve the query and yours restates it, there is nothing to index that Google does not have.
• The page is a soft 404. It returns HTTP 200 while the content reads as absent: an empty search result, a "coming soon", a category with no products. Google has a named status for this, and the fix is to return a real 404 or put real content there.
• Nothing links to it internally. A page nothing on your site points at reads as a page you do not believe in either.

Two of the strings in the table are not failures at all. "Alternate page with proper canonical tag" means your canonical is working: the page is a variant and Google indexed the original. Our SEO content audit piece covers when to consolidate those variants and when to leave them.

"Duplicate, Google chose different canonical than user" is the interesting one. You declared a canonical and Google overruled it. That happens when your internal links, sitemap, and canonical tag disagree with each other, and Google resolves the contradiction in favour of the signal you send most often.

Branch 3: you blocked it, and you probably did not mean to

This is the branch with the highest ratio of severity to effort. The fix is usually one line, and the cause is usually a config that was correct in staging and shipped to production unchanged.

Start with the file itself. robots.txt has to sit at the root of the host, and Google's documentation is blunt about what it is for: "A robots.txt file tells search engine crawlers which URLs the crawler can access on your site. This is used mainly to avoid overloading your site with requests; it is not a mechanism for keeping a web page out of Google." That page was last updated 2025-12-10.

curl -s https://yourdomain.com/robots.txt

If you see Disallow: / under User-agent: *, that is your answer and you can stop reading. A staging site's robots file deployed to production blocks everything, and it is the single most common cause of a site that vanished overnight rather than never appeared.

Now the trap that costs people weeks. Blocking a URL in robots.txt and putting a noindex tag on it are not belt and braces. They cancel each other out. Google's page on blocking indexing states it directly: "If a page is blocked by a robots.txt file or the crawler can't access the page, the crawler will never see the noindex rule, and the page can still appear in search results."

The crawler has to fetch the page to read the tag. Block the fetch and the tag is invisible. That produces the status "Indexed, though blocked by robots.txt": your URL appears in results, with no description, permanently, because the instruction telling Google to drop it is behind the wall you built.

The reverse holds too. Google explains that "a page that's disallowed in robots.txt can still be indexed if linked to from other sites", because "the URL address and, potentially, other publicly available information such as anchor text in links to the page can still appear in Google Search results".

To actually keep a page out, let Google crawl it and serve one of these:

<meta name="robots" content="noindex">

<meta name="googlebot" content="noindex">

Or as a response header, which is the only option for a PDF or an image:

X-Robots-Tag: noindex

If you run Next.js, the robots file is generated code and worth reading rather than guessing at. In this repo, on Next 16.2.12, src/app/robots.ts exports a function returning a MetadataRoute.Robots object:

import type { MetadataRoute } from 'next'

export default function robots(): MetadataRoute.Robots {
    return {
        rules: [
            {
                userAgent: '*',
                allow: '/',
                disallow: ['/api/', '/dashboard', '/onboarding'],
            },
        ],
        sitemap: 'https://yourdomain.com/sitemap.xml',
    }
}

The bug to look for is a disallow entry that is a prefix of something public. disallow: ['/blog-admin'] also blocks /blog-admin-notes, and disallow: ['/p'] blocks every path starting with p. Our Next.js SEO article walks through the metadata and sitemap routes in the same file layout.

On a hosted platform the same failure has a different shape. Squarespace, Wix, Shopify and WordPress all ship a "discourage search engines" or "hide from search" switch, and it is on by default on a trial or staging plan. One of the pages ranking for this query is Squarespace's own help article about exactly that switch, which tells you how often it happens.

Finally, check the boring HTTP layer. A 401 or 403 to the crawler is a documented not-indexed reason, and password-protected sites produce both. So does a firewall or bot-protection rule that serves a challenge page to anything that is not a browser.

curl -sI -A 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)' \
  https://yourdomain.com/the-missing-page | head -5

Compare that to the same request with a normal browser user agent. If they differ, something in your stack is treating crawlers as hostile traffic.

Branch 4: it is indexed and you are searching the wrong thing

The status says "Page is indexed" and you still cannot find yourself. Nothing is broken. You are looking for a page at position 43 by scanning page one.

Two habits produce this reliably. The first is searching for your own business name and assuming brand queries represent everything. The second is searching from a browser logged into your own Google account, in your own city, with your own history, which is not what a stranger sees.

The honest check is the Performance report in Search Console, not a manual search. It tells you which queries produced impressions, at what average position, and whether anybody clicked. A page at average position 30 with 400 impressions and zero clicks is not missing from Google. It is in the part of Google nobody scrolls to.

That distinction matters because the fix is a different job entirely: the page exists, it needs to beat the pages above it. How long SEO takes to work covers the timing side of that, and is SEO worth it covers the arithmetic of whether the climb pays for itself.

There is a third case worth naming. Your page is indexed, ranks fine, and the query now resolves inside an AI Overview or an assistant answer where nobody clicks through. That is a visibility problem with a different measurement, which is what answer engine optimization and LLM SEO are about.

How long before "not yet" becomes "a problem"

Google gives two numbers, and they are the only two worth quoting because everything else on this topic is guesswork.

From the Search Console help page on missing pages: "allow at least a week after submitting a sitemap or a submit to index request before assuming a problem". And on total time to index: "The total time can be anywhere from a day or two to a few weeks, typically, depending on many factors."

A week is the threshold for panic, not a day. If you launched on Monday and searched on Tuesday, you have not found a bug, you have found impatience.

The same page is candid about the ceiling: "The web is immense, and Google doesn't get to every page, though we try to!" Combined with "Google doesn't guarantee that all pages everywhere will make it into the Google index", the honest reading is that indexing is a decision made about your page, not a service you are owed. No one can guarantee a position, a timeline, or even entry into the index, and anybody who does is selling something.

Checking every URL at once instead of one at a time

Clicking through the URL Inspection tool works for one page. It does not work for the 200 pages of a store or a blog archive, and this is where most people give up and assume the whole site is broken.

The same data is available over the API. The request is a POST to https://searchconsole.googleapis.com/v1/urlInspection/index:inspect with two required fields, inspectionUrl and siteUrl, where siteUrl is the property exactly as it appears in Search Console.

curl -s -X POST \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"inspectionUrl":"https://yourdomain.com/the-missing-page","siteUrl":"sc-domain:yourdomain.com"}' \
  https://searchconsole.googleapis.com/v1/urlInspection/index:inspect

The fields that answer this article's question live under indexStatusResult. coverageState carries the same string you saw in the table. robotsTxtState returns ALLOWED or DISALLOWED. indexingState returns one of INDEXING_ALLOWED, BLOCKED_BY_META_TAG, BLOCKED_BY_HTTP_HEADER or BLOCKED_BY_ROBOTS_TXT, which sorts Branch 3 into its three sub-causes with no guessing. pageFetchState returns SUCCESSFUL, SOFT_404, NOT_FOUND, ACCESS_DENIED, SERVER_ERROR, REDIRECT_ERROR and others.

One documented limit shapes how you use it: "Presently only the status of the version in the Google index is available; you cannot test the indexability of a live URL." The API is the default panel, never the live test. Fix something and the API will keep reporting the old state until Google recrawls.

Per-site quotas are 2,000 queries per day and 600 per minute, documented on the Search Console API limits page last updated 2025-08-28. That is enough to sweep a few hundred URLs nightly and diff the result, which turns "my site is not showing up" into a dated log of which URLs changed state and when. SEO for SaaS goes further into wiring that into a cron job.

Four fixes that do nothing

Every one of these appears in articles ranking for this query today.

• Resubmitting your sitemap repeatedly. A sitemap declares URLs. Declaring them twice does not make them more declared. If the status is "Crawled - currently not indexed", Google has already told you not to resubmit.
• Pressing "Request indexing" daily. There is a documented daily limit, and the request carries no guarantee. Once per meaningful change is the correct cadence.
• Meta keywords. Google has not used them for well over a decade. Filling the tag costs nothing and does nothing.
• "Submit your site to 500 search engines" services. There are not 500 search engines worth submitting to, and the two that matter, Google and Bing, both take submissions directly and for free through their own consoles.

What is left after you remove those is unglamorous: make sure the page is reachable, make sure nothing blocks it, make sure it answers something, then wait a week before concluding anything. DIY SEO for small business lists the checks in the order a non-specialist can run them, and how much SEO costs covers what you would be paying somebody else to do the same thing.

Run the diagnosis in order

The whole procedure fits in six steps, and the order matters because each step makes the next one cheaper.

1. curl https://yourdomain.com/robots.txt and look for Disallow: /. Thirty seconds, and it resolves a meaningful share of cases outright.
2. Open URL Inspection on the exact URL, and read the default panel and the live test separately.
3. Write down the status string, verbatim.
4. Match it to a branch in the table above and read only that branch.
5. Apply the one fix for that branch.
6. Wait a week. Recheck the same URL and compare the string, not your memory of it.

The reason this beats a list of fourteen causes is that it terminates. You either have a string or you have a page that is indexed, and both of those are actionable. "Could be any of fourteen things" is not.

If the string comes back "Page is indexed" and you are still invisible, the article you need is not this one. Your page is in Google and losing, which is a content and competition problem rather than a technical one. Product page SEO and Google Business Profile optimization each take that from a different angle depending on what you sell.

FAQ

How do I get my website to show up on Google?

Make the URL reachable by a crawler, make sure nothing blocks it, and give Google a path to it. In practice that is three things: no Disallow rule covering the page, no noindex tag or X-Robots-Tag header on it, and at least one internal link from a page Google already crawls. A sitemap helps discovery but is the weakest of the signals. Verify the property in Search Console so you can read the status rather than guess at it, then allow at least a week, which is Google's own stated threshold before assuming a problem.

Why is Google not crawling my website?

If the status is "Discovered - currently not indexed", Google's documentation says the crawl was rescheduled, typically because fetching the URL "was expected to overload the site". Check your server response times before your content. If the status is "URL blocked by robots.txt" or a 401 or 403, the crawler is being refused at the door and no amount of waiting changes that. If Google has no record of the URL at all, nothing links to it and it is in no sitemap, so discovery never happened.

Why is my website not popping up?

Usually because you are searching for it rather than measuring it. A logged-in search from your own location and history is not what a stranger sees, and a page at position 40 is invisible without being broken. Open the Performance report in Search Console and look at impressions and average position for the queries that matter. If impressions exist, the page is indexed and the problem is competition. If impressions are zero across the board, go back to the URL Inspection tool and read the status string.

How long does it take for a website to show up on Google?

Google's stated range is "anywhere from a day or two to a few weeks, typically, depending on many factors", and its advice is to "allow at least a week after submitting a sitemap or a submit to index request before assuming a problem". There is no guaranteed figure, and results vary with your server, your link profile, and how much of the web Google is processing that week. The documentation also states plainly that Google "doesn't guarantee that all pages everywhere will make it into the Google index", so a page can remain out indefinitely.

Does requesting indexing in Search Console make the page rank?

No. The two are separate. Requesting indexing asks Google to consider fetching a URL, and Google states that "submitting a request does not guarantee that the page will appear in the Google Index". Even when it works, being indexed only makes the page eligible to appear for a query. Where it appears is decided by everything else: what the page answers, what competes with it, and what links to it.

Why does site:mydomain.com show fewer pages than Search Console?

Because they answer different questions. A site: search is a search, filtered to your domain, and it is not a report of your index coverage. The Page Indexing report counts URLs by status across the property, including ones that would not surface in a site: search. When the two disagree, the Search Console number is the one built for this purpose, and the per-URL status string is more useful than either total.