Why I Built a Custom SEO Plugin Instead of Using Yoast
Building a custom WordPress SEO plugin makes sense when your client’s language, market, and workflow don’t fit the assumptions baked into off-the-shelf tools. That was exactly the situation with my client, a multi-location, Hebrew-first service business in Israel, and this series documents how I built them a bespoke SEO engine I’ll call “Project Spark”.
Development began in December 2025; by mid-2026 the system was feature-complete, locked, and in maintenance. This opening post explains the decision itself: what we evaluated, why every off-the-shelf option fell short, what “custom” actually delivered, and what it honestly cost. The nineteen posts that follow go deep on the engineering. This one is about judgement.
Key takeaway: Off-the-shelf SEO plugins are optimized for left-to-right, English-first, single-location websites. When a business is Hebrew-first, multi-location, and competing for AI-generated answers, not just blue links, a custom plugin stops being a luxury and becomes infrastructure.
The situation: one business, four kinds of search
My client’s customers reach them through four distinct channels that all get called “search.” Some type queries into Google and scan the classic results page. Some ask ChatGPT or Google’s AI Overviews a question and read a synthesized answer. Some speak to a voice assistant while driving, “is the branch open now?”, and hear a single spoken reply. And some open a map application and look for the nearest location.
Each channel consumes website data differently. Classic search reads titles, descriptions, and links. Answer engines extract structured question-and-answer pairs and quotable statements. Voice assistants need machine-readable opening hours and phone numbers. Map and local surfaces need consistent name, address, and phone data across the website and the business’s Google listing.
Now add the constraint that defines this whole series: all of it happens in Hebrew. Right-to-left text, mixed Hebrew and Latin brand spellings, and a customer base that phrases spoken questions differently from typed ones. The intersection of those four channels and that one language is the space where every mainstream tool we evaluated ran out of road.
The three gaps that forced a custom build
1. Hebrew and RTL are second-class citizens in mainstream SEO tools
Most SEO plugins treat right-to-left languages as a translation problem: translate the interface, and the job is done. In reality, Hebrew SEO is a *data-handling* problem, and the failure modes are subtle enough that most teams discover them in production. Bidirectional text marks travel invisibly inside copied text and defeat string comparisons. Mixed Hebrew/Latin brand names confuse any heuristic that assumes one script per title. Title separators render differently under the bidirectional algorithm, so a “helpful” separator rewrite produces visibly wrong titles in Hebrew search results. And database tables created with the wrong character set silently destroy 4-byte characters, emoji become question marks on write, before any plugin code even runs.
None of these problems appear on an English demonstration site, which is why generic tools rarely prioritize them. All of them appeared on my client’s site within weeks.
2. Search is no longer just search
My client’s customers increasingly ask ChatGPT, Google’s AI Overviews, and voice assistants, not just Google’s ten blue links. That demands Answer Engine Optimization (AEO) and Generative Engine Optimization (GEO): machine-readable content inventories, FAQ structured data, explicit AI crawler policies, and answer-shaped copy.
When we started, no mainstream plugin treated these as first-class features. There was no llms.txt generation, no registry of AI crawlers with explicit allow-or-block decisions, no workflow for producing extraction-ready Hebrew question-and-answer pairs at scale. We could have bolted fragments together from several plugins, but that meant several vendors’ assumptions colliding in the same page markup, and, as explains, multiple SEO tools emitting output simultaneously is worse than any single tool alone.
3. Multi-location local SEO needed real Google integration
The client operates multiple physical locations. They needed Google Business Profile data flowing into structured data, geographic meta tags, and consistency monitoring, automated detection of name, address, and phone drift between the website and the Google listing, because that drift silently erodes local rankings.
They also needed a guarantee no generic tool offered: that nothing in the system could ever write to their Google listing. A business’s Google profile is often worth more than its website, and granting write access to any plugin, with its bugs, its updates, its integrations, is a risk a careful owner should refuse. Project Spark’s Google integration is read-only at the architectural level: the write capability does not exist in the code, and automated tests verify its absence.
The build-versus-buy evaluation we actually ran
The decision was not taken on instinct. We scored the options against five questions, and I recommend the same five to anyone facing this choice:
- Does the tool handle our language at the byte level, or only at the interface level? Translated menus are cosmetic; byte-faithful storage of RTL text is structural.
- Does it treat AI search channels as core features or as future promises? Roadmap slides are not features.
- Can it integrate with our Google surfaces under the trust constraints we require? Read-only guarantees, encrypted credentials, auditable access.
- Who owns the workflow? A busy in-house team needs review-and-approve workflows, not automation that acts first and apologizes later.
- What happens in five years? Subscription tools change pricing, drop features, and get acquired. A bespoke tool the client owns changes only when the client decides.
Off-the-shelf candidates scored well on classic SEO features and poorly on nearly everything else. The build option scored well everywhere except one line: cost. Which brings us to honesty.
What “custom” actually bought us
- Language-correct output.
- Every stored value round-trips byte-for-byte, Hebrew, emoji, punctuation, verified by an automated test suite that grew past 4,700 tests. When a corruption report arrived, we could prove within minutes whether the fault was ours.
- AI with a human in the loop.
- Google Gemini drafts titles, descriptions, and FAQs in Hebrew; a human approves every field before it’s saved. No blind automation, no auto-publish paths, anywhere.
- Triple-engine coverage from one data layer. The same human-approved metadata feeds the search snippet, the AI citation, and the voice answer. One pipeline, one review workflow, one source of truth.
- Zero runtime dependencies. No third-party libraries shipping to production means no supply-chain risk and no unpredictable update conflicts.
- A lossless migration. Years of accumulated SEO data moved from the previous plugin without a single byte changing, after a hard-won engineering effort documented .
- A locked scope. The product was declared feature-complete and locked; only user-reported bugs, security fixes, and regression tests ship now. Custom software you can *finish* is a feature in itself.
What it cost, an honest accounting
A custom build of this scale is not a weekend project, and pretending otherwise would undermine everything else in this series. The final system spans roughly 41,000 lines of code across more than 80 classes, exposing over 170 endpoints across browser, REST, and command-line surfaces, with a 16-step setup wizard and 26 dashboard screens. It evolved over hundreds of incremental releases.
The larger cost, though, was not the features, it was the verification. In the mature phase of the project, the majority of engineering effort went into tests: regression tests pinning every fixed bug, structural tests that parse the plugin’s own code to prevent silent drift, and byte-fidelity tests that push hostile characters through every write path. That investment is precisely what makes a custom tool safe to own long-term: the test suite is the warranty.
If your budget only covers the features and not the verification, buy off-the-shelf. An untested custom tool is the worst of both worlds.
The risks we accepted, and how we hedged them
Choosing to build meant accepting risks that buying avoids, and it is worth naming how each was managed rather than pretending they did not exist. The single-maintainer risk, custom software that only its author understands, was hedged with discoverable architecture (every behavior wired through one orchestrator file), exhaustive documentation kept in step with the code, and a test suite that encodes the system’s intended behavior so completely that a new maintainer could change code with confidence on day one. The scope-creep risk, bespoke projects that never end, was hedged with the written feature lock. a defined finish line, agreed with the client, after which only fixes and tests ship. And the platform-drift risk, WordPress and PHP moving underneath the plugin, was hedged by building against stable core APIs only, with continuous testing across PHP versions, so upgrades are verified events rather than surprises.
The one risk that cannot be engineered away is dependence on the decision itself: a custom build is a commitment, and half-committing is the only guaranteed way to lose. The client understood this from the first conversation, which is a large part of why the project succeeded.
Was it worth it?
For this client, unquestionably. The plugin now handles traditional SEO, answer engines, voice assistants, and local search from one dashboard, in Hebrew, with an audit trail behind every AI suggestion and a written guarantee of what the software will never do. Their team works in a tool shaped around their language and their workflow rather than adapting themselves to a tool shaped around someone else’s.
Would I recommend a custom build to everyone? No. If your site is English-first, single-location, and well served by mainstream channels, the off-the-shelf ecosystem is excellent and getting better. The build decision earns itself at the intersections, of language, channels, trust requirements, and workflow, where one size stops fitting all. The next nineteen posts break down how each piece was engineered, what went wrong along the way, and what I would do differently.
Next in the series: Part 2, Hebrew SEO Is Different: RTL, Unicode, and Why Global Plugins Stumbles.
FAQ
Why build a custom SEO plugin instead of using Yoast or Rank Math?
Because off-the-shelf plugins assume English-first, left-to-right, single-location websites. A Hebrew-first, multi-location business competing for AI-generated answers needs language-correct data handling, AEO/GEO features, and Google integrations that generic tools don’t prioritize.
Is Yoast good for Hebrew websites?
Yoast works for basic Hebrew sites, but edge cases, RTL title separators, mixed-script brand names, byte-level data fidelity, often need custom handling. We actually kept a data-faithful Yoast import path so the client’s historical SEO data migrated losslessly.
How long does a custom SEO plugin take to build?
This one evolved over hundreds of incremental releases between December 2025 and mid-2026, with a locked, maintenance-only scope at the end. Budget for ongoing testing infrastructure, not just initial development.
What is Answer Engine Optimization (AEO)?
AEO is optimizing content so AI systems like ChatGPT, Perplexity, and Google AI Overviews can extract and cite your answers directly, through FAQ schema, llms.txt files, and answer-shaped writing.
How much does a custom WordPress SEO plugin cost?
Expect the verification to cost as much as the features: a production-grade build needs automated tests, security review, and long-term maintenance planning. If the budget covers features only, an off-the-shelf plugin is the safer choice.
When should a business choose a custom SEO tool?
When language, multiple locations, AI search channels, or trust requirements, such as read-only access to Google listings, are poorly served by mainstream plugins, and the business wants to own its tooling long-term.
