GoDaddy’s Market Mistake

I know, I know. GoDaddy are one of the biggest, most successful web hosts in the history of web hosts. What makes Luke more of an expert than the brightest minds in WordPress?

Well, nothing really. But after talking strategy with friends at GoDaddy (some of their top WordPress people), I can’t shake the feeling that they’re miscalculating their marketing strategy.

To explain, there’s some groundwork to cover… here we go:

People spend a lot of time deciding where to buy.


You’re much more likely to buy when you already know the seller. Research by Adobe suggests that existing customers are 9⨉ more likely to convert than a first-timer!

For long-term WordPress hosting commitments, brand precedence is a major factor. That’s why hosts are the leading sponsor of WordCamps – they need to get their logo in your brain.

In terms of engagement (and, of course, brand recognition), nobody captures the market as well as hosting. Automattic’s strategy is unique in this space:

  • Free to start
  • Easy upgrade paths (domains, theme marketplace, etc.)
  • Account required to use Jetpack and WooCommerce
  • Sign-in with to your blog and comments


Every marketing campaign has a target. When making a purchasing decision, you look for the market messaging that most closely identifies your use-case.

Use-cases for WordPress hosting are organised along an axis of scalability. Low-traffic hobbyist websites are the cheapest, while enterprise requirements are most the expensive.

HobbySmall BusinessAgencyEnterprise

We can classify which of these audience each WordPress host targets with some simple analysis of the copywriting used on their landing pages.

For example, GoDaddy’s messaging is clearly targeted at the small business DIY website market:

Got stuff to sell? No problem.

The retail pitch.

Your hosting plan is set up with WordPress installed and ready.

Removing barriers for non-technical folks.

Our WordPress search engine optimization (SEO) plugin walks through your pages and automatically handles your basic SEO needs.

Just in case you didn’t know what SEO stands for.

While WP Engine is targeted at agencies:

We offer the best WordPress hosting and developer experience on a proven, reliable architecture that delivers unparalleled speed, scalability, and security for your sites.

Notice how “sites” is plural?

We empower developers with the Genesis theme framework, dev/stage/prod environments on every site, Git and SFTP connections, automated backups, and WordPress core updates.

Definitely not for beginners.

If we look at all major hosts through this lens, we get a table that looks something like this¹:

Hobby / DIYAgencyEnterprise
WP Engine
Liquid Web
Siteground VIP
DIY Cloud

Relationship + Use-case

Since we’re thinking about WordPress hosts along two different axis, let’s overlay them. Who doesn’t love a good quad chart?

The goal is to move out of the bottom half, and establish ongoing relationships with your customers.

Ecosystem Strategy

In order to move on up, WP Engine and GoDaddy are building a product ecosystem. WP Engine owns Genesis, which moves them into the “existing relationship” quadrant for Genesis users. GoDaddy own CoBlocks – same deal.

Now that we’ve got this framework to work with, we come to the main point of this post…

GoDaddy’s Gaffe

Problem #1: GoDaddy’s product ecosystem strategy doesn’t create repeat business within their market.

GoDaddy’s ecosystem products (right now) consist of:

These are all very compelling products for their target market: small business owners who want to DIY their website. Check one for Use-case column ✔️.

Unfortunately, the DIY website market don’t typically keep coming back for more. I mean, ask any freelancer employed to fix or upgrade this style of website – the client often doesn’t even remember which host they chose.

Compare with WP Engine – Local, Genesis, and Atomic blocks are all agency focused. Check one for Use-case ✔️. Also, agencies will keep coming back for more. Their products establish ongoing relationships. Check two ✔️✔️.

Problem #2: The market is way too crowded.

When you target non-technical people who want to DIY their own website, you’re competing with the likes of:

  • Squarespace
  • Shopify
  • Facebook

That’s quite the contest in the top-left corner. GoDaddy are big enough to compete at this scale, but it’s got to be tough going toe-to-toe with some of the most successful brands in the world.


There’s a market for small business hosts – no doubt.

Compared to an agency focused strategy, finding a regular stream of repeat business, plus clear competitive differentiation – that’s going to be really hard.

1. Of course, there’s always a little overlap. Liquid Web would be happy to host your retail eCommerce store, and WP Engine provides enterprise grade solutions.



This post is a response to a question recently asked by WP Tavern: Can the Block Directory and Business Interests Coexist?

When you stop to think about it, the WordPress Plugin and Theme ecosystem is a shining example of the Free & Open Source Software ideology working sustainably.

Take a completely open source project, and extend it with purely open source plugins. Keep it up for 16 years, until you power over a third of the internet, with no signs of stopping.

It seems outrageous, but that’s what WordPress has done!

The WordPress ecosystem is a perfect answer to skepticism from die-hard capitalists – it really is possible to build a business on non-proprietary, freely licensed, shared knowledge.

Of course, this doesn’t work without some private enterprise – there’s got to be some money in it, somewhere, if it’s going to last. Here we meet the cast: Hosting, Premium Plugins, Premium Themes, and Marketplaces.’s laissez-faire approach has, thus far, created an ecosystem perfectly balanced between free for accessibility, and premium for sustainability.

> Enter stage left: Blocks

This year, a new extension paradigm is being introduced to WordPress. We’ll soon meet the Block Directory, and we’ll install and manage Blocks in the same way as Plugins and Themes.

Put briefly, I’d like to propose a new type of WordPress plugin that provides blocks and nothing else: Single Block Plugins. These will be hosted in a separate Block Directory section of the Plugin Directory.

Alex Shiels – The Block Directory, and a new type of plugin

It’s going to look something like this:

Mel Choyce-Dwan – Block Directory in WP-Admin: V1

This looks amazing. Especially the “grouping” of blocks below the parent block library. Imagine this on the Plugins screen, for all your WooCommerce extensions!

Since Blocks are basically just Plugins, there shouldn’t be any reason we couldn’t build a Block business in the same way as our Plugin Businesses, right?

Wrong. 😕

> Cue scary music
> Cue fog machine
> Enter: The Block Directory Guidelines

In no uncertain terms, the Block Directory forbids monetising Blocks. From the Guidelines:

5. Block Plugins must not require payment or a paid account to function.

This includes payment for premium features. You may use the donation link feature.

8. Must not promote other blocks, plugins, or themes.

Block Plugins are blocks. They must not include advertisements, prompts, or promotional messages.


Although I’m sure a few excited developers will create some great blocks just for kicks, without any long-term support model, these efforts are bound to be short-lived, unsupported, and unsustainable.

5 years from now the Block Directory will be full of blocks that haven’t been updated in the last 4 years.

Scene: Luke Has An Idea

> Spotlight centre stage

Instead of completely removing any monetisation opportunities, we could create a user experience which anticipates which Blocks are free of ads and up-sells, and which aren’t.

We could allow users to filter out plugins with strings attached, so that when an advertising fiasco like this happens, it was (in a way) consented to.

Apple’s App Store does this with In-App Purchases:

Jonathan Wold and I came up with this idea during an episode of Crossword. The more I think about it, the more it makes sense.

So I put together a few mockups. Concepts of how this might look in the Plugin and Block Directory. I’ve taken a few different approaches – which do you think works best?

The “Contains Ads” text is right below the Install button, can’t miss it.
Some plugins require an account with a third-party service.
Here the “Sign-In Required” text is shown below More Details – this makes it more informational, implying less of a “warning” before install.
Alternatively, we could move the text to the bottom section. This area shows information helpful for deciding between a number of different options.
Rather than denote “Ads” or “Sign-In”, we could show a badge which references the plugin’s monetisation model, if it has one. Freemium, Premium, or Paid Service.

The language here is a bit tricky. I’m not 100% happy with the words I chose, but I’m confident we can figure that out.

We can apply the same thinking to the Block Directory:

These Block Directory designs are still being iterated on, but I love how simple and clear they are. This adds just one more element into the mix.

Taking this approach would give users a better experience with Blocks and Plugins, and contribute to a more vibrant and sustainable Block Directory.

It might even pave the way to a future where handles payments for premium extensions natively!

> Audience cheers
> Ensemble bows

The End


An Ecosystem Play

The most common question I hear from agencies and freelancers is “where do I start”? They’re ready to dive-in and build Gutenberg-first themes, but there’s no clear starter theme to get them going.

What does a Gutenberg-first theme even look like?

Getting Started

Once upon a time, we could use starter themes like Underscores to kickstart a new site build – but most of these themes haven’t seen any updates for a long time. Not counting community PRs:

Notice a trend here? Starter themes seem to have stopped development around the start of 2019 – at the exact time that Gutenberg was released (December 2018).

Because of the new block paradigm, the future of themes in WordPress is ambiguous and uncertain, and that’s causing foundational theme developers to put on the breaks.

When Powers Combine

An exception to this trend is the Genesis Framework by StudioPress.

StudioPress was acquired by WP Engine in June 2018, just a few months before they acquired Atomic Blocks. Their approach to Gutenberg-first themes is to build theme support for all the blocks in the Atomic library natively, with Genesis.

This is an ecosystem play: Hosting + Base Theme + Block Library. You can create a build modern, fully-featured WordPress site with the combined power of:

WP Engine + Genesis + Atomic

It’s not just WP Engine who has adopted this strategy. GoDaddy have done exactly the same thing. In April 2019, GoDaddy acquired ThemeBeans, including their CoBlocks plugin. Rich Tabor (a recent guest on the Crossword podcast) started work almost immediately on a new theme called Go.

This is exactly the same ecosystem play:

GoDaddy + Go + CoBlocks

AirPods work best with an iPhone, and an iPhone works best with a Mac. In the same way, if you build with Genesis, you’ll also want to host with WP Engine, and use Atomic Blocks.

We start to see something that looks a bit like this:

WP EngineGenesisAtomic Blocks

Local Development

For any theme build, the first step is almost always getting a local development environment up and running. There are a few options out there (Vagrant, DesktopServer, XAMPP), but the most widely-used solution (by far) is Local by Flywheel

… which was acquired by WP Engine in June 2019.

Of course, this ties back into ecosystem thinking – if I use Local, I’m much more likely to host with Flywheel. It also introduces us to a very important part of building ecosystems: Integration.


Integration maximises the likelihood of success for new products in the ecosystem, leading to more and more lock-in effect. Our table is starting to look more like:

Since GoDaddy’s target audience is more small-business focused (not really the developer type), I don’t think we’re likely to see GoDaddy exploring local development environments.

Since WP Engine have more of a focus on agencies and freelancers, you can see that they’ve established some very strong beachheads.

As an agency, buying-in to the WP Engine ecosystem is an easy decision, since there are multiple points of integration. On the other hand, if you just want to build a site without any development experience, GoDaddy makes it easy with Go + CoBlocks.

If you’re SiteGround, Kinsta, Pagely, or Dreamhost, you’ve got to start thinking in terms of ecosystems and integrations, or you’ll be left behind.

The Weakest Link

Interestingly, the poorest user experience for both WP Engine and GoDaddy is their core offering – their managed hosting. In both cases, managing your WordPress sites is clunky and difficult.

Flywheel’s management interface is the total opposite – a genuine delight to use. If WP Engine can learn a UX lesson or two from their friends at Flywheel, they’ll have a killer combo.

Or better yet, bring Genesis and Atomic Block to Flywheel customers!

A Consolidated Web?

The thing about ecosystems is that they create sudo-monopolies. Does Apple have a monopoly on computers? No, but they have a monopoly on MacOS – and if you’ve invested into that, it’s very hard to escape.

It’s simply not possible to compete with integrated ecosystems in the long-term. I feel safe in predicting that WordPress hosting providers will consolidate over the next 5 years, to the point where there are really only 3 or 4 options, each with its unique set of products and services.²

What does this mean for the open web?

Is WordPress still distributed if it’s primarily hosted by just four different providers?

Yes – it is. When we talk about an open web being distributed, there are two aspects that matter:

  • The URL layer – what visitors see in the address bar
  • The CMS layer – portable and non-proprietary software

WordPress sites can still be built in weird and wonderful ways, and exist outside of a centralised domain, even if they’re all hosted in the same place.

1. An interesting obstacle to keep an eye on is block-based themes. The entire concept of a theme in WordPress will experience some major disruption in 2020, which could potentially upset Genesis and Go (though Go seems better positioned for agility here).

2. Not discussed in this article is Automattic, who could easily make a Managed WordPress play. In the case of, there’s a tight integration between the “Management Dashboard”, and the WordPress installation itself. Add to that Products like Calypso or WooCommerce, and you’ve got an easy entry into the WordPress ecosystem market.



Reflecting on the topics I’ve covered on this blog recently, I can’t help but notice that my tone has been pretty salty lately. Despite receiving a ton of positive feedback on my writing (thank you!), I’m personally disappointed that I’ve not been more constructive.

In a recent Twitter thread with Birgit Pauli-Haack (whom I really admire) I came to realise that I was just having a whinge, and not providing any productive feedback. Birgit and Mark – I apologise.

This grouchy attitude really runs contrary to how I usually think. I try to be a “if you don’t like it, fix it” kinda guy.

As an aside, I’ve evolved my thinking on the problem with Gutenberg development. The issue is not just that key decisions about the future of WordPress are facilitated through a developer tool¹ – the issue is that nobody is proactively seeking input from the WordPress users who aren’t involved in core development.

One of the things I love about the WordPress community is that there’s a culture of “we’ll hear you out”. When an irritated crazy with an axe to grind joins the Core Dev Meeting on Slack, it’s always handled with grace and care. Criticism rarely results in controversial political encounters.

I think this comes from the top. Listening, recognising, responding in a politically sensitive way – that’s one of Matt Mullenweg’s superpowers. You should see this guy deftly manoeuvre through questions from the floor during a State of the Word address. It’s impressive!

Maybe we’ve gotten too good at handling criticism? In an open source project the size of WordPress, critics are numerous and persistent. Out of necessity, we’ve become experts at hiding negative sentiment in plain sight.

For example, nobody seems to be talking about this:

The Classic Editor, used to disable Gutenberg, is the fourth most popular plugin. And consider me suspicious about Contact Form 7 taking that top spot.

It seems like simply noticing and writing about problems with the WordPress project² doesn’t really achieve much. So in the future, I’ll attempt to include a practical aspect to my writing.

For example, I might write about how it’s nearly impossible for plugin authors to have a clear picture of how (or even how many) people use their plugin, due to restrictions in the plugin guidelines. With this post, I could include a functional workaround – a loophole in the guidelines, based on examples from Jetpack and Woo.

In this manner, I hope to keep writing here, and hopefully have more of a positive impact on the ecosystem³.

1. Don’t try to convince me that GitHub isn’t a developer tool. I know discussions also happen on the Make blog and Slack, but it’s all funnelled back to GitHub for the real decision making.

2. Insularity from users; power dynamics with Automattic; plugin guideline hypocrisies (looking at you Jetpack); Envato’s enduring WordCamp ban; developer-centric decision making; the list goes on.

3. Can anyone recommend a good footnotes plugin?


Block Based Themes

Who decides the future of themes in WordPress?

I remember back when Gutenberg was still in beta, we were talking a lot about what the block editor would mean for the future of WordPress.

Would blocks be distributed in themes, or in plugins? What would Gutenberg look like if it were combined with the Customiser? Should widgets be blocks (and if so, what about the header logo, or copyright colophon)?

This week we started to get some early rumblings of answers to these questions. Riad Benguella created a Pull Request to the Gutenberg GitHub repo, proposing an experiment for completely block based themes.

It described something very important! The future of themes in WordPress! Unfortunately, it was published on GitHub, and to read it, you needed to view the changeset and parse the markdown. Of course, the WP community doesn’t read every new PR that comes through the Gutenberg repo – so this could have easily flew under the radar.

But we got lucky – it caught the attention of Justin Tadlock over on WP Tavern, which drew some attention to the PR.

This Pull Request has been met with a considerable degree of concern. I wanted to take the time to write about this from the perspective of:

  1. What does this experiment look like?
  2. Why is there resistance to the idea?
  3. Where do we go from here?

What does this experiment look like?

Sorry Riad! I think a large part of the problem here is that this first documentation on block based themes is actually quite difficult to understand. I spoke to a few different people who couldn’t quite wrap their head around it.

Here’s my interpretation:

Let’s start by imagining that blocks could be used as widgets. You could add, say, a Quote block to any one of your widget areas.

Actually, you don’t have to imagine this – just activate the Gutenberg plugin and enable Widgets under Gutenberg > Experiments.

Okay, makes sense so far. Now imagine replacing your footer with a widget area. Chances are, your footer already contains one, so this shouldn’t be too hard. But instead of a © section at the bottom, imagine this is a paragraph block instead, and there’s an interface in the WP Admin to change the text displayed here.

Now, did you know that in the latest version of Gutenberg there’s a “Navigation” block? This is what it looks like:

So, now we could easily replace the navigation in our header with a widget area, and insert the Navigation block. While we’re there, we could insert our logo as an image block, and align it to the left.

At this point, the name “Widget Area” isn’t such a great fit. Let’s call it a “Template Part” instead. We’ll have Template Parts like Header, Footer, and Sidebar.

Hey, now that we’re thinking about it, don’t forget that WordPress 5.3 introduced Group blocks. We could use these to do something pretty cool…

Start with a completely blank page. Nothing on it – no header, no sidebar, nothing. We could add a group block to the top, and make that our Header Template Part. Then below that we could add another Group Block, and expect the Post Title and Post Content to be added there. Maybe another Group Block next, and put Comments in that. Let’s finish off with a Group block for the Sidebar Template Part, and then a Footer Group.

We’ll call it “single”. It will be structured something like…

  • Group block
    • Header Template Part
      • “Logo” image block
      • Navigation block
  • Group block
    • Post Title block
    • Post Content block
  • Group block
    • Comments block
  • Group block
    • Sidebar Template Part
      • Search block
      • Categories block
  • Group block
    • Footer Template Part
      • “Copyright” paragraph block

(Notice our Template Parts are kind of like reusable block groups.)

This is called a Block Template. We could create it in some sort of Template Editor in the WP-Admin, and export it to be used as a theme.

So themes would be responsible for three things:


This includes the structure of how the Template Parts fit together visually, as well as styles for all blocks (they might even be styled differently in different Template Parts).

Block Templates

Not dissimilar to current theme templates, and maintaining adherence to the Template Hierarchy, these describe the overall structure of the page, in the language of blocks (especially Group blocks) and Template Parts.

Template Parts

The theme should probably add some default blocks: a logo and navigation to the header, and a paragraph with copyright text to the footer. Even though these blocks could be easily changed and removed by the user, the theme should include a starting point. These defaults belong in a Template Part, and the Template Part is included inside a Block Template.

Hopefully that makes things a little clearer! For those of us who have been using traditional WordPress templating for the past decade or more, this is quite a tough change to wrap your head around. 💫😵💫

Why is there resistance to the idea?

Aah… politics. Unsurprisingly, there’s some #wpdrama going down because of this proposal. Some of it is based on simple misunderstanding (a.k.a. poor communication), but there’s more to it than that.

The subtext here is that Riad works for Automattic. I won’t dive into the history of WordPress and Automattic, suffice to say that their CEO leads the WordPress project¹, and as such, there is a constant concern from the community when Automattic approaches conflict-of-interest boundaries.

So, when an Automattician makes a giant proposal on the future of theming in WordPress, which gets merged into the Gutenberg project the very next day², I think it’s very reasonable that people are concerned.

Here’s a timeline of how it went down³:

September 5: Automattician Matías Ventura publishes a Make WordPress post describing full site editing with blocks. It’s met with a lot of positivity, but doesn’t include much detail on technical implementation.

September 23: Google employee Felix Arntz created an Issue in the Gutenberg Github repo describing Matías’ post. The 15 comments on that issue (before the PR on December 4) were all made by Automattic or Google employees.

December 4: Automattician Riad Benguella creates a PR for documenting the experiment. There is some early concern from Joy Reynolds (a well-known WordPress core contributor), but there’s no time to discuss it further, because…

December 5: Automattician Enrique Piqueras approves the PR just 24 hours later!

December 5: Riad merges the PR (the day after it’s proposed).

Notice a pattern?

The people with power all work for Automattic and Google.

It seems fairly clear to me why there is so much resistance to the idea. I believe it’s because:

  1. The experiment was poorly explained, and widely misunderstood.
  2. There wasn’t any opportunity to understand the technical implementation.
  3. There wasn’t any opportunity to discuss it either.
  4. The whole project is being rushed through by Automattic (with some help from Google).
  5. Feedback / concern is being brushed aside or hand-waved away, instead of properly discussed.

December 5: Hours after this PR is approved, Derek Hermann chimes in. Derek has been contributing to WordPress for years. Over that time he was a feature lead on the Customiser, worked with me to build Tide, and has been very active in Gutenberg’s development. He’s also the CTO of XWP (one of the largest WordPress VIP agencies in the world).

Derek has some real concerns, and lots of questions, which Matías tries his best to answer (although to be honest, Matías’ answers left me even more confused). Derek’s Github comments get lots of 👍 and ❤️ support. Even so, nothing changes.

Derek’s most important question is this one:

You have to research what the users want, not what the team wants to build. Where is your research?

Which brings me to…

Where do we go from here?

Alright, now we start to get into the territory of my opinion. Of course, you’re entitled to agree or disagree – take it up with me on Twitter if you like.

So, in my opinion, the entire experiment should be reverted.

The perception is that Automattic is working on Block Template themes in the shadows. Why? Do they see themselves as pioneering a future that we don’t yet know we need?

The rest of us need to be looped in to the decision making process.

Reword the document in this PR as a proposal, and post it on Make WordPress for feedback. The first Make WordPress post from Matías contained very few technical details.

Allow time for discussion! Put it on the agenda for the Editor Chats that happen every week.

Help the community to understand what this looks like – because clearly nobody does right now.

Most importantly, research how Users, Agencies, and Theme Designers want to engage with themes in WordPress. Make a decision based on that research, not based on a handful developers best guesses at how a block based themes should be implemented technically.

Merely asking for feedback is just not good enough. If nobody responds, that doesn’t mean you get to decide for yourself. That’s not how research works.

Maybe a developer tool isn’t the best place to ask for feedback on the future of WordPress. We can’t expect our community to learn GitHub, and follow the discussions happening across nearly 20,000 issues.

Maybe, if we facilitate a friendly, open, and wide-reaching dialog, we might arrive at different conclusions.

Important note: Nobody involved here is being intentionally malicious or hostile. I believe we have a problem with structure and power dynamics, which is what I’m trying to call attention to (not the individual developers).

I reached out to Matías and Riad and get their feedback before publishing this article.

Riad also offered these thoughts:

The reality is that I’d love more contributors that are non-Automatticians, but the reality is that a big part of WordPress contributors today are Automatticians. If you’d like to join our team and work with us to improve the proposal or change it you’re welcome.

There’s no shadow here . This was discussed for more than a year now in different Github issues by different people and regularly on #core-editor weekly meetings (which I invite you to join to discuss the proposal and help).

In chatting with Matías, he noted that the proposal for block templates has been discussed for a really long time in multiple places — there are GitHub issues from all the way back to 2017.

1. Matt Mullenweg, CEO of Automattic and co-founder of WordPress, is known as the “Benevolent Dictator for Life” of the WordPress project.

2. Actually, the experiment itself was merged a while ago – what we’re talking about here is only the documentation about the experiment. To be aware that any of this was happening, you’d have to be following along on GitHub.

The reason this PR was noticed was because the part that got merged was Documentation – thankfully a bit easier to understand than trying to string together multiple conversations between PRs, issues, and code. Even as it was, though, this could have easily gone under the radar if it weren’t for Justin picking it up on the Tavern.

3. There was also a call for feedback published on the Make WordPress blog, on November 3. I didn’t include it in the timeline because block based themes are just one line item among many – easily lost on a Make post that seems to have gone mostly unnoticed.