What Actually Changed in Web Design. And What Did Not.

We have been building websites since 1994. We started in hand-coded HTML, moved to Joomla, then Drupal, took a brief detour into Plone, settled into WordPress for the long haul, and now ship on React and Next.js. Every one of those platforms was going to be the future. Each one was. Each one was also replaced. What we learned across thirty years of that adaptation is that platforms come and go. Strategy compounds. The job is not the stack. The job is the outcome.

In 2026, that lesson matters more than it ever has. Because the tools just changed faster than they have at any point in the last three decades, and a lot of people are confusing the speed of the tooling with the difficulty of the work.

The 2026 Landscape, in Honest Numbers

Before anything else, the context. What actually happened in the last eighteen months.

Fifty-one percent of code committed to GitHub in early 2026 was AI-generated or AI-assisted (Gartner 2026 survey of software engineering). Eighty-seven percent of professional developers now use LLM-powered coding assistants daily. Eighty percent of new GitHub users activated Copilot in their first week. The barrier to “a working website” has not just lowered. It has effectively disappeared.^[1]

In March 2026, twelve AI models launched in a single week from six companies: OpenAI, Google, xAI, Anthropic, Mistral, and Cursor. Frontier models now ship every two to three weeks. Evaluation cycles take four to six weeks. You are perpetually evaluating models that are already deprecated by the time you deploy them, with production systems permanently running last quarter’s technology.

And the adoption numbers are staggering. AI-referred traffic to Shopify alone grew 7× between January 2025 and early 2026. AI-attributed orders grew 11× over the same period. Twenty percent of Google searches now show AI Overviews.^[10] The way people find websites has changed as fundamentally as the way people build them.

So that is the speed. Now the quality.

A Stanford and NYU study found that 40% of GitHub Copilot output contained security vulnerabilities including SQL injection, cross-site scripting, and hardcoded credentials.^[4] Veracode tested code from multiple LLMs and found a 45% security test failure rate, with an 86% failure rate against cross-site scripting attacks specifically.^[5] Trust in AI code accuracy has dropped from 40% to 29% year over year, with 46% of developers now actively distrusting the output.

And the business consequences are becoming visible. An estimated 8,000 startups that built production applications with AI now need full or partial rebuilds, at costs ranging from $50,000 to $500,000 each. Total estimated cleanup cost: $400 million to $4 billion.

The Speed Illusion

Here is the part that surprises people.

A July 2025 randomized controlled trial by METR found that experienced open-source developers were 19% slower using AI coding tools, despite predicting they would be 24% faster.^[3] The perception gap was 43 percentage points. Developers believed they were accelerating. They were not.

This matches what we see in practice. A page that took three days to hand-code takes about four hours of directed AI work plus four hours of review. Eight-hour day. Still a full day. The composition of the work changed. The time did not collapse the way the marketing suggested it would.

Where it gets worse is over time. Initial velocity gains of around 40% crash to 50% below baseline by month six as the debugging burden accumulates. Eighty-eight percent of companies report that verification work for AI code now consumes 26 to 50 percent of their developers’ weekly capacity. Code refactoring has dropped from 25% of all commits in 2021 to less than 10% in 2024. Code churn (lines revised within two weeks) jumped from 5.5% to 7.9%. The code ships faster. It also rots faster.

Technical debt increases 30 to 41 percent within six months of unstructured AI adoption (ByteIota, 2025). By year two, maintenance costs on unmanaged AI-built codebases reach roughly four times traditional levels.^[8] This is the part the vibe-coding evangelists leave off the slide deck.

What Actually Changed. What Did Not.

What changed. The tools. The speed of generating a first draft. The ratio of typing to thinking. We used to spend most of our time writing HTML. Now we spend most of our time architecting prompts, reviewing AI output, and wiring systems together. Developers are evolving from sole code writers into overseers and orchestrators. Eighty percent of GitHub newcomers now use Copilot in their first week. The floor has risen.

What did not change. Everything the client actually pays for.

Content strategy still decides whether the site converts. Information architecture still decides whether the site is findable. Conversion funnels still decide whether a visitor becomes a lead. Schema and technical SEO still decide whether the site is cited in AI Overviews, and with AI-referred sessions jumping 527% year over year, that matters more than it ever has.^[11] Accessibility still decides whether you are sued. Brand voice still decides whether you sound like you or like everyone else using the same AI model.

Only 33% of websites pass all three Core Web Vitals. Sites that do pass see a 12 to 20 percent organic traffic lift and a 15 to 30 percent conversion lift. That gap is not closing. AI tools do not optimize for it by default. Performance is not a secondary signal. It is the price of admission.

The Three Problems Nobody Talks About

The Handoff Problem

A site built in Cursor, Claude Code, Bolt, Lovable, or Base44 ships as code. React components. Next.js pages. Static files. There is no WordPress dashboard. There is no Webflow editor. There is no “edit this text” button your marketing coordinator can click.

When the marketing team wants to update the blog, change a headline, swap a testimonial, or push out a new landing page, one of two things has to happen. Either a developer edits the code, or the marketing team opens a pull request. Neither is a fit for a marketing coordinator who just wants to update copy.

The vibe-coding tools are aware of this gap but have not solved it. Bolt lacks two-way sync with Git. Lovable auto-syncs to GitHub but is, in its own documentation’s words, “very prompt-sensitive,” with vague instructions leading to garbage-in, garbage-out problems. Cursor lacks built-in deployment. None of them ship with a CMS layer a non-technical team member can operate.

The first time your CEO wants to change a headline and nobody can do it without calling a developer, the project failed. That is not a technology problem. That is a planning problem. And it is the most common failure mode we see in 2026.

The Twelve-Week Obsolescence Cycle

AI tooling ships major changes roughly every twelve weeks. Sometimes faster. Twelve models in one week in March 2026. Frontier models every two to three weeks. WordPress 7.0 shipped the Abilities API in April 2026. Next.js 16 landed. React Compiler 1.0 arrived. Commerce7 completed its WineDirect acquisition and began platform migrations.^[16]

If you build on the newest thing, it is legacy before the site launches. If you build on yesterday’s stack, you are already behind. Neither is acceptable for a serious client investment.

The solution is architectural, not technological. Build behind an API boundary. The front end can be rewritten, swapped, or regenerated. The content, the data, the commerce engine, and the CRM stay put. WordPress, for all the excitement about new frameworks, still powers 43.4% of all websites and 60.8% of CMS market share.^[14] It is not going anywhere. As a content layer behind a performance front end, it is the most proven pattern we build on, and 64% of enterprise WordPress users have now implemented or are exploring headless configurations.

Legacy-proofing is not a feature. It is an architectural decision made on day one.

The Accessibility and Compliance Minefield

This is the one that has legal teeth.

The WebAIM Million 2026 report found 95.9% of home pages have detected WCAG 2 failures, reversing six years of improvement.^[12] Average errors per page jumped to 56.1, a 10.1% increase from the prior year. The report detected 56,114,377 total distinct accessibility errors across one million home pages. Seventy-nine percent of pages had low-contrast text. Over half were missing alternative text on images, and 44% of those involved linked images that completely break navigation for screen reader users.

The enforcement side is accelerating in parallel. Over 5,100 ADA Title III lawsuits were filed in 2025, a 24% increase from 2024.^[13] Website accessibility lawsuits now account for 36% of all ADA Title III filings. Forty-five to forty-six percent of digital accessibility lawsuits target previously-sued companies, meaning the first lawsuit is rarely the last. And the April 24, 2026 Title II deadline for public entities and state and local governments over 50,000 population will trigger another wave.

Vibe-coded sites disproportionately fail because AI tools default to div-soup layouts without semantic HTML, aria labels, keyboard flows, or proper heading hierarchy. Automated testing catches roughly 30 to 40 percent of WCAG issues. The rest requires manual testing: keyboard navigation, screen reader flow, focus visibility, touch targets, color contrast. AI cannot do that work yet. Humans can.

The Security Problem Nobody Wants to Admit

This is newer and less discussed, but the data is already alarming.

An analysis of 1,645 applications built with Lovable found that 10.3% had critical row-level security flaws in their Supabase configurations.^[19] That is 170 live applications with exploitable vulnerabilities that shipped because the AI generated functional code that looked correct but lacked basic security architecture.

Veracode tested code generated by multiple LLMs and found a 45% security test failure rate overall, with an 86% failure rate against cross-site scripting attacks specifically. A Georgia Tech research team published findings in April 2026 warning that AI-generated code is systematically vulnerable, describing it as “highly functional but systematically lacking in architectural judgment.”^[6]

The tools write code that runs. They do not write code that is safe. The difference between “it works” and “it is secure” is the gap where liability lives.

How We Think About It: Four Approaches

We are not writing this to scare anyone away from AI. We use every AI tool available. Cursor, Claude Code, Claude Design. Our builds move faster than they ever have. We are AI-accelerated and human-directed.

But after thirty years of watching platforms come and go, we have learned that the way you engage with new tooling matters more than which tooling you pick. Here is how we think about the four realistic approaches to building a website in 2026.

The right approach depends on your team, your budget, your timeline, and how much of the work you want to own. None of them is “better.” They are different answers to the same question.

The GEO Shift: Why Site Structure Matters More Than Ever

This is the change most businesses have not caught up to yet.

AI-referred sessions jumped 527% year over year in the first five months of 2025.^[11] Twenty percent of Google searches now show AI Overviews. AI-attributed orders on Shopify grew 11× (January 2025 to early 2026). The way people discover and evaluate businesses is shifting from “type a query, scan ten blue links” to “ask an AI, get a synthesized answer with citations.”

If your site is not structured for AI citation, you are becoming invisible to a growing share of your audience.

Including citations and statistics boosts source visibility by over 40% across queries (Position.digital, 2026). Forty-seven percent of brands still lack a deliberate GEO strategy. The ones that do have one are capturing a disproportionate share of the AI-mediated discovery layer. This is not optional anymore. It is the 2026 version of “you need to be on the first page of Google.”

What End Goal Are You Actually Building For?

The tooling decision is downstream of the goal decision. Three outcomes cover 95% of the work anyone does.

The brochure site. Ten to thirty pages. About, services, leadership, blog, contact. The job is to establish credibility and route a warm lead to a sales conversation. Success metric: trust plus a clean path to the contact form.

The lead generation engine. Twenty to a hundred pages plus landing pages, content library, gated assets, automation, and attribution. The job is to turn organic traffic, paid traffic, and inbound referrals into qualified sales conversations at a cost per lead that makes the economics work.

The commerce site. Catalog, personalization, subscription or club management, compliance, payment, fulfillment. The job is to convert browsers to buyers and buyers to repeat buyers. Usually WooCommerce with a headless front end when the project warrants it, or Commerce7 for wine clients (they now control nearly 50% of the wine commerce market post-WineDirect acquisition).^[16] Sixty-seven percent of companies have adopted headless commerce architectures, with the market projected to exceed $7.16 billion by 2032.^[17]

Every one of those outcomes can be built on any of the four approaches. The approach changes the timeline and who owns which part of the work. The goal does not.

The Four-Question Self-Test

Before you commission a site in 2026, answer these.

1. What is the end goal, exactly? Brochure, lead generation, or commerce. If you cannot answer in one sentence, the build will drift and the budget will break.
2. Who owns the site after launch? If it is a marketing coordinator, the technical stack has to respect that. A vibe-coded site with no CMS is a site nobody on your team can maintain.
3. What is your legal exposure tolerance? If you serve the public, sell in regulated categories, or touch healthcare data, accessibility and compliance are not optional. Budget accordingly.
4. Is this a stand-alone project or the start of a content engine? A one-time build and a long-running platform are different products. Design the engagement to match.

What Has Not Changed Since 1994

I built my first website in 1994. On a Macintosh Performa, in BBEdit, published via FTP to a university server. Since then we have built on every major web platform that came and went. Joomla. Drupal. Plone. ExpressionEngine. WordPress. Custom PHP. Ruby on Rails. Django. React. Next.js.

Every one of those was going to be the future. Each one was. Each one was also replaced.

The job in 1994 was the same as the job in 2026. Figure out who the audience is. Figure out what they need to see, read, and click in order to become a customer. Build the path. Measure it. Iterate. Compound.

The tools we use to do that job have changed every few years for thirty-two years. We expect them to change again. Probably in twelve weeks. We are not betting on a stack. We are betting on the craft.

If you hire a new agency, you get the stack of the month and the enthusiasm that goes with it. If you hire a team that has watched the stack of the month come and go seven times, you get something different. You get the knowledge of which parts of the work are permanent.

Frequently Asked Questions