Shopify Discovered, Not Indexed: Get Pages Crawled
Shopify 'Discovered - currently not indexed' means Google knows a URL but has not crawled it. How to check internal links, sitemap hygiene and junk URLs.
Quick answer: “Discovered - currently not indexed” means Google knows a URL exists but has not crawled it yet. Google says that typically it wanted to crawl the URL but expected that to overload the site, so it rescheduled the crawl, which is why the last crawl date is empty. That is different from “Crawled - currently not indexed”, where Google fetched the page and has not indexed it. On a Shopify store, check four things in order: whether the URLs are ones you want, whether crawled pages link to them, whether your sitemap is clean, and how many low-value URLs the store exposes.
You open Search Console, go to Indexing, then Pages, and one of the grey rows says “Discovered - currently not indexed”. The count might be 12. It might be 2,400. Either way, the wording suggests Google has a queue and your pages are stuck in it.
Advice online tends to split into two camps: it is a crawl budget disaster that needs a rebuild, or click “Request indexing” and wait. Neither starts from what Google actually says.
This guide is about the earlier stage of the pipeline: pages Google has heard of but not fetched. It covers what the status means, whether crawl budget is your problem, and the order I would work through on a Shopify store: sort the list, check internal links, clean up the sitemap, then count the junk URLs the store creates. If your list says “Crawled” instead, you want our guide to Crawled - currently not indexed, which is about whether the page deserves to be in the index. This one is about whether Google has bothered to look yet.
I will not give you a timeframe for when pages get crawled. Google does not publish one, and Shopify’s help centre says Google does not guarantee how long crawling and indexing take.
What “Discovered - currently not indexed” says, and what it does not
Google’s Page indexing report help describes it in a few short lines. The page was found by Google but not crawled yet. Typically, Google wanted to crawl the URL but expected that to overload the site, so it rescheduled the crawl, which is why the last crawl date is empty on the report.
That is the whole definition. It does not say the page is poor, penalised or broken. Google has not fetched it, so there is no crawled version to judge yet. The same help says not to expect every URL on your site to be indexed, only to make sure the key pages are, and that non-indexed URLs can be fine, because some are duplicates or carry no meaningful information.
The two statuses people mix up sit at different stages:
| Question | Discovered - currently not indexed | Crawled - currently not indexed |
|---|---|---|
| Did Google fetch the page? | No (last crawl date is empty) | Yes |
| What Google’s help says | Found but not crawled; typically rescheduled because crawling was expected to overload the site | Crawled but not indexed; may or may not be indexed in future; no need to resubmit |
| Where I look first (my approach) | How Google reaches and prioritises the URL: links, sitemap, URL volume | The page itself: duplication, canonical, content |
The last row is my working method, not Google’s. If Google has not fetched a page, rewriting that page is a poor first move. Google does list page quality as one input to crawl demand, so content is not irrelevant. It is just not where I start.
Is this a crawl budget problem?
Probably not, but the honest answer needs Google’s own wording, because the term gets thrown around loosely.
Google’s crawl budget guide defines crawl budget as the set of URLs Googlebot can and wants to crawl. It depends on two things:
- Crawl capacity limit: how much crawling your server can handle. Google says the limit goes up when a site responds quickly and reliably, and down when it slows or returns server errors.
- Crawl demand: how much Google wants to crawl your URLs, which depends on site size, how often content changes, page quality and relevance.
The guide says who it is for. As at 30 October 2026 (the page shows it was last updated on 22 July 2026), it lists large sites (1 million or more unique pages with content that changes about weekly), medium or larger sites (10,000 or more unique pages with very rapidly changing content, meaning daily), and sites with a large portion of their URLs classified by Search Console as Discovered - currently not indexed. Google calls the numbers a rough estimate, not exact thresholds. Its opening lines add that if your site does not have a large number of rapidly changing pages, or your pages seem to be crawled the same day they are published, you do not need the guide, and that for Google Search keeping your sitemap up to date and checking the Page indexing report regularly is adequate.
Read that third group carefully, because it is the one that applies to a store seeing this status. Google does not define “a large portion”, so I treat it as a prompt to look, not a threshold. A handful of Discovered URLs on a store that added a collection last week is not a finding. A report where most URLs are Discovered, and your key products are among them, is.
The part of the guide that matters for a small store is “perceived inventory”. Google’s wording is that without guidance from you, it tries to crawl all or most of the URLs it knows about on your site. If a store of 100 products exposes thousands of URLs, Google knows about all of them, and the pages you care about compete with a lot of clutter. That is why most of this guide is about what your store tells Google exists.
After a launch, a big catalogue import or a migration, a wave of new URLs may sit in this status for a while. Google does not say so, but I check the dates first, before treating a recent batch as a fault.
Step 1: sort the list before you fix anything
A count of 400 means nothing until you know which 400.
Open the status and read the examples. In Indexing, then Pages, click the Discovered row. Google says the example table is limited to 1,000 rows and does not necessarily list every URL with that status. On a larger store, work in slices rather than assuming the table is the whole picture.
Filter by sitemap. The report can show All known pages, All submitted pages, Unsubmitted pages only, or one sitemap. A URL counts as submitted if it is in a sitemap you submitted, even if Google also found it by a link. This split is the most useful thing in the report for Shopify:
- Submitted and Discovered: URLs Shopify’s own sitemap offers as pages that matter, which Google has not crawled. These are the ones to take seriously first.
- Unsubmitted and Discovered: URLs Google found some other way, usually through links. On a Shopify store these tend to be filter, tag, search and parameter URLs.
This only works if you have submitted your sitemap: verify the domain in Search Console, then add sitemap.xml under Sitemaps, as Shopify’s help describes.
Group the URLs by type in a spreadsheet: product, collection, blog post, page, filtered or tag URL, search URL, paginated URL, localised version, other. “Almost all products” is one story. “Almost all parameter URLs” is a different one.
Compare what Google knows with what you own. Compare the All known pages total with the real number of products, collections, pages and posts you want found. If Google knows several times more URLs than you have real pages, the store is exposing clutter. That ratio is my rule of thumb, not a Google threshold, and I use it only to decide where to look next.
Then decide per group:
| URL group | Do you want it indexed? | First move |
|---|---|---|
| Products you sell | Yes | Check internal links (step 2) |
| Collections a buyer would search for | Yes | Check internal links and menu placement |
| New blog posts and pages | Yes | Link from related, already-crawled pages |
| Filter and tag URLs | Only if it is a real search term | Step 4: find where they are linked from |
| Search result URLs | Rarely | Step 4 |
| Deep paginated pages | Not as landing pages | Check products are reachable another way |
Step 2: check the internal links
Google says every page you care about should be linked from at least one other page on your site, and that it can generally follow a link only if it is an <a> element with an href attribute. Links added by JavaScript are fine if they use that same markup. A button, or an element that runs a script on click and has no href, may not be followed.
A URL in your sitemap but not linked from anywhere is an orphan. Google can find it through the sitemap, which is one way a URL ends up as Discovered, but nothing on your site says it matters. I cannot tell you Google deprioritises orphans, because Google does not say that in the documentation I read. It is my working assumption, and the test below checks it on your own store.
How to check. Crawl your store the way a visitor would, following links only, with any crawler you have. Then compare that list with the sitemap. Sitemap URLs the crawl never reached are orphans. Common causes on Shopify stores are:
- products not assigned to any collection;
- collections that are not in the main menu, a footer menu or another collection;
- new blog posts that nothing links to;
- links built so that they are not plain anchors, such as a product grid that loads more items only after a click.
How to fix. Give each important URL two or three links from pages that are already crawled and relevant:
- Put the product in the collection a buyer would browse, and link related products to each other.
- Put the collection in the main menu, or link it from a parent collection’s introduction.
- Link blog posts to the products and collections they discuss, with descriptive anchor text. Google’s guidance is that good anchor text is descriptive, reasonably concise and relevant, and it calls “Click here” and “Read more” too generic.
Our guides to collection page SEO and category pages as the highest-leverage SEO asset cover what those collection pages should contain. If you publish content, our post on topical authority and backlinks covers one way to organise related pages so that each one earns its place.
A cheap test. Pick ten Discovered URLs that you want indexed. Add links to them from two or three pages that are already indexed and crawled. Then run URL Inspection on a few and watch whether the Last crawl field fills in. Google makes no promise, so treat it as a test, not a fix. If the dates fill in, links were part of the answer. If nothing changes, the next two steps matter more.
Step 3: tidy the sitemap
Shopify generates your sitemap. Its help says the file links to separate sitemaps for products, collections, blogs and pages, and updates automatically when you add content, and the demo store’s sitemap I checked on 30 October 2026 carried a comment saying it cannot be edited manually. So “sitemap hygiene” on Shopify does not mean hand-editing a file. It means controlling what goes into it and checking what is wrong with it.
Google’s sitemap guidance helps here. A sitemap should list the URLs you want in results, preferably canonical ones. Google ignores the priority and changefreq values, and uses lastmod only if it is consistently accurate. A single sitemap is limited to 50,000 URLs or 50MB uncompressed. Most importantly, Google says a sitemap does not guarantee that URLs will be crawled and indexed. It is a discovery aid, and for a Discovered URL, discovery has already happened.
So I do not treat resubmitting the sitemap as the fix for this status. Instead, check these:
- One submission, status Success. Submit
sitemap.xmlonce. In the Sitemaps report, Success means Google fetched and read it. “Couldn’t fetch” means Google could not retrieve the file, and Google’s help points you to URL Inspection to troubleshoot. - Is anything blocking access? Shopify says search engines cannot reach your sitemap or store while private mode is on, and that extra domains not used for international targeting should redirect to your primary domain.
- Extra sitemaps. If an app or theme gives you a second sitemap, open it. Every URL in it is a URL you are telling Google matters.
- Read the rest of the report for submitted URLs. Filter the Page indexing report to All submitted pages and look at the other statuses. Sitemap URLs that redirect, return 404 or are alternates of other pages are noise in a file that should list the canonical URLs you want in results. Google’s troubleshooting advice is to fix only the 404s you link to yourself or list in a sitemap.
- Hide what should not be there. For a page, post or product that should not be in search at all, Shopify’s
seo.hiddenmetafield, set to 1, removes it from sitemaps, search engines and your store search. Use that only where the page has no search role. Do not use it on a product you want found.
If you want to consolidate duplicate URLs, Google ranks the signals: a permanent redirect and rel="canonical" are strong, a sitemap entry is weak. Our guide to Shopify duplicate content and canonical URLs covers the collection-path product URLs that can create duplicates on Shopify.
Step 4: count the junk URLs
Google’s guidance on faceted navigation explains the mechanism. Filters and parameters can create a huge number of URL combinations, and a crawler may request a very large number of them before recognising they are useless, which leaves less time for new, useful pages. Google’s options for managing it are a robots.txt disallow (listed first, for faceted URLs you do not need in Google Search), rel="canonical" to the unfiltered page, and rel="nofollow" on links. Google says the last two are generally less effective in the long term.
On Shopify, the default robots.txt already blocks some of this. Shopify’s help lists admin, cart, checkout, account and order pages, plus filtered collection pages (/collections/*+*) and sorted collection pages (/collections/*sort_by*). Here is what I saw on Shopify’s demo store (os2-demo.myshopify.com) on 30 October 2026, by checking its robots.txt and the page source of each URL type:
| URL type | What I saw | What I would do |
|---|---|---|
?sort_by= on a collection | Blocked in robots.txt; canonical points to the main collection | Nothing, if nothing links to it |
| Two filters combined | Blocked by a filter*&*filter rule | Nothing |
Several tags joined with + | Blocked | Nothing |
One filter, ?filter.p.product_type= | Not blocked; canonical points to the unfiltered collection | Count how many are linked internally |
One tag in the path, /collections/all/handbag | Not blocked; canonical points to itself | Decide if the tag is a real search term |
Search results, /search?q= | Not in the robots.txt I read; canonical points to itself; I found no robots meta tag | Check nothing in your theme links to search URLs |
Page 2 and beyond, ?page=2 | Not blocked; canonical points to itself | Leave; make sure products are reachable elsewhere |
Two cautions. This is one demo store on one day, and defaults change, so read your own file at yourstore.com/robots.txt and check the source of your own URLs. And a canonical tag tells Google which version you prefer. Google says it may, over time, decrease the crawl volume of the non-canonical versions, which is gradual at best, so canonicalised filter URLs can still be known and queued in the meantime.
Find out where the junk comes from. Open URL Inspection on a few unsubmitted Discovered URLs. Google shows the sitemaps that point to the URL and a referring page it possibly used to discover it. If the referring pages are your own collections, the cause may be in your theme or an app: a filter widget that outputs crawlable links, a tag cloud, or a search box that links to results. Fix the source of the links before you touch anything else. If it is in theme code, that is a job for whoever maintains your theme.
Be careful with robots.txt. Shopify describes editing robots.txt.liquid as an unsupported customisation, says Shopify Support cannot help with it, and warns that wrong changes can cost you all your traffic. Google adds two points. Do not use noindex to save crawling, because Google still requests the page and then drops it. And noindex only works if the page is not blocked in robots.txt, because Google has to crawl the page to see the rule. Our Shopify robots.txt guide covers when an edit is justified. For most stores the answer is: stop linking to the clutter first.
Remove what is actually dead. Google’s crawl budget guide says to return a 404 or 410 for permanently removed pages, to eliminate soft 404s (pages that show “not found” but return a success code), and to avoid long redirect chains.
Do not create more. Mass-producing filter, tag or location pages makes the pile bigger. Google’s spam policies also define scaled content abuse as many pages generated for the primary purpose of manipulating search rankings and not helping users, which is one more reason to avoid it. Why programmatic SEO is a trap for sub-$1M DTC stores covers the commercial side.
Step 5: glance at the Crawl Stats report
Google’s help says the Crawl Stats report is aimed at advanced users and that sites with fewer than a thousand pages generally do not need it. If your store is bigger, or the Discovered count is large, take one look at the host status: green means Google found no significant availability issues in the past 90 days, and a “Recent availability issue” (one in the last week) is worth checking for repeats.
What does not work
- Clicking Request indexing on every URL. Google’s URL Inspection help says a request does not guarantee the page will appear in the index, that you cannot request indexing for a page the live test finds non-indexable, and that there is a daily limit. It is fine for a few important pages after a real change, not a way to clear a list.
- Resubmitting the sitemap, or adding noindex to reduce crawling. Covered above: Google says a sitemap guarantees nothing, and noindex does not save crawling.
- Rewriting every Discovered product page. Google has not fetched them. Fix reach first, then content.
A worked example (illustrative numbers)
These numbers are made up to show the method. Say a store has 90 products, 20 collections, 12 blog posts and 6 pages: 128 real URLs. Search Console shows 2,350 URLs known to Google and 1,900 Discovered - currently not indexed.
| Group in Discovered | URLs | Finding | Action |
|---|---|---|---|
| Single-filter collection URLs | 1,150 | Linked from a filter widget in the theme | Remove crawlable links from the widget; keep the filters working |
| Single-tag collection URLs | 380 | Linked from a tag list on blog posts | Make 5 real collections for tags with search demand; unlink the rest |
| Search result URLs | 240 | Linked from “popular searches” block | Remove the block |
| Paginated collections | 90 | Normal | Leave; check products are linked elsewhere |
| Products in the sitemap | 26 | Not in any collection | Add to collections; link from related products |
| Blog posts in the sitemap | 8 | Nothing links to them | Link each from 2 related posts or collections |
| Old product URLs | 6 | Return 404 and are linked from a menu | Remove links; redirect where a close match exists |
The page-level work is about 45 URLs: the 26 products, 8 posts, 5 new collections and 6 old product URLs. The 1,770 filter, tag and search URLs are a theme-link problem, not 1,770 pages to fix, and the 90 paginated pages need nothing. Improving the content on 1,900 pages would leave the cause untouched.
After you make changes: measure it properly
Do the cheap things first, then give Google time without chasing a date. Where the report offers Validate fix, Google says to fix all instances first and not to click it again until validation has succeeded or failed. It says validation typically takes up to about two weeks but can take much longer. That is how long Google takes to check, not how long a page takes to be crawled.
Track three things, using only Search Console and Shopify:
- By group: how many URLs in each group are still Discovered, using the sitemap filter and your spreadsheet.
- By page: for the 20 or so pages that matter most, run URL Inspection and note whether Last crawl has a date and what the status is now.
- By revenue: impressions and clicks in the Performance report for those pages, then orders from them in Shopify. A page that is indexed and never visited is a different problem, which our Shopify SEO guide covers.
When to leave it alone
I would not spend time on this report when the count is small and the URLs are new, when the Discovered URLs are almost all filter, tag, search or paginated URLs and your products and collections are crawled and indexed, or when the count has been steady for months and the pages that earn revenue are not in it. I would act when URLs you want, such as products you sell, collections buyers search for and your best posts, are sitting in Discovered while the store exposes far more URLs than it has real pages.
Key takeaways
- “Discovered - currently not indexed” means Google found the URL but has not crawled it, and Google says it typically expected crawling to overload the site, so it rescheduled. It is not a penalty and not a verdict on the page.
- It is a different problem from “Crawled - currently not indexed”. Start with how Google reaches and prioritises the URL, not with rewriting the page.
- Google’s crawl budget guide lists sites of 1 million or more pages, sites of 10,000 or more pages changing daily, and sites with a large portion of URLs in this status. Google does not define “large portion”, so use it as a prompt to look.
- Sort first: filter by sitemap, group by URL type, and compare what Google knows with what you really have.
- Check internal links, then the sitemap, then junk URL volume. On Shopify, clutter often comes from links your theme or apps output, not from the pages you wrote.
- Do not rely on Request indexing or sitemap resubmission. Google says neither guarantees crawling or indexing, and it says not to use noindex to save crawling.
- The goal is not a zero count. It is that the pages that sell are crawled and indexed.
FAQs
What does “Discovered - currently not indexed” mean on Shopify?
Google knows the URL exists, for example from your sitemap or a link, but has not crawled it yet. Google’s help says that typically it wanted to crawl the URL but expected that to overload the site, so it rescheduled the crawl, and the last crawl date is empty. It is not a penalty, and it does not say anything about the quality of the page.
How long until Discovered pages get crawled?
Nobody can say. Google does not give a timeframe, and Shopify’s help says Google does not guarantee how long crawling and indexing take. If you make fixes and use Validate fix, Google says validation typically takes up to about two weeks, sometimes longer, which is the time it takes to check your fix.
Is this a crawl budget problem on my small store?
Usually it is a smaller issue than the term suggests. Google’s guide lists sites with 1 million or more pages, sites with 10,000 or more pages that change daily, and sites with a large portion of URLs in this status. It also says that if a site does not have many rapidly changing pages, or its pages are crawled the same day they are published, you do not need the guide. If a large share of your URLs is Discovered, it is worth checking whether your store exposes far more URLs than it has real pages.
What is the difference between Discovered and Crawled - currently not indexed?
Discovered means Google has not fetched the page yet. Crawled means Google fetched it and has not added it to the index. The first points you at links, sitemap and URL volume. The second points you at the page: duplication, canonical and content. We cover the second in a separate guide.
Should I use Request indexing on these URLs?
Only for a few important pages, after a real change. Google’s help says a request does not guarantee the page will appear in the index, you cannot request indexing for a page the live test finds non-indexable, and there is a daily limit.
Will noindex or a robots.txt block fix it?
Noindex will not. Google says not to use it to save crawling, because Google still requests the page and then drops it. Google lists a robots.txt disallow first among its options for faceted URLs you do not need in search, but Shopify treats editing robots.txt.liquid as an unsupported customisation. Fixing the links that create the URLs is usually the safer first step.
Do I need to edit robots.txt on Shopify?
Often not. Shopify’s default file already blocks admin, cart, checkout, account and order pages, plus filtered and sorted collection pages. Read your own file, find where the unblocked URLs are linked from, and fix that first.
Want someone to sort your Search Console report for you?
Our Shopify SEO service includes a technical audit that covers crawlability and indexation. The hard part is not reading the status. It is knowing which URLs are costing you sales and which are noise, and that depends on your catalogue, theme and apps. If you want a second pair of eyes, book a free 30-minute diagnostic or tell us about your store. We look at your store before we recommend anything, and we tell you honestly if SEO isn’t the right move. No pitch.
Free 30-min diagnostic
Seen enough?
Book a free diagnostic.
We'll look at your store's search pages, find what is costing you traffic and tell you what to fix first. No pitch. No email gate. 30 minutes.
More from Prism3
Afterpay vs Zip vs Shop Pay Instalments: Shopify AU
Afterpay, Zip and Shop Pay Instalments compared for Australian Shopify stores: merchant fees, payouts, approval, checkout placement and a worked margin example.
AI-Referred Orders on Shopify: What Is Real and What Is Hype
What Shopify has disclosed about AI-referred orders, why the 13x headline needs context, how to find AI traffic in GA4 and Shopify, and what to do now.
AI Visibility Tools for Shopify: What They Measure and Miss
What AI visibility tools for Shopify stores really count: mentions, share of voice and citations, where the data is sampled or unstable, and how to use them.