Your site is live but missing from Google. Here’s how to find out why
Neaptide · September 7, 2026 · 9 min read
Check Google indexing step by step: Search Console statuses, noindex, robots.txt and canonical URLs. Includes an example and a downloadable developer handoff.
On this page
Your new website loads, the links work and friends can open it. Yet a search for your business or service turns up nothing. Before rewriting every page or buying an “instant indexing” service, find out what is happening to one important URL.
Start with URL Inspection in Google Search Console. If the page is not indexed, investigate discovery, access and the reported reason. If it is indexed, investigate impressions and queries. A working website, an indexed page and visits from search are three different outcomes.
Start with one page and its exact URL
Choose a page that should bring customers to the business: the homepage or a specific service. Copy the final address after redirects. Versions with and without www, http and https, languages and parameters can produce different URLs. Inspecting the homepage will not explain what happened to a service page.
- Open the verified site property in Search Console and paste the full URL into the inspection bar.
- Record the status, last crawl date and Google-selected canonical: the primary URL Google chose among duplicates.
- If the page has changed since that crawl, run a live test. Compare what is available now with Google’s stored information.
A live test checks whether Google can currently fetch and process the page. It does not mean that the current version is indexed, and it cannot predict canonical selection. Without Search Console access, you can inspect public responses and HTML; ask the property owner for the indexed status.
A site:example.com search is a useful first look, but it is not a complete inventory of indexed pages. Do not treat its result count as the size of your index or diagnose a missing page from that query alone.
Read the status before choosing a fix
| Status | What it tells you | Next check |
|---|---|---|
| URL is unknown to Google | The URL has not been discovered | A normal link from a site section and the correct URL in the sitemap |
| Discovered — currently not indexed | Google knows the URL but has not crawled it | Server availability, internal links and crawl statistics if many pages are affected |
| Crawled — currently not indexed | A crawl occurred; the page is not indexed | Page content, similar pages and canonical selection |
| Excluded by noindex / blocked by robots.txt | A specific restriction was found | Whether this URL should be indexed and where the rule comes from |
| Duplicate or alternate page | Another version is being used | Whether the selected primary URL is the right one and is indexed |
“Discovered — currently not indexed” does not by itself prove poor writing: the page has not been crawled yet. Excluding a duplicate, login page or private exercise can also be correct. The aim is to make the right pages available, not to get every exclusion count down to zero.
Worked example: a working page with noindex left in its template
Imagine a pottery workshop launching its website. The classes page is public, responds with HTTP 200 and appears in the sitemap. But its test template still contains noindex. This is an instructional example, not a finding from a real client site.
HTTP/2 200
Content-Type: text/html
<head>
<meta name="robots" content="noindex, nofollow">
<link rel="canonical" href="https://example.com/workshops">
</head>The 200 response confirms a successful server response. The canonical identifies a preferred URL. Neither overrides noindex: once Google reads that rule, it excludes the page from Search. The same restriction can arrive in an X-Robots-Tag HTTP header even when it is absent from the HTML.
- Find the source of noindex: a CMS setting, template, server or CDN. Remove the unintended restriction there for this public page.
- Check the published URL’s headers, HTML and actual content. Adding index alongside an existing noindex will not fix the conflict.
- Run a live test in Search Console again. Once the issue is fixed, you can request indexing for the URL.
Do not hide the page in robots.txt to keep Google from seeing noindex. Robots.txt controls crawling; Google needs access to read the changed indexing rule. Keep intentional restrictions on private and utility pages where they belong.
No restrictions? Check content and duplicate versions
In URL Inspection, check the page Google renders after loading it. Confirm that the service name, terms and main text are visible. Google runs JavaScript, so the use of React or another framework does not explain an indexing problem on its own. Look for a specific fault, such as an empty content block, a failed data request or a resource that cannot be loaded.
Compare the canonical URL declared on the page with the one Google selected. A mistake in a shared service-page template might make every page declare the homepage as its canonical; correct that setting if so. For pages that really are duplicates, use the preferred URL consistently in internal links, the sitemap and canonical declarations. These declarations express a preference, so also check which version Google actually chose.
If you have not found a technical cause, read the page as a customer. Three pages called “pottery lessons”, “ceramics classes” and “pottery workshops” with identical terms may not answer three distinct needs. Compare their purpose, content and search data before merging anything. If the formats really differ, explain duration, materials, experience level and what participants make.
Adding a thousand words for length alone is unlikely to help a reader decide. A schedule, cancellation terms, real examples of finished work and an answer about beginners may be much more useful. This is a content review, not a promise of indexing.
The page is indexed, but nobody visits
Open the Search results performance report and filter by the page’s URL. Check the date range, country, device and search type. Look at which queries produced impressions—appearances in search results—and how many clicks they brought. Searching once on your own phone cannot replace this data.
- No impressions: check filters and the canonical URL, then whether the page matches what your audience searches for. Missing data does not establish a single cause.
- Impressions but few clicks: examine the query, position and displayed search result together. A vague title may hurt understanding, but a low position also limits visits.
- Clicks but no enquiries: check the offer and the route to contacting you. Find a test enquiry at its destination; a “Sent” message alone is not enough.
Give your developer a problem they can verify
Replace “fix our SEO, we aren’t on Google” with a record for one page. Include its URL, check date, Search Console status, last crawl, server response, indexing restrictions, both canonical URLs and intended behaviour. Attach the relevant HTML or a report screenshot when it supports the finding.
For the workshop example, acceptance means the published classes page is public, returns its actual content with HTTP 200 and no longer sends the accidental noindex in HTML or headers. A fresh Google live test no longer finds that restriction. Record the change date. This confirms the fix; it does not yet confirm indexing.
After publishing, watch for a new crawl and the URL’s status. Repeated requests for the same URL do not speed up crawling. Google does not guarantee inclusion or a deadline, so “indexed within 24 hours” is not a sound acceptance criterion.
If the cause remains unclear, this record gives an audit a useful starting point. Once access and indexing questions are resolved, you can separately improve how well the site answers questions in conventional and AI search.