[00:00:19] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, how the Static Site Importer makes migrating any website to WordPress easier than ever.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox, and use the form there.

So on the podcast today we have Chris Huber. Chris’s journey with WordPress began in his college days, first as a writer and blogger, and eventually progressing to software engineering after moving his personal site, extrachill.com to WordPress in 2018, Chris went deeply into WordPress, developing custom plugins and exploring all the corners of the platform. His passion for experimentation and creative tech led him to Automattic where he now helps shape the WordPress experience as a software engineer.

Our discussion centres around two main topics, Data Liberation and the Static Site Importer tool.

We focus upon the evolving landscape of website migration and ownership. Chris explains how Data Liberation aims to make it easier for users to take control of their sites, whether they’re moving to WordPress from platforms like Wix, Squarespace, or Drupal, or just want portability for their data.

We also get into the Static Site Importer, which takes this a step further by converting any static HTML / CSS website into a fully editable WordPress block theme, headers, footers, and all.

Chris walks us through how these tools work in tandem, highlighting the mechanics behind website crawling, mapping HTML elements to Gutenberg blocks, and handling complex features like WooCommerce and calendars.

We talk about the continuous improvement of these tools, how each migration helps raise the bar for future imports, and how this project could fundamentally change the way people move websites between platforms.

If you’re curious about the future of website migration, and how WordPress is removing the hurdles for users who want to truly own and manage their content, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Chris Huber.

I am joined on the podcast by Chris Huber. Hello, Chris.

[00:03:21] Chris Huber: Hey Nathan. Thanks for having me.

[00:03:22] Nathan Wrigley: Yeah, very welcome. Chris and I have never spoken before, but we’re going to be talking today about two things, data liberation, but also a tool that I’ve never used, but sounds really interesting. It’s called the Static Site Importer.

As is always the case, if you go to wptavern.com and search for the episode with Chris in it, you’ll be able to find all of the necessary links. In this case, it’ll be, GitHub pages and things like that.

But before we get stuck into it, Chris, would you mind just telling us a little bit about yourself, your background with WordPress, who you work for, that kind of thing?

[00:03:54] Chris Huber: So I’m Chris. I live in South Carolina. My background with WordPress is I started my own blog back when I was in college, that was 2011. But I wasn’t on WordPress at the time. I switched to WordPress around 2018, and I started getting more and more into it over the years. Now I work for Automattic as of about six months ago. And I’m a software engineer.

[00:04:14] Nathan Wrigley: Thank you. So before those six months, a lot of people in the WordPress space have this, I think, desire to end up at a place like Automattic where they can fully work just on WordPress. That’s my estimation anyway sometimes.

[00:04:26] Chris Huber: Definitely a dream job. I really love working on WordPress, and it’s super cool to be able to work at Automattic but I got into software engineering a little bit later in my WordPress career. I was more of a writer and a blogger at first, and over time my website started getting more advanced and I wanted to build more things on it.

And I got, I was an early adopter to AI, and I started learning a lot. Like as soon as I picked up AI, I started asking a lot of questions and turned my website, my personal WordPress site is called extrachill.com, and it’s kind of a WordPress multi-site like application with 60 custom plugins on it.

And I just, I just went crazy. That’s how I ended up at Automattic is because my website, some things I built on my website were like, attention on Twitter from some people who have been around WordPress for a good bit of time.

[00:05:15] Nathan Wrigley: Yeah, I’ve noticed this trend. I think there’s a trend in upper management. Let’s go for that phrase, for the more curious bits. The unusual, the interesting, the weird and the wonderful. I think there’s a bit of a movement right now to see that again.

Back in the day, I have grey hair, I am considerably older than you, I think Chris. And, when the internet began, I was old enough to be able to use a computer. The internet was a truly strange place. Nobody had the faintest idea what to do with it. And so everybody launched their crazy, unusual thing, and it was normal. And then everything became a bit of a homogenised version of the internet.

These social media platforms came along and normalised everything. And UIs settled down and UXs settled down, and got stuck in a rut. But now there does feel, especially in the WordPress space, as if there’s a desire create the unusual, and the weird and the wonderful, and that’s brilliant. That sounds like you’ve been hired to do just that.

What we’re going to talk about today is not that weird. It’s fairly useful though, I would say. And, there’s two parts to it. As I mentioned at the top of the show, there’s the data liberation part, and then there’s the static sighting importer.

I think we’ll go through them in turn, if that’s all right? Starting with the Data liberation. This was a phrase that I used to trot out a couple of years ago when the Data Liberation project began.

Do you want to just run and tell us what the Data Liberation Project is, what its goals are?

[00:06:42] Chris Huber: So the Daily Liberation Project has been ongoing since way before I started working on it. And it is basically, a lot of proprietary website building platforms make it really hard to get off of these platforms. Especially if you want to keep your website design. And that’s their business model is, they’re not open source.

So for a long time we have assumed that Data Liberation meant using WordPress. But recently we have changed that definition a little bit, and it just means turning any website into a portable copy that you can download, and do whatever you would like with.

So the data Liberation Agent that we have created actually can convert any URL into a portable copy. So you just give it a URL and it loads the site in a browser, and downloads every single page as a perfect copy with all the animations and everything. The only thing it doesn’t get is anything that’s inside the database, inside the site. Because it’s all happening on the outside of the site.

So that’s step one to our process.

[00:07:42] Nathan Wrigley: I think that’s great. I remember it being couched in terms of trying to onboard people from going to use the word rival, although that’s the wrong word, rival CMSs. So for example, Drupal and Joomla and things like that. The idea being that its really hard work.

It can be a lot of work getting a site from over there, Drupal, let’s say, and bringing it over to WordPress. And so there was an endeavour to make it point and clickable. And in, in the way that you’ve described it, all that you have to do really to get a fairly functional version of your website is to know the URL.

So you go to the original domain, you paste in the URL, some magical voodoo goes on in the background. And within a few moments, that site has been replicated, and hopefully it can then be migrated over to WordPress. But I suppose it goes a little bit further than that because it’s a two-way promise, isn’t it?

It’s not just that you can bring things into WordPress. The promise is that should you become fed up of WordPress, you could go in the other direction. You could go WordPress to Drupal. Or indeed you could go WordPress, WordPress. So you could use it as a migration tool or something like that.

So it isn’t just this importing mechanism, it really is liberation in the strictest sense of the word. It’s your data. Pick it up from wherever it is now. Take it to wherever the heck you want it to go, and we’ll enable you to do that.

[00:09:01] Chris Huber: Yeah, basically. Not even just Drupal, but places like Wix and Squarespace and Weebly and other website building platforms that might be proprietary and open source. Yeah, that’s step one to the process that we’re using.

[00:09:13] Nathan Wrigley: Okay, is there anything technical that we need to know about how that process works before we move on to the Static Site Importer? Or are the two things bound so that if we move on, it’ll all make sense in due course.

[00:09:24] Chris Huber: It will all make sense I think.

[00:09:25] Nathan Wrigley: Yeah. I’ll interrupt as I see fit.

So the next part of this jigsaw puzzle, now that we’ve got the data liberation piece under control is the Static Site Importer.

Now, this to me at least is new. I had not seen it. I caught a post by a colleague of yours, on maybe it was X or something like that. And I saw it and I thought, okay, that’s interesting. Static Site Importer, what does that mean? And I dug a little bit deeper, and that’s why you are on the podcast to explain it.

Okay, 10,000 mile view looking down, what’s the goal of the project? And then I suppose we can get into how it does it and all of that magical stuff.

[00:09:59] Chris Huber: So the goal of the project is to create WordPress Block Themes from a static HTML website. So any basic HTML, CSS, JavaScript website, converting it into a WordPress site, with the click of a button. So that’s the basic goal.

[00:10:15] Nathan Wrigley: Okay, so the idea here is that you see a website somewhere online, hopefully it’s yours. And then you take the URL, but rather than the sort of more generic approach that we just described with Data Liberation, this is then binding it into, you said theme. I’m going to go with blocks in my definition here.

For example, where there’s a paragraph. Inside the block editor, we would see a paragraph block. And if it was an image, we’d see an image block. And I guess if there was something on the left and something on the right, we’d see a, I don’t know, a group block or something like that. And the design would trickle down from there.

The tool itself would make assumptions based upon what it, I’m doing air quotes, sees. And then it would build it inside the block editor. But curiously, you said theme, so is it also building a theme in the background to take care of all the other, I don’t know, the headers and the footers and all of that kind of stuff as well?

[00:11:10] Chris Huber: Yeah, it is materialising an entire WordPress site from scratch. So the importer does take a URL, but how we’re using it in our tools is we are combining it with data liberation first.

So data liberation gives us that clean copy of the website. So the URL actually goes through data liberation, and then we take the portable copy created by data liberation, and import the whole entire website into WordPress. And it turns this static website into a WordPress site.

So it’s not just about URLs. It’s also about like AI generated websites that you might have on your computer that you might have generated with Claude or Codex. And you want to use it on WordPress. It’s traditionally been pretty hard to get a high quality block theme from an AI agent without a lot of iteration.

So this kind of sidesteps that need to iterate on the block theme, and pull your hair out with the AI who doesn’t understand so much about how to create a good block theme. And you just don’t bother with that, and you just convert it into a block theme on its own.

The point of it really is removing the responsibility from the AI to create the block theme.

[00:12:14] Nathan Wrigley: Okay. So the way that you described it, it sounded like, forgive forgive me if I’ve misunderstood this. It sounded like you use the tool, and we’ll get into how that works properly in a minute. You use the tool. You paste in a URL, that could be a locally hosted website, or it could be something out in the wild on the internet.

And then the data liberation part of it spins up. And then it sounds like there’s a blob of data somewhere, which the data liberation tool finally exports. So it does its bits. This blob of data is then consumed, and we can discuss what that is. Is that a plugin? How does that even work?

And then once it’s parsed that blob of data, then it can figure out, okay, this part belongs in the header, this part belongs in the footer.

This part is the main content area, this is the homepage. And so on. How does it do that? How does it shatter out particular URLs? Like this is the about us page. Or do you have to do it page by page? About, home, archive? How does it do all that? Is it literally one URL and it goes around and spiders the whole thing?

[00:13:13] Chris Huber: It crawls every page on the website, the data liberation part does. But I think of the importer almost like a giant funnel and like a sorting mechanism. And it’s very much mapped to Core, WordPress Core. So I built the whole thing’s built with AI and just basically like over time mapping different elements on the page to Gutenberg, while having the AI read Gutenberg Core directly, and read the source and make its own mappings.

And the whole thing is just a series of import, a website, see what breaks. I pull it up on my screen, side by side. And I’ll be like, all right, this looks wrong, like this and this. And then you just run it again. And I wrote a prompt basically, an AI orchestration prompt that teaches the AI how to run this loop, like for a long period of time.

So how I’ve built it is I’ve basically just given the AI a URL, and had multiple sessions going side by side, working on different types of URLs. And they just run, and open pull requests.

The assumption that a lot of people would make about something like this is you take the HTML site and you tell the AI how to build the block theme from it. We’re not using the AI to do that. We’re using the AI to improve on the importer. So that every time we run an import, it raises the floor just a little bit. So the more sites that you run through it and loop on it like this, the better quality overall you’re going to get for just a random, arbitrary website that you might feed it.

So it’s really just about data annotation, and taking as much as you can in finding ways to parse it without having to look at it.

[00:14:41] Nathan Wrigley: Does the tool phone home. So the way you described it there was, it sounds like there was an opportunity to improve the tool for yourself on your install. But I was wondering if it phoned home so it also at the same time, improved the tool for everybody else so that the next version of the tool is better for everybody?

But I’m going to guess that it is just working locally. It’s improving your version each time. But I could be wrong.

[00:15:05] Chris Huber: So the prompt I share with my coworkers, and we all use it to work on the tool, so it’s more of a development thing is how I’ve built the tool is just by importing a tonne of different websites, over and over again. But the way I have it set up on GitHub is every merge to main automatically releases a new version and updates all the pins.

So the latest release is always the latest work that I’ve done. So, I get to benefit from the changes right away. As soon as I merge the PR, it’s in a new release and I can just keep going. It’s just not on wordpress.org yet, or anything like that.

[00:15:37] Nathan Wrigley: So how do we actually get hold of the tool? I’m going to link to a, a GitHub page, but just reading it into the record, it’s actually a fairly straightforward url. It’s github.com/automattic. You know the one with the two T’s, and then static-site-importer. You can go over there.

How does it work? You download it. You run it locally on your machine? And then once that’s up and running, what do you see? Is there like a GUI that you have to run through? Is there a WordPress plugin component to it? Just describe the workflow.

[00:16:07] Chris Huber: Okay. Yeah, so the Static Site importer is a WordPress plugin. And anyone can instal it on a WordPress site to turn a website into a WordPress site for sure. Using the command line locally. It works in the browser too, but there’s no UI. It’s like API based, so you’d have to call the API to do it or the CLI.

Another place to use it and the easiest, probably the easiest place for anyone listening, to try it other than Riad’s website, is WordPress Studio. I added a tool to the CLI in WordPress Studio. That is, studiocreate-from. And then you can enter a URL. So it’s just one CLI command, and that orchestrates the whole thing in the background. Loads the Data Liberation agent, and then installs Static Site Importer on the site.

You run it once you wait 10 or 15 minutes, and it spits out a WordPress Studio site that’s built using this tool. And that is the same way we run it on wordpress.com. Riad’s tool, the liberate.sh is a, it uses the wordpress.com API, which works the exact same way as WordPress Studio, where it loads Data Liberation Agent.

And Riad’s website gives you a copy of the website that you can download and take with you, anywhere you want. A WordPress website, anywhere. You can host it anywhere. but it’s all using the same wordpress.com API on the backend. Except in WordPress Studio uses the actual tools, does that make sense?

[00:17:21] Nathan Wrigley: Thank you. That’s great. And so how successful is it? If you point it at google.com, it’s probably going to a fairly easy time with it because there’s not a lot going on. But, i’m imagining on a, let’s imagine that you went to some high-end sports website or something where they’ve got animations of people and videos, and all sorts of stuff going on.

How does it hold up? For paragraphs and images and all of that kind of stuff? I’m guessing it’s pretty good. Are there any areas where you’d need to be a little bit more mindful? Because, I don’t know, just experience shows it doesn’t work out so well.

[00:17:53] Chris Huber: Yeah, definitely. So if you’re watching it today, there might be some failures on things like stores. Things that have a lot of products and like really image heavy websites might have problems as well. And just like really large websites. But it gets better every single day. What I say right now might become outdated very fast on what we can and can’t handle, but it definitely is not like perfect yet, for sure.

A small website, like a one page brochure website, or five pages or so. Most of the time you’ll get a pretty good copy of it. If you start to scale up to a really big, large, for example, wix.com, like the actual Wix.

[00:18:30] Nathan Wrigley: Good luck.

[00:18:31] Chris Huber: I sometimes will run that through there as a way to see how far I can get. Yeah, I’m trying to reach for the stars. So eventually I would love to be able to import this 50,000 page heavy duty, old school website, but right now it fails miserably, and it would take. The timing that was given to me last night when I was working on this was like two weeks. You’ll have a copy of wix.com, if you just let it run. And then you’d get the copy and it would just be like 10,000 pages of nonsense. We have a lot of work to do.

[00:18:59] Nathan Wrigley: Okay, but for a normal, typical, run of the mill, let’s go with brochure site, 12 pages, fairly ordinary stuff. Imagery, maybe a video here and there, but mostly text, CSS, maybe a tiny smattering of JavaScript sprinkled around. Forms, that kind of thing. It would do a pretty good job with that out of the box?

[00:19:17] Chris Huber: I would say like more than half the time you would get a good editable WordPress website. Not always perfect. And sometimes you would get a perfect site. But a lot of times you might have a few things that are wrong, like maybe a couple form fields, or like buttons or like menus.

One thing that happens a lot is like the header and the footer are like duplicated across every page, instead of being properly extracted into a template part. If there’s like SVG images, WordPress has a kind of a hard time handling those. So we have dealt with it. But it’s not always perfect.

One of the coolest things about it that I like is that blocks, so it’s static site importer is the WordPress plugin that creates the WordPress site. And then there’s a PHP package inside of it called Block Engine. Which is what handles the actual, like, mechanics of converting and creating the blocks.

And inside of that tool I have added some like carried blocks that are in the holster ready to go, like for common elements that might appear on websites in the wild.

So like a marquee or something like that. Like a ticker that you see running across a page that Gutenberg cannot represent on its own, out of, the box. And so this tool, it knows how to build this block as if it was part of Gutenberg, so that you’ll see a real block in there. That’s my WordPress nerd favourite thing about the tool. It feels like I’m pushing on Gutenberg, finding places where Gutenberg is like maybe falling short, or just doesn’t supply the things that people need to build websites. With the right amount of attention, this might help be like, oh, we need to add some of this stuff.

[00:20:48] Nathan Wrigley: A curious question, because we all know how AI never gives you the same thing twice. I was wondering if you fed it the same URL, do you predictably get something similar out? Or do you suffer each time a different set of, and I’m doing air quotes again, failures. So for example, you described, the SVG images, or the form fields, or the footers being duplicated or whatever it was.

Is it sometimes better just to begin again, and cross your fingers and hope that the AI has a better go the second time around? Or is it always a case of go with the first version and iterate from there?

[00:21:22] Chris Huber: So it works the same exact way every time. The actual process does not use any AI at all. I used the AI to build it from the outside. But the actual, It’s literally like a machine. The process doesn’t use any AI to convert the website. We have some stuff in place, like when we’re using it on wordpress.com. We’re doing migrations from non WordPress to WordPress sites, we do it for assisted migrations currently.

But the people running these migrations will use the tool first and see how far it gets them. And then they take Claude Code or whatever and they work on the site that came out. And they hand it over to the customer. So it gets them closer to the finish line than they would have gotten if they just had to start building the site from scratch on their own.

And then over time we’re getting closer to the finish line, and hopefully get to the point where we can just hand people the website coming from another source and be like, here’s your exact copy of your website WordPress version. And eventually we will make that like a publicly available thing. But that’s how we’re working on it internally, so.

[00:22:21] Nathan Wrigley: So I think I’d misunderstood there, so the AI portion is in the creation of the tool, but the tool itself is deterministic. The tool will give predictably the exact same thing out. If you give it the URL, it’s going to parse it with a mechanised approach? It’s not relying on AI at that point. And so do it once.

And then it sounded to me from the way you described it, you were holding your hands up at this point. It sounded like your had two screens open. You’ve got the output and then maybe the original. And you’re trying to iterate and just spot the errors. Okay, let’s scroll them both and see. Ah look, that’s gone a bit astray there.

And then presumably at this point you’re logging into WordPress. If it can be done inside the block editor, you’re doing it there. But it also sounded like you are now at .com. You are removing that part even and just doing a second run with AI at that point. Rather than logging into WordPress and using the block editor, it’s more CLI. Let’s just see if the AI can spot those mistakes, because I spotted them, prompt it and fix it in that way. That’s interesting.

[00:23:21] Chris Huber: So I’m the one just building the tool. There’s other people working on delivering websites to customers and stuff internally. But, I started looking at the websites originally, but now I have a, I just have a prompt that I copy and paste to the AI every time and it walks through the process.

And what it does is it loads both sites in a headless browser called Playwright. Basically, I have the AI look at the site as if it was the site owner. I say you’re a non-technical site owner. Open this site and look at the Gutenberg editor and see how you would feel if you came over from Wix and this was what you got.

It’ll go through and click things around in the editor and be like, okay, here’s my feedback. And then I say, okay, fix everything all at once and open pull requests. And it will fan out subagents, 10 or so at a time sometimes, and open pull requests in three repos, and then I just merge them and run it again. Because the automated releases that I mentioned.

So it’s very much trusting the machine and letting them. The machine in this case is, more able to parse this than, than a human is because it’s so much at once. And just letting them do it is what I’ve found. Describing to them what I want them to do.

[00:24:26] Nathan Wrigley: I’m guessing the onboarding team over on .com, presumably, if you roll the clock back a couple of years, this was all a very manual process. Find a client, get them to sign on the dotted line. Okay, they’ve got a.com account, now they want to move over. And then it would’ve been a process of, okay, let’s inspect the site, let’s get a bunch of technical people on it, and figure out what we need to migrate and when, and try to map it. Get a designer in and recreate graphics, and colour palettes, and brands and all of this kind of stuff. But it sounds like these people no longer have a, place because you just use the tool and in most cases it’s going to work.

Has that in fact been the case? It sounded like over on the .com side of things, there’s like this, I don’t know, 90, 95, 99%, trust in the tool now. That must be incredible. Presumably you can onboard people much more rapidly.

[00:25:14] Chris Huber: Yeah, it’s not quite that much of trust in the tool yet. It’s more one in 10 sites are getting close enough to the finish line to just be handed off. So like the original process that you mentioned is a good process for like a big site, like manual migrations and stuff. But for small sites it’s not really a good business model. It’s not economically viable to spend a lot of resources rebuilding a small website because you’re putting a lot of manual effort into one website.

So what we would do mostly in the past would be, if the customer is willing to do the do it for me route, where they have our team build it for them, we would do that. But otherwise we would offer them a content import. So they can just import all their blog posts or whatever, and then rebuild the site their own.

This kind of gives us an option for people that were historically told no, that we can now start saying yes to them. And letting them migrate over. It’s not necessarily about reducing the labour that was going into it because it was a dead end before, and now it’s not.

[00:26:10] Nathan Wrigley: And how has it been received over on the .com side of things? I’m presuming that you are in touch with these people. And even if it’s a one in 10 at the moment, we have expectations that it’ll be two in 10, and then three in 10, and by the end of next year, maybe nine in 10 or what have you.

That gives them the opportunity to talk about other things with the clients that they’re onboarding, I suspect. Instead of just, okay, let’s figure out how to make the exact same website that we had over there, over here. That doesn’t feel like necessarily interesting work anyway.

[00:26:36] Chris Huber: Yeah, exactly. But it was always really hard to make the exact copy. And yeah, the tool has a lot of internal support and a lot of internal attention. People are rallying behind it. It’s basically what I’ve been working on full time since WordCamp US. Three months ago now.

So I’ve been putting full-time effort into this tool for three months now. And now it’s starting. We have a lot of momentum behind it internally now that it’s starting to get to a point where it’s actually good. It’s very cool to see this for myself. I’m very proud of the work that we’ve done. And it’s exciting. It’s just exciting.

[00:27:06] Nathan Wrigley: We mentioned that there were some things that it didn’t do particularly well. Presumably it would be nice to be able to hoover up some of that in the future. What would be the roadmap items that you’ve got for the next, I don’t know, short period of time, month, two months, six months, whatever it may be. What are the bits that it can’t currently do, or the bits that there’s wrinkles in, that you could tell us about that hopefully, given the passage of time, will go away?

[00:27:30] Chris Huber: The more complicated stuff is like, installing another plugin when you’re materialising the website. So the the most obvious example is WooCommerce. If we’re detecting products in the source, we actually pre-install WooCommerce, and convert to WooCommerce blocks, and import actual products into the catalogue, and like wire up everything that we possibly can.

[00:27:50] Nathan Wrigley: That’s amazing.

[00:27:51] Chris Huber: It’s crazy, but it doesn’t work very well yet, because it’s very complicated. But, another thing is like is like events. Like an events calendar on a website, the tool kind of chokes on that, but it’s the same process. You install The Events Calendar plugin. You find the most widely supported and used WordPress equivalent of whatever feature you need, and you find a way to deterministically wire it up on the back end.

There is a WordPress equivalent for like most things. It’s just a one at a time process to pick the one that, at least for .com. The tool itself is composable. So any developer. For forms, we use Jetpack Forms. But any developer can hook in and do whatever form provider they want, if they provide their own mappings to the tool. That’s the kind of stuff that doesn’t work quite as well right now.

And, of course JavaScript animations and other things. WordPress has the Interactivity, API, so we do use that. More and more core blocks are coming in. Like we have the tabs now in the accordions and things like that, that we can actually represent in Gutenberg more effectively now.

The real solution is just keep importing sites, you find that the tool used to choke on, it doesn’t choke on anymore, and you get further. And you just keep getting further and closer to success. The only thing it chokes on, this site is the products. Okay, so we’ll just work on improving the WooCommerce integration.

Yeah. So it’s like almost as far as you can get and then just keep. I like to think of it as raising the floor, like raising the bar is like. This is as bad as it could possibly be, and then the next time it’s a little bit better.

[00:29:18] Nathan Wrigley: And it sounds like it’s going through those iterations fairly rapidly in terms of time, what three or four years ago would’ve been years into the future now increasingly feels like months, and then weeks, and then finally in a few years time, maybe days. A lot of this stuff will be taken on in short measure, things like an events system, or a WooCommerce system or an LMS kind of system. Maybe that stuff will be in scope in the near future.

The project, obviously being on GitHub, and being a WordPressy thing is open source and I’m, just curious whether or not you are doing this hand in hand with any other people? Or is it just a project within Automattic? Or are you getting kind of intuitions from WordPress agencies out there who are obviously having to do this kind of work?

They’re bringing in clients from all over the place and trying to convert them over to WordPress. I just wondered if there was any collaboration going on, or do you wish there to be collaboration?

[00:30:12] Chris Huber: I think something like this should be part of WordPress Core. I don’t know that necessarily this exact tool or this approach. There’s a lot of work in the ecosystem around this area, like Human Made has a tool like this. And then Pascal from WordPress Core, is working on this in Gutenberg, not the exact same thing, but some way to convert HTML to blocks.

And I just think it’s a big challenge for the WordPress ecosystem that if it gets solved can help move the whole project forward and help make us more future proof. Just because AI is so good at generating HTML, and that’s what kind of becoming the native format of the internet now. Maybe always has been, but just making that translatable into WordPress is something important I think.

[00:30:53] Nathan Wrigley: Yeah, I think so. And obviously in an era where market share in the WordPress space is no longer seemingly guaranteed to just keep climbing. People face with that decision of, okay, I’ve got a website, it’s now starting to look a bit stale, but rather than throw the baby out with a bath water, we’ll, okay, we want an alternative CMS. We want to upgrade, see where we can go. It feels like a tool like this makes WordPress a bit of a forerunner, actually.

If you’re going to pick a CMS, have a CMS where there’s a pretty good chance that by clicking a button you can bring most of your existing stuff across. I don’t know what the other CMSs do in that regard. Maybe they do nothing, but this does feel like a tool in WordPress’s arsenal, which is pretty compelling. I would hope that it would bring a lot of people in our direction.

[00:31:42] Chris Huber: I hope so too, and I agree. I think the fact that it can exist. It takes one of the points of WordPress that has been difficult for people to embrace, which is the block editor. And it almost turns it into an advantage. Because then you get a WYSIWYG version of every website. Whereas if you were to generate a static site with AI and go and host it on a static host, you don’t have the CMS. If you want to add another blog post, you have to generate the page, upload it to the site. And of course there are solutions to this.

What if you just want to change one word? You just want to go into the block editor and change the one word. Then you can do that and like without having to build the whole page from scratch in the editor. You have to be good at it and know what you’re doing to build a custom website using the block editor, I think.

[00:32:26] Nathan Wrigley: This is going to be a discussion which will go on, I think in the days, weeks, and months to come. Obviously everybody at the minute is very beguiled by the interface of building a website through some kind of chat mechanism. It’s so fascinating that’s possible.

But then the reality of maintaining that, and understanding how that page even got there. And where do the assets, on that page even live? And how do I modify the title of the hero section over here? All of that has yet to land with ordinary people. Again, doing air quotes.

[00:33:04] Chris Huber: Yeah.

[00:33:05] Nathan Wrigley: If you’re very technical, you can probably figure all that stuff out, because you were probably the person that created that AI based site anyway. But if you’re not technical and your job is just to occasionally modify content, or inspect somebody else’s content, and click publish when it met the guidelines that you’d got as an organisation. You’re not going to care about some sort of CLI interface or getting an AI to do that for you.

You just want to be in, out, and then move on, because WordPress is not what makes up the majority of your day. I think all of that stuff is going to hit us in 2027, and it’ll be interesting to see where we land and where the landscape moves.

[00:33:41] Chris Huber: Yeah, I hope that we can continue to grow WordPress definitely.

[00:33:45] Nathan Wrigley: Okay, that’s really interesting. I’ll read into the record one more time the tool itself. So github.com/auttomatic, two ts, /static-site-importer. You can go over there and make comments. It’s a GitHub page so you can do all of that normal stuff.

If people wanted to find you, Chris, do you hang out online anywhere? If people wanted to contact you and had intuitions on where this should perhaps go in the future?

[00:34:11] Chris Huber: Yeah, they can reach out to me on x x.com/chubes4, C-H-U-B-E-S four. They can also find my GitHub, which is the same tag. I have my personal WordPress site at extrachill.com, is like my main site. Then I have my other one, chubes.net. Or, just leave a pull request or a GitHub issue, me or my AI agent will reply.

[00:34:33] Nathan Wrigley: This is how it is in the year 2026.

[00:34:35] Chris Huber: Yeah.

[00:34:37] Nathan Wrigley: Okay Chris, absolutely fascinating. Let’s hope that the tool manages to do a lot more than you’ve described. It sounds like you’ve got a very extensive, and interesting, roadmap going on, but thank you for bringing that to us and, thank for explaining it all to us today. Appreciate it.

[00:34:49] Chris Huber: Yeah. Thanks for your time. Thanks for having me.

[00:00:19] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, the state of WordPress security in 2026, and the battle against AI threats.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you, and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox and use the form there.

So on the podcast today we have Robert Abela.

Robert has been working in IT security for 25 years, ranging from antivirus software to web security scanners, and for the past decade has been running Melapress. A company focused on WordPress security plugins, particularly around user visibility, authentication, activity logs, and 2FA.

Robert is here to talk about the 2026 WordPress security survey. This is an annual project now in its fourth, or fifth, year gathering data from a wide range of WordPress professionals across agencies, enterprise teams, freelancers, and product owners. The conversation today is focused on the biggest security challenges and trends facing WordPress users in 2026.

We start off with some sobering stats. Over 67% of survey respondents reported experiencing at least one security incident in the past year, and concerns about WordPress security remain high, especially among less technical users.

We chat about the disconnect between awareness of security threats and actually taking steps to mitigate them, such as breach recovery plans and team training.

The discussion also explored the different types of risks that worry site owners. Site downtime, defacement, reputational damage, data loss, and even legal compliance issues. How the shakeout depends on the type of site, whether it’s e-commerce membership, a news outlet, or a simple brochure site.

We also talk about the tendency for even experienced WordPress users to take a reactive approach, only addressing vulnerabilities after something has gone wrong.

Towards the end of the episode, we discuss the rising impact of a AI on security, the explosion of AI facilitated vulnerabilities, and the shifting landscape of risk and response. There’s a healthy dose of reality, some optimism about the tools and best practises available, and plenty of good advice, especially for smaller teams and freelancers who may not have access to enterprise level resources.

If you care about keeping your WordPress sites secure, or want to understand where the community’s biggest concerns and opportunities are in 2026, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast where you’ll find all the other episodes as well.

And so without further delay, I bring you Robert Abela.

I am joined on the podcast by Robert Abela. Hello, Robert.

[00:03:48] Robert Abela: Hello Nathan. Thanks for having me.

[00:03:50] Nathan Wrigley: You’re very welcome. Nice to have you with us.

We’re going to chat today about internet security, but we’re going to be looking back over the past year, so the year 2026. Robert, can tell us a little bit about the company he founded, works for, and so on. It’s called Melapress, you can find out about that in just a moment.

But I would like to draw your attention to something which is going to really be the fulcrum of what we talk about. It is their 2026 WordPress Security Survey. Now, the easiest way to get that is probably to go to wptavern.com, search for the episode with Robert in it, and I will make sure it is linked in the show notes there.

But it might be a good idea to read it, because in about 10 minutes, you’re going to be able to capture absolutely everything that we’re talking about today, and you’ll get all of the data and, what have you. But that’s going to be the point of this episode, summarizing what happened in the security space in WordPress in 2026.

Robert, I guess there are a few areas in the WordPress space where it’s pretty important to know that we know, that you know, what you’re talking about when it comes to security, because we don’t want to have a lot of hot air from somebody who’s not experienced. So it’s an opportunity for you really to give us your bio and tell us a little bit about what you’ve been doing in the WordPress space, particularly around security, the companies you’ve worked for, the things that you’ve founded and so on. So over to you, Robert.

[00:05:07] Robert Abela: Thanks. I’ve been working in IT security for twenty-five years. I’ve always worked for software companies, software startups which worked in security industry. We used to do antivirus software, web security scanners, et cetera. I’ve had different positions. I started as systems engineer, QA, product management, project management, almost any field.

Anyway, and the last ten years I founded Melapress, and it’s a WordPress plugin business, and basically we develop a number of security plugins for WordPress. The security we do, we don’t do the typical firewall malware, et cetera, like the other, brands. We mostly focus on user visibility and authentication. So basically we have an activity logs plugin, and we also have a plugin for 2FA, passkeys et cetera. So we are focusing much more, on what happens post login once someone logs into WordPress, rather than the whole hardening and protection.

[00:05:56] Nathan Wrigley: Thank you for that. So anybody that’s interested, anything that we mention today, including the URLs of the companies that Robert has just mentioned, so Melapress, you’ll be able to find those in the show notes as well.

So the 2026 WordPress Security Survey, how many times have you actually run this? So obviously we’re looking at the 2026 version. Have you done this a couple of times and refined the way that you’ve done it and the way that you’ve surveyed over many years?

[00:06:21] Robert Abela: Yes. I’m not sure if this is the fourth or fifth year. But yes, we do every year, we’ve had more respondents. This year, by the way, it was the highest ever with 219 respondents. We had more, but before we publish all the results, we go through the sheet. Maybe there are some duplicates. Maybe some of them are not correctly filled in, et cetera.

But yeah, we’ve been doing it for around four years, and we’ve also fine-tuned from where we gather the data. For example, the first year, we’re only sending our newsletter basically, but this year we’ve done a lot. We’ve promoted the survey through third parties. We’ve gathered responses from WordCamp Europe, in person, through a number of other conferences, et cetera.

So while there is still a percentage that most probably are our users or our clients, still the biggest percentages is spread out to a wide range of different type of WordPress users, ranging from people who work for agencies, developers, designers, but also people who work with WordPress in bigger enterprises or businesses.

[00:07:15] Nathan Wrigley: Okay, so yeah, caveat emptor. With that in mind, the limitations, or otherwise, of the numbers that you’ve got represents what you’ve got in this survey.

And essentially, what it boils down to is a, it was kind of a bunch of questions which then led to a bunch of information being spat out the other side. And I’ve summarized it into about 10 bullet points. It may very well be that I’ve missed a few bits and pieces, but be interesting to go through, and you can lend your experience as to whether or not there’s been any change, whether things have got worse, whether things seemingly have got better.

We’ll begin, if it’s okay with you, with the top item, which I suppose, came out, which was a concern around WordPress’s security, or the things that can happen around WordPress and security. And what came out of it was that 7.85 out of 10, so 78 and a half percent, I suppose you could describe it as. They were developers who were expressing basically that they were concerned.

Now, I don’t know if you have more telemetry, like what concerned means, but off the face of it, that seems like quite a high number. If the platform that you’re using to build websites, you are in the sort of mid-70s concerned, is there anything you wanted to add to that or is that just the sort of top level statistic?

[00:08:28] Robert Abela: No. That was like a top-level statistic, a question we ask, like if people are concerned or they have worries about their WordPress, the security of their website.

What’s funny is the last few years, the level of concern has been the same. However, also we’ve noticed that people who have some sort of recovery plan, et cetera, also remains the same. So the level of concern has remained the same. So the majority of people know that something can happen to their WordPress website, especially now with AI, et cetera. It’s even more, things are moving much faster.

However, it seems like people are not taking the next step, as in like taking action to make sure nothing happens. What I’ve noticed as well, once we break down those who have concerns and what job they have, if they’re developers, or with their security people, et cetera. There’s this correlation, like, the more informed someone is, the more is involved in the tech aspect of the website, the more understanding they have on how things work, the less concerned they are.

So maybe it could also be education or awareness because of course, if you don’t know about how something works, then of course you are much more concerned. How you’re going to protect it? However, if you are, let’s say, a developer and has an understanding of sessions, cookies, the usual things, like passwords, maybe you’re a bit less concerned because you feel you are a bit more in control of how you can protect your website and what you can do.

[00:09:39] Nathan Wrigley: It seems like on the face of it, I should say, it seems like 78%. It seems like quite a lot.

[00:09:44] Robert Abela: Yes.

[00:09:45] Nathan Wrigley: If I had any kind of intuition, let’s say I was to go out into my car and drive around the street, if I thought that 78% of the time there was going to be some potential accident. Or I was worrying of the time about the possibility of an accident, I don’t think I’d be getting in the car. So it’s kinda curious. But, let’s move on.

So the next data point that dropped out was 67.7%, so let’s call it 68% of respondents. Now this is fairly shocking, and maybe this number will actually start driving up in the years to come, and we can get into that later.

68% of respondents had experienced at least one known security incident, with many multiple incidents. Now, that really is shocking to me. Closing in on 70% of people have had some kind of incident. I don’t know what, or maybe you do, what the magnitude of that is, but did that surprise you? Did that seem like a really large number?

[00:10:38] Robert Abela: 67.7 of all respondents, correct, they reported one security incident. I’m not surprised because almost everyone I speak to at WordCamps, even non-WordCamps, other events, someone down the line has had some security issue. Not just with WordPress, but especially with WordPress. And the funny thing, it’s not even funny, but 13.2% of those are repeat targets, which means they have experienced more than five security incidents.

Now, why does it happen? There are a number of reasons. Outdated software, lack of user awareness. In fact, what’s really more concerning is, I have some numbers here actually I can tell you. Yes, we’re still looking at some other statistics. Only 27.9% reported like they have some sort of training for their users. And only 37% use logs. At least 2FA’s a bit higher, it’s around the 40% something. I don’t have the exact number right now.

So yeah, so I’m not surprised because there is still a lot that can be done from website owners, from agencies, from everyone, to make sure we take down that number, and not everyone. Or so not the majority of people experience some sort of security incident on their website.

[00:11:41] Nathan Wrigley: Yeah, it’s curious. It’s not really a conversation. When I’m at events or chatting to fellow WordPressers, security is not the default conversation that I have, because I’m not a security person. So I end up chatting about, I don’t know, custom post types and how to do various things that I’m doing. Maybe podcasting in the WordPress space or something along those lines.

You, I guess, are having these conversations, and it’s very much in the territory. It’s in your wheelhouse. And so maybe it’s not a surprise to you that 67-plus percent of people have had something in the last year. But, on the face of it, that just seemed like so many. If I see 1,000 people at a WordCamp and I think, “Well, 670 of those have had a problem during the course of this year,” gosh that really does seem like a systemic problem.

And I know that outside of the WordPress community, WordPress gets a bit of a hard rap, on the security front. It’s insecure and what have you, and, all of the caveats. We know that really isn’t typically the case for WordPress Core. Tends to be the addition of code and plugins and themes that adds that on top. But I’m still surprised, feels almost like if the mainstream press got hold of your survey and just pull out that one statistic and bandy it around, it doesn’t feel great, if you know what I mean.

[00:12:53] Robert Abela: Yes. I think WordPress gets a lot of bad rep also because it’s very popular. As in like pre-WordPress, I’ve used web servers before as in like custom PHP websites, .NET, IIS, Apache, et cetera. Websites used to get hacked as well in the thousands. The thing is that you couldn’t point your finger to one type of website, you know because they were all custom. So these problems have been happening since we started having websites, quite frankly.

With WordPress, unfortunately it happens and we have a bad rep because I think there are two things. Look, first of all, it’s very popular, so it’s always there. If WordPress power is around 42, 43% of the, or maybe it went a bit down, but anyway, let’s say 40%.

[00:13:30] Nathan Wrigley: Roughly, yeah.

[00:13:32] Robert Abela: Yeah, The chances, for every 10 websites, four of them are going to be WordPress. That’s a common denominator. So of course, WordPress is going to get a lot of attention.

I also think, again, goes hand in hand with how many people have security concerns. WordPress has made it very easy to launch your own website, which is a good thing. However, of course, those same people who launch their own website, maybe they don’t have the technical understanding and experience what it takes. Because setting up a website’s one thing, but keeping, managing a website for a year, two, three, and growing it, adding new functionality is another thing. So most people might not have the experience that they have, so of course, it’s much easier to find security issues with these type of websites.

[00:14:10] Nathan Wrigley: Okay, we’ll move on anyway. So we’ll talk about the concerns. So you’ve obviously polled your recipients of the survey about the kind of things that they were worried about. So what are the outcomes that they fear the most, if you like?

And website availability, so the taking down of a website came in at number one, with 55.8. And then in no particular order, but these are the two that I picked out. The fear of being defaced, so the website in some way being amended, or there being some reputational damage because of what the amendment was. I don’t know, maybe there was some imagery, or some slightly political content that ended up on your website.

That was just slightly south of the availability, so that was 54.2%. And then dropping a full 10%, so 46.4%, was the worry about data theft or loss. Frankly, I’m not surprised by that. I guess any developer’s nightmare is their website actually disappearing off the internet. That’s number one, so that doesn’t surprise me.

I remember in the day, 15 years ago, defacement was the thing. Honestly, I can’t say that I’ve been browsing the internet recently and seen something that’s been defaced. It seems like the hackers have all moved on. Maybe there’s things buried in the source code that I don’t know about.

Yeah, it doesn’t surprise me that the availability is the main thing. But I am surprised that data loss comes in third, if you like. I personally would have had that as number one, especially, if you’ve got a, I don’t know, an LMS, or you’re connecting with a CRM, or you’ve got form data which potentially is capturing something personal that the GDPR would worry about. So there’s no question, just if you want to comment on those particular things, go for it.

[00:15:42] Robert Abela: No, definitely. Those are the numbers based on all the respondents. But if you start breaking down the numbers, there’s more nuance to, to these things. So for example, if you look, those who are concerned about website availability, or defacement, are usually those who have content websites. Mostly based on content, news, magazines, et cetera. Those who are more concerned about financial loss or data theft are more the e-commerce websites.

[00:16:08] Nathan Wrigley: Oh that makes sense. Yeah.

[00:16:09] Robert Abela: The membership websites, et cetera. In fact, the membership websites are as well more concerned, for example, about compliance because of privacy. So those numbers, like fifty-five point eight percent, those are from the all respondents. But as soon as you break all that down, it differs a bit on the type of website you have.

And it’s expected because if you have an e-commerce website, of course you are dealing with billing details, payments, and all this stuff. If you have a membership website, maybe you are also dealing with payment details, but you are also dealing with much more data. Maybe you have some sort of internal chat. People are sharing their addresses on it, their personal information. So that you are more concerned about GDPR or any sort of compliance, et cetera.

But if your main selling point is if you have a content website, a news website, and your main selling point is your website being available, then of course that is your biggest worry.

[00:16:53] Nathan Wrigley: That’s an interesting split of the data there. That makes perfect sense, of course, now that you say it in that way it really is obvious.

So that was you polling your respondants respondents there, and you were trying to figure out what their worries were and what they were into and all of that kind of stuff.

And then we sort of to move to a different realm where despite all of that being said, so, you know, got a lot of people worried. We’ve outlined some of the different worries that they have, depending on the type of website that they’ve got.

From all of that, if you’d have ended the survey there, I would have assumed at that point that everybody had something in the back pocket to pull out, an SOP or something like that, to pull out in the event of an actual problem. If data theft is apparent, we do this. If the website goes down, we do this. But your survey reveals entirely the opposite.

So the high numbers on the one side, the fear numbers, are not mirrored by the what we’re going to do about it numbers, because you go straight into the high 20s, so 27.9% had a breach recovery plan. So how to get back from a problem with your website being, let’s say, hacked, let’s use that word. And 26% provided some sort of training for their team, some sort of security team training, that kind of thing.

Again, does that surprise you? You’re in this space. Maybe that’s really typical, but given the high levels of concern, there seems to be a real disconnect with what we’re going to do about it. That’s curious.

[00:18:18] Robert Abela: I’m not surprised, in the sense, it’s very common. The majority of people, especially nowadays, there’s much more knowledge that, yes, websites can be hacked, this can happen. However, that doesn’t translate. People don’t have the, I don’t know if it’s the resources, the means, the time to actually take action on it, to prepare some things. So, I’m not surprised.

Again, similar to what we discussed before, there’s a bit more nuance to these type of numbers because you said only 27.9% has a breach recovery plan. Actually, that’s based on all the respondents, but typically the number is much less, because when you look at it, from the respondents, from all those who have a security breach, from those 27.2%, 70.2% which have control in place are corporate or brand websites, which means they have their own in-house team. Only those, 70% of those have their own, have their activity logs, have their firewalls in place, have a recovery plan in place, et cetera.

So the number of, let’s say, the non-branded, the smaller websites, yeah, they have absolutely nothing. They have no sort of recovery plan or anything like that. In fact, the numbers are much smaller. Only 23% of those websites typically have some sort of recovery plan.

[00:19:23] Nathan Wrigley: Okay.

[00:19:24] Robert Abela: I’m not surprised because usually, especially if you’re an enterprise, or a bigger business, you are bound by more compliance. Maybe you have more security people on board who are much more aware what can happen of what they need to do. But yeah, the average website doesn’t have these things.

[00:19:38] Nathan Wrigley: Yeah. I wonder if your data here might be skewed by the type of correspondent that you got. So for example, who knows how many blue-chip companies, have submitted to your information gathering here. Perhaps not many, but maybe you got lots of WordPress community members, and so the data might be skewed in that direction. But that’s an interesting point. So dependent upon the nature of the website and the type of team they have behind it.

But it is still, regardless of all of that, it is still quite low. And I was using my analogy earlier about insurance, and I think that applies here. Insurance is the most uninteresting thing to purchase because you spend this money and, let’s say for example, you got home insurance. I would imagine most people typically go through a year and they never make use of it. Sorry to anybody listening who has obviously had to make use of that. But the moment you need it is the moment that you’re glad of every single penny that you’ve sunk into that, and I guess that applies here. If we can persuade people to get that data breach recovery plan, whatever it may be, have that in your back pocket, that would be a useful thing to have.

[00:20:38] Robert Abela: Yeah. As I’ve said in the beginning, I’ve been working in IT security companies, security software companies for 25 years. All of them, the most common sales opening, like sales reason, like people coming to us like, “Hey, this happened, so now I need this.” They’re always after they’ve been hacked, after they’ve been a leakage, after there’s been something wrong.

Very few proactively come and as I said, like the bigger enterprise companies, because they have certain regulations and stuff and certain budgets that they invest in these things. But the average website, yes, first they have to experience something, and then. I think it’s, in all fairness, I think it’s common human nature. It’s not just about IT. We tend to be all humans. We tend to be like, “Oh, we’ll see later,” and then if it happens, “Ooh, I should have…” it’s always like that.

[00:21:17] Nathan Wrigley: Well, there’s also that calculus of how much time does it take to recover. So for example, if you’ve got a brochure site, and you’ve got backups going back for many many months you can restore to a point that you’re fairly sure that everything was actually fine, and the breach has been mitigated by going backwards in time. But it’s just all the wasted time. It’s the wasted time going through the backups and seeing, okay, is this backup, does it have the malware in as well? Okay, that one does. What about this one? What about this one?

And there’s no knowing how long that’s going to be, and the minute you step, as you said, into e-commerce and you’ve got transactions happening every couple of minutes, and then you’ve got receipts and you’ve got to fulfill those orders, and somehow, oh boy, yeah.

[00:21:59] Robert Abela: Yes. Then it’s a different ballgame. Yeah.

[00:22:02] Nathan Wrigley: Different ballgame isn’t it? Yeah.

Okay, so the next point that we’re going to move on to is actually one that you probably just made. And it’s that the detection in most cases, well actually not most cases, in many cases. So 42.6% of your respondents said that their detection is mostly retroactive. So that is to say the thing has already gone wrong. Somebody in the 42.6% of the case is because they see something on the website. They’ve noticed that something isn’t quite right, something looks out of order.

38.4% because they were actually inspecting the logs. That tells me that whoever’s inspecting the logs is doing diligent work. That’s kind of interesting. So don’t know if you want to comment on that, but basically a lot of people are figuring this stuff out after the thing has happened, as you described, not before the thing has happened.

[00:22:51] Robert Abela: Yes. So there are four criteria. So 42.6%, as you said, is common website behavior, either detected by their team or by clients. 38.4 via logs. Now, the logs is a bit, it can be reactive and proactive, because with the logs, you can actually, in fact, we have some notes on this, but I don’t have the exact numbers right now. Because some of them were actually by someone analyzing the logs, but some of them were actually because someone has configured notifications based on the logs, like a sort of intrusion detection system.

And so if, I don’t know, if X login happens after X time, whatever, please send me an email or an SMS, and that, it’s still reactive in a way, but at least they could act right away as soon as it’s happening. Yeah.

[00:23:31] Nathan Wrigley: Yeah kind of proactive reactive, isn’t it? That’s a really interesting subcatagory.

[00:23:33] Robert Abela: Exactly, yeah.

[00:23:34] Nathan Wrigley: Yeah.

[00:23:34] Robert Abela: So yeah, but yeah, it’s still reactive because then you have 35.6% they knew through their web host, and 30% they knew through some sort of malware scanner alerts on their website, et cetera.

[00:23:45] Nathan Wrigley: Okay. Again, just kind of interesting data coming out.

So the next one, incidents most commonly resulted in downtime for the website. So that’s pushing up to 70%, 68.4% of whatever happened, resulted in some downtime. And then I don’t have the numbers for the following data, but I guess it decreases from here.

The next thing was reputational damage. That was a result of some sort of incident. And then search engine ranking is affected. That’s an interesting byproduct.

This one’s brutal. Client trust disappearing. That’s really interesting. And then in some cases, lost revenue. I imagine the lost revenue is being described as in some cases, because, as we described earlier, if you’re dealing with revenue, you’ve probably got more bulletproof security measures in place.

But the ones that sort of jump out to me there aren’t the downtime, because I would’ve assumed that. It’s really the curious byproducts of things like the reputational damage, the search engine damage. You can’t really get your hands on those, can you? There’s no real way of knowing what that’s going to look like or feel like, or how that’s going to affect your business this year or next year.

Just to know that, you wake up one morning to discover that you were in first place on Google after six years of hard SEO work, only to discover that you’re now in fourth and descending fast, that’s pretty brutal.

[00:25:01] Robert Abela: Yes. And in fact, if you break down those numbers a bit more, like 45.9%, there’s loss of search engine ranking, and that happens usually when search engines detect you have issues. I don’t know if you remember, Google used to have that page sometimes.

So that happens. When that happens, when the search engine themselves realise there’s an issue, you lose a lot of rank. The penalty you get there is very heavy. In fact, only 14.5 of those who have had some issues with the website has lost ranking because they have discovered their issues before the search engine did.

So again, that’s why you should be a bit more proactive because if your search engine finds out before you, the penalty, as you said, and you cannot really quantify it because God knows how long you will remain. As you said, if you were position one for six years in a row, now one fine day you’re on the second page, God knows how much work you need to go back up, and you cannot even calculate what the revenue loss is.

But when it comes to revenue loss, again, it’s the same. There are some websites, I’ve seen some websites where like they generate $70,000 per hour. So for every hour down, that’s $70,000 gone.

So yeah, there are lots, and of course, the reputation, on top of the reputation, there’s also compliance and legal consequences, especially in the US. Things are becoming much stricter now. If you had some issue, some customer data has been leaked, you have problems with the law, fines, and other similar stuff. So, the financial damage to all of this, of your website getting hacked, is very high.

Not just the reputation, losing customers, you might end up in court. You might lose your search engine ranking, and that is why most probably it’s a good idea to become a bit more proactive rather than reactive. Or it’s almost impossible to, there is no 100% secure solution, and that is why I think it’s very important to have good hardening, but also good monitoring, the whole process, the whole 360 degrees, the whole cycle.

[00:26:44] Nathan Wrigley: It’s such a curious industry that you’re in because, how to describe this? It would seem, or at least, it would be possible to perceive that this security survey is perfectly aligned with your business goals in a way. There’s loads of problems out there on the internet. There’s multitudes of ways that things can go wrong, and for every one of them, there’s, a WordPress solution out there.

But I know Robert. We’ve met many times before. I get the intuition that’s really not why you’re doing this, although somebody listening to this might have that sort of slightly, I don’t know, cynical approach that, Robert’s just saying this so that he can launch his Melapress products at you. Just put our minds to rest on that score. Why do you actually carry out this survey?

[00:27:25] Robert Abela: Good question. Actually, our plugins only address part of the security. There’s much more when it comes to firewalls, et cetera, that I still say hardening you still need. We don’t even cover it.

No, we do it, honestly, it started around four or five years ago, for me, it was just curiosity. It sounded like an interesting to do. Hey, let’s do a survey, just experimenting, et cetera. And we had very good response, and now we’re just, doing it honestly.

Like I really believe that by knowing, this is not just about WordPress security, about everything else. By knowing where other people are doing it wrong, you will learn from it. By knowing, okay, clearly I can see, for example, as we were saying, like seventy percent, seventy point two percent of enterprise and marked businesses usually have logs, usually have firewalls, et cetera. Maybe we should aspire more towards them and be more like the average website should have a bit more like things like that, and maybe they’re doing something right.

So yes, there is a lot to learn from surveys in general, not just this, any type of survey. There is usually a lot to learn. And that’s why we’re doing it as well, because from the first time we’ve done it, which started really as a curiosity project, we got so much good feedback. And actually the second year people were asking us if we are going to do it. Because yeah, people learn from these things.

I mean, of course there’s the benefit of it, hopefully it will promote as well a bit our plugins. But anyway, it’s going to promote all other type of security solutions. We are not, in fact, the survey is not tailored just for our plugin. It talks about everything. As I said, the whole security cycle. You have the hardening, you have the monitoring, updating, et cetera, and we only do one part of it, the monitoring aspect, basically.

[00:28:50] Nathan Wrigley: Before we move on to our sort of final bit, which I want to concentrate on AI, I’m just going to wrap up the security bit just by summarizing what comes towards the end. And it’s less about numbers, and it’s more about just conclusions that may have been drawn. But most of it, I think, would be fairly obvious from what we said. So I’ll just summarize it a little bit.

The first one is that e-commerce and membership sites tend to have greater security concerns and stronger practices. That kind of makes sense. I guess it reflects the nature of the business they’re in, and the kind of data that they’re holding, and the legal compliance that they may need to be concerend with.

In-house teams are more likely to have recovery plans. Again, I presume that’s fairly obvious. The boss, the head of the pyramid can sit down and say, “Okay, it’s your job now to crack on and do that. You’ve got a week to figure out all this sort of stuff,” and what have you. Whereas a freelancer sitting in their own office, there’s always regular work to be built, sites to be built and other things to do. So I can well imagine why that’s the case.

And sites, again, fairly obvious, sites with repeated security incidents tended to have stronger controls in place. Today, presumably, it’s a case of once bitten and all of that. Once you’ve actually had this nasty stuff happen to you, you’re pretty likely to make sure that does not happen again.

In summary, I suppose the reports really, the recommendations are focus on prevention, detection, and recovery rather than simply adding in more security tools, would be the way that I would describe it.

Okay, let’s move on then just before we finish. It is, as we’re recording this, it’s September 2026. In the more recent past, I want to say, I don’t know, the last two months, something like that, the WordPress security news bulletins have been on red alert really. We’ve had some charts being put out on social media which show the amount of vulnerabilities discovered, and also the amount of AI-based plugins that have gone into the repository. The supply chain attacks that have suddenly become a thing. A lot of it really because people can corral AI to do mischievous stuff and what have you.

I don’t really have a question, but I just wondered if you had a comment on where we are in September 2026, because it does feel as if there’s quite a lot of, there’s a lot of scope to be very doomer at the moment. It almost feels like the AI is winning the arms race, but maybe that’s not what you’re thinking from your end.

[00:31:04] Robert Abela: No, it looks a bit negative. I wouldn’t say AI is winning the race. Actually, people with malicious intent using AI are winning because AI is neutral in a way, like it depends on what people ask the AI to do.

[00:31:15] Nathan Wrigley: Yes.

[00:31:16] Robert Abela: But it is worrying, yes. The graph you are mentioning, I saw a graph shared by John Blackbourn, yeah, about the number of issues reported in the HackerOne WordPress vulnerability program, which is insane.

[00:31:28] Nathan Wrigley: Yes.

[00:31:29] Robert Abela: And they received more reports in the last week than they ever did in a whole number of months. So yes, it is worrying. You can look at it both ways. The same way attackers can use AI to find issues. We are doing it ourselves as well, quite frankly, because whenever there’s a new model out there from all of these vendors, most probably attackers are going to use them to scan our code, et cetera. So we’re doing it as well.

We always used to do the manual security analysis, et cetera, but now that we have AI, with every release, we just hammer the update and try to find as many issues as we can.

The reality is also that some, if not many of these vulnerabilities are not actually so easy to exploit. Like it’s really, the stars really have to align and it’s really, but still, it’s better safe than sorry. Because even though today it might be difficult to exploit a particular issue, in six months’ time, we might have technology that might make it very easy to exploit this type of issue.

It looks negative, but the same tools that attackers have, malicious users have, we have them as well. So it’s up to us to use them and be ahead of the curve, and use them proactively ourselves and before every update, during the whole development cycle. We should use them more often to make sure at least that we cover what other people can find before us.

[00:32:35] Nathan Wrigley: Yeah. I suppose the bit that I find curious is the optics of it. So, there was always this universe in which people would be able to throw dirt at WordPress because you know WordPress isn’t secure, and we talked about that earlier. It’s usually plugins and very rarely Core. Plugins, themes, additional code, what have you.

However, given that it would appear that people can stack 14 overlapping problems and create this one vulnerability from things that probably humans would never have conceived in the past. That then just lends into this narrative of, well there’s this deluge, this tidal wave of things that are coming at WordPress.

So I woke up this morning to discover in my feed BleepingComputer. I don’t know if you’ve seen this one yet today, but BleepingComputer have got an article with a CSV attached to it about yet another WordPress thing. And it just feels like that sort of day in, day out, there’s just another and another, and it’s that narrative that, that concerns me. It’s just that it gets away from us, that there’s one this day, there’s one this day, one this day, one this day.

And having to explain, “Look, calm down. That one was nothing. Okay, calm down. That one was also nothing. Okay, yeah, that one was something, but that one was nothing, that…” It’s just that constant fighting the narrative in an era where every day something seems to be out in the press, a problem that WordPress. Do you capture what I’m saying there?

[00:33:57] Robert Abela: Yes, no, and no wonder we get negative rep in the rest of the IT industry because, yes, we do get these news, and the numbers are very big. If you find a vulnerability in a plugin that has half a million installations, all of a sudden you see the news, “Oh, half a million WordPress websites are vulnerable to X.”

Unfortunately, yes. The thing is, WordPress in general, it’s very secure like. There are so many I’ve seen in my life, I don’t know how many custom web applications I have seen that are horrible in terms of security, like really horrible. It’s just because, of course, no one is seeing these because this might be a website in millions of websites, so no one is targeting. But WordPress, because it’s a popular platform, is going to be targeted.

But yeah, because the numbers are big, yeah, unfortunately, we do have a bad rep. And yeah, the news like to sensationalize things as well. So yeah, the rep is not good, no. But the reality is that it’s going to happen. It’s going to happen more often, most probably. It happened to us. All the vendors I’ve spoken to at WordCamp US and WordCamp Europe, they’re all the same. If you look at our plugins as well, maybe we used to get, I don’t know, maybe on average a vulnerability or two reported a year.

As soon as this whole AI started thing, all of a sudden within a month or two, you get like four, five, six reports like, “Whoa, what happened?” In just one week. It’s just reality. It’s up to us, as I say, we have to be more proactive. Of course, it’s easier said than done, but we have to be more proactive and try to use the same tools that attackers are using to make sure at least we detect them, yeah.

[00:35:13] Nathan Wrigley: Yeah, the bit that genuinely I find curious is what will be the calculus in terms of time that people can spend on this stuff. So as an example, if let’s say that by January 2027, many of us are having to spend a good proportion of every day, and by a good proportion, I don’t know, let’s say 30 minutes or something, browsing through the news to see if anything has cropped up. Or indeed to read the things that we know has cropped up because the fire hose of security news has gone through the roof.

This seems like it could happen, that we’ll all have to be mindful of it. And it’s just that sort of attritional wear and tear that, “Okay, really? Do I have to do this each and every day?” That will be interesting.

I suppose the flip side of that, curiously, is that it, how to describe this? It doesn’t do your business any harm because the more that people are concerned about their WordPress websites, the more security news there is, the more that they will be drawn to companies like yours. So it’s a very curious tightrope walk that you’re going to have to perform, I think as well.

[00:36:10] Robert Abela: Yes. Yes, it’s the reality. If I can do a shameless plug, at WordCamp US, I spoke about, WordPress user sessions and hijacking, and one of my lines was that all the things I had mentioned, but the talk is available on YouTube on the WordPress channel. All the things that I have mentioned, so many missed it, because if you look at user session hijacking, the bottom of it is all derives from user mistakes. A user making a mistake, that’s all it is.

And the reality is it all sounds dramatic. It all sounds like it’s the end of the world and apocalyptic. However, the reality is that, yes, nowadays, if you use a website, even as a user, you need to be aware of some basic things.

So yes, there are these news, and hopefully more and more people will become aware and more and more people need to become aware that yes, these are the dangers, these are like the risks of logging into a website nowadays. Of maintaining a website nowadays. It is. It’s like a double-edged sword. Like the news are making sometimes a bad rep for WordPress, but they’re also reaching more people that they need to wake up and say, “Oh, these are the risks, so we need to take action.”

[00:37:07] Nathan Wrigley: Yeah, it will be interesting in the face of AI vulnerability. It’d be interesting to see what the, let’s say hosting companies, let’s paint a target there. What they do to manage their stack, because obviously it’s going to be very important for them to make sure that the clients that they have. And how they position themselves in the news, and how they can portray the security solutions they’ve got. But as well as companies like you, you know, plugins and other firewall companies and things like that. Be interesting to see through 2027 how they manage that.

Okay. In which case we will wrap it up there. Just another quick reminder, go to the WP Tavern.com website, search for the episode with Robert Abela. You will be able to find the 2026 Melapress WordPress Security Survey over there. Download it, have a little bit of a look. And Robert, are you available anywhere online? Do you, other than Melapress’ do you actually make yourself available? And if so, where can we find you?

[00:37:58] Robert Abela: Yes, I’m active on LinkedIn, Robert Abela. I’m active on X.com, and I finally also have my own website. It’s more on personal things quite frankly, but yeah, it’s robertabela.me.

[00:38:08] Nathan Wrigley: In which case I will bury those in the bottom of the show notes as well.

[00:38:12] Robert Abela: Thanks.

[00:38:12] Nathan Wrigley: So that you can find those. Robert Abela, thank you for chatting to me today. I really appreciate it.

[00:38:16] Robert Abela: Thanks likewise.