A WordPress SEO story, and what it taught me about choosing a CMS.
I want to tell you about the worst week I’ve had on a client project, because I think it’s more useful than another “WordPress SEO in 6 steps” guide. There are thousands of those. This is the one thing I actually know that most of them don’t cover.
A couple of years ago we built a site for a real-estate agency on Bali — villas and land, the usual mix of sales and long-term rentals. It went well. For months it went really well. And then, over the course of a few weeks, more than half of its pages quietly fell out of Google’s index. Not dropped in ranking. Fell out. Gone.
It took us five to six months to fully recover. I’ll walk through exactly what happened, because the failure itself is instructive — but the bigger lesson is the one underneath it, about what kind of platform you’re standing on when something like this hits. That’s the part nobody tells you when they say “WordPress is the best CMS for SEO.”
Real-estate sites have a filter problem. A visitor wants villas, for sale, under a certain price, in a certain area, maybe tagged “luxury.” Most WordPress property sites handle that the lazy way — with URL parameters. You end up with addresses like this:
site.com/property/for-sale/villa?currency=IDR&filter[0]=3
That kind of URL is close to dead weight for SEO. It’s ugly, it’s hard for a person to read, it spawns endless near-duplicate combinations, and search engines mostly don’t want to index it. So we didn’t do that. We did the slower thing.
We pulled the full keyword set for the niche — what people on Bali actually search when they’re looking to buy or rent — and we built the filter system around clean, static, human-readable paths instead. So a filtered view lived at an address like this:
site.com/buy/type-villas/tag-luxury/
And each of those filter pages wasn’t just a bare list of listings. Every one had its own title tag, its own meta description, its own H1, and a genuine block of descriptive text written for that specific combination — buying luxury villas, renting land long-term, whatever the path was. Honestly, not many people building property sites bother with this. It’s real work. But it meant every meaningful filter combination was a proper landing page that could rank on its own for a specific, high-intent search.
It worked. Those pages pulled in traffic and enquiries. I’m telling you all this not to pat ourselves on the back, but so you understand the scale of what we were about to lose. This wasn’t a blog with ten posts. It was a few hundred carefully built, individually optimized pages — and they were the whole engine of the site’s organic traffic.
Here’s the mechanism, in plain language, because it matters for the rest of this article.
Every page on a site carries a small, invisible instruction in its code called a canonical tag. It tells Google: “this is the real, original address for this page — index this one.” Normally each page’s canonical points to itself. That’s correct and healthy. It’s how Google knows your luxury-villas page is its own thing.
On our site, the Yoast SEO plugin was generating those canonical tags. Then two things updated at roughly the same time: the Yoast plugin pushed a new version, and the WordPress core itself updated. After that, the canonical tags on those filter pages were no longer pointing to themselves. They were all pointing at one single internal technical page.
Sit with what that means for a second. Every one of our few hundred optimized filter pages was now, in its own source code, telling Google: “don’t index me — index that other page instead.” We had, without touching a thing ourselves, instructed the search engine to throw away the entire library we’d built. And Google, eventually, did exactly as it was told.
If this sounds like a freak accident — it isn’t, and that’s the uncomfortable part. Yoast has a documented history of this class of bug. Since the version where it started storing SEO metadata in its own database table, there have been repeated reports of updates and migrations leaving wrong canonical values behind — pointing at staging URLs, at dev machines, at the wrong page entirely — and quietly deindexing sites. We weren’t unlucky pioneers. We hit a known pothole. We just didn’t know it was there.
I could end the cautionary tale at “a plugin broke our canonicals.” But that would let me off too easily, and it would skip the part you can actually learn from. Because the technical fault wasn’t really our fault. What happened next was.
The timing was cruel. This all coincided, more or less, with one of Google’s broad core updates — one of those big algorithm refreshes where rankings shuffle around across the whole web for a couple of weeks and everyone in SEO stares at their dashboards. So when our traffic started sliding, we had a ready-made explanation sitting right there. “It’s the core update. Google’s just stormy right now. It’ll settle.”
So we waited. We told ourselves the sensible-sounding thing and we waited for it to settle. I don’t know precisely how many weeks we lost to that assumption, but it was enough weeks that by the time we actually looked under the hood, a lot of pages were already fully dropped rather than just wobbling — and a page that’s been deindexed for a while is much slower to bring back than one that’s only slipping.
That’s the real lesson, and it’s not a technical one. When traffic falls, there is always a plausible external story available — a core update, a seasonal dip, a competitor. Those stories are comforting because they mean it’s not your job to fix anything. And sometimes they’re even true. But “it’s probably the algorithm” is a diagnosis you have to earn by ruling things out, not the one you reach for first because it lets you close the laptop. The first move when traffic drops should always be to open Search Console and check whether your pages are still actually indexed. We know that. We teach that. We skipped it anyway, because a core update gave us permission to.
Fixing the canonical tags themselves was, in the end, not the hard part. Once we’d correctly identified what was happening, we got every filter page pointing its canonical back at itself, cleared out the bad data the plugin had stored, and made sure our sitemap listed only the real, correct URLs.
Getting back into the index was the slow part. Recovery is not symmetrical with the fall. Telling Google “actually, please index these pages again” is a request, not a command — you re-submit, you request indexing, and then you wait on Google’s schedule, not yours. Trust that’s been withdrawn comes back slowly. All in, it was something like five to six months before the site was properly back to where it had been, earning the traffic it had already earned once.
Months of a client’s organic pipeline, lost. Not to a competitor, not to a penalty, not to bad content. To one tag, flipped by a routine update, on a platform where that’s allowed to happen silently.
It would be easy to finish here with “audit your plugins” and move on. But I think this case points at something bigger, and it’s the thing I now actually think about when a client asks which platform to build on.
WordPress runs a huge share of the web, and it earned that. It’s flexible, it’s familiar, and for content-heavy sites its SEO tooling is genuinely strong — plugins like Yoast and Rank Math will generate more than twenty types of structured data automatically, which matters a lot now that you’re trying to get cited in Google’s AI Overviews and not just ranked. I’m not anti-WordPress. We build on it constantly.
But our Bali disaster was not a random misfortune. It was a structural property of how WordPress works. A WordPress site is an assembly: a core, plus a theme, plus a stack of plugins, each from a different developer, each updating on its own schedule, for reasons you don’t control. The canonical tag for every page on a major site was being produced by a third-party plugin — and when that plugin and the core both moved at once, something load-bearing changed underneath us with no announcement and no warning light. The very flexibility that makes WordPress powerful is the same flexibility that let this happen. Those are not two separate traits. They are one trait, seen from two sides.
That’s worth weighing honestly against the alternatives, because the alternatives fail differently — and some of them can’t fail this particular way at all.
Here’s the comparison the way I’d give it to a client now — not “which is best,” but how each one behaves, including how each one breaks.
CMS comparison for SEO in 2026. No single winner — each platform trades flexibility, control, and maintenance differently. WordPress leads on schema depth; Webflow on out-of-the-box stability; headless on scale and AI-search readiness.
Read that table honestly and you’ll see it doesn’t crown a winner. Webflow gives you fewer moving parts, so the specific failure we hit — a plugin silently rewriting canonicals — basically can’t happen, because there’s no plugin doing that job; the platform owns it. The trade is less deep control and a subscription you can’t walk away from. A headless setup gives you near-total control and scales beautifully, which matters more every month as AI search rewards clean, machine-readable content — but it’s more expensive, slower to build, and the failures move from “a plugin broke” to “we broke it ourselves.” And WordPress keeps its real strengths: schema depth, data ownership, the enormous ecosystem. It just asks something in return.
I’m not telling you to abandon WordPress. We didn’t. The site on Bali is still on WordPress and doing well. The point isn’t the platform; it’s that WordPress is a platform you have to actively watch, and a lot of people treat it like one they can install and forget. Concretely, after living through this, here’s what changed in how we run WordPress sites.
Treat every update as a change that can break SEO. A plugin or core update is not routine housekeeping — it’s a deployment. Where it’s feasible, updates go onto a staging copy first, not straight onto the live site. The point is to never again let two updates land on production at once with nobody looking.
Check canonicals and indexing on a schedule, not just when something feels wrong. After any significant update, actually look: are pages still self-canonical, is the indexed-page count in Search Console roughly what it should be. This takes minutes. It would have saved us months.
Set up Search Console properly and actually read it. A deindexing event is loud and obvious in Search Console and completely invisible from the WordPress dashboard. If we’d been watching the right screen, we’d have caught this in week one instead of week six.
When traffic drops, rule out the boring causes before you blame the algorithm. Indexing status, canonical tags, robots.txt, a stray noindex. Check those first. “It’s a core update” is a conclusion you’re allowed to reach only after the boring checks come back clean.
Keep the plugin stack thin. Every plugin is another developer’s code updating on its own clock — another thing that can collide with something else. One SEO plugin, never two. Fewer moving parts genuinely means fewer ways to fail. This is, quietly, the same lesson the platform comparison teaches.
Most WordPress SEO advice is a checklist of things to switch on — permalinks, title tags, a sitemap, a plugin. That advice isn’t wrong, it’s just the easy 80%, and it’s already been written a thousand times. The hard 20%, the part that actually cost a real client half a year of traffic, is this: WordPress is an assembly of independently moving parts, and SEO-critical things can change underneath you without a sound.
Choosing a CMS is really choosing which kind of failure you’re signing up for. WordPress gives you unmatched flexibility and asks for constant attention in return. Webflow gives you fewer ways to break and less room to move. Headless gives you total control and hands you the full weight of it. There is no option without a cost — there’s only the cost that fits your team and the cost that doesn’t.
If your site is on WordPress and you haven’t checked your indexing or your canonical tags since the last round of updates, that’s not a criticism — it’s just the most useful thing you could go and do today. We learned that the expensive way so that, ideally, you don’t have to.
We build and maintain WordPress sites for businesses that depend on organic traffic — including the unglamorous part, watching the platform so a routine update never quietly costs you six months. If that’s the kind of partner you’re after, that’s the work we do.
