To get a blog post indexed by Google, first verify the specific published URL: it must be discoverable, accessible, eligible for indexing and worth choosing over duplicates. Then use Search Console's URL Inspection for that post and fix the reason it reports. A sitemap or indexing request can help Google discover a URL, but cannot force its inclusion. Google says recrawling may take days to weeks and repeated requests do not make it faster.
Start with the exact address of the article
Copy the URL from the published post, not the editor preview or a tracking link. Check it in a private browser and inspect the response: is it a 200 article, a redirect to another URL, a 404, or a login screen? Check both HTML robots meta and HTTP X-Robots-Tag for noindex. A permitted robots.txt path is not the same as index permission; if robots.txt blocks the page, Google may not even see its noindex. Search Console's URL Inspection help explains the separate “Crawl allowed?”, “Page fetch” and “Indexing allowed?” fields. Remove an accidental block only if this article really is meant to appear in Search.
For a JavaScript-heavy post, compare the source and Search Console's live rendered page: can Google see the headline, main text and article links without a sign-in or click to load them? A browser opening the page is not proof that the crawler received the same content. If the live test fails, inspect the tested HTML and resources; if it passes, do not assume the post has already been indexed. The initial URL Inspection result reflects Google's last indexed/crawled version, while the live test checks today's accessibility and cannot predict the final canonical choice.
Check whether Google chose another version
Look at “User-declared canonical” and “Google-selected canonical” in the indexed result. A post might also be reachable through http, another host, a different trailing-slash URL, a category alias or a parameterized share link. Point internal links and the sitemap to the preferred final URL; make redirects and the declared canonical consistent. If Google selected another canonical, inspect that version too before trying to “submit harder.” The canonical is a preference, not a guarantee: Google says it may select a different URL, and the live test does not decide which duplicate will be canonical.
Do not label every non-indexed variant a problem. If the clean article is indexed and a tracking variant is excluded as an alternate, that is usually the intended outcome. If the canonical points to an unrelated page or a duplicate translation, correct the relationship and check the actual visible content; simply changing the sitemap cannot resolve the contradiction.
Give this post a route in—and a reason to stay
Link to the article from a relevant, crawlable category, guide or older post with an anchor that describes its subject. Then make the post genuinely useful for its query: answer the main question early, show a worked example or a decision criterion, explain exceptions, and support policy or technical claims with sources. Google's people-first content guidance asks whether the content offers original analysis, substantial value and a satisfying answer—not whether it hits an 800-word threshold. A 200 response plus boilerplate is not a promise of indexing; don't change only the date to pretend the post is fresh.
If an existing article already answers the same query, decide whether the new one covers a distinct reader need or whether you should improve the established page instead. For example, a post on “why this one article is missing” should provide checks on that article, whereas a site-wide indexing strategy addresses patterns across many URLs. Where appropriate, link the new post to a relevant next step such as English SEO article planning, without making every editorial link an advertisement.
Put the preferred URL in the sitemap, then request selectively
Check that the XML sitemap contains the absolute final URL, not its editor preview or redirected version. If the page had a significant content, link or structured-data update, set its <lastmod> truthfully; Google says it may use the value only when it is consistently and verifiably accurate, and it ignores <changefreq> and <priority>. See Google's XML sitemap notes and the sitemap update guide. Submitting a sitemap for many articles is a discovery route, not a bulk index command.
For one important new or repaired URL that you manage, enter it into Search Console, test the live URL, then use “Request indexing” if eligible and available. The recrawl instructions distinguish a few URLs in URL Inspection from many URLs in a sitemap. The Indexing API is only for qualifying JobPosting or livestream BroadcastEvent pages, not ordinary blog posts; do not use a third-party “instant indexing” service as a workaround.
If the article is still missing, follow its reported state
- Unknown or discovered, not crawled: verify the exact URL appears on a crawlable page and in the intended sitemap; check server availability and give Google time. A request is not a deadline.
- Crawled, currently not indexed: inspect the last crawl date and Google-selected canonical, then compare the page with its close alternatives. Improve the answer and evidence where they are weak; another request without a meaningful change is unlikely to solve that.
- Blocked,
noindex, fetch failed or redirected: fix the specific technical cause and use the live test to verify the fix. Recheck the published URL, not only the preview. - Indexed but no search visits: indexing succeeded; move to query relevance, impressions and the post's usefulness rather than resubmitting. “URL is on Google” is eligibility, not a promise that it appears for every search.
Record the URL, publication or repair date, indexed-result crawl date, live-test result and next check. That small record separates a genuine indexing issue from a slow report update or a page that is indexed but has not earned relevant impressions.