Join our community of websites already using SEOJuice to automate the boring SEO work.
See what our customers say and learn about sustainable SEO that drives long-term growth.
Explore the blog →TL;DR: Your website is either not indexed or indexed but ranking too low for you to find it. Open Google Search Console, inspect the exact production URL, then follow the matching fix below. Repeatedly searching your domain will not tell you what is wrong.
| Search Console result | What it means | What to do next |
|---|---|---|
| URL is on Google | The page is indexed | Stop debugging indexing. Work on relevance, content, links, and ranking. |
| URL is not on Google | The page is not indexed | Check the reported reason, then work through items 1–9 below. |
| Discovered – currently not indexed | Google knows the URL but has not crawled it | Submit a sitemap, add crawlable links, request indexing, and wait. |
| Crawled – currently not indexed | Google fetched the page but did not store it | Improve or consolidate the content and strengthen internal links. |
| Excluded by noindex | Your site explicitly told Google not to index the page | Remove the directive, test the live URL, and request indexing. |
| Blocked by robots.txt | Googlebot cannot crawl the page | Correct robots.txt so the intended URL is crawlable. |

Google Search Central describes three separate stages: crawling, indexing, and serving search results. Crawling is when Google downloads a page. Indexing is when it analyzes and stores that page. Serving is when Google selects results relevant to a search.
Crawled does not mean indexed. Indexed does not mean ranked. Each is a separate gate.
The quickest diagnostic is Google Search Console’s URL Inspection tool. Paste the complete production URL, including the correct protocol, hostname, path, and trailing slash if your site uses one. If it says URL is on Google, the page is indexed. If it says URL is not on Google, inspect the reason underneath.
Do this before changing anything. At SEOJuice, Lida and I are a two-person team, so chasing the wrong diagnosis costs us directly (and I still check the exact URL rather than trusting my memory of what we deployed).
“Google doesn't guarantee that it will crawl, index, or serve your page, even if your page follows the Google Search Essentials.”
That is Google Search Central’s wording. Its documentation also says indexing is not guaranteed because not every processed page is indexed. This is not a reason to shrug; it is a reason to distinguish a technical block from a page Google has evaluated and declined to store.
For more detail on the pipeline, read how Google indexing works. Otherwise, run through these checks in order.

For a site deployed a few days ago, this is the default explanation. Google does not receive a launch notification from your hosting provider. It discovers URLs through pages it already knows, links from those pages, and submitted sitemaps. A new domain with no links and no submitted sitemap provides few discovery paths.
Google Search Advocate John Mueller said indexing new or updated content can take “several hours to several weeks,” as reported by Search Engine Land. There is no dependable deadline inside that range (and yes, “weeks” feels ridiculous when the launch announcement is already out).
Inspect the URL in Search Console. You may see URL is not on Google, no known data for the URL, or Discovered – currently not indexed. Google describes the latter as a page it found but has not yet crawled.
Do not submit every filter, parameter, and minor variation because a button exists. Request Indexing adds a URL to a crawl queue; it does not force immediate crawling or inclusion in the index. Our guide to crawling in SEO explains why links and sitemaps help discovery without giving you control over Google’s schedule.
Founders often search site:example.com, get no results, and assume the domain has been rejected or penalized. That operator is useful as a five-second check, not as an indexing audit.
Google explicitly says the site: operator “doesn't necessarily return all the URLs that are indexed under the prefix specified in the query.” It recommends URL Inspection when a page is absent from a site: search.
Use URL Inspection. URL is on Google means the URL is indexed, even if the site: operator omitted it. Inspection normally shows data from the most recently indexed version of the page, not necessarily the deployment currently visible in your browser.
That last distinction matters after a fix. Use Test live URL to check whether Google can fetch the corrected version now, but use the indexed result to understand what Google previously stored.
There may be nothing to fix. Use the Page Indexing report for patterns across the site and URL Inspection for the exact page. A live test performs a fresh fetch, but Google’s documentation is clear that the test itself does not add the URL to the index.
This is the classic self-inflicted blocker. Staging environments are deliberately kept out of search, then the same setting survives deployment. WordPress’s discourage-search-engines option can produce the same result.
A noindex directive can appear in a robots meta tag inside the HTML or in an X-Robots-Tag HTTP response header. The header version is easy to miss because “view source” will not show it.
Look for Excluded by ‘noindex’ tag in the Page Indexing report. URL Inspection also reports the directive. Then check the response headers directly by running curl -I https://yoursite.com/ and looking for X-Robots-Tag: noindex.
Check both places. Removing the meta tag accomplishes nothing if the CDN or server still sends the header (I have missed that header on a first pass).
Remove every unintended noindex directive from the page, server, CDN, or framework configuration. If you use WordPress, check the discourage-search-engines setting. Deploy the change, run a live URL test, confirm Google can see an indexable response, and request indexing.
Google documents both supported noindex mechanisms. Checking only the visible HTML is not enough.
Open https://yourdomain.com/robots.txt. A leftover Disallow: / under a rule that applies to Googlebot can prevent the entire production site from being crawled.
The distinction is important: robots.txt controls crawling, not indexing. Google calls it “not a mechanism for keeping a web page out of Google” and says a disallowed URL can still be indexed if other pages link to it.
Search Console may report Blocked by robots.txt. URL Inspection will also indicate that crawling is blocked. Read the actual file and identify the most specific rule applying to the URL and user agent; do not stop after finding a reassuring-looking Allow line elsewhere.
Remove rules blocking pages and resources Google should crawl. If you need a clean starting point, use SEOJuice’s robots.txt generator, then review the result against your real URL structure before publishing it.
Do not combine a robots.txt block with noindex to hide the same page. If Google cannot crawl the URL, it cannot read the noindex instruction. I initially assumed stacking both directives was safer; it is actually self-defeating. Use a crawlable noindex page or authentication instead.
A client-rendered React, Vue, or Angular application can initially return little more than an HTML shell. Google can execute JavaScript, but its JavaScript SEO documentation describes separate crawling, rendering, and indexing phases. Rendering is queued and occurs when resources are available.
“Google cannot read JavaScript” is therefore the wrong diagnosis. The practical risks are delayed rendering, failed resources, and content or navigation that appears only after user interaction. Google also says crawlable links should be anchor elements with an href attribute. A clickable JavaScript component is not automatically a discoverable link.
In URL Inspection, use View crawled page and Test live URL. Inspect the rendered HTML and screenshot. If the main copy, product details, or navigation are absent, Google is not receiving the page you think you deployed.
An almost-empty source document is a warning, not the final verdict. The rendered result matters more (or, more precisely, the content and links Google can actually render).
Use server-side rendering, static generation, or prerendering so meaningful content exists in the initial response. Build navigation with real anchor links. Ensure robots.txt does not block JavaScript or CSS required to render the page. Our JavaScript SEO guide covers the implementation trade-offs.
A route existing in your application does not create a crawl path. If no crawlable page links to it and it is absent from your sitemap, Google may have no reliable way to discover it or little reason to prioritize it.
Discovered – currently not indexed can indicate that Google knows the URL but has not prioritized crawling it. It does not prove the page is orphaned, so check the site itself: can you reach the page by following normal HTML links from the homepage or another indexed page?
Across sites we inspect through SEOJuice, two blockers repeatedly masquerade as “Google is ignoring me”: a staging noindex that survived deployment and pages nothing internally links to. Both can remain invisible while the page works perfectly for a human with the direct URL.
Add useful internal links from navigation, category pages, content hubs, or contextually related pages. Include the canonical URL in your sitemap. External links can provide additional discovery paths, but you should not need an external backlink merely to make your own product page reachable.
One caution: do not create hundreds of irrelevant footer links just to eliminate an orphan report. The link should help a visitor move between related pages. Discovery is the immediate benefit; clearer site structure is the durable one.
Google selects one canonical URL from duplicate or substantially similar pages. If your canonical points to staging, the homepage, an HTTP version, an old domain, or a parameter variant, you are suggesting that Google index that other URL instead.
Look for Alternate page with proper canonical tag, Duplicate without user-selected canonical, or Duplicate, Google chose different canonical than user. URL Inspection shows your user-declared canonical and Google’s selected canonical. Compare them character by character.
Give an independent page a self-referencing canonical pointing to its preferred live HTTPS URL. Correct templates or plugins generating stale domain names. Consolidate genuinely duplicate pages rather than forcing every variation into the index.
Canonical bugs are particularly easy to miss after a domain move because the browser can load the new page while its indexing signal still points elsewhere. We migrated SEOJuice from seojuice.io to seojuice.com in January 2026. During a move like that, I trust the declared and Google-selected canonicals more than a successful browser load.
Crawled – currently not indexed is materially different from Discovered – currently not indexed. In the former case, Google fetched the page and did not store it.
The status does not reveal one precise cause. Google says indexing can be skipped because of low content quality or site design that complicates indexing. Thin placeholders, boilerplate location pages, near-duplicates, and pages with little information beyond a repeated template are sensible places to investigate. Search Console may classify an empty page returning HTTP 200 as a Soft 404 instead.
Inspect the version Google crawled, then compare it with other pages on the site. Ask concrete questions: Is most of the copy repeated? Does the page answer something no indexed page already answers? Is the main content present in the rendered output? Does it return the correct HTTP status?
Make the page meaningfully distinct and useful. Consolidate near-duplicates. Give removed or nonexistent pages a real 404 or 410 response instead of returning a contentless success page. Strengthen relevant internal links after improving the page.
Do not respond by adding generic paragraphs until a word-count tool turns green. More text can produce a larger weak page. It does not necessarily produce a better one.
This is rare for a newly launched site, so do not start here. Google defines a manual action as action taken after a human reviewer determines that pages do not comply with its spam policies.
Open Security & Manual Actions, then Manual actions in Search Console. A clean property reports no detected issues. If you launched a new site on a newly registered domain and used no spam tactics, expect this check to be uneventful.
Correct the specific issue described in the report and request a review. This is more relevant for an acquired or expired domain with an unknown history, hacked content, or deliberate tactics covered by Google’s spam policies. There is no value in submitting a reconsideration request when Search Console shows no manual action.
If URL Inspection says URL is on Google, stop trying to solve an indexing problem. The page is eligible to appear, but it may not be relevant or competitive enough for the query you are testing.
“‘URL is on Google’ doesn't actually guarantee that your page will appear in Search results.”
That warning comes directly from Google’s URL Inspection documentation. Mueller made the same distinction in #AskGooglebot: “forcing something to be indexed does not mean that page will be shown prominently in Google Search.”
Search for your exact brand name or a distinctive sentence from the page in quotation marks. Then check Search Console’s Performance report. Impressions above zero mean the page has appeared in results, potentially at a position you never reached while checking manually.
Be careful with your own searches. Location, language, device, personalization, and the exact wording of the query can change what you see. Search Console performance data is better evidence than one manual search.
Match the page to a query people use, make the title and content accurately satisfy that query, add relevant internal links, earn credible external links, and allow time for Google to reassess the page. Requesting indexing again will not improve the ranking of an already indexed URL.
If checking headers, canonicals, robots rules, and orphan pages by hand is slowing you down, run the free SEO audit. It can surface those on-site blockers; it cannot make Google crawl faster or guarantee indexing. That boundary matters.
Your website may be new and waiting to be crawled, or it may be blocked by noindex, robots.txt, an incorrect canonical, missing links, rendering problems, or weak duplicate content. Use URL Inspection in Google Search Console to determine whether the exact page is unindexed or merely ranking too low.
There is no fixed timeline. Google’s John Mueller said indexing new or updated content can take “several hours to several weeks.” A sitemap, indexing request, and crawlable links help Google discover the URL, but Google does not guarantee when or whether it will index it.
Inspect the exact URL in Google Search Console. URL is on Google means indexed, while URL is not on Google means it is not indexed. A site:yourdomain.com search is only a rough check because Google says that operator does not necessarily return every indexed URL.
Google fetched the page but did not add it to the index. The status does not specify a single cause. Review whether the page is thin, mostly boilerplate, near-duplicate, empty, difficult to render, or returning an inappropriate status. Improve its distinct value, consolidate duplicates, and add relevant internal links.
Indexing only makes a page eligible to appear. Ranking depends on how relevant and useful Google considers it for a particular query, alongside competition and other signals. Check Search Console impressions, improve the page around a real search need, and stop repeatedly requesting indexing for a URL already in Google.
Not reliably. Robots.txt restricts crawling rather than indexing, and Google says a blocked URL can still appear if other pages link to it. To exclude a page, use noindex while leaving it crawlable, or protect it with authentication. Do not block the URL in robots.txt if Google needs to see its noindex directive.
no credit card required