0 Clicks in 90 Days: The 2013 WordPress Plugin That Was Killing My SEO

For years, my answer to “why isn’t my blog getting indexed” was a shrug and “WordPress, man.” Today I finally sat down with Claude, pulled 90 days of real Search Console data, and audited the site properly instead of guessing. What I found wasn’t “WordPress is broken.” It was two specific, fixable bugs — and a plugin I’d genuinely forgotten was still installed.

The number that made me stop guessing

Zero. That’s how many clicks susiloharjo.web.id got from Google search in the last 90 days. Not “low” — zero, out of 611 impressions. Some of those impressions were at position #1. Position #1, zero clicks. That doesn’t happen by accident, and it doesn’t happen because “WordPress is slow” or “the algorithm hates small blogs.” It happens because something specific in the pipeline is broken.

The second number was worse: 378 of 515 published posts — 73% of everything I’ve ever written on this site — never showed up in a single search result in three months. Not low ranking. Not page 5. Literally never surfaced once.

Auditing via the REST API instead of clicking through wp-admin

Instead of poking around wp-admin tab by tab, I had Claude authenticate against the WordPress REST API with an Application Password and pull the site apart programmatically — plugin list, sitemap files, robots.txt, response headers, taxonomy counts, the works. First real finding:

curl https://[site]/wp-sitemap.xml
<urlset xmlns:xsi='...'></urlset>

WordPress core’s own sitemap endpoint was returning a completely empty <urlset>. The culprit: a plugin called XML Sitemap Generator for Google, last updated around 2013, still active, quietly telling WordPress core “don’t bother generating your own sitemap, I’ve got this” — and then serving nothing at that particular URL.

The twist: it was actually working, just not where I was looking

Here’s the part that made me correct myself mid-investigation. When I pulled the actual Google Search Console “Submitted sitemaps” report, it showed /post-sitemap.xml — the OLD plugin’s own URL — successfully read by Google, status “Success,” 515 pages discovered, last read the day before.

So the sitemap Google was actually using was fine. The one that was empty (/wp-sitemap.xml) was a WordPress-core endpoint the old plugin had intentionally disabled, and Google was never pointed at it in the first place — robots.txt and Search Console both referenced the plugin’s own URLs. Deactivating a decade-abandoned plugin was still the right call for security reasons alone, but it wasn’t the smoking gun for the indexing problem I assumed it was. It’s a good reminder to check what’s actually submitted before declaring something “the root cause.”

(Deactivating it did break those old URLs — they 404 now — so cleaning up the stale entries in Search Console is next on my list, otherwise Google just logs fetch errors against dead links going forward.)

Zero clicks at position #1 — the real suspect

If discovery wasn’t the problem, what explained zero clicks even at good rankings? The title tag. Every single post on the site was rendering like this:

<title>Why Harness &amp; Loop Engineering Are The Missing Layer Susiloharjo</title>

No separator. The site name just slams into the post title with a single space. In a Google results page, that reads as a broken or spammy result — exactly the kind of snippet people scroll past even when it’s sitting in the #1 slot. The fix was a one-line change in Rank Math’s title template, from %title% %sitename% to %title% | %sitename%. Small change, but it’s the single most plausible explanation for a 0% CTR across the entire site.

705 tags for 515 posts

The last thing I expected to find was a taxonomy problem, but it turned up by accident while fixing something else — tagging a post revealed the site had more tags than posts: 705 tags across 515 posts. Browsing the list, near-duplicates were everywhere: Agentic AI, Agentic-AI, AI Agents, AI-Agents — all separate tags, most used exactly once. Somewhere along the way, whatever process generated these posts was minting a fresh tag per post instead of reusing a shared vocabulary. Each one is a real, crawlable archive page. Hundreds of near-empty archive pages is not a good look for topical authority.

First pass: I had Claude cluster tags by normalized name (case, hyphens, plurals stripped) to find exact duplicates, then merge posts onto the canonical tag and delete the redundant one via the REST API. Ran into a fun Cloudflare gotcha along the way — DELETE requests kept failing with a cryptic 403 until we realized Python’s default HTTP client sends no User-Agent header at all, and Cloudflare quietly blocks that (error code 1010). Adding a normal User-Agent string fixed it instantly. 27 exact-duplicate tags merged, 705 down to 678. Still a long way from a clean taxonomy, but the mechanical part is done — the rest is an editorial call, not a script.

What’s actually fixed, and what isn’t yet

• ✅ Abandoned 2013 plugin deactivated
• ✅ WordPress core sitemap now populated and live
• ✅ Title separator fixed — verified live on every post
• ✅ 27 duplicate tags merged (705 → 678)
• ⏳ Stale sitemap URLs need removing from Search Console
• ⏳ 678 tags is still way too many — needs a real editorial consolidation pass
• ⏳ No featured images on most posts, so shared links show no preview
• ⏳ TTFB sitting around 1.1s behind Cloudflare — worth a caching config pass

What I actually learned

“WordPress keeps not getting indexed” turned out to be two specific, boring bugs — a title template missing a separator, and a plugin quietly disabling a sitemap endpoint nobody was even using. Neither one is a platform problem. Both were sitting there the whole time, just never surfaced because nobody had pulled the actual data and cross-referenced it against what Google Search Console had on file.

I’m giving it one to two weeks and pulling Search Console again. If impressions and CTR move, that’s confirmation. If they don’t, that’s the signal to dig deeper instead of reaching for a full platform migration — which, given 515 posts of indexing history, would cost far more than it would save.