Discovered—Currently Not Indexed: How to Get Google to Crawl the Page
Discovered—currently not indexed means Google knows the URL but has not crawled it yet, so the status is not a verdict on page quality. Fix access and discovery problems, reduce wasteful URL inventory, strengthen internal importance, then let Google reschedule the crawl.
What Does “Discovered—Currently Not Indexed” Mean?
“Discovered—currently not indexed” means Google has found the URL but has not crawled it. The empty “Last crawl” field is therefore expected. This status describes Google’s scheduling state, not a content-quality verdict, because Google has not fetched the page it would need to evaluate.
Google says it typically rescheduled the crawl because fetching might overload the site; immediate, complete indexing is not expected (Page Indexing documentation). Treat the reason as a diagnostic, not proof of a penalty.
“Crawled—currently not indexed” is different: Google fetched that URL but did not index it. With “discovered,” start with availability, URL volume, and discovery importance before rewriting unseen copy. Use URL Inspection for individual examples.
How Should a Small Shopify Store Triage the Report?
For a small Shopify store, first decide whether the affected sample contains pages that should matter to shoppers and search. Then check basic access, canonical intent, sitemap presence, and internal discovery. Do not begin with an abstract crawl-budget project or request indexing for every excluded URL.
| Priority | What the sample shows | First action |
|---|---|---|
| P0 | Important URLs return errors, challenges, or unstable responses | Fix access and server behavior |
| P1 | Valuable canonical pages lack links or sitemap discovery | Strengthen truthful discovery signals |
| P2 | Filters, searches, or parameters dominate the sample | Reduce unwanted URL inventory |
| P3 | Pages are accessible, useful, and consistently signaled | Monitor and allow recrawling time |
| No action | URLs are duplicates or have no search purpose | Consolidate or stop promoting them |
Sample several URLs. Each important page needs a distinct shopper purpose, helpful content, and a crawlable path. Google’s Search Essentials make these eligibility foundations, not an indexing promise.
Which Server and Access Problems Should You Fix First?
Fix access and capacity problems before changing content or canonical tags. If Google repeatedly encounters server errors, long responses, security challenges, or blocked resources, it may reduce crawling to protect the site. The practical goal is a consistently fast, ordinary response for Googlebot and shoppers.
Check representative URLs for:
- intermittent
5xxor timeout responses; - severe response slowdowns during traffic spikes;
- WAF, bot challenge, login, or cookie walls;
- host, DNS, TLS, or primary-domain redirect instability;
- redirect chains before the final canonical URL.
Use server evidence to separate a capacity problem from report delay. Google says speed and errors affect crawl capacity, while duplicate and unwanted URLs consume crawling (crawl-budget guidance). Preserve security while permitting necessary crawler access.
How Should You Control URL Inventory and Discovery?
Control which URLs the store asks Google to discover. A compact inventory of canonical products, collections, pages, and posts is easier to crawl than endless filter, search, calendar, tracking, and parameter combinations. Keep valuable routes discoverable, and consolidate equivalent routes instead of promoting every variation.
- List canonical URLs in the sitemap and use accurate
lastmodonly after meaningful changes; fake freshness is not a strategy (sitemap guidance). - Link important pages from relevant collections or hubs with descriptive anchors, following Shopify’s site-structure guidance.
- Audit filters, searches, calendars, sorts, tracking parameters, and pagination; stop crawlable combinations without distinct search value.
- Consolidate genuine duplicates. Align canonical tags, internal links, and sitemap entries around the preferred URL, following Google’s duplicate-consolidation guidance.
Do not publish thin pages to inflate indexable counts. Promote URLs that provide distinct, useful destinations; otherwise simplify the inventory.
Which Shopify-Specific Signals Need Checking?
Shopify supplies useful defaults, but verify the storefront that Google actually receives. The primary domain should be the consistent destination, /sitemap.xml should expose intended canonical pages, and one canonical policy should survive theme, app, proxy, and headless rendering without contradictory tags or links.
- Confirm internal navigation uses the primary-domain version.
- Inspect theme and app output for altered canonical or robots tags.
- Check that collection and product links resolve without long redirect paths.
- Compare headless storefront metadata with the Shopify origin configuration.
Shopify’s root sitemap covers products, primary images, pages, collections, and posts, but cannot guarantee crawling or indexing (sitemap guidance). Shopify provides baseline canonical, robots, sitemap, and SSL behavior; themes and apps can alter the delivered result.
When Is a Formal Crawl-Budget Diagnosis Warranted?
Use formal crawl-budget analysis when scale or evidence justifies it, not as a default explanation for a small catalog. Google frames crawl budget as crawl capacity plus crawl demand, and directs its detailed guidance mainly toward very large, fast-changing, or heavily discovery-backlogged sites.
Google highlights roughly one million moderately changing pages, ten thousand rapidly changing pages, or a large share of discovered-not-indexed URLs. At that scale, examine capacity, demand, speed, errors, duplicates, soft 404s, and redirect chains using its crawl-budget criteria.
For most small stores, the higher-value questions are simpler:
- Is the server reliably available?
- Are important pages linked and in the sitemap?
- Is the store generating far more URLs than useful destinations?
- Are duplicate and canonical signals consistent?
Popularity, perceived quality, update relevance, and crawl health influence demand. “Crawl budget” should name an evidenced constraint, not become a universal excuse for weak discovery or noisy URL creation.
How Should You Request and Monitor a Crawl?
Request indexing for one high-value URL only after the underlying access and discovery signals are fixed. The request is a prompt, not a queue-jump guarantee. Monitor the representative URL and the broader report afterward; repeated submissions cannot substitute for stable infrastructure, useful pages, and crawlable links.
- Deploy the server, linking, sitemap, or consolidation fix.
- Run the live URL Inspection test to confirm current access and eligibility.
- Request indexing once for a representative, important canonical URL.
- Record the date, then monitor its inspection result and related report group.
- Recheck server evidence if “Last crawl” remains empty across important pages.
The live test cannot prove indexed state or guarantee a future crawl, and requests have limits (URL Inspection documentation). Google also emphasizes links and/or sitemap inclusion for important pages (Page Indexing guidance). Mass requests are not a strategy.
What Can StoreCited Verify and What Can It Not Verify?
StoreCited can surface readiness problems that a merchant can act on, but it cannot observe Google’s internal scheduling decisions. Use it to check the store’s exposed crawl and index signals, then use Search Console and server evidence to understand whether Google has discovered, fetched, and indexed a specific URL.
StoreCited checks crawl/index readiness signals exposed in initial HTML and site structure. It cannot see Google’s crawl queue, access a store’s Search Console by default, allocate crawl budget, or guarantee crawl/index/citation.
Get the answer for your specific store