The evolution of web design: from AOL CDs to AI-controlled websites.

Four decades. Five fundamental shifts. From dial-up walled gardens to web standards to mobile to accessibility to the AI-assisted era now arriving. Here’s how we got here, why it matters for your business right now, and what the next chapter looks like for businesses that don’t have a developer on staff.

Before the web: AOL and the walled garden era

If you were online before the mid-1990s, you probably weren’t on the web. You were on a service. AOL, CompuServe, Prodigy. You dialled in with a modem that sounded like a small machine having a panic attack, logged in with a four-digit screen name, and explored a curated, walled-off slice of online life: chat rooms, forums, news, weather.

For most people, the internet *was* AOL. AOL distributed so many install CDs that they reportedly made up half of all CDs produced globally at one point. Hard to imagine now, but for nearly a decade those discs were how most of the English-speaking world got online.

The actual World Wide Web existed in parallel. Tim Berners-Lee had proposed it at CERN in 1989 and put up the first website in 1991. But it was a technical curiosity until two things changed: Mosaic and then Netscape made it visually accessible in 1993–94, and AOL eventually let its users out onto the open web in 1994.

What the AOL era taught us

The walled garden model failed for one reason: the open web was simply more powerful. Once people could go anywhere, they did. The lesson, repeated several times in tech history since: openness wins. We’ll come back to this when we talk about AI in 2026.

The wild west of early HTML

Between 1995 and 2000, the web grew from roughly 23,000 sites to over 17 million. Anyone could publish anything, and they did, on hosting services like GeoCities, Angelfire and Tripod. The aesthetic was glorious and terrible in equal measure.

This was the era of:

• Tables nested inside tables for layout (CSS as a layout tool didn’t really arrive until much later)
• <marquee> and <blink> tags — HTML tags Mozilla and Microsoft each added unilaterally
• Animated GIFs as banner ads, page dividers, and “under construction” signs
• Web rings: hand-curated networks of similar sites linking to each other
• Frame-based layouts that broke every back button and every search engine
• “View source” as a learning tool — you could right-click any site and read how it was built

The Wayback Machine preserves a remarkable archive of this era if you want to time-travel. It’s a good reminder of how far we’ve come, and how much of the modern web’s polish is built on conventions that simply didn’t exist back then.

It was also the first browser war: Netscape Navigator versus Internet Explorer, each adding proprietary HTML extensions to lock in developers. Without a standards body to push back, every site needed to be tested in both browsers, and very often broke in one. The web fragmented into competing dialects. Something had to give.

The Dreamweaver and Flash era

Somewhere around 2003, I sat down at a computer and opened Macromedia Dreamweaver MX for the first time. (Macromedia was later bought by Adobe.) Dreamweaver was a revelation: a visual editor where you could drag elements onto a canvas and watch the HTML and CSS appear in a panel beside it. You felt like a wizard.

The promise of WYSIWYG editors — What You See Is What You Get — was that you didn’t need to know code. The reality was rather different. Dreamweaver produced thick, table-based, deeply nested HTML that looked fine in the editor but rendered inconsistently across browsers, was nightmarish to maintain, and often had no semantic meaning whatsoever to search engines or screen readers.

Spacer GIFs — transparent 1-pixel images stretched to control layout — were everywhere. So were inline styles, hardcoded fonts, and the dreaded <font color="#FF0000"> tag wrapping everything.

The Flash years

If Dreamweaver was the visual-editing dream that fell short, Adobe Flash was the dream of *interactive* visual design. For most of the 2000s, Flash was how you built anything fancy on the web: animations, games, interactive products, splash intros with auto-playing music. It was beautiful and it broke a lot of things.

Flash content was invisible to search engines. It was inaccessible to screen readers. It crashed mobile browsers regularly. It was a perennial security nightmare with constant zero-day vulnerabilities. And Steve Jobs banned it from the iPhone in 2007, in a famous open letter that effectively killed it as a serious technology for the open web. Adobe finally retired Flash in December 2020.

The lesson of Flash, told plainly: closed, proprietary technologies sitting on top of the open web tend to lose. Open standards persist. Closed platforms die.

The W3C and the standards movement

The World Wide Web Consortium (W3C) was founded by Tim Berners-Lee in 1994 with a mission to ensure the web stayed open, interoperable, and accessible to everyone. It produced the specifications that hold the web together: HTML, CSS, accessibility guidelines, web fonts, web video, web payments, and a hundred more.

The transition was slow. CSS1 came out in 1996 but wasn’t broadly usable until the late 2000s thanks to Microsoft Internet Explorer 6’s grip on the market and its idiosyncratic interpretation of standards. CSS2, CSS3 and now CSS4 progressively gave designers the tools to abandon tables, embrace semantic HTML, and build for real fluidity rather than pixel-perfect static layouts.

JavaScript followed a similar arc. Standardised under the name ECMAScript, it slowly grew from a quirky little scripting language into the most-used programming language in the world. The 2015 ES6 / ES2015 release was a watershed; suddenly JavaScript had classes, modules, async/await, and the foundations of modern application development.

HTML5 and the modern era

HTML5 was ratified as a W3C recommendation in October 2014. It brought us native video, audio, semantic elements like <header>, <article>, <nav>, <footer>. It brought offline storage, geolocation, canvas, WebSockets. It made it possible to build full applications in the browser. And it deprecated the worst sins of the 1990s — the <font> tag, the <marquee> tag, the <frame> element.

Why this matters for businesses: a site built to modern web standards in 2026 will still render correctly in 2046. A site built on proprietary technologies, page builders that lock content into shortcodes, or themes that depend on a single vendor staying in business — those have shelf lives measured in years, not decades.

Mobile-first and responsive design

The iPhone arrived in June 2007. Mobile browsing went from a curiosity to dominant within seven years. By 2014, more searches happened on mobile devices than on desktops. By 2020, mobile was around 60% of all web traffic globally.

The industry’s first response was wrong: build a separate mobile site at m.example.com, redirect mobile users to it, maintain two sites in parallel. It was a mess of duplicate content, fragmented analytics, and bad user experience when people on tablets got served the phone version (or vice versa).

The breakthrough was a 2010 essay by Ethan Marcotte on A List Apart introducing the term “responsive web design”. The idea: one HTML document, one CSS file, layouts that adapt to whatever screen they’re viewed on. CSS media queries, fluid grids, flexible images. It was elegant and it won.

Google formalised the shift in 2016 by moving to mobile-first indexing — meaning Google’s primary view of your website is the mobile version. If your mobile experience is poor, your rankings suffer everywhere.

Most established WordPress sites built before 2018 are still carrying compromises from the desktop-first era. It’s one of the most common reasons businesses underperform in search results without realising why.

WCAG and the accessibility imperative

One of the W3C’s most consequential contributions is the Web Content Accessibility Guidelines (WCAG), first published in 1999. WCAG 2.0 followed in 2008, became an ISO international standard, and is now embedded in legislation across Europe, North America, Australia and beyond.

The guidelines rest on four principles, often abbreviated as POUR:

• Perceivable — users must be able to perceive the content (alt text for images, captions for video)
• Operable — users must be able to operate the interface (keyboard navigation, no tiny touch targets, no flashing content that triggers seizures)
• Understandable — content and interaction must be understandable (clear language, predictable behaviour)
• Robust — content must be robust enough to be interpreted by a wide variety of user agents, including assistive technology

WCAG defines three conformance levels: A (minimum), AA (the practical industry standard), and AAA (the gold standard). Most legal and procurement requirements target AA.

Why this matters more in 2026

The European Accessibility Act came into force in June 2025 and now obligates many private-sector businesses across the EU to meet WCAG-aligned accessibility standards for digital products and services. In the UK, public-sector bodies have been bound by the Public Sector Bodies Accessibility Regulations since 2018. In the US, ADA-related lawsuits over inaccessible websites have grown into the thousands per year.

The business case is even stronger than the legal case. The World Health Organisation estimates that around 16% of the world’s population — one in six people — lives with significant disability. Excluding them from your website excludes 16% of your potential market. Accessible websites also score higher on Google search rankings, convert better for all users, and have lower bounce rates.

Accessibility isn’t a checklist. It’s a design philosophy. The website you’re reading right now was built with WCAG 2.2 AA conformance as a structural target from the first line of code — not bolted on with a plugin afterwards.

The CMS and page-builder explosion

WordPress launched in May 2003, a fork of an earlier blog tool by Matt Mullenweg and Mike Little. Twenty-three years later, WordPress runs roughly 43% of all websites on the internet. The next biggest CMS, Shopify, runs about 4.5%. It’s the most dominant single piece of software in the history of the web.

WordPress’s rise democratised publishing. A small business could buy a domain, install WordPress, pick a theme, and have a credible-looking website online in a weekend. The hosting industry exploded around it: Bluehost, SiteGround, HostGator, then later managed-WordPress hosts like WP Engine and Kinsta.

Then came the page builders. Around 2010, drag-and-drop visual editors layered on top of WordPress began to appear. Elementor and Divi grew to massive scale. They re-introduced something close to the Dreamweaver experience — visual editing without code — but in the browser, on top of WordPress.

The cost of the page-builder shortcut

Page builders solved a real problem (small businesses couldn’t afford developers) and created an equally large one (page-builder sites tend to be slow, bloated, and locked into the builder forever).

A typical page-builder site loads 1.5–3MB of JavaScript and CSS on every page. It uses dozens of nested div containers to render what could be a single HTML section. Removing the page builder typically requires rebuilding the entire site — the content is locked into shortcodes that mean nothing without the plugin.

For about a decade, that was the trade-off most businesses lived with: cheap-to-set-up, expensive-to-leave, slow-to-load sites that just about did the job.

Where this leaves businesses now

Step back. In nearly forty years of web evolution, here’s what businesses have had to deal with:

• Five major shifts in best practice (walled gardens → open web → standards → mobile → accessibility)
• A proliferation of platforms, plugins, hosts, builders, all claiming to be the answer
• Recurring legal and compliance changes (GDPR, ePrivacy, accessibility regulations, cookie consent)
• The constant churn of “your theme needs updating”, “this plugin conflicts with that one”, “the page builder broke”
• Growing performance demands from Google as Core Web Vitals became a ranking factor
• An expanding cookie banner / GDPR / privacy regime that every website must now navigate

Most businesses we encounter in 2026 are stuck on legacy WordPress stacks built somewhere between 2015 and 2020. They’re paying £300–600 a year in plugin subscriptions, occasionally calling a developer to fix something for £100–300 a pop, watching their PageSpeed scores languish in the 50s on mobile, and quietly losing search rankings to competitors with newer, cleaner builds.

And the maintenance burden, far from getting easier, has been getting harder. Every WordPress update introduces edge cases. Every plugin update brings risk. The whole stack feels increasingly fragile in a world that increasingly expects sites to just work.

The AI-assisted era is here

Something fundamental shifted in late 2022. Large language models — the technology behind ChatGPT and Anthropic’s Claude — reached commercial viability. By 2024, they were good enough to write production-quality code, reason about complex systems, and operate over long context windows of tens of thousands of words.

The first wave of AI-on-websites was about content. AI wrote blog posts, product descriptions, marketing copy. Useful, but a small slice of the actual work.

The second wave is now arriving, and it’s much bigger. AI is moving from “the thing that writes content” to “the thing that operates the system”.

The Model Context Protocol

The breakthrough that’s making this practical is the Model Context Protocol (MCP), an open standard introduced by Anthropic in late 2024 and rapidly adopted across the industry. Think of MCP as USB for AI: a standard way for AI assistants to connect to the tools, applications, files and systems where work actually happens.

An AI assistant connected to your website via MCP can:

• Read your existing content and structure
• Write new pages, posts and products
• Optimise images and generate web-ready formats
• Audit accessibility against WCAG and report issues
• Generate schema markup for better search visibility
• Diagnose performance issues and propose fixes
• Migrate content between systems
• Interpret analytics data in plain English

All of this through plain conversation. Not configuration files. Not plugin settings. Not developer tickets. A sentence in English.

What this looks like for non-technical staff

The most important shift here is who gets to do the work. For thirty years, websites were operated by a tiny technical priesthood. To change anything beyond text, you needed someone who knew HTML, or CSS, or PHP, or the specific quirks of your page builder.

AI flips that equation. A marketing manager can describe a new landing page in plain English and have it built. A shop owner can adjust pricing logic, change product descriptions across hundreds of SKUs, or update opening hours across location pages — all by typing what they want.

This isn’t hypothetical. It’s how this website you’re reading is being maintained, day by day. The technical priesthood isn’t gone — somebody still has to architect the system properly — but the day-to-day operational work has been moved much closer to the people who actually understand the business.

The new relationship with your web partner

If you currently work with a developer or a small studio, your relationship is about to change. Instead of being the bottleneck for every small change, your developer becomes the architect: setting up the system properly, training the AI on your specific business, defining the rules and guardrails, and stepping in only when something genuinely complex needs human judgement.

The day-to-day operation moves to you and your team. The developer’s value moves up the stack: strategy, architecture, the things only an experienced human can really judge. Hourly rates for routine content work are about to collapse. Strategic value for senior engineering is about to rise.

What this means for your business

If you’re running a business with a website in 2026, here’s the short version of where things stand.

Your current site, if it was built before 2023, is almost certainly carrying technical debt across performance, accessibility, mobile experience, and search visibility. None of that gets fixed by switching plugins or buying a faster host. It gets fixed by rebuilding on modern foundations.

The next twelve to twenty-four months will be the cleanest opportunity to do that. The tools have matured, the standards have settled, AI-assisted operation has crossed the line from novelty into genuine business productivity, and the playing field is briefly levelled before everyone else catches on.

The businesses that move now will spend the next three to five years compounding the advantages: faster sites that rank better, lower maintenance costs that free up budget for other things, easier publishing that lets non-technical staff actually use their website, and a foundation that won’t need rebuilding the next time Google changes the rules or the EU passes a new regulation.

The businesses that don’t move now will find themselves in the same place in 2028 that they’re in today: still on a legacy stack, still paying developers to do work they could do themselves, still losing ground to competitors who took the modern path.

Where to start

Start with an honest audit. Pull up your site in PageSpeed Insights. Note the mobile score. Open the Accessibility tab in Chrome DevTools and run a Lighthouse audit. Note the score. Look at the list of plugins you’re paying for and add up the annual cost. Compare your bounce rate on mobile from twelve months ago to today.

Then ask: is what we have actually working for the business? Or is it costing us in ways we’ve stopped noticing because we’re used to them?

If you’d like to talk about what a modern, AI-assisted website looks like for your specific business, danelian designs offers free discovery calls. We’re an independent Edinburgh studio working with clients across Scotland and the UK on the next chapter of WordPress. The conversation is free, conversational, and you’ll get an honest read on whether this approach makes sense for you.

gregory@daneliandesigns.co.uk — or use the contact section on the homepage.