Why Google found your pages but has not crawled them yet, and what moves them

What the error means

Google knows the URL exists, usually from your sitemap or a link, but has not fetched it yet. In the Pages report the "Last crawled" column shows N/A. Nothing is wrong with the page itself, because Google has not looked at it.

Why Google rejects it

Google schedules crawls by priority. When it expects a page to be low value, or when your server looked slow the last time it crawled, it postpones the fetch. New domains, large batches of similar pages, and pages with few internal links sit in this queue the longest.

How to fix it

1. Check the date first. On a site or property that is only days or weeks old, a large Discovered count is normal and clears as Google works through the queue.
2. Link to the pages that matter from pages Google already crawls: the home page, navigation, hub pages and related articles. A page with one internal link is a low priority.
3. Keep the sitemap to pages you want indexed. Redirects, noindex pages and parameter URLs in the sitemap dilute the signal.
4. Look for patterns. If hundreds of near-identical pages are waiting (filters, tags, thin variants), improve or remove the pattern rather than requesting each URL.
5. Use Request indexing in URL Inspection for your most important pages only. There is a daily limit, and it does not help pages Google considers low value.

Common causes

Few internal links to the URL

Google may know a URL from a sitemap but have no strong signal that it matters. Pages linked only from the sitemap or several clicks deep often wait behind URLs supported by prominent navigation and contextual links. Check whether the page is reachable through normal links from a page Google already crawls.

Large batch of low-priority URLs

Faceted filters, tags, search results, and near-identical landing pages can create more crawlable URLs than the site needs indexed. Google may discover many of them but defer fetching them. Look for repeated URL patterns in the report rather than submitting each URL separately.

Recent launch or URL migration

A new domain, new page set, or large migration can leave Google with a queue of discovered URLs and little crawl history. This does not prove a technical defect. Check that redirects, internal links, and the sitemap consistently point to the new canonical URLs.

Server instability or slow responses

Google may reduce crawl activity if the host returns errors or responds slowly. A temporary spike can leave URLs discovered but not yet fetched. Compare Search Console Crawl Stats with hosting logs for response-time or availability problems during the same period.

Fix it on your platform

On Shopify

1. Keep Shopify's generated sitemap at the primary domain and submit that live URL in the matching Search Console property. Check that the store is public and the domain resolves consistently.
2. Link important products from indexable collections and link those collections from navigation or relevant editorial pages. Do not depend on the sitemap as the only route to a key page.
3. Review filter, tag, and app-generated landing page patterns. Avoid publishing batches of thin URLs merely to expose them to Google; Shopify's default robots rules intentionally constrain some filtered URLs.
4. Check the URL Inspection live test and Shopify/CDN logs if crawling appears delayed across many pages, especially after a theme or domain change.

On WooCommerce

1. Submit one sitemap source, either WordPress core or the active SEO plugin, and confirm the sitemap contains the intended canonical product and page URLs.
2. Add links to new products from public categories and related products. Remove internal links to old slugs or parameter variants that compete with the final URL.
3. Review tag, author, date, and filtered archives. If they are not useful search pages, noindex or exclude them from the sitemap through the active SEO plugin.
4. Check the host's cache and Crawl Stats when many pages wait together; slow PHP or intermittent 5xx responses can reduce crawling.

On other platforms

1. Use the platform's current sitemap URL and ensure it lists the canonical public URLs you want crawled.
2. Add ordinary HTML links from navigation, category pages, and related content to the pages that matter. A sitemap is a discovery hint, not a substitute for useful site structure.
3. Reduce unnecessary URL patterns from filters, internal search, and auto-generated page builders; keep low-value URLs out of the sitemap.
4. Check hosting logs and Search Console Crawl Stats for slow or failed requests before interpreting a queue as a content problem.

How to confirm it is fixed

1. Inspect a representative URL and check the discovery and crawl sections; a Last crawl date means Google has fetched it, but not necessarily indexed it.
2. Confirm the sitemap contains the final canonical URL and that at least one crawlable internal link points to it.
3. Use the index signals check to compare sitemap and page signals, then track the Page indexing report after Google revisits the URL.
4. Request indexing for a few important URLs only after checking access; Google does not guarantee immediate crawling or indexing.

A worked example

Hypothetical case: a small furniture shop publishes 80 new product pages after a catalog import. Search Console shows many as Discovered – currently not indexed, and the sitemap lists them all. The owner finds that most products are not assigned to a public collection, so the only discovery path is the sitemap. They add the products to relevant collections, link the collections from the main navigation, and remove imported draft variants from the sitemap. Crawl dates begin appearing after Google revisits the site; the owner treats indexing as a separate decision and does not submit every URL repeatedly.

Other errors like this