The History of WordPress: Versions, Turns and What It Taught Me
WordPress powers roughly a third of the web. That is a strange fact when you remember it started as a blogging tool in 2003. I have been building sites since before WordPress existed, and I have watched it change from something I was sceptical about to something I use every day. This is not a Wikipedia summary. It is an honest look at what WordPress actually is, where it came from, and what each big shift meant for people building sites on it.
On this page
- Before WordPress: What the Web Looked Like
- WordPress 1.x to 2.x: A Blogging Tool, Nothing More
- WordPress 3.x: The Version That Changed Everything
- The Gutenberg Era: WordPress 5.x and the Block Editor
- WordPress Types: Core, Multisite, Headless and the Rest
- What WordPress Still Gets Wrong (and How to Work Around It)
- Where WordPress Is Heading and What That Means for Your Site
Before WordPress: What the Web Looked Like
Building a website in the early 2000s meant writing every line yourself. There was no drag and drop, no plugin library, no update button.
I built Find-Me-Now.com in 2005, and the process was exactly what you’d expect from that era. PHP files, hand-rolled HTML, a text editor, and a lot of patience. Every page was a decision. Navigation links were hardcoded. If you wanted to change the header across thirty pages, you changed it thirty times, or you wrote an include file and hoped it behaved. Databases were MySQL, queries were written by hand, and if something broke at 2am you were the one fixing it. There was no community forum to rescue you. You either knew what you were doing or the site stayed broken. I genuinely enjoyed it. There is something satisfying about understanding every layer of what you have built, knowing exactly why a page loads the way it does because you wrote the logic that makes it happen. That grease-monkey instinct, wanting to see what is going on underneath rather than just polishing the surface, came from those years of handbuilt work.
I was working with Google at Palo Alto in 2004, and even there the web felt raw compared to what came later. The infrastructure existed, the traffic was real, but the tooling for building and managing sites was still largely a DIY exercise. Content management was either a custom-built admin panel someone had cobbled together in PHP, or it simply did not exist. You published by FTP. That was the web WordPress was born into, and understanding that context matters if you want to understand why it changed everything.
WordPress 1.x to 2.x: A Blogging Tool, Nothing More
WordPress started as a fork. In May 2003, Matt Mullenweg and Mike Little took the b2/cafelog codebase, which had been largely abandoned by its original developer Michel Valdrighi, and rebuilt it into something they could actually use. The name came quickly. The first proper release, version 0.70, landed that same month. It was rough, it was simple, and it did one thing, it let you publish blog posts. There was no plugin architecture to speak of, no theme system in the way we understand it now, and the template tags were basic enough that any halfway competent PHP developer could read the whole codebase in an afternoon. That simplicity was the point. Mullenweg wanted a publishing tool that a non-technical person could install and use without calling in a favour.
Version 1.0, named after jazz musician Miles Davis, arrived in January 2004. It introduced a genuine template system and the beginnings of a plugin hook structure. By 1.5 in February 2005, named after Strayhorn, you had theme support and the Kubrick default theme that stuck around for years. These were real steps forward, but the platform still sat firmly in the “personal blog” category. Serious developers building actual business sites were not paying attention. PHP developers with any experience were hand-rolling their own CMS or using something like Drupal, which had a proper content architecture from early on. WordPress felt lightweight by comparison, and not always in a flattering way.
Version 2.0 arrived in late 2005 and brought a redesigned admin panel and WYSIWYG editing via TinyMCE. Useful, but still not enough to shift the perception. It was a blogging tool. That was the honest truth of it.
WordPress 3.x: The Version That Changed Everything
Before version 3.0, I kept WordPress at arm’s length. It was a blogging tool, and a fairly limited one at that. I was building sites in PHP by hand, and that felt like the right way to do serious work. Then WordPress 3.0 dropped in 2010 and merged the main platform with WordPress MU, the multisite variant that had been running separately for years. Suddenly you could run multiple sites from a single install, manage them from one dashboard, and actually think about WordPress as infrastructure rather than just a content layer. That merger alone changed the conversation. But what really shifted my thinking was custom post types.
Custom post types meant you were no longer stuck forcing everything through the ‘post’ or ‘page’ model. A property listing, a staff profile, a product, a case study , each could have its own structure, its own fields, its own admin interface. That is when WordPress stopped being a blog platform and started behaving like a real CMS. Pair that with custom taxonomies and you had a content architecture that could serve almost any kind of site without hacking the core to pieces. It was not perfect, but it was serious. I remember building a property site around that time and thinking, for the first time, that WordPress was doing the heavy lifting rather than fighting me.
That shift in 3.x is also where a lot of the bad habits crept in. Developers started treating WordPress as a framework it was never quite designed to be, loading custom post types and meta boxes onto sites that did not need them, and wondering later why performance had fallen off a cliff. Understanding what sits underneath the surface of a WordPress build matters far more than most people realise, and the 3.x era is honestly where that lesson started.
The Gutenberg Era: WordPress 5.x and the Block Editor
WordPress 5.0 dropped in December 2018 and with it came Gutenberg, a block-based editor that replaced the old TinyMCE setup most developers had built their workflows around. The idea was sound enough. Instead of writing HTML in a text box and hoping your theme rendered it cleanly, you would place discrete content blocks, paragraphs, images, headings, columns, each self-contained. On the surface that looks tidier. Under the hood it was a significant shift in how content is stored. Every block is wrapped in HTML comments that act as delimiters, so the database now holds structured markup rather than raw prose. That is fine until you switch themes or drop the plugin that registered a custom block, at which point those comment tags become orphaned and your content page looks like a car with its engine on the back seat. I have spent more than a few afternoons unpicking exactly that kind of mess for clients who changed themes without realising what Gutenberg had quietly done to their post data.
The Classic Editor plugin hit over five million active installs almost immediately, which tells you everything about how the community felt at the time. Developers who had built shortcode-heavy sites or relied on the old meta box layout found whole sections of their admin UI rearranged or gone. Page builders like Elementor carried on largely unaffected because they were already abstracting the editor away, but anyone building leaner sites without a builder had to rethink their approach.
What Gutenberg did fix is real, though. Full-site editing, introduced properly in the 5.9 cycle, finally gave non-technical users a way to edit headers and footers without touching PHP templates. Block patterns made consistent layout reuse straightforward. And for technical SEO on WordPress, the shift to cleaner block output, when you keep the block count sensible, tends to produce leaner markup than the old shortcode soup ever did. It is not perfect, but it is the direction WordPress is heading and the internals are more coherent for it.
WordPress Types: Core, Multisite, Headless and the Rest
Most people think of WordPress as one thing. It isn’t.
A standard single-site install is what the majority of people run, and it covers most use cases well. You get a database, a theme, a plugin directory, and a front end that WordPress itself renders. That’s the setup I’ve worked with since the early days, and it still makes sense for the vast majority of client projects. But underneath that familiar admin panel, WordPress has grown into something considerably more flexible. Multisite networks, for instance, let you run dozens or even hundreds of separate sites from a single WordPress installation, each with its own content, its own users, and optionally its own domain. News publishers and university departments tend to use this setup because managing updates and plugins from one place is far more practical than maintaining separate installs. The trade-off is complexity. A misconfigured multisite can create permission headaches and plugin conflicts that take real time to unpick. If you’re choosing someone to build on this kind of architecture, it’s worth knowing what you’re looking for.
Then there’s headless WordPress, which is a genuinely different way of thinking about the platform. In a headless setup, WordPress handles content management and data storage, but it doesn’t render the front end. Instead, the REST API serves content as JSON to a separate front-end framework, typically something like Next.js or Nuxt. The result can be extremely fast and gives developers fine control over performance. The downside is that you lose a lot of the convenience that makes WordPress approachable. Theme customisers, page builders, and many plugins simply don’t apply. It’s a setup that suits high-traffic editorial sites or web apps more than a small business wanting to update their own pages. Knowing which deployment type fits the actual brief is part of building websites properly from a technical perspective, not just picking the most fashionable option.
What WordPress Still Gets Wrong (and How to Work Around It)
WordPress carries a lot of baggage. The more a site grows, the more that baggage weighs on every page load. Database bloat is the problem most people ignore until something breaks. Every time a post is saved, WordPress creates a revision. Every plugin that runs an automated task writes to the database. Over a few years, a busy site can accumulate tens of thousands of rows that serve no purpose at all. That noise adds up. Queries take longer, pages load slower, and Core Web Vitals scores start to slip in ways that are genuinely hard to diagnose unless you know where to look. The fix is straightforward, regular database maintenance, pruning revisions, clearing transients, and keeping autoloaded data to a minimum, but almost nobody does it until the damage is visible. If you want to understand what is actually happening under the hood, this breakdown of database bloat and page speed covers the specifics in plain terms.
Plugin dependency is the other structural problem. WordPress makes it too easy to install a plugin for every small task. Before long, a site is running thirty plugins, several of which are doing overlapping jobs, loading scripts on pages that do not need them, and quietly killing Largest Contentful Paint scores. The right approach is to do more in code and less through plugins. That takes more time upfront, but the performance headroom it creates is real and lasting.
Hosting choices matter more than most people admit. A slow server makes every optimisation effort pointless. WordPress does not self-tune to a bad environment, no amount of caching fixes a genuinely underpowered host. Pick the wrong plan and you are fighting the infrastructure on every page. Don’t expect too much from a five-pound-a-month shared account.
Where WordPress Is Heading and What That Means for Your Site
Full Site Editing has been the biggest structural shift in WordPress since Gutenberg landed. The idea is sound, give site owners control over headers, footers, and templates without touching PHP. In practice, the execution is still catching up. FSE themes are getting more capable with each release, but the underlying block system adds markup that needs careful attention if you care about page speed and Core Web Vitals. A block-heavy homepage can easily balloon with render-blocking assets if nobody is watching the output. That is the part most people building with FSE miss, and it is exactly the kind of unseen work that makes the difference between a site that ranks and one that sits there looking fine but loading slowly.
AI integration is coming into WordPress properly now. Not just content tools bolted on top, but automation woven into the build itself. I built the ComPOS AI Automation System to handle exactly that kind of workflow. The goal was a leaner stack where repetitive tasks run without manual input, and the site stays fast because nothing unnecessary is being loaded. That is where WordPress development is heading, and the sites that get it right will be noticeably quicker and easier to maintain than those still running ten plugins doing what one automated process could do. If you want to understand how automation tools compare at the workflow level, this breakdown of Make vs Zapier for WordPress covers the practical differences.
Faster, leaner, information-rich. That is the direction. A site built properly from a technical perspective is the foundation that makes everything else, the SEO, the automation, the content, actually work.