The last piece I published on WPCoven was in June 2025 — a look at FluentCart and what it represented for self-hosted WordPress commerce. At the time, I had a publishing schedule outlined and a queue of topics drafted. None of that materialized on the timeline I had intended. A combination of health setbacks that took longer to work through than anticipated, and sustained work on Aegis that consumed the kind of focused time that leaves little room for anything else, pushed WPCoven into the background for the better part of nine months.
I am not going to treat the gap as something requiring extensive explanation. It happened, the reasons were real, and the publication is now back on a planned editorial track. The approach going forward is deliberate: a structured editorial calendar, articles that earn their length rather than fill it, and a consistent commitment to the positions this publication exists to hold.
This article is the first under that approach, and it addresses something that has been generating considerable noise in the WordPress developer conversation — noise that I think deserves a more disciplined response than it has received so far.
One thing worth stating plainly before going further: the writing on this blog is not aligned with the style most WordPress publications follow, and that is a deliberate decision.
I have contributed to WordPress documentation and have read the WordPress Documentation Style Guide carefully. The guidelines are useful for their intended purpose — producing consistent, accessible, institutional documentation. But following them for WPCoven would mean subordinating my academic and journalistic approach to a register built for reference material.
Long-form argumentation, personal voice, and the willingness to hold and defend a position are not compatible with that framework. The writing here is meant to be read, not consulted. If that makes WPCoven a different kind of presence in the WordPress ecosystem, that is the point.
There is also a practical note attached to this return. During the publishing gap, Atmostfear Entertainment began a deliberate transition from Google Workspace to Proton — Proton Mail, Proton Drive, and Proton Docs — as part of a broader commitment to digital sovereignty within the organization.
The reasons are several, and the inclusion of AI in every layer of productivity tooling, with the privacy implications that follow, is among the most significant. This article is the first piece produced entirely in Proton Docs, part of a gradual migration away from Google Docs and toward an internal workflow that does not route our editorial work through systems optimized for data extraction.
If anyone is interested in the full scope of that approach — it extends considerably beyond swapping one productivity suite for another — the comments are the right place to begin that conversation.
What the Current Debate Keeps Missing
Two arguments have been circulating with increasing confidence in web development communities over the past year. The first is that static site generators — Astro, Hugo, Eleventy, Jekyll — are the right choice for clients with simpler content needs, eliminating the overhead of a CMS without sacrificing anything essential.
The second is that AI tools have lowered the barrier to building websites to the point where coding knowledge is no longer a prerequisite, and that this is straightforwardly good news for everyone. Both arguments have a grain of truth in them. Both, as client-facing recommendations, are incomplete in ways that matter professionally.
The fuller position is this: static site generators are the correct recommendation for a specific and narrow client profile. AI-vibe-coded websites are not a professional recommendation at all. And WordPress, despite sustained criticism of its complexity and its governance, remains the responsible default for the majority of client work — not because the alternatives are technically inferior, but because professional web development carries obligations that neither alternative honors without the oversight of a skilled developer who has chosen to remain engaged.
What a Static Site Can and Cannot Do
The technical merits of static site generators are not in dispute. A pre-rendered HTML file served from a CDN incurs no database query, no PHP execution, and no application server round-trip. The security surface is reduced by definition: no exposed database connection, no admin interface, no server-side application to patch.
Hosting on Cloudflare Pages, Netlify, or Vercel is free at typical content site traffic volumes. For a developer-run blog, a documentation site maintained by an engineering team, or a marketing microsite with two technically capable staff members, the recommendation is defensible on every practical dimension.
Astro implements an island architecture that ships static HTML and hydrates JavaScript selectively — pages reach the browser lean, with interactivity only where the interface actually requires it. Hugo builds sites with thousands of posts in seconds. Eleventy offers templating flexibility without a component-driven model. These are mature tools. They produce fast, clean output. They eliminate entire categories of SEO problems caused by plugin conflicts and injected resources. The case for using them is real.
The case collapses the moment both of two conditions are not simultaneously true: the client is technically capable of operating the result independently, and the content model is genuinely static. In most client engagements, one or both of those conditions does not hold.
A client who cannot commit a Markdown file to a Git repository is not an edge case. That client is the majority of client work. The tools built to bridge this gap — Decap CMS, TinaCMS, Keystatic — are genuinely capable, and we have shipped client projects with two of the three. Each reintroduces a content management layer on top of the static stack.
The editorial result is not simpler than WordPress; it is differently complex, with narrower community documentation, a thinner support market, and a steeper learning curve for non-technical editors.
Build pipeline failures receive too little attention in developer-to-developer discussions about static sites. When a Cloudflare Pages or Netlify build fails because a Node.js package version conflict was introduced in a dependency update, the client’s content change does not appear on the site — and the client has no way to diagnose or resolve this without the developer.
The argument that static sites eliminate update overhead is accurate as applied to WordPress core and plugin updates; it is not accurate as applied to the node_modules directory on a production Astro site. npm audit surfaces security advisories in npm packages routinely, and the resolution path is less approachable for non-developers than WordPress‘s dashboard notifications.
The argument for reduced maintenance overhead proves out for the developer running their own site. It does not prove out for the client paying someone else to maintain theirs.
The SEO argument for static sites rests on two real advantages: faster page delivery from a CDN and cleaner HTML output uncontaminated by plugin conflicts. Both are legitimate. Neither is exclusive to static site generators. A block theme served behind a full-page caching layer — W3 Total Cache or LiteSpeed Cache with a CDN in front — delivers cached HTML to the vast majority of requests without a database query.
The HTML cleanliness problem is a configuration and discipline problem, not a platform problem. A block theme with settings.color.custom and settings.typography.customFontSize disabled, no plugin injecting into wp_head without audit, and no page builder appending its own stylesheet to every page produces output that is structurally comparable to a static generator’s.
The SEO fundamentals — title tags, canonical URLs, Open Graph tags, XML sitemaps — have been in WordPress core since version 5.5 introduced native XML sitemaps, and a block theme requires no additional plugin to produce semantically correct heading hierarchies, descriptive link text, or properly associated image alt attributes.
The Part of This Conversation That Is Not a Client Strategy at All
Vibe coding is the practice of describing software in natural language to an AI model and accepting the generated code without reviewing, testing, or understanding it. The term was coined by Andrej Karpathy, an OpenAI co-founder, in February 2025.
Collins Dictionary named it Word of the Year for 2025. By early 2026, according to the Wikipedia entry on vibe coding, 25% of Y Combinator’s Winter 2025 startup batch had codebases that were 95% or more AI-generated.
A social network called Moltbook, built entirely through this method — its founder stating publicly that he wrote zero lines of code — was found by security firm Wiz in February 2026 to have a misconfigured database exposing 1.5 million authentication tokens and 35,000 email addresses.
The root cause was not a sophisticated attack. The AI scaffolded the database with permissive settings during development, and the founder deployed it without reviewing the infrastructure code.
That incident is not exceptional. It is representative of a documented pattern.
A December 2025 analysis by CodeRabbit of 470 open-source GitHub pull requests found that AI co-authored code contained 1.7 times more major issues than human-written code, with misconfigurations 75% more common and security vulnerabilities 2.74 times higher.
A December 2025 assessment by security startup Tenzai reported by InfoWorld tested five vibe coding tools — Claude Code, OpenAI Codex, Cursor, Replit, and Devin — and found 69 vulnerabilities across 15 applications, with approximately half a dozen rated critical.
In May 2025, Lovable, a Swedish vibe coding platform, was found to have CVE-2025-48757 affecting 170 of its 1,645 generated applications, each with exploitable row-level security flaws in their Supabase configurations exposing real user data.
The user promoting this approach to clients is not making a platform recommendation. They are making a liability transfer.
The specific problem with vibe coding as a client-facing web development strategy is not that AI tools are incapable of generating useful code — they are, under appropriate supervision. The problem is that the practice, by definition, excludes the supervision that makes the output safe.
Vibe coding optimizes for the appearance of a working product at the moment of delivery. Security configurations that look correct at first load can expose data the moment any non-standard request reaches the application. Accessibility requirements that are invisible to a sighted developer testing in a modern browser are invisible to the AI that generated the interface as well.
What AI-Generated Code Systematically Gets Wrong
Security is the most documented failure mode, but it is not the only one. Accessibility is equally systematic, and receives far less attention in the vibe coding discourse.
WebAIM’s 2025 analysis of the top one million home pages found that 94.8% contained detectable WCAG 2 A/AA failures — an average of 51 accessibility errors per page. That baseline reflects the state of the web as built by developers who, at least in principle, are aware that accessibility standards exist.
The six failure categories that account for 96% of all detected accessibility errors in that dataset — low-contrast text, missing alt text, missing form labels, empty links, missing document language, and empty buttons — are not only WCAG failures.
Missing alt text on linked images is a direct SEO signal loss; empty links and buttons produce crawlable anchor text that conveys nothing to a search engine. The accessibility problem and the SEO problem have the same root: output generated without the structural discipline that a reviewed, standards-compliant codebase enforces from the start.
AI models trained on this corpus inherit its biases. A model trained primarily on inaccessible code cannot generate accessible code reliably. It reproduces the statistical patterns of its training data, and those patterns include missing alt text, low-contrast text combinations, unlabeled form elements, and keyboard navigation that was designed for mouse users.
Vibe-coded interfaces also lack the documentation, consistent naming conventions, and structural coherence that make accessibility audits tractable. Accessibility cannot be retrofitted aesthetically; it has to be present in the structure of the HTML from the beginning.
An interface that passes visual review and a few manual link clicks can fail every test that matters to screen reader users or keyboard-only navigators — and neither of those failure modes is visible to a sighted developer who never tests outside a mouse and a modern browser.
The position that this is fixable with additional prompting is not well supported by the data. The Tenzai assessment found that vibe coding tools struggle specifically where the distinction between safe and dangerous behavior is context-dependent — which describes most of the meaningful accessibility and security decisions in a real application.
There is no universal rule the model can apply; the correct behavior depends on what the page is doing, who is using it, and under what conditions.
The European Accessibility Act came into force across EU member states in June 2025, requiring digital products and services provided to consumers to meet accessibility standards — specifically those mapped to EN 301 549, which incorporates and extends WCAG 2.1. For any client operating in the EU or serving EU residents, delivering a site without an accessibility review is no longer only an ethical failing. It is a legal liability.
A vibe-coded site delivered without accessibility testing, or a static site assembled from ad hoc HTML choices, does not satisfy that obligation. A block theme built on core WordPress blocks — whose semantic, accessible output is a contribution requirement enforced by the Make WordPress Accessibility team — is the closest a developer can come to accessibility compliance as an architectural guarantee rather than a post-delivery audit item.
The Maintenance Problem Nobody Is Talking About
The individuals promoting AI-vibe-coded websites are overwhelmingly not the people who will maintain them. This is the detail that gets omitted from every demonstration of a working site built in 45 minutes.
Code that no human has read is code that no human can maintain with confidence. A December 2025 paper from GitClear analyzing 211 million lines of code changes from 2020 to 2024 found that code duplication increased approximately four times in volume as AI assistance became standard.
Copy-pasted code exceeded the historical baseline significantly. Code refactoring dropped from 25% of changed lines in 2021 to under 10% by 2024. The pattern this describes is a codebase that grows quickly, accumulates structural debt silently, and becomes harder to change over time — not easier.
When something breaks on a vibe-coded site six months after delivery, the developer who returns to fix it faces code they did not write, do not understand, and cannot trace to a decision that made sense at the time it was made.
As Simon Willison observed, quoted in Ars Technica: “Vibe coding your way to a production codebase is clearly risky. Most of the work we do as software engineers involves evolving existing systems, where the quality and understandability of the underlying code is crucial.” The client’s experience of this situation is watching their site break and receiving an estimate to rebuild rather than repair it.
Maintenance is also not only about the developer. WordPress core releases security updates on a predictable schedule. Plugin authors maintain their packages against a published API. The WordPress Security team operates as a coordinated function. A vibe-coded application has no equivalent.
The AI that generated it is not patching it when a dependency acquires a CVE (Common vulnerabilities and Exposures). The tooling that scaffolded it is not monitoring it for configuration drift. The founder who shipped it in a weekend is not, in most cases, the person who will be reviewing npm audit output six months later.
Why WordPress Remains the Professional Default
The version of WordPress that critics of CMS complexity are typically describing — functions.php accumulations, plugins injecting markup without discipline, 15 plugins doing the work of three — has a successor that the conversation routinely ignores.
Modern WordPress development in 2026 means a block theme, a theme.json file controlling typography and color at the declaration level, and a local environment provisioned by @wordpress/env in under a minute. version: 3 in theme.json, supported from WordPress 6.6 onward, enables a fully declarative presentation layer:
{
"$schema": "https://schemas.wp.org/wp/6.8/theme.json",
"version": 3,
"settings": {
"color": {
"custom": false,
"defaultPalette": false
},
"typography": {
"customFontSize": false
},
"layout": {
"contentSize": "min(calc(100dvw - var(--wp--preset--spacing--lg,2rem) * 2), 720px)",
"wideSize": "min(calc(100dvw - var(--wp--preset--spacing--lg,2rem) * 2), 1620px)"
}
}
}This is not the WordPress of 2016. No PHP is required for presentation configuration. Every core block respects the settings declared here. The distance between this and a static site generator’s configuration file is narrower than critics tend to acknowledge.
The configuration above is a starting point. A professionally built block theme takes theme.json as its design system foundation and adds discipline above it: a curated, locked color palette that clients cannot break, a controlled set of named font sizes that preserve typographic hierarchy, and a pattern library built specifically for the client’s content types rather than generic stock layouts.
These are decisions made at authorship time, enforced at the editor level — not applied during a build step, and not encoded in a configuration file that requires a terminal to modify.
This is the approach behind Aegis, the block theme we develop and maintain for our own client work. Aegis targets WordPress 6.7+ on PHP 8.2. Every design decision is declared in theme.json and enforced through the editor.
Custom color input is disabled — not hidden, disabled — so a client cannot inadvertently introduce a hex value that violates the approved palette or fails the WCAG 2.1 Level AA contrast threshold defined in Success Criterion 1.4.3. Font sizes are declared as named tokens rather than arbitrary values, so the typographic scale holds regardless of which block is receiving the text. The pattern library covers the content models the client actually uses — no generic layouts imported at scale, no 200-pattern taxonomy problem that defeats its own purpose.
Because Aegis is built on documented WordPress core APIs — theme.json, the block editor, the site editor’s template part system — and ships its own open-source framework that extends core blocks with additional settings and capabilities, any developer familiar with block theme architecture can read, audit, and maintain the project if the client relationship changes.
The Aegis Framework is not a black box and not a proprietary layer: the source is available, the extension points follow WordPress conventions, and nothing in the stack requires a commercial license or vendor relationship to operate.
The dependency Aegis creates is a dependency on competent WordPress development, not on any specific agency’s continued involvement. That is a meaningful distinction from classic themes built on third-party frameworks like Genesis, which has not received a substantive update since 2023 and is estimated to run on between 600,000 and one million sites with no active maintainer.
It also removes the case for third-party page builders for the majority of client projects. Elementor, Divi, and their equivalents addressed a real gap when the WordPress editing surface could not manage headers, footers, templates, or site-wide design without custom PHP. Full Site Editing closed that gap.
What these builders add today — for a content-focused client site — is CSS and JacaScript that loads on every page regardless of what is rendered, proprietary shortcodes that create vendor lock-in if the builder is ever removed or abandoned, and a DOM structure that inflates page weight without a corresponding gain in capability.
For the client profile this article addresses, a professionally built block theme on a current WordPress installation handles every design and editorial task these builders were introduced to solve, without the performance overhead and without the lock-in.
There are cases where a builder still earns its place — highly design-intensive marketing sites with complex animation sequences, for instance — but those cases should be identified on their merits, not assumed by habit.
The performance characteristics of a lean, custom block theme compare directly to a static site generator on the dimensions that matter most for client work. Block themes load only the CSS for blocks present on the rendered page. On a content page using paragraph, image, heading, and list blocks, no stylesheet for the query loop, cover block, or media-text block is requested.
Per the block theme documentation at developer.wordpress.org, CSS is generated from theme.json declarations and scoped to the blocks that actually appear. A static site generator with a bundled stylesheet ships the same CSS to every page regardless of what is rendered.
That difference is visible in Lighthouse scores and in Core Web Vitals measurements on pages with minimal block diversity.
The SEO implications of that CSS architecture are concrete. Largest Contentful Paint — one of the three Core Web Vitals that Google uses as a ranking signal — is directly affected by render-blocking resources. A block theme that ships only the CSS required for the blocks on the current page eliminates a category of render-blocking stylesheet requests that classic themes and page builders routinely produce.
The Font Library, introduced in WordPress 6.5 and stable in 6.7, serves fonts locally from the WordPress media library rather than loading them from an external source. That eliminates the DNS lookup, TCP handshake, and connection overhead of a Google Fonts request on every page load — an improvement to both Time to First Byte and, under European data protection law, a meaningful compliance point that static site developers frequently have to configure manually.
Structured data follows the same principle: WordPress core exposes post type metadata, author data, and publication dates through the REST API, and a block theme can produce application/ld+json output for Article and WebPage schema without a plugin, at the template level, using data that is already present in core.
The remaining front-end performance gap — scripts injected by plugins that load across every page regardless of where they are needed — is addressed at the plugin layer. Perfmatters, a premium WordPress performance plugin created by Brian Jackson and his brother Brett under Forgemedia LLC, handles this with a Script Manager that controls which scripts load on which pages and post types.
Jackson conceived the plugin during his years as CMO at Kinsta, observing the same pattern repeatedly across client sites: hosting quality could be resolved, but front-end bloat from plugins loading unnecessary scripts everywhere could not be fixed at the server level.
A per-page script control layer is the tool that closes this specific gap. Perfmatters complements a caching plugin — it does not replace one — and works without conflict alongside server-level caching on managed hosting platforms.
For a block theme with a minimal plugin footprint, its impact on Core Web Vitals is measurable in cases where third-party scripts would otherwise load unconditionally on every page.
There is also an advantage that static site generators structurally cannot offer: accessibility-compliant output as a default, not a retrofit. WordPress core blocks produce semantic HTML — proper heading hierarchies, <nav> landmarks with ARIA labels, <figure> and <figcaption> associations, keyboard-navigable interactive controls.
A block theme built on that foundation inherits those properties. A vibe-coded site or a static site where the developer made ad hoc HTML choices inherits whatever the developer happened to produce, and the WebAIM Million 2025 data makes clear how that tends to go: 94.8% of the web fails at least one automatically detectable WCAG 2 criterion. Block theme output from core blocks is not the source of that statistic.
Static site generators do not provide a WYSIWYG editing surface that a non-technical client can operate without training. The block editor, combined with the site editor’s template part system and a pattern library matched to the client’s specific content needs, provides exactly that.
A client can insert a pre-built content section, edit the copy, and publish — without the developer’s involvement, without a build pipeline, and without Git. That operational independence is not a feature of WordPress alone. It is a feature of a block theme built with the client’s operational reality in mind from the first commit.
Managed WordPress hosting — the tier at which security updates, staging environments, uptime monitoring, and server-level caching are included as baseline services — runs between approximately $25 and $100 per month depending on the provider and traffic profile.
Kinsta, which runs every WordPress site in an isolated container on Google Cloud with Cloudflare Enterprise included on every plan, starts at $35 per month for a single site and is the hosting platform we use for client WordPress work.
For static site deployments where the client profile justifies the approach, Sevalla — a platform-as-a-service built by Kinsta and running on Kubernetes and Cloudflare’s edge network — offers static site hosting free of charge within a generous baseline of 100 GB bandwidth and 600 build minutes per month.
The comparison is instructive: free static site hosting on Sevalla is a legitimate option for the technically capable client who fits the profile described earlier in this article; Kinsta‘s managed WordPress hosting is the appropriate infrastructure when the client and content model require everything WordPress provides. Neither is universally correct. The choice follows the platform recommendation, not the other way around.
The honest answer to the cost question is that the hosting cost for WordPress is not overhead on top of the service — it is part of the service. It funds the update pipeline, the support infrastructure, and the server-level safeguards that make WordPress the professionally defensible recommendation. A free hosting bill on a vibe-coded site or an unmanaged static deployment is not a saving. It is the absence of the managed infrastructure that justified the recommendation in the first place.
WooCommerce, BuddyPress, and the REST API at /wp-json/wp/v2/ address business requirements — e-commerce, membership, content as a structured JSON service — that static generators cannot fulfill without becoming distributed applications that require their own maintenance overhead. These are not niche use cases. They represent a significant portion of the websites clients actually need.
One architectural pattern deserves explicit acknowledgment because it sits between the options this article addresses: Headless WordPress, where WordPress functions as a content repository serving data through the REST API or WPGraphQL to a statically generated or server-rendered front-end.
The pattern is legitimate and, for teams with the engineering capability to maintain both layers independently, a considered architectural choice. It also inherits the operational complexity of both a static generator and a WordPress installation, requires separate maintenance of each, and introduces the same build pipeline dependencies as a standalone static site alongside full WordPress administration and update requirements.
Recommending Headless WordPress to a client who cannot independently maintain either layer is the same category of error as recommending a static generator to a client who cannot commit to Git.
The practical consideration that receives the least attention in this debate is what happens after the developer hands the project over.
WordPress‘s own security surface is documented and real: xmlrpc.php exposure, wp-admin brute force vectors, plugin vulnerabilities that span the gap between a developer’s last update and the moment a CVE is published.
The honest position is not that WordPress has no attack surface — it is that WordPress‘s attack surface is managed by a coordinated security team operating on a published disclosure schedule, with hosting platforms that apply core updates automatically as a baseline service, and a decade of documented mitigation patterns available to any developer who consults the WordPress security documentation.
A vibe-coded site’s attack surface is equally real and is managed by none of those things. That asymmetry is not a minor operational detail. It is the core of the argument.
WordPress‘s support ecosystem is the largest of any open-source CMS: documentation at developer.wordpress.org, a global market of developers and agencies who can pick up any WordPress project without project-specific onboarding, and hosting platforms that provide support for core and common plugin configurations as a baseline service.
When a client’s key technical contact changes, when the agency relationship ends, when the business needs a developer for a different reason — WordPress makes that transition navigable. An Astro site with a custom build pipeline and a TinaCMS editorial layer requires a developer familiar with that specific stack. The available pool is narrower, the documentation is thinner, and the client’s position when something breaks is weaker.
The Obligation That Precedes the Recommendation
The question a developer should be asking before recommending a platform is not “can this be done in Astro?” or “can this be delivered quickly using AI?” The answers to both are almost always yes.
The question is “can the client operate this site on the day I am unavailable, six months from now, and two years from now, without that creating a dependency on my permanent availability — and does the site, at the moment of delivery and throughout its life, meet the security, accessibility, and standards requirements that apply to a professional web publication?”
Static site generators answer yes to the first question for a specific and narrow client profile: technically capable, comfortable with command-line tooling or Git-backed editorial interfaces, running a genuinely static content model.
For that client, the recommendation is sound. For the nonprofit executive director, the restaurant owner, the property manager, the association publishing regular member communications — the answer to the first question is no, and the recommendation changes accordingly.
Vibe-coded websites do not answer yes to the second question in their current form. The documentation of security failures is extensive and recent. The accessibility problem is structural, not incidental. The maintenance liability is transferred to the client in a form they are not equipped to carry.
I am not making the argument that AI tools have no place in professional web development — AI-assisted development with skilled human oversight is a different practice entirely, and a legitimate one. I am making the argument that shipping a site to a client that was generated without review, without accessibility testing, without security configuration, and without a maintenance plan is not a service. It is a liability dressed as a deliverable.
WordPress, maintained professionally, remains the answer that satisfies all four questions simultaneously for the majority of client work. That is the recommendation. It is not a comfortable one for the current discourse, and that is exactly why it needs to be stated plainly.
If you have reached a different conclusion for a specific client profile — a case where a static generator or an AI-assisted workflow genuinely met the security, accessibility, and long-term maintainability bar without ongoing developer dependency — what did the client profile, the content model, and the post-delivery support structure actually look like?
Leave a Reply