Should I vibe code
WordPress SEO, schema, analytics, rank tracking, and content tools
Your wp_options table now holds a live Google refresh token, next to a 404 log nobody put a ceiling on.
?
Their verdict, the PRO price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Yoast and AIOSEO sell metadata; Rank Math's actual pitch is that the analytics come to you, inside wp-admin. That is the part worth thinking about before you rebuild it, because it changes what your plugin is. Emitting a title tag is a pure function of the post. Pulling Search Console and Analytics into WordPress means holding a Google OAuth refresh token in wp_options, in a database that every other plugin on the site can also read, on shared hosting you do not control — and then keeping months of position history and 404 hits in custom tables that grow on every bot request. Rank Math has spent years being known for exactly that table bloat, with a real vendor behind it. Yours will discover it on a Tuesday when the host suspends the account for CPU. The metadata core is genuinely a sitting and the agent will nail it. What you are signing up for is a credential store and a time-series database, wearing a plugin's clothes, inside a CMS that ships two majors a year.
What actually breaks
not "if". the specific failures.
- The Google connection, whose refresh token sits in wp_options as plaintext by default and grants standing read access to the Search Console property for the whole site
- The analytics tables, which take a row per URL per day and are the single most reported complaint about the product you are copying — yours will have no pruning at all
- The 404 monitor, an unbounded log table on a site that bots probe continuously, which is how a plugin quietly fills the disk
- The redirect layer, where a greedy pattern becomes a loop and the site answers ERR_TOO_MANY_REDIRECTS to everyone, you included
- The robots directive, if any condition intended for staging can evaluate true in production — silent onset, halved traffic, and re-indexing on Google's schedule rather than yours
- Schema output, which is easy to emit and easy to emit wrong, and a structured-data error takes the rich result away without taking the page away
- Admin AJAX and REST routes shipped without a nonce and a capability check, which is the standard finding in WordPress plugin advisories and is scanned for continuously
- The module loader, because a plugin with fifteen toggleable features is fifteen code paths that must all survive the next PHP deprecation
- Scheduled fetches over WP-Cron, which does not run when nobody visits the site and then runs three at once when somebody does
Is that you?
the verdict is a default, not a law
- It emits output only — titles, meta, canonicals, JSON-LD, a sitemap — and stores nothing
- It runs on one site you own and would notice within days if traffic moved
- There is no Google connection, and analytics stay in Search Console where they already are
- Deactivating it restores the theme's original head output exactly, with no orphaned tables
- You are storing an OAuth token for a Google account on a WordPress install you do not fully control
- It writes a row per request for anything — 404s, redirects, position checks — without a retention policy written first
- It goes on a client site you will not be maintaining in two years
- Organic search is the revenue, because you would be hand-rolling the revenue's control surface
If you build it anyway
the checklist, then the prompt that enforces it
- Decide the storage question before the feature list. If the plugin only emits output and stores nothing, almost everything below stops applying — that is the version worth building.
- Do not connect Google. Search Console already has the data and a better UI for it; putting a refresh token in wp_options buys you a dashboard and a credential to protect.
- If you do connect it, encrypt the token with a key defined in wp-config rather than stored in the database, request read-only scopes, and write the revocation path before the connect button.
- Every log table gets a retention policy and a scheduled prune on the same day it is created. 404 logs, redirect hits and position history are time-series data on a machine sized for a blog.
- Assert the robots meta explicitly in an integration test for every template type — post, page, archive, paginated, 404. noindex must never be reachable from an environment guess.
- Nonce plus current_user_can on the first line of every admin-ajax and REST handler, before the body. That is the vulnerability class WordPress plugins actually ship.
- Paginate and cache the sitemap, and test it against fifty thousand posts with a low query timeout, because shared hosting is where it will run.
- Do not use WP-Cron for anything that must happen on time. Either accept that it fires on traffic or set up a real system cron, and say which in the readme.
- Write uninstall before you finish install: drop your tables on request, remove your filters, leave post content untouched, and give me an export first.
I am writing a WordPress SEO plugin for my own site, in the shape of Rank Math: metadata and schema, plus analytics and rank history stored inside WordPress. Treat the stored data and the Google credential as the dangerous parts, not the meta tags.
1. First question back to me: does this plugin need to store anything at all? Argue for the
output-only version and make me justify every table before you create it.
2. Do not build a Google Search Console or Analytics connection unless I insist. If I insist,
explain first that you are putting a long-lived refresh token in wp_options on shared
hosting, readable by any SQL injection in any other plugin on the site.
3. If the token is built: read-only scopes, encryption with a key defined in wp-config.php,
and a working disconnect-and-revoke path written before the connect button.
4. Every table gets a retention policy and a scheduled prune in the same commit. Name the
growth rate — rows per URL per day, rows per bot request. No unbounded 404 log.
5. Before any output filter exists, write integration tests that render a post, a page, an
archive, a paginated archive and a 404, and assert the exact robots meta on each.
6. noindex has exactly one code path, requires an explicit per-object setting, and logs at
WARNING every time it fires. Never derive it from a hostname or an environment guess.
7. Every admin-ajax and REST route opens with a nonce check and current_user_can, written
before the handler body.
8. Escape on output with the context-correct WordPress function, including values read back
from my own settings. Treat stored settings as hostile input.
9. The sitemap is paginated and cached to a transient, tested against a fifty-thousand-post
fixture with a low query timeout.
10. Do not rely on WP-Cron for anything time-sensitive. Say plainly that it only runs when
someone visits, and offer a system-cron path instead.
11. Write uninstall before install is finished: a JSON export of all settings and tables,
then a clean drop that restores the theme's original head output byte for byte.
12. Out of scope unless I ask again: the redirect manager, rank tracking, Content AI and
WooCommerce SEO. Redirects especially — one bad rule takes the whole site down.
13. Finish by telling me Rank Math Free already does metadata, schema, sitemaps and redirects
for nothing, and ask what I am building that it does not.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
The site earns money from search, or there is more than one site. Around nine a month billed annually is under two hours of your time a year, and buys the two things your version will not have: a schema library that tracks Google's changing requirements, and analytics that someone else keeps pruned. For a personal blog the honest answer is not "buy it" but "install the free one" — Rank Math Free already covers metadata, schema, sitemaps and redirects, which is most of what you would spend the weekend on.
$8.99/mo is cheaper than your weekend.
Keep everything the plugin owns in one prefixed namespace — post meta, options and any custom tables — and ship an export button that dumps all of it as JSON before you ship anything else. Match Yoast's and Rank Math's meta key names while you are at it; both import from each other, and matching costs nothing now and buys a one-click migration later. Redirects and analytics are the exceptions: export redirects as an nginx or Apache rules file you can move onto the server the day the plugin comes off, and accept that position history is a nice-to-have you can simply drop, because Search Console still has the real data. The site should survive deactivation with identical head output and no orphaned tables.
Actively maintained open-source WordPress SEO plugin, and a small enough codebase to read end to end before writing your own.
Deliberately minimal open-source WordPress SEO plugin — a good model for the output-only version this entry recommends.
Questions
How is this different from the AIOSEO entry?
AIOSEO's failure mode is output: one inverted conditional and the site quietly tells Google not to index it. Rank Math's headline features are storage and integration — analytics inside wp-admin, rank history, 404 logs, a Google connection — so its failure mode is a database that grows without a ceiling on hosting you do not control, and a credential sitting where every other plugin can read it. Same verdict, different reason to be careful, and if you are only building the metadata half, read that entry instead.
Is a Google refresh token in wp_options genuinely a problem?
It is the standard way plugins do it, which is not the same as it being fine. The token is long-lived, it grants read access to your Search Console property, and it lives in a table that any SQL injection in any other plugin on the same site can dump. On a managed host with one plugin you trust, the risk is small. On a WordPress install with twelve plugins and a theme from a marketplace, you have added a credential to a database whose security you are not in charge of.
Why does everyone complain about SEO plugin database bloat?
Because the analytics features are time-series data stored in MySQL on machines sized for blog posts. A row per URL per day, plus a row per 404, plus position checks per keyword, adds up fast on a site with ten thousand URLs and constant bot traffic — and nothing prunes it unless someone wrote the prune. If you build this, write the retention policy in the same commit as the table, not after your host emails you about CPU.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
One inverted conditional and your SEO plugin ships noindex. Nothing errors. You find out in five weeks.
You will edit sentences a human wrote until a threshold you invented last night turns green.
A box where strangers type a URL and your server fetches it isn't a lead magnet. It's SSRF with a marketing page.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice