You published a site, searched for its name, and got nothing. Maybe you tried site:yourdomain.com and got nothing there either.
Almost always, the site is not in Google's index yet — it is not that it ranks badly. There are three reasons that happens: Google has not found the page, something is telling Google not to index it, or Google fetched it and decided not to. A plain search cannot tell those apart. Google's free Search Console can, page by page, and each answer has a different fix.
The 30-second version
The quoted names are the statuses Google's Page indexing report uses.
| You see | It means | Do this |
|---|---|---|
| Nothing at all, and the site is days old | Google has not discovered it | Link to it from a page Google already knows; add the site to Search Console; submit a sitemap |
| URL Inspection says the URL is not on Google | Not in the index | Read the reason in the same report — it is one of the rows below |
| "URL marked ‘noindex’" | A meta tag or an X-Robots-Tag header asked Google not to index it |
Remove it; check the response headers too, not only the HTML |
| "URL blocked by robots.txt" | Google is not allowed to fetch the page | Remove the Disallow rule |
| "Discovered - currently not indexed" | Found, not fetched yet | Wait; link to the page from your other pages |
| "Crawled - currently not indexed" | Fetched, not chosen | Make the page worth indexing, then request indexing once; resubmitting an unchanged page does not help |
| "Duplicate without user-selected canonical" | Google thinks another URL is the same page | Pick one address; redirect the other, or point a canonical at it |
| "Soft 404" | The page looks empty or like an error | Serve real content with a 200, or a real 404 |
| "Blocked due to unauthorized request (401)" | The page needs a login or a password | Expected for a private page |
| Indexed, but not found for your name | That is ranking, not indexing | A different problem from the one this article solves |
Not indexed, or just not ranking?
The usual first check is a search for site:yourdomain.com. It is a reasonable smoke test, but Google says the operator doesn't necessarily return all the URLs that are indexed. An empty result is a hint, not a diagnosis.
The real answer is in Google Search Console. Add your site — a URL-prefix property can be verified with an HTML file or a meta tag on the site itself — then paste any page's address into the URL Inspection box at the top. It tells you whether that exact URL is on Google, and if not, why not.
If it says the page is on Google but nobody finds it, you have a ranking problem: the page exists in the index and loses to other pages for the words people search for. That is a question about content and links, and nothing below will change it.
How Google finds a new site
Google discovers pages mostly by following links from pages it already knows, and secondly from sitemaps. Its starter guide is plain about what that asks of you: "You usually don't need to do anything except publish your site on the web."
The catch is one word in that sentence: usually. A brand-new site that nothing links to has no way in except a sitemap or a manual request. The fastest honest fix is a link from somewhere Google already crawls — your GitHub profile, a social profile, another site of yours.
Then there is time, and Google gives several figures on different pages:
- Recrawling "can take anywhere from a few days to a few weeks".
- After a request in URL Inspection, indexing "typically takes only a day or so, but can take much longer in some cases" — and the same page says elsewhere that it "can take up to a week or two".
- For changes in general, "some changes might take effect in a few hours, others could take several months".
None of them is a promise. Google says it doesn't guarantee that it will crawl, index, or serve your page.
Something is telling Google not to index it
This is the cause that is easiest to fix, and the easiest to miss because the instruction is often invisible from the page itself.
A noindex in the HTML or in a header
noindex can live in two places, and Google honours both:
<meta name="robots" content="noindex">X-Robots-Tag: noindexThe second is an HTTP response header. It never appears in your HTML, in your source code, or in "view source". It is set by the server, and some hosts set it for you. Check what the server actually sends:
curl -sIL https://yourdomain.com/the-page | grep -iE '^(HTTP|x-robots-tag)'-L follows redirects and prints the headers of every response along the way, so each HTTP line starts a new response and the last one is the page you end up on — a noindex on a redirect is not a noindex on the page. The header can also differ from path to path, so check a page that is missing, not only the home page. No x-robots-tag line means no header. If you see noindex, it came from the host or from a header rule in your configuration — not from your page.
We checked four default addresses on 8 November 2026. A GitHub Pages user site, a *.vercel.app production site and a *.netlify.app site sent no X-Robots-Tag — though Vercel sends it on preview deployments and on a deployment's own unique URL, even a production one, so check the production domain rather than a deployment URL. A default *.dropto.live address sends noindex on every response, on purpose: a shared domain anybody can publish to is a gift to SEO spammers, and noindex takes away what they would come for. On that host a site becomes indexable on its own custom domain, as long as it is not behind a password or an invite list. Whatever your host, the curl line above is how you find out.
If you remove a noindex, Google only sees the change on its next crawl, and depending on the importance of the page, it may take months for Googlebot to revisit. Request indexing in URL Inspection once the tag or header is gone.
robots.txt, and the trap inside it
robots.txt controls what Google may fetch, not what it may index. Google's own words: it is not a mechanism for keeping a web page out of Google.
That leads to a trap people walk into from both sides. A page blocked in robots.txt and also marked noindex will not be removed, because Google is not allowed to fetch the page and so will never see the noindex rule. If you want a page out of Google, let it be fetched and mark it noindex. If you want it in, remove the Disallow.
Check https://yourdomain.com/robots.txt directly, rather than the file in your project. A CDN can add rules you did not write — Cloudflare, for one, prepends its own directives when its managed robots.txt is switched on.
A login, a password, or a page that looks empty
A page that answers with a login screen or a 401 is a page Googlebot will not crawl. That is correct for anything private.
A page that answers 200 but looks like nothing — an empty app shell, a "not found" message with a success status — can be reported as a "Soft 404". If that is your single-page app's unknown routes, why a static site 404s on refresh covers the status codes.
Google found it and decided not to index it
Two statuses cause most of the worry, and neither is an error in itself.
"Discovered - currently not indexed" means Google knows the URL exists and has not fetched it yet. It is a queue, not a verdict. Links from your other pages and a sitemap are the levers you have.
"Crawled - currently not indexed" means Google fetched the page and chose not to add it. Google's help page says this doesn't necessarily indicate an issue. For a thin page, a near-copy of another page, or a placeholder, it is a reasonable call. Making the page substantial and distinct is the only real fix. Asking again is not: requesting a recrawl multiple times for the same URL won't get it crawled any faster.
"Page with redirect" is a URL that redirects somewhere else. It will not be indexed; the destination might be. Inspect the destination, not this one.
One site, two addresses
Most hosts give a site a default address and let you add your own domain. Unless something says otherwise, that is two copies of every page, and Google picks one to show. You might see "Duplicate without user-selected canonical" on one of them.
Choose the address you want and say so. A redirect from the other one is a strong signal, and so is a canonical link in each page's head, written as a full URL:
<link rel="canonical" href="https://yourdomain.com/about" />A redirect is the cleaner of the two, because visitors and links end up in one place as well. Pointing a custom domain at a static site covers getting the domain itself working.
Pages built by JavaScript
Google renders pages before indexing them, which is why a React or Vue app can be indexed at all. But rendering is a separate step: a page can wait in the render queue "for a few seconds, but it can take longer than that", and if the HTML Google first receives says noindex, Google "may skip rendering and JavaScript execution" — so a script that removes the tag later may never run.
This matters for single-page apps, including the ones an AI tool builds: the HTML is a shell, and everything a search engine would read arrives after a script runs. If being found matters, prerender the pages that matter or use a framework that sends real HTML per route. The links between pages should be real <a href> elements, not click handlers.
What doesn't speed it up
- Clicking Request indexing again. There is a daily limit to how many index requests you can submit, and requesting the same URL again won't get it crawled any faster.
- The Indexing API. It looks like the answer and it is not: Google says it can only be used for job postings and livestream videos — pages with JobPosting, or BroadcastEvent embedded in a VideoObject.
<priority>and<changefreq>in a sitemap. Google ignores both. A sitemap is a hint about which URLs exist, not a ranking request.
When not being on Google is correct
Plenty of pages should stay out, and it is worth deciding on purpose rather than discovering it later:
- Drafts, client previews and review copies. A preview that ranks for the client's name before the real site launches is a mess to undo.
- Pages made for one person — a report, a proposal, a page an AI made for a meeting.
- Anything private. For these,
noindexis not enough. It asks search engines to stay away; it does not stop anybody who has the link from opening the page. Put a password or a sign-in in front of it, and it stays out of search as a side effect.
A default address that is not indexed is often exactly what you want while a site is unfinished. When it is ready to be found, move it to the address you want it found at.
Questions
How long does it take for a new site to show up on Google?
Google gives no single figure. Its pages mention a few days to a few weeks for crawling, typically a day or so — but up to a week or two — after a manual request, and anything from hours to months for changes in general. A link from a page Google already knows usually helps more than waiting.
Does site:yourdomain.com show every page Google has indexed?
No. Google says the operator does not necessarily return every indexed URL. Use URL Inspection in Search Console for a definite answer about one page.
I clicked Request indexing. Can I click it again?
You can, but it will not make the page crawl faster, and requests count against a daily limit for your property. Request once, then check back in a week or two.
Will blocking a page in robots.txt remove it from Google?
No. robots.txt controls fetching, not indexing. A blocked page can still appear in results if other pages link to it, and Google cannot see a noindex on a page it is not allowed to fetch.
What does "Discovered - currently not indexed" mean?
Google knows the URL exists and has not fetched it yet. It is not an error. Links from your other pages and an up-to-date sitemap are what move it along.
My site has a default address and my own domain. Which one will Google show?
Whichever it chooses as the canonical, unless you tell it. Redirect the address you do not want to the one you do, or add a canonical link with the full URL on every page.
Can Google index a React app or an AI-made single-page app?
Yes, Google renders JavaScript before indexing. But rendering can be delayed, a noindex in the initial HTML can stop it entirely, and other search engines may not render at all. For pages that need to be found, send real HTML.