Slow indexing vs. not indexed: how do you actually tell them apart?

Let’s define the two terms first. Slow indexing means the page will eventually enter the index, it just has to wait. Not indexed means it is stuck at some step and no longer moving forward — waiting until next year changes nothing. The two call for completely different actions: for the first, do nothing and wait; for the second, you have to dig in.

The most common mistake in practice is treating slow as not indexed. The article has been live for three days and can’t be found, so you start rewriting the title, rewriting the opening paragraph, clicking submit request again and again, and even wondering whether the content needs a full rewrite. None of that helps, and it muddies variables that were clean to begin with, leaving you without even a baseline when you really do need to diagnose.

The way to tell is not intuition but one concrete action: paste the full URL into the URL Inspection box at the top of Search Console. The status it returns tells you exactly which tier the page is stuck in, and what to do about that tier. That reading method is covered in more detail in index check methods; here I’ll keep only the conclusion.

One counterintuitive fact is worth stating up front: content quality affects only one of the four status tiers. In other words, when most site owners rush to rewrite content, the real blocker usually isn’t content. In the original record of our indexing troubleshooting, we tallied the status distribution across our own sites, and the distribution of culprits was far from intuitive.

Check the status first: which tier is your page stuck in?

URL Inspection results essentially fall into the four tiers below. Run a few unindexed pages through each and you can tell whether this is a widespread problem or an isolated one.

One thing to note when reading this table: if a large number of pages sit at unknown, the discovery layer is broken and changing content is pointless. If many sit at Discovered, it usually means the pages are orphans — Google knows they exist but has no reason to crawl them first. Both situations show up in the three cases below.

There is also the case where a page never made it into the sitemap at all — the entry point itself is wrong. For what a sitemap does and how to write one, see what a sitemap is; I won’t repeat it here.

Case one: the sitemap never updates, so Google holds an old version

The first case looks unremarkable on the surface: a content site keeps publishing, yet rankings and indexing haven’t budged in months, and the logs show no errors. The site owner assumed the sitemap was updating every day, because the plugin dashboard showed a green checkmark.

What was actually happening is that the sitemap output had been frozen by caching. The site had object caching (Redis) enabled, and the generated sitemap was held in a transient cache. New articles were written to the database, but when Google requested sitemap.xml it still received the version from before the freeze. To the crawler, the site had published nothing new for months.

This kind of failure is characterized by zero errors. The plugin believes it delivered the sitemap, the cache believes it scored a hit, and the dashboard shows nothing unusual. There are only two ways to expose it: open sitemap.xml directly in a browser and check whether the newest article is in there; or go to the sitemaps report in Search Console and verify the time Google actually read it and the number of URLs discovered — not the last generated time shown in the plugin dashboard.

How do you confirm the sitemap is live?

The most reliable trick is to publish a probe article and immediately open sitemap.xml to see whether it appears. If it doesn’t, clear the cache and look again; if clearing the cache makes it appear, the caching policy is the culprit. This site was only fully fixed by using an mu-plugin to exclude the sitemap from caching — the new page entered the sitemap the same day.

One more blind spot worth flagging: if the cache file name doesn’t contain the word sitemap, searching the server by file name will never find it. When investigating, don’t search by file name alone — search by directory and timestamp.

Someone will ask: if the sitemap isn’t updating, can a single request-indexing submission rescue it? No. Manual indexing requests are an accelerator, and the precondition is that the page itself can be discovered. If the basics of indexing controls like robots, noindex, canonical, and sitemap aren’t working, the accelerator is accelerating zero.

Case two: rendering isn’t readable, so the page looks empty to Google

The second case is subtler. The page opens perfectly in a browser — text, images, and tables all there — but in the HTML Google fetched, the body is an empty shell: the content is injected entirely by JavaScript on the client side.

Google does render JavaScript, but rendering has a queue, and the result it renders is not guaranteed to match what you see in your browser. When the body only appears after rendering, and the render resources are queued behind theme scripts, the crawler receives a page with no content. It won’t report an error; it will simply judge the value of that empty shell, and the conclusion is naturally not to index it.

The site owner’s instinct is usually “my page clearly has content,” so they rewrite the copy and add more words — wrong from the start. To diagnose this, you need to look at two versions of the HTML, not a browser screenshot.

How do you tell whether it’s a rendering problem or a content problem?

In URL Inspection, compare two things: the HTML under “View crawled page,” which is the raw version Google first received; and the rendered result under “Test live URL.” If the raw HTML has no body text and it only appears after rendering, that’s a rendering problem, unrelated to content quality.

There are three fix directions, ordered from lowest cost to highest: move the key body content to server-side output so the first-screen content goes straight into the initial HTML; switch render-blocking scripts to deferred loading; or use prerendering or static generation to produce the rendered result ahead of time. The core principle is just one — the body text must be readable in the initial HTML, so don’t leave it to a script that may never execute.

Related problems include content hidden in tabs, accordions, or modules that load only after interaction. Anything that requires a click to see should be assumed invisible to crawlers, unless it really is in the initial HTML. The relationship between crawling, indexing, and speed along this chain is covered systematically in the technical SEO guide to crawling and indexing.

Case three: the canonical points elsewhere, so the page votes for someone else

The third case is the most unfair: the page can be crawled, it renders, and the content is solid, yet it never gets indexed. After digging all the way down, the problem was the canonical tag — the page declared another URL as its canonical version.

The canonical tag tells Google “among this pile of similar pages, treat this one as the reference.” Once a page’s canonical points elsewhere, Google consolidates its signals into the target page; the page that was pointed at gets no vote, and the page itself may also be excluded from the index. There are three common causes: a template variable written wrong so every page points to the homepage; an old address that wasn’t updated after a migration or domain change; and mishandled pagination or filter parameters where variant pages point at each other. This kind of error throws no errors, and you can’t find it by looking at the page alone.

How do you verify the canonical URL Google actually selected?

Don’t just look at what the HTML says; look at which one Google chose. URL Inspection has a field that explicitly states the canonical URL Google selected — if it doesn’t match the page’s real address, this is where the problem lies. For bulk diagnosis, fetch the source of a batch of pages and compare each declared canonical against its own URL; the cost is very low.

One pitfall when fixing: after changing the canonical, clear the cache before verifying — a 200 served from cache is an illusion. For the definition of canonical and common misuse, see what canonical means, which lists every scenario in which a page should point to itself. To understand the version of a page as Google sees it, URL Inspection in practice is a stage you have to pass.

How long does indexing actually take? The D+14 timeline of 7 canary pages

With the three blockers covered, let’s come back to “slow.” Much of the anxiety owners feel comes from a wrong expectation: that a page published one day should be searchable on Google the next. That isn’t how it works.

We ran a canary test: 7 pages published on 09-18, with indexing status checked daily afterward. The first few days showed zero indexed, pages trickled in along the way, and it wasn’t until day 14 that all 7/7 were indexed. Nothing special was done during the process and nothing broke — this is simply the normal speed of a site with normal authority right now.

The test yields two direct conclusions. First, indexing is measured in weeks, not hours. Second, not being indexed on days three through seven after publication falls in the normal range, and any “rescue” action at that point is superfluous and pollutes the variables. What you should really do is wait — and use the waiting period to shore up the deterministic work, like internal links and the sitemap.

By the way, most of those “how many days to get indexed” anecdotes floating around can’t be reproduced. There’s a public Reddit discussion whose original post is titled “Recently hit 6.4 mil monthly organic traffic for a SaaS website. Here’s the 40 tips that h…”, with participants including /u/levi815 and /u/DrJigsaw. When reading posts like this from public Reddit discussions, separate long-term practices from one-off results — an indexing blocker is never solved by a single trick.

If you want to know which pages are holding you back, crawl budget and logs are more reliable evidence; the method is in log analysis and crawl budget.

A table for the order of diagnosis

Let’s compress the above into a single table. The order is sorted by “speed of falsification,” with the items that can be ruled out in a few minutes first.

The order matters because it stops the bleeding. Most tutorials out there have you start at step 6 and go straight to rewriting content, but in the indexing investigations we’ve handled, the culprit is almost always hiding in the first five steps. Only once the first five are clean is it worth talking about content without wasting effort. The complete guide to Google indexing and the crawl, index, and ranking process can serve as background reading for this table.

Once it’s fixed, which numbers should you watch?

Fixing it isn’t the end. Indexing can break again: changing themes, installing plugins, migrating servers, altering caching policy — any one of these can snap a chain that works today. So leave behind numbers you can re-check.

I watch four: the number of indexed pages site-wide, the last time the sitemap was read, the status distribution of unindexed pages, and the rate at which canonicals match their own URLs. The first two weekly; the last two need only a monthly spot check on a batch of pages. An anomaly becomes a number first, and an incident second.

One more lever deserves its own mention: internal links. Unindexed pages are mostly orphans, and linking from indexed, topically related pages is the fastest and most controllable action. Use the target page’s real title as the anchor text; don’t stuff keywords. With pages built at scale, pay particular attention to the indexing risk of templated sites — see programmatic SEO template pages and indexing risk — and to the plugin–index–content interactions common on WordPress sites, in WordPress plugins and indexing speed.

One last reminder: indexing is only the ticket in. Being in the index doesn’t mean you rank, and ranking doesn’t mean you get inquiries. If indexing and traffic are both fixed and inquiries still haven’t moved, that’s a different problem — don’t keep doubling down on the indexing line.

Frequently asked questions

How long after publishing before not being indexed counts as abnormal?

According to our canary test, it took until day 14 for all 7 pages to be indexed. So if it’s been under two weeks, don’t draw conclusions — treat it as a normal waiting period, and meanwhile confirm the page is in the sitemap and that internal links point to it. If it’s still not indexed past that window, work through the order table above item by item.

Does repeatedly clicking “Request indexing” speed up indexing?

No. The quota for indexing requests is limited, and the official notice is explicit: submitting the same URL multiple times does not change its place in the queue. It is only an accelerator, and the precondition is that the page itself can be discovered. Submitting an already-indexed page just burns quota for nothing.

The plugin dashboard says the sitemap is fine — do I still need to verify it myself?

Yes. A frozen sitemap is a silent, zero-error failure: the plugin believes it delivered, the cache believes it hit, and the dashboard looks normal. The only reliable method is to open sitemap.xml directly and see whether the newest page is there, then check the sitemaps report in Search Console for the time and URL count Google actually read.

If the canonical is written wrong, will Google correct it on its own?

Don’t count on it. Google sometimes ignores an obviously wrong canonical, but that’s the exception, not a mechanism you can rely on. The right approach is to make every page’s canonical point to itself, clear the cache after the change, then use URL Inspection to confirm Google’s selected canonical has caught up.

If a site is slow to index, does that mean its content quality is poor?

No. Content quality affects only the “Crawled – currently not indexed” tier of the four. When a large number of pages are stuck at unknown or Discovered, the problem is in the discovery and crawling layer — rewriting content means fixing the wrong part.

Liu Yu · Tianwen SEO Research

I work on SEO and GEO for foreign-trade independent sites, and I make a habit of writing up the tests I’ve run along with the failure criteria. For research methods and my integrity boundaries, see the About page; more records like this are in research articles. If you want to tell me directly which tier your site is stuck at, you can leave a message on the contact page.

Sources = hands-on testing: tianwenseo indexing investigation records (three blockers: stale sitemap / unreadable rendering / misdirected canonical; root cause of the sitemap freeze incident = twwl Redis transient cache freeze, fixed with an mu-plugin); canary test: 7 pages published on 09-18, 7/7 indexed by D+14. Public material: the public Reddit discussion thread “Recently hit 6.4 mil monthly organic traffic for a SaaS website. Here’s the 40 tips that h…” (participants /u/levi815, /u/DrJigsaw, and others); tianwenseo.com/google-indexing-problems-three-real-cases-tw/ (Traditional Chinese original, verifiable).

This page was machine translated from the Simplified Chinese version and is still awaiting human review.