Discovered – Currently Not Indexed: Why Our New Pages Waited, and What We Fixed

Twenty pages on our new site, including our main product page, sat at Discovered – currently not indexed in Search Console. What Google says the status means, the two causes we found, and what we changed.

Our website, leelaramtechnologies.com, went live on 10 September 2026. Within a few weeks we had published about 100 URLs: product and service pages, a free tool, and a steady run of blog posts. By Search Console's update of 9 October, 77 of those pages were indexed and 22 were not. Twenty of the 22 carried the same status, Discovered – currently not indexed. One of them was the page that matters most to us, the product page for SellRank, our Shopify app, and Google had never crawled it.

This is what that status means according to Google's own documentation, what we checked first, the two problems we found in our own site, what we changed, and what we are still waiting to see. We are writing it before the results are in, on purpose. If you have the same status on your site, the diagnosis is the useful part, and we would rather show it now than wait for a happy ending we cannot promise.

What Search Console showed on 9 October

• About 100 URLs published since the domain went live on 10 September 2026.
• 77 indexed.
• 22 not indexed: 20 Discovered – currently not indexed, 1 Crawled – currently not indexed, and 1 excluded by a noindex tag.
• Among the 20: the main SellRank product page, with no last crawl date at all.

The single noindex page is a different matter: Search Console reports that status when a page tells Google not to index it, so it is a decision on our side, not a problem Google has found. The single Crawled – currently not indexed page is also different. The 20 Discovered pages are the subject of this post.

What Discovered – currently not indexed means

Google's Search Console Help page on the Page indexing report describes the status plainly. The page was found by Google but not crawled yet. Typically, it says, Google wanted to crawl the URL but expected this to overload the site, so it rescheduled the crawl. That is why the last crawl date in the report is empty.

The same help page describes Crawled – currently not indexed differently. That page was crawled but not indexed, it may or may not be indexed in the future, and there is no need to resubmit it for crawling. So the two statuses are not the same problem. Discovered means Google knows the URL exists and has not yet fetched it. Crawled means Google fetched it and decided, for now, not to index it.

Our site is small and runs on hosting that responds quickly, so we did not read "overload" literally. Google's guide to managing crawl budget, written for much larger sites, gives a more useful frame. It separates crawl capacity, how much crawling a site can handle, from crawl demand, how much Google wants to crawl it. It says demand depends on factors including how popular URLs are and how stale Google's copy is. It also lists many URLs in Discovered – currently not indexed as one sign that a site may need that guide. For a new domain with almost no links from other sites, our reading was that demand was low, and that we had given Google few reasons to treat the uncrawled pages as important. That is our interpretation, not something Google told us.

First, rule out a technical block

Before blaming crawl priority, check that nothing on your side stops Google from crawling or indexing the page. We checked the SellRank product page against each of these, and it passed every one.

• It returns a 200 status, not a redirect or an error.
• It is indexable: no noindex in a meta tag or HTTP header.
• Its canonical tag points to itself, the URL we want indexed.
• It is listed in the sitemap.
• robots.txt allows it.
• It responds in about half a second.

Google's help page also suggests using the URL Inspection tool to test the live URL and see whether Google can access it. If any of these checks fail on your page, fix that first. Nothing else in this post will help a page Google is told not to crawl or index.

Cause 1: our internal links all pointed at the same two posts

Google's documentation on crawlable links says Google uses links both as a signal of relevance and to find new pages to crawl. It also says every page you care about should be linked from at least one other page on your site. We met that bar on paper. In practice we barely did.

Every blog post on our site ends with a Keep reading block. When we built it, it picked the newest posts. That sounds harmless until you count what it does. Every post, old or new, linked to the same two newest posts. As soon as two more were published, those took over, and the previous two lost their incoming links from across the archive. A post published three weeks earlier had only the links that other posts had written by hand, and most had very few.

When we counted inbound links from other posts, 13 posts had at most one. To a crawler working through a new site, those pages looked like the least important on it: rarely linked, and never from anywhere new.

We changed Keep reading to pick the posts closest in topic instead. It scores every live post on the words it shares with the current one, in their titles and keywords, and shows the closest matches, newest first on a tie. Because topic is mutual, a post about collection sorting now links to other posts about collection sorting, and they link back. After the change, we counted again: one post had a single inbound post link, and the median was six.

Cause 2: our sitemap's lastmod dates were not honest

Google's sitemap documentation says Google uses the lastmod value if it is consistently and verifiably accurate, for example when it matches the page's last modification. It says lastmod should reflect the last significant update to the page: a change to the main content, the structured data or links, not, for example, an updated copyright year. The same page says Google ignores the priority and changefreq values.

Our sitemap failed that test in two ways.

• Static pages used the time of the request. Our sitemap is regenerated every hour, so that scheduled posts appear on their publication date without a redeploy. Pages with no dated content, such as About and Contact, took the current time as their lastmod. Every hour, the sitemap claimed those pages had just changed, when they had not changed in weeks.
• The product page's date ignored real edits. The SellRank page's lastmod came from a fixed launch date, so when we updated the page, the sitemap did not say so.

Put those together and you have a sitemap that says many pages change every hour, which they did not, and that one important page never changes, which it did. If Google uses lastmod only when it proves accurate, a sitemap like that teaches it that our dates mean nothing.

Each page now carries the date its content last changed. Posts use their publication date, or their updated date if they have one. The SellRank product page uses the latest of its launch date, its last update and its most recent release in our changelog. Pages without dated content carry a fixed date, the day their content last changed, which we update when we edit them. Nothing uses the request time any more.

What else we changed

Those two fixes address the causes we found. We made three more changes that we expect to help a new site get crawled, though we cannot separate their effect from the fixes above.

• Topic hub pages. Each blog topic, such as collection merchandising, Indian D2C, or search and AI, now has its own page listing every live post on that subject. Posts join the right hubs automatically from their titles and keywords. Every post is now reachable from a page about its subject as well as from the main blog list.
• Scheduled publishing. Posts are written in batches but published on their own dates, so the site gains a few pages at a time rather than dozens at once. A post with a future date stays hidden until that day, and the hourly sitemap picks it up on the day.
• IndexNow for Bing. IndexNow is a protocol that lets a site notify search engines when a URL is new or changed. indexnow.org lists Bing, Yandex, Seznam.cz, Naver, Amazon and Yep among the participating engines. Google is not on that list, so this does nothing for the Search Console report above. It is for the search engines that do take part.

What we did not do

A few common responses to this status seemed to us either wasted effort or risky, so we left them out.

• We did not request indexing for every URL. Google's documentation on asking Google to recrawl says there is a quota for individual URL submissions, and that submitting the same URL repeatedly does not speed up crawling. We used requests for the pages that matter most.
• We did not delete or noindex newer posts to make the site look smaller. Those pages are written for readers and we want them found.
• We did not pay for links or submit the site to directories. Neither addresses what we found on our own site.

What the owner does in Search Console now

Once the fixes are live, the remaining steps happen in Search Console. If you are fixing the same status on your own site, these are the steps in order.

1. 1Open URL Inspection and enter the most important uncrawled URL. In our case, that was the SellRank product page.
2. 2Click Test live URL and confirm Google can fetch the page and that it is indexable. If the live test reports a problem, fix that before going further.
3. 3Click Request indexing. Do this for your most important pages only, because there is a quota, and repeating a request does not speed it up.
4. 4In the Sitemaps report, resubmit your sitemap so Google fetches the corrected version with its new lastmod dates. Check that it shows as read successfully.
5. 5Wait, then check the Page indexing report and URL Inspection again. Google's documentation says crawling can take anywhere from a few days to a few weeks.

Google is clear that requesting a crawl does not guarantee inclusion in search results, instantly or at all. These steps make sure Google has the right information. What it does with that information is up to Google.

Results: pending

As we write this, the fixes are live and the Search Console steps are being done. We do not yet know whether the 20 pages will be crawled and indexed, how long it will take, or whether one cause mattered more than the other. We have changed several things at once, so even a good result will not tell us exactly which change produced it. We plan to update this post when the Page indexing report shows the outcome, whatever it is.

What we can say is that both causes were real faults on our side, found by counting rather than guessing. An internal linking pattern that starved most of our archive, and a sitemap whose dates were wrong in both directions, are worth fixing regardless of what Search Console does next. Both would have hurt readers too.

What we would do differently on day one

None of this was hard to fix. It was hard to notice, because every individual page looked fine. If we were launching the site again, we would build these in from the first day rather than finding them five weeks later.

• Related content by topic from the start. A widget that shows the newest items is the default in many templates because it is easy to build. It is also the version that leaves older pages unlinked. Matching by topic takes a little more code and gives every page a fair share of links.
• Honest dates from the start. Decide for every page type where its last-changed date comes from before the sitemap goes live. Never fall back to the build time or the request time, however convenient.
• A steady publishing rhythm. Write ahead if you like, but release a few pages at a time, so each one is linked from the pages around it by the time a crawler arrives.
• Topic pages early. Even a hub with four posts on it is a page about a subject, linking to everything on that subject.
• An early look at Search Console. The figures in this post come from the 9 October update; a check of the Page indexing report in the first fortnight might have shown the pattern sooner.

The broader lesson for us was that a site's structure is part of its content. Readers follow links from post to post, and so do crawlers. A page that nothing points to is, for both of them, a page that is hard to find.

A checklist for your own site

1. 1Open the Page indexing report and list every URL marked Discovered – currently not indexed. Note which ones matter most to your business.
2. 2Check each important one for a technical block: status code, noindex, canonical, sitemap entry and robots.txt.
3. 3Count inbound internal links to each page. Any page you care about with zero or one link from the rest of your site needs more, from pages on the same subject.
4. 4Check your related-content widgets. If they always show the newest items, change them to show related items instead.
5. 5Open your sitemap and compare lastmod dates against when each page really changed. Remove any lastmod generated from the request or build time.
6. 6Give each topic a page that lists everything you have on it, and link to that page from your navigation or posts.
7. 7Then request indexing for the most important pages, resubmit the sitemap, and give it a few weeks.

The same thinking applies to a Shopify store. Collection pages that nothing links to, and product pages reachable only through a filter, are the e-commerce version of our unlinked posts. If your store has the same status on pages that matter, or you want a second opinion on a site that is not getting crawled, tell us about it on our contact page and we will give you a straight answer. If your collection pages are indexed but showing the wrong products first, see how SellRank works and try it on the free plan.