I Lost 20 Indexed Pages on Blogger. Here's Why

Blogger indexed pages dropping? I lost 20 indexed pages on my Blogger blog in under three weeks, dropping from 32 to 12, and the cause was almost always one of three things: duplicate ?m=1 mobile URLs confusing Google's crawler, a JSON-LD schema conflict between your theme and individual posts, or Google actively deprioritizing thin or oversaturated content. This audit walks through the exact Search Console diagnostic I ran, including the real before/after numbers, so you can find which one is hitting you and fix it without guessing.

Diagnose Your Exact Problem in 60 Seconds

Before reading the full breakdown, check which symptom matches what you're seeing in Search Console. Each one links straight to its fix below.

What you see in Search Console	What it actually means	Fix
Same URL twice, one with ?m=1	Legacy Blogger mobile parameter, not a real duplicate	Step 3, usually nothing to fix beyond confirming one setting
"Redirect error" on live, working posts	Stale crawl data from a recent template republish	Test live in URL Inspection, then request reindexing
Rich Results Test shows two BlogPosting blocks	A pasted schema conflicting with your theme's auto-generated one	Step 4, delete the pasted block
Real, unique articles stuck in "Explored, not indexed"	A content problem, not a technical one	Step 5, needs a sharper angle, not a settings change

The Day My Indexed Pages Dropped From 32 to 12

I didn't notice it through traffic first. I noticed it in Search Console's "Pages" report. Thirty-two indexed pages in early August, twelve just a few weeks later. No algorithm update in the news, no manual action notice, nothing obviously broken when I opened the homepage. Just fewer pages showing up where they used to.

If you're reading this because the same thing happened to you, most Blogger SEO guides simply won't help. They're written for WordPress, they assume you have plugin-level control over your sitemap and schema, and they treat "indexation dropped" as one problem instead of the three or four separate problems it usually turns out to be. If your issue is the opposite, posts that were never indexed in the first place, I covered the basics of that in Why Your Blogger Blog Isn't Showing on Google. This post picks up where that one leaves off: what to do when pages that were indexed start dropping out.

So this is the audit I actually ran, property by property, report by report, to find out exactly what was happening and fix it.

Step 1: Confirm You're Looking at the Right Search Console Property

Before touching any report, check which property you're viewing. This sounds obvious, but it's the single most common source of confusing, contradictory data on Blogger specifically. Blogger blogs typically end up with up to four separate Search Console properties without the owner realizing it:

• sc-domain:flowclique.com — the domain property. This aggregates www, non-www, http, and https automatically. This is the one you should trust.
• https://www.flowclique.com — a URL-prefix property. Shows only that exact prefix, which can look artificially low if some traffic or indexation is split elsewhere.
• Two Blogspot properties (leftover from before I connected a custom domain) — these often still show old data and can make it look like your indexation crashed when really you're just looking at an abandoned Blogspot subdomain.

If you've ever migrated from a free Blogspot subdomain to a custom domain, check this now. Every diagnosis after this step assumes you're looking at the domain property (sc-domain:). If you're not, your numbers may be misleading you before you've even started.

Step 2: Read the "Page Indexing" Report Like Google Actually Means It

Go to Indexing → Pages in Search Console. You'll see a breakdown by "reason," each with a page count. Google's own tooltips are frustratingly vague, so here's what each one actually means:

• Explored, currently not indexed — Google crawled the page and chose not to index it. This is the one to worry about most; it's usually a content or duplication signal, not a technical error.
• Detected, currently not indexed — Google knows the URL exists, usually from a link or sitemap, but hasn't crawled it in depth yet. Often resolves on its own within a couple of weeks.
• Redirect error — Googlebot received an actual HTTP redirect response when requesting the URL. On Blogger, this is almost never caused by your theme code; it's a platform or domain-settings issue, usually temporary after a template republish.
• Page with redirect — Usually harmless; old URLs correctly redirecting to new ones. On my blog this bucket was mostly http:// and www. variants redirecting cleanly to the canonical https:// URL, plus a handful of ?m=1 URLs redirecting into their clean counterpart — exactly the kind of entry that looks alarming but is Google confirming the redirect works.
• Alternate page with proper canonical tag — Good news, not bad. This is Google correctly recognizing a duplicate (often a ?m=1 URL) and consolidating it into your real page.
• Excluded by 'noindex' tag — Worth checking every entry here individually. Sometimes it's intentional (search pages, tag archives); sometimes it's a template bug applying noindex somewhere it shouldn't.

The category that actually matters for a real content or indexing problem is "Explored, currently not indexed." Everything else on this list is either self-resolving or a technical footnote. Sort your attention accordingly; most people panic about the wrong row.

Here's what the "Page with redirect" bucket actually looked like on my property when I clicked into it — entirely http://, www., and ?m=1 variants, each correctly redirecting to a clean canonical URL:

Step 3: The ?m=1 Trap (And Why It Looks Worse Than It Is)

Click into "Explored, currently not indexed" and you'll likely see a pattern: the same article appearing twice, once as a normal URL and once with ?m=1 appended. Google's own documentation on how indexing works confirms that being crawled and being indexed are two separate steps. A page can be fetched successfully and still not make it into the index if Google's systems judge it redundant or low-value relative to what's already indexed.

flowclique.com/2026/07/chatgpt-vs-persistent-ai-agents-whats.htmlThis is Blogger's legacy mobile-view parameter. Even with a fully responsive theme, old links, cached versions, and sometimes Google's own crawl history can generate both versions. As long as your theme has a proper canonical tag pointing to the non-parameter version, this is not a real duplication problem. Google will consolidate it over time. But it does inflate your "problem" page counts and can make a healthy blog look broken at a glance.

How to confirm your setup is correct:

1. Go to Blogger → Theme → Customize (dropdown) → Choose mobile theme.
2. Confirm it's set to "Desktop", not "Mobile." If your theme is already responsive, this stops Blogger from serving a separate mobile template that generates fresh ?m=1 URLs.
3. View your page source and confirm you have a single <link rel="canonical"> tag pointing to the clean URL, generated dynamically (in Blogger's XML theme language, this looks like data:view.url.canonical).

If both of those are already correct, as they were on my blog, the ?m=1 entries you're seeing are simply old crawl data working its way out of the index. No action needed beyond confirming the setting. In "Explored, currently not indexed" this shows up as each affected article listed twice — once as the clean URL, once with ?m=1 tacked on — which is exactly the pattern to look for before you assume anything is broken.

✅ The Fix: Set your mobile theme to "Desktop" in Blogger settings if it isn't already, confirm your canonical tag is dynamic (not hardcoded), and stop worrying about ?m=1 rows in your report. They clear themselves once Google recrawls.

Step 4: The JSON-LD Duplication Bug Almost Nobody Talks About

Few guides mention this one, and it's worth checking even if your indexation numbers look fine, because it's a data-quality issue rather than a visible error.

Most Blogger themes generate a BlogPosting schema (structured data) automatically for every post, using dynamic variables like data:post.url and data:post.title so it always matches the real page. That part is usually fine.

The problem shows up when you've copied a draft from another editor, a template, or an outside source that also includes its own hardcoded <script type="application/ld+json"> block with a manually-written BlogPosting schema, often with a placeholder headline or an old draft URL that no longer matches the published page.

The result: two competing BlogPosting schemas on the same page, one correct (from your theme) and one wrong (pasted into the post body), disagreeing with each other about the page's own title and URL.

How to check: View the page source (right-click → View Page Source, or use Google's Rich Results Test) and search for "@type": "BlogPosting". If it appears more than once, you have this issue.

How to fix it: Keep the version your theme generates automatically. Delete any hardcoded BlogPosting block pasted directly into a post's HTML. If you want to keep an FAQ schema from the same block, that's fine to leave in place on its own, since it isn't duplicated by the theme.

Here's what a healthy result looks like once the duplicate is removed — a single BlogPosting block and a single breadcrumb block, each validated once:

✅ The Fix: Run any recent post through Google's Rich Results Test. If "BlogPosting" appears twice, open the post's HTML editor, find the second hardcoded block, and delete it. Leave your theme's automatic one untouched.

Step 5: Separate "Technical Problem" From "Content Problem"

This is the step most audits skip, and it's the one that actually determines what you do next. Once you've cleared out the ?m=1 noise and confirmed your schema isn't duplicated, look at what's left in "Explored, currently not indexed." If you still have real, unique articles in that list, not parameter duplicates, not RSS feeds, not your favicon, that's not a technical bug anymore. That's Google telling you the content itself isn't earning a place in the index, the same underlying signal behind why some blogs get traffic but no sales: the content isn't standing out enough to earn its spot.

The tell is usually the topic itself. Oversaturated formats, generic "best of" listicles, tool comparisons that hundreds of other blogs have already written, are far more likely to sit unindexed than genuinely narrow, specific content, even when the writing quality is identical. Google doesn't need a fourth "Tool A vs Tool B" article. It needs the one angle nobody else has covered.

✅ The Fix: Don't add more words to a generic article. Add a narrower angle it currently lacks: a regional detail, a real number from your own experience, a screenshot, or a specific audience nobody else is writing for. Then strengthen internal links pointing to it and request reindexing.

Monthly Indexation Health Checklist

1. Confirm you're checking the sc-domain: property, not a URL-prefix or leftover Blogspot property.
2. Check Indexing → Pages and note the count under "Explored, currently not indexed." This is your real signal to watch month over month.
3. Filter out ?m=1, RSS feed URLs, and favicon entries before judging the number.
4. Spot-check 2–3 flagged URLs with the URL Inspection tool's "Test Live URL" to rule out temporary technical errors.
5. View source on a random recent post and confirm only one BlogPosting JSON-LD block exists.
6. Confirm your sitemap is still listed under Sitemaps with a "Success" status and a recent read date.
7. For any genuinely unindexed unique article, ask honestly whether it covers ground five other blogs haven't already covered — the same gap I dig into in Why Your Blogger Blog Isn't Showing on Google.

FAQ

How long does it take for a Blogger page to get reindexed after a fix?

Anywhere from a few days to a couple of weeks for organic recrawl. Using URL Inspection → "Request Indexing" after a fix usually speeds this up, though Search Console limits manual requests to roughly 10–12 URLs per property per day.

Does Blogger generate a sitemap automatically?

Yes. Blogger automatically serves a sitemap at flowclique.com/sitemap.xml. You still need to manually submit it once under Search Console → Sitemaps; it isn't detected automatically just because it exists.

Is a dropping indexed-page count always a sign of a penalty?

No. Manual actions are shown explicitly under Security & Manual Actions in Search Console; if that page is clean, you're not dealing with a penalty. A drop is far more often duplicate-URL noise, a template change still propagating, or content that Google is deprioritizing rather than punishing.

Should I delete unindexed articles instead of fixing them?

Only as a last resort. Deleting loses whatever backlinks or social shares the page has already earned. Rewriting with a more specific angle, and strengthening internal links pointing to it, resolves most cases without losing that equity.