What “Discovered - currently not indexed” means
It means Google knows the URL exists, but has not crawled it yet. The page is in Google’s queue, not in the index. In practice, this usually points to one of three things: Google does not see enough value to prioritize the page, your site is signaling too many low-priority URLs, or crawl access is being slowed by technical issues.
Fixing it is usually less about one magic setting and more about removing obstacles in a specific order. Start with crawlability, then internal signals, then page quality, then site-wide bloat. If the page matters for leads or local visibility, use the steps below before assuming the problem is temporary.
The most common root causes
1. The page is crawlable, but not important enough yet
Google often leaves newly discovered or weakly linked pages in this state when it can find them but does not have a strong reason to fetch them right away. Thin pages, duplicated service pages, and pages buried deep in the site structure are common examples.
2. Internal links are weak or inconsistent
If only one or two pages link to the URL, and those pages are themselves low value, Google may treat the target as low priority. Pages that are only in XML sitemaps and not linked from navigation or relevant content often stay discovered for longer.
3. The site has crawl waste
Faceted URLs, tag archives, search result pages, parameter URLs, and near-duplicate location pages can consume attention without helping indexing. Even small business sites can create this problem after a redesign, migration, or CMS change.
4. Server response or performance issues slow Google down
If the site times out, returns intermittent 5xx errors, or is unusually slow, Google may postpone crawling. This is especially common after migrations, plugin conflicts, or hosting changes.
5. The page looks low quality or too similar to other pages
Pages with little original text, copied location descriptions, or templated service copy are often discovered but not fetched quickly because they do not add much unique value.
6. Canonical and noindex signals conflict
If the page canonicals to another URL, is blocked by robots rules, or has an accidental noindex tag, Google may decide not to prioritize it. Even when the Search Console status says “discovered,” these signals can still confuse the indexing path.
What to check first in Google Search Console
Do not start by requesting indexing repeatedly. First, inspect the URL and confirm whether the issue is isolated or site-wide.
- Open URL Inspection and check whether the page is indexed, crawled, or simply discovered.
- Review the canonical Google selected versus the canonical you declared.
- Look at the last crawl date if one exists. No crawl history can indicate priority or access issues.
- Compare the affected URL with similar indexed URLs on your site. If one location page is indexed and four others are not, the issue may be template quality or duplication.
- Check the sitemap submission and confirm the URL is included in the correct sitemap.
If Search Console also shows coverage issues like “Crawled - currently not indexed,” “Duplicate without user-selected canonical,” or server errors, fix those first because they often explain the discovered status.
Step-by-step remediation sequence
Step 1: Make sure Google can crawl the page
Verify the URL returns a 200 status code, is not blocked by robots.txt, and does not carry a noindex meta tag or header. If the page should be public, keep the path clean and avoid unnecessary redirects.
Quick checklist:
- Page returns 200, not 3xx, 4xx, or 5xx
- Robots.txt does not block the path
- No noindex tag or header
- Canonical points to the preferred URL
- Mobile version renders the main content
Step 2: Strengthen internal links to the page
Google discovers priority through structure. Add links from pages that already earn attention, such as the homepage, main service pages, location pages, or strong blog posts. Use descriptive anchor text that matches the page topic instead of vague phrases like “click here.”
Example: if a local plumbing service page is not being indexed, link to it from the homepage footer, the main services hub, and a relevant blog post about emergency leak repair. That gives Google multiple paths and shows topical relevance.
Step 3: Improve the page so it is worth crawling
Ask whether the page deserves to be in the index on its own. If not, combine it with a stronger page. If yes, add content that is specific, useful, and different from nearby pages.
Useful additions include:
- Clear service scope and location details
- Pricing factors or buying considerations
- FAQs that answer real customer questions
- Original photos, examples, or process details
- Proof points such as licenses, service areas, or case summaries
Avoid padding the page with repeated city names, generic paragraphs, or content copied from another location page. That usually makes the page look more like crawl clutter than a useful result.
Step 4: Remove or consolidate low-value URL variants
If your site generates many near-duplicates, Google may keep discovering them and delay crawling the pages that matter. Consolidate overlapping pages, noindex obvious utility pages, and fix internal links so they point to the preferred version.
Typical cleanup targets include:
- Duplicate location pages with only the city name changed
- Filter or parameter URLs
- Search result pages inside your site
- Old campaign landing pages
- Tag archives that do not serve a real search intent
Step 5: Check sitemap quality, not just sitemap submission
A sitemap is only helpful if it contains indexable, canonical URLs that you actually want indexed. Remove redirected pages, blocked pages, and duplicates. If your sitemap includes thousands of low-value URLs, it can weaken the signal instead of helping it.
For small business sites, a smaller sitemap with your core pages, main service pages, and best supporting content is often more useful than a bloated one.
Step 6: Fix server and performance bottlenecks
If crawl delay seems unusual across many pages, check hosting logs, uptime monitoring, and recent plugin or theme changes. Common problems include slow database queries, excessive redirects, cache failures, and intermittent timeouts. After a migration, make sure old URLs redirect cleanly and do not chain through multiple hops.
Step 7: Request indexing only after the page is ready
Once the page is crawlable, internally linked, and worth indexing, submit it again through URL Inspection. Use this sparingly. Repeated requests do not override weak site signals, and they do not solve duplication or quality problems.
How to decide whether to keep, merge, or remove a page
Not every discovered URL should be forced into the index. Use this simple decision rule:
- Keep and improve if the page has a clear search purpose, can rank for a real query, and adds something unique.
- Merge if the page overlaps heavily with another page and splits relevance or internal links.
- Remove or noindex if the page exists only for internal navigation, campaign tracking, or thin utility use.
This is where many teams save time. Instead of trying to index every URL, focus on the pages that support conversions. A cleaner structure often improves indexing for the important pages faster than chasing low-value URLs.
Practical examples
Example 1: Local service page stuck in discovered status
A roofing company has one general services page and six city pages. The city pages all use the same paragraph with only the city name changed. Google discovers them but does not crawl them often. The fix is to merge overlapping pages, rewrite the strongest city page with real local details, link to it from the homepage and service hub, and remove weak duplicates from the sitemap.
Example 2: Blog post published but not indexed
A marketing blog publishes a post on seasonal email tips, but no other pages link to it. It sits in discovered status for weeks. The fix is to add links from the blog archive, a related evergreen guide, and the homepage featured section if appropriate. Then improve the post with examples, templates, and a better title.
Example 3: Migration created crawl backlog
After moving platforms, a site still has old URLs, redirect chains, and parameter versions in the sitemap. Google keeps finding duplicates and delays the new pages. The fix is to clean redirects, update internal links to point directly to final URLs, prune the sitemap, and verify the canonical setup.
How long it should take to recover
There is no fixed timeline. A well-linked, useful page on a clean site may move faster after reinspection, while a site with duplication or technical debt can stay in this state for weeks. The key signal to watch is whether Google starts crawling the page and whether the status changes across similar URLs.
Track these indicators after changes:
- Improved crawl date in Search Console
- More pages moving from discovered to crawled or indexed
- Reduced duplicate or canonical issues
- Better internal link coverage to priority pages
A simple troubleshooting order you can follow today
- Confirm the page is meant to be indexed.
- Check robots, noindex, canonical, and status code.
- Add relevant internal links from strong pages.
- Improve the page so it is clearly unique and useful.
- Clean up duplicate URLs and weak sitemap entries.
- Check for server, redirect, or migration issues.
- Request indexing once the page is ready.
If you are rebuilding a small site or launching a simpler marketing website, a tool like Solo can help you publish a cleaner structure faster. The important part is still the same: keep the site focused, make the pages distinct, and connect them logically so Google can understand what matters.
When to get extra help
If the issue affects many important URLs, continues after technical fixes, or appears right after a migration, it may be worth having someone review logs, templates, internal linking, and canonical behavior together. The problem is often not one broken setting but a combination of weak signals.
For most small business sites, the fastest path is to reduce page noise, improve the strongest pages, and make crawl paths obvious. That gives Google fewer reasons to delay discovery and more reasons to index the URLs that support your business.
Is “Discovered - currently not indexed” the same as “Crawled - currently not indexed”?
No. “Discovered - currently not indexed” means Google knows the URL exists but has not crawled it yet. “Crawled - currently not indexed” means Google fetched the page but decided not to keep it in the index, usually because of quality, duplication, or relevance signals.
Should I request indexing for every discovered page?
No. Only request indexing after you have confirmed the page is crawlable, internally linked, and worth indexing. Repeated requests do not fix weak content or site structure.
Can a sitemap fix this status by itself?
Usually not. A sitemap helps Google discover URLs, but it does not guarantee crawling or indexing. The page still needs strong internal links, clear canonicals, and enough value to justify crawling.
How do I know if the problem is site-wide or just one page?
Compare the affected page with similar pages in Search Console and inspect multiple URLs. If many similar pages are stuck, the issue is usually structural, such as duplication, weak internal linking, or crawl waste.
What should I do after a website migration?
Check redirects, canonical tags, internal links, sitemap URLs, and server performance. Migration issues often create duplicate paths and crawl inefficiencies that keep important pages in discovered status.