COMPARING HTML WITH CMS

FOR SMALL WEBSITES THE WHEEL HAS TURNED. HTML > WYSIWYG editors > CMS > HTML5

In the beginning (and I was there using the precursor to the Internet in Australia called the Australian Academic Research Network = AARNet), web pages were made with a simple text editor (eg Notepad) by people who knew how to write code.

WYSIWYG HTML EDITORS ..

…. like MS FrontPage and Dreamweaver allowed non-coders to create web pages just like they were using wordprocessing software. It pumped out HTML at the back of a webpage.

CMS ..

… like Joomla, WordPress, Wix, Squarespace came along. They could create responsive, dynamic webpages and work well with databases, especially if your site has a lot of pages, products and/or transactions. For most sites, this and the many vulnerabilities of CMS are overkill. So what’s the alternative? ….

.. HTML is BACK

Why? Because pure HTML5 is fast and easy to create with AI. Build web pages in minutes.

WHAT ARE ADVANTAGES OF HTML5 OVER CMS?

Pure HTML5 has some real advantages over a CMS depending on the project, though the right choice depends on your goals. Here’s a fair rundown:

Advantages of pure HTML5

Performance

No database queries, no PHP/server-side processing, no plugin bloat. Pages load faster because the server just serves static files. This matters a lot for Core Web Vitals and SEO.

Security

CMSs (especially WordPress) are constant targets for attacks because of plugins, themes, and the admin login surface. Static HTML has no database to inject into and no login panel to brute-force — the attack surface is tiny. See below for more security information.

Simplicity and control

You write exactly the markup you need. No fighting a theme’s CSS, no mystery plugin conflicts, no “why is this div wrapped in three other divs I didn’t create.” Full control over every byte sent to the browser.

Hosting cost and ease:

Static files can be hosted for free or nearly free (GitHub Pages, Netlify, Cloudflare Pages, S3) with a CDN in front. No need for a database server, PHP runtime, or ongoing server maintenance.

No maintenance treadmill

No core updates, no plugin updates, no compatibility breakage when a CMS pushes a new version. A pure HTML site built five years ago still works exactly the same today.

Longevity and portability

The files are just… files. No vendor lock-in, no database export headaches, no risk of a CMS company shutting down or changing its licensing (a real concern with some CMS platforms).

Predictable, clean code

Easier to audit, easier to hand off to another developer, easier to optimise for accessibility or performance since there’s no abstraction layer generating the HTML for you.

Where a CMS still wins

To be fair, this isn’t one-sided:

• Content updates: Non-technical people can edit a CMS site through a dashboard. Pure HTML requires editing code (or a static site generator + Git workflow) for every change.
• Scale: Sites with hundreds/thousands of pages, blogs, or e-commerce catalogues get unwieldy in raw HTML fast.
• Built-in features: Comments, user accounts, search, multilingual support, e-commerce — a CMS gives you these out of the box; in HTML you’re building or bolting them on yourself.
• Collaboration: Multiple non-developer editors working simultaneously is trivial in a CMS, painful in raw HTML.

Rule of thumb: pure HTML5 suits small marketing sites, landing pages, portfolios, documentation sites, or anything where content changes rarely and performance/security matter most. A CMS (or a static site generator like Hugo/Astro as a middle ground) suits content-heavy sites updated frequently by non-developers.

SECURITY

This turned out to be a very real, very recent (and fairly serious) event — nicknamed “WP2Shell.”

What it is WP2Shell? Two chained core WordPress bugs — a REST API batch-route confusion allowing unauthenticated remote code execution (CVE-2026-63030), combined with a SQL injection flaw (CVE-2026-60137) — let an anonymous attacker take full control of a default WordPress install with zero plugins, no login required. The vulnerabilities affect WordPress versions 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1.

How widespread has the exploitation been?

• Exploitation in the wild began shortly after the disclosure and patch release, with security firms Patchstack, Hexastrike, and WatchTowr confirming attackers are actively seizing control of unpatched sites.
• Public proof-of-concept exploit code has been circulating even though the original researchers held back their full working exploit.
• Scale estimates vary but are all large: one industry estimate put the number of still-vulnerable WordPress sites at tens of millions, and a security consultant’s sampling of roughly 4,200 sites found fewer than 15% remained unpatched, which extrapolated suggests around 90 million installations may still be vulnerable.
• Official WordPress data shows more than 400 million websites were on the vulnerable versions, though that figure predates the wave of patching since.
• Because of the severity, WordPress enabled forced automatic updates for as many sites as technically possible, and Cloudflare rolled out rules to detect and block exploitation attempts for sites that hadn’t updated yet.
• Compromised sites are being used for follow-on abuse such as malware distribution, spam operations, and staging further attacks on other systems.

FIX WORDPRESS HACK

If your WordPress site got hacked, use Acronis in cPanel to revert to a previous version. Don’t forget to tick the box that says delete all files made after the rollback date.

Bottom line: this wasn’t a niche or contained incident — it hit WordPress core itself (which powers roughly half the web), required no user interaction to exploit, and despite an emergency patch and forced updates, tens of millions of sites are believed to still be exposed as of the most recent reporting (mid-to-late July 2026). If you run a WordPress site, the key action is confirming you’re on 6.9.5 or 7.0.3 (whichever branch applies) and that auto-updates are enabled.

DIGITAL MARKETING PERTH