If your site has been live 1–4 weeks but site:yourdomain.com still returns zero results, work through this checklist. It covers nearly every real-world case.
1. robots.txt is blocking everything
Visit https://yourdomain.com/robots.txt and check it doesn’t contain:
User-agent: *
Disallow: /The single most common and most catastrophic mistake.
2. Pages carry a noindex meta tag
Right-click an article → View Source → search for:
<meta name="robots" content="noindex">If it’s there, nothing will be indexed. Common causes:
- Astro/Next templates that ship with
noindexin dev mode and you forgot to flip it off. - A theme/template adding
noindexsilently. - WordPress’s “Discourage search engines from indexing this site” checkbox left on.
3. Canonicals pointing to the wrong URL
If article A’s canonical points to article B, Google only indexes B, not A.
Bilingual sites: each language version should canonical to itself, and use hreflang to link the two.
4. The site relies entirely on JavaScript
If disabling JS leaves a blank page, Google may see a blank page too.
Fix: use SSG or SSR. Astro defaults to SSG, which is SEO-friendly out of the box.
5. Sitemap was never submitted
Search Console → Sitemaps — make sure your sitemap shows “Success.” If it says “Submitted” but the page count stays at zero, that is a specific state — see Sitemap submitted but not indexed. For broader Search Console setup, the submit sitemap walkthrough covers it end to end.
6. New-domain sandbox effect
Brand-new domains are often held back for a few weeks while Google decides you’re not spam. Be patient. While you wait, the two most common in-between states are Crawled — currently not indexed and Discovered — currently not indexed; both have specific fixes.
7. Duplicate or “thin” content
If the homepage has three lines and articles have 100–200 words, Google delays or refuses indexing. Guidance:
- Homepage: at least 300 words of real content.
- Articles: at least 800 words.
- Never publish copied or auto-translated content as-is.
8. Weak internal linking
Crawlers need a path. Every page should link to at least three others — category, related, breadcrumbs.
9. DNS or HTTPS issues
- No HTTPS: heavily suppressed.
- Flaky DNS: crawlers eventually give up.
10. Manual actions or security warnings
Search Console → Security & Manual Actions. If anything appears, fix it and request a review.
A practical debugging checklist
- Try
site:yourdomain.com— is anything indexed at all? - View source of one article — search for
noindex. - Open robots.txt.
- Use Search Console’s “URL Inspection” tool.
- Submit your sitemap and give it 7–14 days.
Summary
Not being indexed isn’t luck — it’s a concrete problem. Walk through these ten in order; most sites find the cause within a day. If the cause turns out to be content quality or pagination — common on indie sites with hundreds of articles — Search Console low-value URLs and Manage a content site after 1000 articles describe the recovery path.
Decision checklist
- If the error started right after a change, roll back or isolate that change before trying unrelated fixes.
- If the error happens only in production, compare environment variables, build output, cache, permissions, and platform settings.
- If the error happens only for one account or browser, test permissions, cookies, extensions, quota, and regional availability.
- If two fixes seem possible, choose the one that is easiest to verify and easiest to undo first.
When to stop debugging
Stop and escalate when you cannot reproduce the issue, when logs contradict the UI, when billing or account security is involved, or when every fix requires production access you do not control. At that point, package the exact error, timestamp, project ID, reproduction steps, screenshots, and recent changes before asking support or another engineer. Good escalation notes often solve the problem faster than another hour of guessing.
Diagnostic flow
- Reproduce the issue once and write down the exact path. If you cannot reproduce it, collect more evidence before changing settings.
- Check scope: one user or everyone, one browser or all browsers, local only or production only, new content only or old content too.
- Check the last change first. Most troubleshooting work is not about finding a mysterious root cause; it is about identifying which recent change created the mismatch.
- Split the system in two: input vs output, local vs hosted, account vs project, source file vs generated file, prompt vs model. Test which side still fails.
- Apply the smallest reversible fix. Avoid changes that touch DNS, permissions, billing, deployment, and code at the same time.
- Verify the original reproduction path and one nearby path, then write down what fixed it.
Minimal reproduction template
Issue:
- [exact error or broken behavior]
Where it happens:
- URL / tool / project:
- Account:
- Environment: local / preview / production
- Browser / device:
Steps to reproduce:
1.
2.
3.
Expected:
-
Actual:
-
Recent changes:
- Code:
- Config:
- DNS / permissions / billing:
- Prompt / model / uploaded files:
Evidence:
- Screenshot:
- Console error:
- Server or platform log:False fixes to avoid
- Clearing cache without checking whether the underlying file, permission, route, or setting is correct.
- Reinstalling packages when the error is actually caused by environment variables, credentials, quota, or platform config.
- Changing several unrelated settings at once, then not knowing which one mattered.
- Copying a fix from another framework or platform without checking whether the routing, build output, or auth model is the same.
- Treating a temporary platform outage as your own bug before checking status pages and recent reports.