You published the article, waited, and the URL is still absent from Google. Search Console usually puts it in one of two buckets: "Discovered – currently not indexed" or "Crawled – currently not indexed". Those phrases feel like a delay. They are classifications, and each one points at a different kind of work. Resubmitting the URL for the fifth time does not change the classification.
Unindexed articles almost always fail in one of four places: Google has not been given a clean path to the URL, Google cannot use the response it received, Google thinks another URL is the copy that should count, or the page does not add enough of its own to be kept. Fix the one that the report names. A technical block can be removed the same day. Nothing in Search Console forces the index to accept a page on a timer.
Read the URL before you change the site
Open URL Inspection and paste the article URL. Write down four facts:
- Whether the URL is on Google.
- Which sitemaps and referring pages Google lists under discovery.
- Whether crawling was allowed, whether indexing was allowed, and when the URL was last crawled.
- The canonical you declared and the canonical Google selected.
Then run the live test. The indexed view is the last crawl. The live test is what Googlebot gets now. A passing live test means the URL is fetchable and renderable. It does not mean the URL will be indexed. The field-by-field reading is in the URL Inspection guide.
If the live test fails, stop. You do not have an indexing mystery. You have a response Google cannot use.
Discovery: the URL is unknown, or known and unfetched
"URL is unknown to Google" means there is no record of the URL from links or from a sitemap Google has processed. "Discovered – currently not indexed" means Google has the URL on a list and has not crawled it, or has not chosen to crawl it yet.
Check the boring causes first.
The article is missing from the XML sitemap, or the sitemap that contains it has not been submitted, or the sitemap is returning an error. Put the canonical URL in the sitemap with a lastmod that matches a real content change, and submit that sitemap in Search Console. What belongs in the file is covered in the sitemap guide.
No HTML page links to the article. URL Inspection shows no referring pages. Add a link from the section page and from one related article, using a normal href in the HTML. How to do that without a footer dump is the subject of the internal linking guide.
The site is new, or it is large and Google is fetching other URLs first. Discovery can be fine while the crawl queue is long. On a site with a few thousand URLs and healthy responses, Google's crawl budget documentation says you usually do not need a crawl-budget project. If the Page indexing report is dominated by "Discovered – currently not indexed" and the site is large or the URLs change every day, then the queue itself is the topic, and the crawl budget guide is the one to use.
Server errors and slow responses shrink how much Google will fetch. If Crawl stats shows rising response times or 5xx codes, fix the host before you add more URLs to the sitemap.
Access: Google fetched something it cannot index
The report names these directly: blocked by robots.txt, excluded by a noindex tag, soft 404, unauthorized, forbidden, or a server error. The live test agrees when the screenshot is a login wall, a blank document, or an error message.
A noindex meta tag or X-Robots-Tag header left over from staging is the classic one-day fix. Search the article template and the CDN rules for noindex. Remove it on the URLs you want in Search. Keep it on URLs you do not, such as previews and internal search.
robots.txt is the other staging leftover. Disallow: / on production stops crawling of the whole host. Google can still index a blocked URL from outside links, without a snippet. Allow the article paths. The robots.txt guide lists the patterns that catch more than you intended.
Soft 404 means the status was success and the body looked empty or like a "not found" message. If the article is real, render the article and return 200. If the URL is dead, return 404 or 410. The soft 404 guide separates those cases. Do not solve a missing article by pointing a canonical at a different story unless that story is actually the same piece.
JavaScript-only articles fail the live test in a specific way: the raw HTML is a shell, the screenshot never paints the headline, and console messages show failed requests. Put the title and the main text in the first HTML response, or fix the rendering so the live test screenshot shows them. A page that requires a click to reveal the body is a page Google may treat as empty.
Duplication: another URL already represents this story
"Duplicate without user-selected canonical" means Google found copies and you did not name a preferred URL. "Duplicate, Google chose different canonical than user" means you named one and Google kept another. "Alternate page with proper canonical tag" means the duplicate is correctly pointing at the preferred URL. That last one is not a bug on the duplicate. Check that the preferred URL is the one indexed.
Causes that show up on publishing sites:
- The same story on a www host and an apex host, or with and without a trailing slash, without redirects.
- A campaign parameter that the template treats as a new page.
- Two articles that track the same news with the same quotes and the same structure.
- A syndicated copy on another site that canonicals to itself, while yours is thinner.
Consolidate. Pick one URL, redirect the extras with a permanent redirect when they should not exist, and use a self-referential canonical on the URL you keep. Align the sitemap and the internal links with that URL. The canonical guide is the sequence. Do not noindex the copy you hope will pass signals to the original. Google's canonical documentation says noindex drops the URL from Search rather than merging it.
Value: crawled, and not kept
"Crawled – currently not indexed" with a clean live test, an allowed crawl, an allowed index, and a matching canonical means Google fetched the page and did not put it in the index. The usual reading is that the page does not add enough beyond what Google already has, or that the site has many URLs of the same kind.
Improve the page or combine it with a stronger one. Add reporting, documents, or a clear account of what changed, in your own words. Merge thin updates into the article that already ranks for the topic, and redirect the thin URL. Remove or noindex tag pages that exist only because the CMS created them. Then give the improved URL a link from the section so the next crawl is of a page the site treats as real.
There is no switch in Search Console that overrides that judgment. Requesting indexing asks for a crawl. The index decision happens after the crawl.
What "within a day" can mean
A stray noindex, a production robots.txt that disallows the site, a sitemap that points at the wrong host, or a soft 404 on a URL that should render the article: those are configuration bugs. You can ship the correction the same day. After the live test shows the article, you can request indexing for that URL if the manual quota for the property still allows it. Google does not publish a fixed public number for that button, and a second request the same day is not a stronger request.
What you cannot promise is that the URL will be indexed before tomorrow. Job postings and livestream pages have a separate, documented notification channel, the Indexing API, described in the Indexing API comparison. Ordinary articles are not what that API is for. IndexNow notifies participating engines and is not Google's indexing path. The comparison is in the IndexNow article.
A single-article sequence
- Confirm the live test shows the headline and the body, with crawling and indexing allowed.
- Confirm the canonical, the sitemap URL, and the internal links are the same URL.
- If a technical block was real, remove it and request indexing once.
- If the status is "Crawled – currently not indexed" and the live test is clean, edit or merge the article before you request anything.
- Check the URL again after the next crawl. If many URLs share the status, fix the template and use the Page indexing report rather than a list of one-off requests.
The article you wanted in Search is either blocked, duplicated, undiscovered, or not distinct enough to keep. The inspection result tells you which. Fix that cause, then look at the next article only if it fails in a different way.
CrawlFaster records indexing status across the URLs you track, so a template bug shows up as a shared status instead of a one-off inspection. The repair is still the template, the links, or the article itself.
