Technical SEO · November 12, 2026 · 8 min read
Google Indexed My Homepage but Not My Blog Posts
Only the homepage indexed usually means the posts were never discovered, not rejected. Four causes produce the symptom, and one URL Inspection reading tells you which one you have.
By FluxWriter
Google indexed your homepage but not your blog posts because, in most cases, the posts were never properly discovered rather than crawled and judged. Those are opposite problems with opposite fixes, and guessing wrong costs you a month of effort pointed at the wrong thing. Four causes produce this one symptom: the posts are missing from your sitemap, nothing on the site links to them, a noindex directive applies to the post type, or Google crawled them and declined. This walks through how to tell which one you have from a single URL Inspection reading, and what each one actually needs.
Your Homepage Gets Found First Because Everything Points At It
The homepage is the most linked page on almost every small site. It is the URL people type, the one other sites use when they mention you, the target of the logo in your header, and usually the first entry in your sitemap. Google finds pages by following links and by reading sitemaps, so the homepage gets found first and re-crawled most often. None of that is a ranking decision. It is connectivity.
Blog posts start from the opposite position. A new post has one link pointing at it, from the blog index, and that link moves further from the homepage every time you publish again. Publish weekly with ten posts to a page and a post drops off page one after ten weeks and off page two after twenty. If the sitemap does not list it and nothing else on the site references it, there is nothing left for a crawler to follow.
So a homepage-only index is the ordinary signature of a discovery problem. There is no site-wide blog penalty, and Google does not treat a /blog/ path as a lower class of URL. These pages either never got found, or got found and were not chosen.
Four Causes Produce This Symptom And Two Of Them Pull In Opposite Directions
The first cause is a sitemap that does not contain the posts. Plenty of platform and plugin combinations generate a sitemap covering the homepage and static pages while quietly excluding a post type, especially a custom one.
The second is that nothing links to the posts internally. They exist, they may even be in the sitemap, and they sit at the end of a crawl path nothing walks.
The third is a noindex directive that applies to the post type rather than to one page. This one matches the symptom exactly, because it fires on every post at once and leaves the homepage untouched.
The fourth is that Google crawled the posts and decided not to index them.
The first three are discovery and permission faults, and they are fixed by adding links, correcting the sitemap, or removing a directive. The fourth is a judgement, and more links or another submission does not reverse it. That is why the order matters. You do not want to spend three weeks building internal links at a problem that was a checkbox, or rewriting posts Google has never fetched.
One URL Inspection Reading Separates Them
Open Search Console, paste one missing post URL into the inspection bar, and read the verdict line before touching anything. Then expand the page indexing details underneath. Those tell you whether Google found a referring page, whether it knows the URL from a sitemap, when it last crawled, and whether indexing was allowed.
The verdict maps to a cause. These are the readings you are most likely to see on a blog that has gone missing, and what each should make you do first.
| Inspection verdict | What it means | Likely cause | First move |
|---|---|---|---|
| URL is unknown to Google | No record of the URL at all | Never discovered | Get it into the sitemap and link to it from an indexed page |
| Discovered, currently not indexed | Known, never fetched | Weak discovery signals | Add internal links from pages Google crawls often |
| Crawled, currently not indexed | Fetched, then passed over | Judgement, not discovery | Improve or merge the page; do not resubmit |
| Excluded by noindex tag | A robots directive says no | Post-type or template setting | Find the directive in the rendered HTML or response headers |
| Duplicate, Google chose a different canonical | Treated as a near-copy | Overlapping or templated posts | Consolidate into one page and redirect the rest |
| Blocked by robots.txt | The crawler was refused | A disallow rule covering the path | Fix the rule, then request indexing |
The two rows to keep apart are the second and third. Discovered means Google knows the URL exists and has not bothered to fetch it. Crawled means it fetched the page and moved on. The first is an argument for better linking. The second is not.
The Sitemap And The Internal Links Fix Discovery And Nothing Else
Open your sitemap in a browser rather than trusting the plugin settings screen. Most sites serve an index at /sitemap.xml or /sitemap_index.xml pointing to child files. Find the one for posts and search it for a missing post URL. If the file does not exist, or the URL is not in it, you have found cause one, and no amount of rewriting will help until it is fixed.
A sitemap is a hint, not an instruction. It says which URLs exist and roughly when they changed. A URL sitting in a submitted sitemap for weeks with an unknown status is telling you the hint was not persuasive on its own.
Internal links are what makes it persuasive. Link each new post from a page that already gets crawled: the homepage if the post matters, a service or category page if it is topical, and two or three older posts on the same subject. A post that is only reachable from page three of an archive is technically linked and practically invisible. As a rough working rule, treat anything more than three clicks from the homepage as at risk, and fix it by shortening the path rather than by waiting.
A Noindex On The Post Type Is Silent, Site-Wide, And Easy To Miss
Rule this one out early, because it costs five minutes. The site-wide switch most people reach for first, the one asking search engines not to index the site, would have taken the homepage down too, so an indexed homepage usually rules it out.
Look instead at anything that applies per post type. SEO plugins expose a visibility toggle for each content type, and a single flipped switch there removes every post in it. Templates can output a robots meta tag on the single-post view only. A directive can also arrive as an X-Robots-Tag in the HTTP response header, where it never appears in the page source at all.
Check what Google actually sees, not what your source code says. Use the live test in URL Inspection and view the tested page's HTML, because the crawler renders the page and a client-side script can inject a directive that view-source never shows. The indexing allowed line in the same panel gives you the verdict in one word. If a directive is there, remove it, then request indexing once and let the recrawl happen.
Crawled And Declined Is A Content Problem, And Resubmitting Does Not Touch It
Crawled, currently not indexed means Google fetched the page and chose not to keep it. Sometimes that is temporary, particularly on a young domain with few external links, and the page appears weeks later on its own. Sometimes it is durable, and the durable version usually comes from the same few patterns: several posts covering the same query, thin posts that answer in 300 words what the ranking pages answer in 1,500, or a batch published on one day with no links, no images and no distinguishing detail.
The fix is subtraction. Take the posts that overlap, pick the one with the best structure, fold the others into it, redirect them to the survivor, and link it from somewhere that already gets crawled. Four thin posts merged into one genuinely useful page is a better outcome than four requests for indexing.
Set your expectations accordingly. Assume weeks rather than days for a recrawl and a changed decision. Google is not obliged to index any page, and no fix here changes that.
FAQ
How long should I wait before deciding something is broken?
If a post is live, linked from an indexed page, and listed in a submitted sitemap, but Search Console still has no record of the URL, that is a fault rather than a delay. As a rough rule, a month with no crawl record on a linked URL is worth investigating. A post showing discovered or crawled is a different situation and does not need the same panic.
Does requesting indexing in Search Console actually help?
It helps for a URL Google has never crawled, because it puts the page in a queue for a fetch. It does nothing for a page that was crawled and declined, since the decision was made after the fetch. The request is rate-limited per property, so use it to test one representative URL rather than working through the whole archive.
Will submitting to IndexNow get the posts into Google?
No. IndexNow is supported by Bing and several other engines, and Google has not adopted it. Pinging it is useful for the engines that do support it and it costs nothing, but it has no effect on Google's discovery or on whether Google chooses to index a page.
The Practical Takeaway
Do the cheap checks before the expensive ones. Inspect one missing post URL in Search Console and write down the verdict. If it is unknown or discovered, open your sitemap file and confirm the post URLs are actually in it, then add internal links from the homepage, a category page and two older posts, and give it two weeks. If it says excluded by noindex, find the post-type toggle or the response header and fix it today. If it says crawled and not indexed, stop publishing for a week and spend that week merging the overlapping posts you already have. Start by inspecting one URL and reading the verdict line, because every other decision on this list depends on which one it is.