shouldivibecodeit

Should I vibe codeAIOSEO?

WordPress metadata, schema, sitemaps, redirects, local SEO, and reports

One inverted conditional and your SEO plugin ships noindex. Nothing errors. You find out in five weeks.

?

Their verdict, the Basic price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.

Can you build it?asked by canivibecodeit.com ↗YESone-shottable · one sitting
?

Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.

Should you ship it?asked by usDEMO ONLYvibe the v0, throw it away.

The honest answer

why the verdict is what it is

Emitting a title tag and an XML sitemap really is one sitting, and that is the trap in the shape of this one. You are not writing an app; you are writing PHP that runs inside somebody else's CMS, on every request, alongside a dozen plugins that all want to filter the same output — and the thing it controls is whether Google is allowed to index the site. Get a conditional backwards and a template quietly emits noindex; nothing errors, nothing alerts, and you notice five weeks later when traffic has halved and re-crawling is on Google's schedule rather than yours. Add the redirect manager from the tagline and you have a component that can take the whole site off the internet with one bad regex. None of that is beyond an agent. What is beyond a weekend is the next four years: WordPress majors, PHP deprecations, block-editor churn, schema.org changing its mind, and the plugin conflict you only reproduce on someone else's host. The free tier of AIOSEO does the metadata part, forever, for nothing.

What actually breaks

not "if". the specific failures.

  • The robots meta tag, when a condition meant for staging fires in production and the site deindexes silently over the following month
  • The redirect manager, where one greedy regex becomes a loop and the site answers ERR_TOO_MANY_REDIRECTS to everyone including you
  • The sitemap, which is a single unbounded query until the post count passes ten thousand and it starts timing out on shared hosting
  • Canonical URLs, which are trivial to emit and easy to point at the wrong variant, at which point you have asked Google to consolidate onto a page that does not exist
  • Admin AJAX and REST endpoints written without a nonce and a capability check, which is the single most common WordPress vulnerability class and is scanned for continuously
  • Filter collisions with every other plugin that wants wp_title, the_content or wp_head, resolved by priority numbers nobody documents
  • Search Console OAuth tokens, if you connect one, sitting in wp_options as plaintext next to the settings
  • The upgrade treadmill: WordPress majors, PHP 8.x deprecations, block-editor API changes and Google's structured-data requirements, none of which you control

Is that you?

the verdict is a default, not a law

ship it if
  • It runs on one site you own and the site is not how you get paid
  • It emits output only — titles, meta, JSON-LD, a sitemap — and never writes redirects
  • Every setting has an off switch and removing the plugin restores the theme's default output exactly
  • You have Search Console open and would notice an indexing drop within days rather than months
don’t ship it if
  • You plan to distribute it, which turns your bug into somebody else's deindexed business
  • It manages redirects on a site with existing traffic and existing inbound links
  • It is going on a client site you will not be maintaining in two years
  • Organic search is the revenue, in which case the thing you are hand-rolling is the revenue's control surface

If you build it anyway

the checklist, then the prompt that enforces it

  1. Start read-only. Build a plugin that reports what the site currently emits before you build one that changes it — you will find real problems and break nothing.
  2. Never emit noindex from a condition that can be true in production. If a staging guard is needed, key it off a constant defined in wp-config, and log loudly every single time it fires.
  3. Put an integration test around the output of a page for every template type — post, page, archive, taxonomy, 404, paginated — and assert the robots directive explicitly. That one assertion is the whole entry.
  4. Cache the sitemap and paginate it. Assume fifty thousand posts on shared hosting with a query timeout, because that is where it will actually run.
  5. Every admin endpoint gets a nonce check and a current_user_can check on the first line. WordPress plugins are scanned constantly and missing capability checks are the standard finding.
  6. Escape on output with the right WordPress function for the context, and never trust settings you saved yourself — stored XSS in a plugin settings field is a privilege escalation against every admin.
  7. Uninstall must be clean and reversible: remove your filters, leave the content untouched, and make deactivating the plugin restore the theme's original output byte for byte.
  8. Keep redirects out of scope for as long as you can. If they go in, cap the chain length, refuse loops at write time, and keep an audit log of who added what.
the guardrail prompt
I am writing a WordPress SEO plugin for my own site. The failure mode I care about is silently telling search engines not to index the site — order the work so that becomes impossible before anything else gets built.

1. Phase one is read-only. A settings screen that reports the title, meta description,
   canonical and robots directive currently emitted for a given URL. No filters that
   change output yet.
2. Before writing any output filter, add integration tests that render a post, a page, a
   category archive, a paginated archive and a 404, and assert the exact robots meta.
   Every later change must keep those green.
3. noindex is never the default of any code path. There is exactly one place that can
   emit it, it requires an explicit per-object setting, and it writes a WARNING-level log
   line every time it fires.
4. If I ask for a "noindex staging automatically" feature, key it to a constant in
   wp-config.php only. Never to a hostname pattern, an environment guess or a URL sniff.
5. Canonical URLs default to the permalink WordPress already computed. Do not derive them
   from the request URI.
6. Every admin-ajax and REST route starts with a nonce check and current_user_can. Write
   that before the handler body, not after.
7. Escape all output with the context-correct WordPress function, including values read
   back from my own settings. Assume the settings table is hostile.
8. The sitemap is paginated and cached to a transient. Test it against a fixture with
   fifty thousand posts and a low query timeout before showing it to me.
9. Emit JSON-LD through a filterable array with one schema type per template. Validate
   the output against schema.org fixtures in CI; do not concatenate JSON by hand.
10. Uninstall is written before install is finished: deactivating restores the theme's
    original head output byte for byte and touches no post content.
11. Deliberately out of scope unless I ask again: the redirect manager, local business SEO,
    Search Console OAuth and any kind of keyword scoring. Redirects especially — say that
    one bad rule takes the whole site down and that it deserves its own project.
12. Finish by reminding me that AIOSEO Lite and Yoast Free already do the metadata and
    sitemap parts for nothing, and ask what I am building that they do not.
paste this before you build — not after something breaks30 lines · 2321 chars

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

just pay for it

The site earns money from search. Basic is $99 a year, which is under nine dollars a month, and the free Lite version already covers titles, meta descriptions and sitemaps — so for a personal blog the honest answer is not "buy it" but "install the free one". Pay when you want the redirect manager, the schema library or the Search Console integration, because those are precisely the three parts where your own bug is expensive and slow to notice.

$8.25/mo is cheaper than your weekend.

your exit plan, if you already built it

The exit is only easy if you never store anything the site cannot recompute. Keep every setting in post meta and wp_options under a single prefix, keep an export button that dumps them as JSON, and make sure deactivating the plugin leaves the theme emitting exactly what it emitted before. Redirects are the exception — those are real state with real traffic on them, so export them as an nginx or Apache rules file you can move to the server the day you delete the plugin. Both Yoast and AIOSEO can import from each other; matching their meta key names costs nothing now and buys you a one-click migration later.

prior art · someone already did this
Yoast SEO

The GPL reference implementation of a WordPress SEO plugin, and the free version already does most of what this entry describes.

The SEO Framework

Lighter open-source WordPress SEO plugin, useful as a smaller codebase to read before writing your own.

Lighthouse

Open-source automated auditing for performance, accessibility, and SEO.

Questions

canivibecodeit says YES and one sitting. Why are you harsher?

Because they are answering whether an agent can produce a working plugin, and it can — the metadata and sitemap core really is one sitting. We are answering whether you should run it. A plugin is not a project you finish; it is a dependency you adopt inside a CMS that ships two major versions a year, next to other plugins fighting over the same filters, controlling the one setting that decides whether your site exists in search. The build is a sitting. The ownership is years.

How bad is an accidental noindex, really?

Bad in a specific and annoying way: it fails silently and recovers slowly. Nothing 500s, no test goes red, the page looks perfect. Google drops the pages over the following weeks, and once you fix the tag, re-indexing runs on their crawl schedule rather than your deploy schedule. That combination — silent onset, delayed detection, slow recovery — is why the robots directive deserves an explicit assertion in a test rather than a code review.

Is a WordPress plugin genuinely a security concern if it is only on my site?

Yes, because the site is on the internet and the scanners do not know it is yours. The standard finding in plugin advisories is an admin-ajax or REST route without a nonce and a capability check, reachable by anyone, and automated scanners walk every WordPress install looking for exactly that. It costs two lines per endpoint to be fine and it is the thing hand-rolled plugins forget.

did you build it?

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.

also on the regret index
Yoast SEO PremiumDEMO ONLY

You will edit sentences a human wrote until a threshold you invented last night turns green.

Screaming Frog SEO SpiderSHIP IT

Crawling your own site and reading the headers is a script, not a licence.

Surfer SEODEMO ONLY

SERP analysis means scraping search results, which is a fragile foundation to build on.

last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice