WildPress Blog

What a Developer Needs to Work on Your Website (and What All the Jargon Means)

Wed, 15 Jul 2026 00:00:00 GMT

If you have ever been asked for your “hosting login” or your “DNS” and had no idea what that meant, this guide is for you. A website is not one single thing. It is a few separate parts that work together, and they are often bought from different companies. When something breaks, or when you bring in a developer, knowing which part is which saves a lot of time.

I will explain each part, what it does, and why a developer needs access to it. No prior knowledge needed.

The quick version: a website is like a shop

It helps to picture a physical shop.

Your domain name is the address on the sign above the door.
Your domain registrar is the company that sold you that address.
DNS and name servers are the signposts that tell people which building the address actually points to.
Your hosting is the building itself, where all your stock and fittings are kept.
WordPress is the shopfit and the till inside, the system you use to run the place.

You can own the sign but rent the building from someone else. You can even keep the sign and move to a new building. That is exactly how websites work, and it is why these parts are separate.

Your domain name

Your domain name is your address on the internet, like yourbusiness.co.uk. It is what people type to reach you, and it is what your email address is built on.

The important thing to understand is that a domain name is not your website. It is just the address. The website, the actual pages and content, lives somewhere else entirely (the hosting, which we will come to).

The domain name registrar

The registrar is the company you bought your domain name from. Common ones are GoDaddy, Namecheap, 123 Reg, and Cloudflare.

Access to the registrar is the most powerful access there is, because it controls where your domain points. With it, you can send your domain to any hosting in the world. This is the ultimate safety net: as long as you control the registrar, you can always move your website away from a host that is slow, broken, or difficult.

If you only keep control of one thing, keep control of your registrar account.

If you have not bought a domain yet, my own favourite registrar is Porkbun. The pricing is fair, the interface is clean, and it does not bury you in upsells the way some of the bigger names do.

DNS and name servers

This is the part that confuses almost everyone, so here is the simple version.

DNS stands for Domain Name System. It is the internet’s address book. When someone types your domain, DNS is what looks up the answer to “which server should I actually send this person to?” and points them to the right place.

Name servers are the specific address books in charge of your domain. Your registrar settings say something like “the name servers for this domain are the ones at Cloudflare”, and from then on Cloudflare holds your DNS records. Changing your name servers is like telling the post office which directory to use for your address.

You do not need to understand the detail. You just need to know that DNS is the layer that connects your domain name to your hosting, and a developer will sometimes need to change a DNS record to fix email, point the site at a new server, or verify ownership.

Website hosting

Your hosting is the computer, called a server, where your website’s files and database actually live. When someone visits your site, the hosting is what sends the pages back to them.

Hosting is usually a monthly or yearly subscription with a company such as SiteGround, Kinsta, GoDaddy, or a smaller web company that set your site up. This is a different account from your registrar, even if you happen to have bought both from the same company.

Hosting access matters more than people expect. WordPress admin lets a developer work on the site from the inside, but hosting or control-panel access lets them work underneath it, at the server level. Some problems cannot be fixed from inside WordPress at all. If a bad update takes the whole site offline, a developer often cannot even log in to WordPress to undo it, but with hosting access they can go in from the ground up and sort it.

If you are choosing hosting yourself, two I like: Cloudways for managed WordPress hosting that stays fast without much fuss, and Bunny.net for fast, affordable content delivery. The Cloudways link is a referral, so it gives me a small credit at no extra cost to you.

WordPress

WordPress is the software your website is built with. It runs on your hosting and gives you the dashboard where you edit pages, write posts, and manage the site. Around 4 in 10 websites use it.

It is worth knowing that “WordPress” actually means two different things, and this trips people up.

WordPress.org versus WordPress.com

WordPress.org is the free, open-source software. You install it on hosting you control, and you can add any plugin, edit any code, and move it wherever you like. This is what most businesses use, and what a developer normally works on.

WordPress.com is a paid hosting service run by a company called Automattic. It hosts a managed version of the same software for you. It is simpler to start with, but it limits which plugins and code you can use on cheaper plans, and your site lives on their platform rather than hosting you fully control.

The short rule: if you pay a hosting company and can install any plugin you like, you are on WordPress.org. If your site is managed at wordpress.com and you log in there, you are on WordPress.com. If you are not sure, that is fine, a developer can tell in a minute.

For what it is worth, I work with WordPress.org sites, not WordPress.com. I do not manage WordPress.com sites as a service. If you are on WordPress.com and feel boxed in by it, I can migrate you to a self-hosted WordPress.org site that you fully control.

How it all connects

Put simply, here is what happens when someone visits your site:

They type your domain name.
DNS looks up where that domain points, using your name servers.
It sends the visitor to your hosting.
Your hosting runs WordPress, which builds the page and sends it back.

flowchart TD
    A[/"Visitor types your domain name"/] --> B["DNS looks up where it points, using your name servers"]
    B --> C[("Hosting: where the site lives")]
    C --> D["WordPress builds the page"]
    D --> E[\"Page shown to the visitor"\]

    classDef io fill:#0b3b2e,stroke:#34d399,stroke-width:1.5px,color:#d1fae5;
    classDef process fill:#172334,stroke:#3f4a5f,color:#e2e8f0;
    classDef store fill:#1e2a4a,stroke:#818cf8,color:#e0e7ff;
    class A,E io;
    class B,D process;
    class C store;

Four separate parts, often four separate logins. That is why “I can’t get into my website” can mean very different things, and why the first job in any emergency is working out which part is actually the problem.

What a developer needs to work on your site

With all that in mind, here is what usually helps a developer get started quickly:

WordPress admin login so they can work on the site itself.
Hosting or control-panel access so they can work at the server level, which is essential when the site is fully down.
Domain registrar or DNS access when the problem involves email, moving hosting, or where the domain points.

You do not have to hand over passwords by email. You can share them securely, and many hosting providers let you invite someone to your account instead, so a developer may not need your login details at all. If you are not sure where any of this is, that is normal, and a good developer will happily walk you through finding it on a screen share.

A short checklist to have ready

Who is your domain registrar (where you bought the domain), and can you log in?
Who is your hosting provider, and can you log in?
Can you log in to your WordPress dashboard?
Do you know whether you are on WordPress.org or WordPress.com?

If you can answer even some of these, you are in good shape. If you cannot, do not worry. Working it out is part of the job.

If your site is down or broken right now and this all feels overwhelming, that is exactly the kind of thing I sort out. See emergency WordPress support, and I will guide you through the access side as we go.

Update and Manage Your Website by Just Asking an AI

Tue, 14 Jul 2026 00:00:00 GMT

Here’s a promise that sounds too good: you can update and manage your website by asking for the change in plain words. Add next Thursday’s event. Put the summer offer on the home page. Change the opening hours. No logging into an editor, no hunting for the right field, no wrestling with a page builder. You describe what you want, and it’s done.

That’s real, and I set it up for the sites I build. But it comes with a big condition, so let me start there rather than oversell it.

AI is a tool, not a replacement

I treat AI as a tool that multiplies what you can already do, two or three times over, not something that does the job for you. You still bring the judgement. It brings the speed.

That distinction matters most when people try to hand a website over to an AI to run on its own. Left to manage things autonomously, without the right setup around it, it goes wrong. The writing stops sounding like you. It reads as generic, a bit off, not quite authentic, and people can tell. Your website is your voice, and an AI running loose doesn’t have it.

So the value isn’t “the robot does it all”. It’s that, used properly and pointed in the right direction, an AI takes the friction out of the everyday work while you stay in charge of what actually gets said. Getting it pointed in the right direction is the part that takes some know-how, and that setup has a name: a harness.

Why you can’t just let an AI loose on your site

Normally you update a website by opening an editor and doing the work yourself: logging in, finding the page, filling in fields, saving. It’s fine, and for a lot of changes it’s quick enough. But you’re still the one doing the fiddly part.

Handing that to an AI sounds obvious. The catch is that a general AI let loose on your website is a liability. It doesn’t know your brand, it doesn’t know your writing style, and it doesn’t know the first thing about how your particular site is built. Point it at a page, tell it to change something, and it will most likely break the layout or get stuck, because every website is put together in its own way. Two sites can run on the same underlying technology and still be nothing alike underneath, so an AI that hasn’t checked any of that first is only making assumptions, and it will make them with complete confidence. You wouldn’t hand a stranger the keys and tell them to get on with it.

That gap is what a harness closes.

What a harness is

A harness is the setup I build around the AI so it can work on your particular site safely. The word comes from harnessing something powerful and pointing it in the right direction.

Think of the difference between a brand new temp and a well-briefed assistant. The temp is capable but knows nothing about you. The briefed assistant has read your brand guidelines, knows how your site is laid out, has the keys to the right rooms and only those, and has a checklist of what good looks like.

The harness gives the AI four things:

Your voice, so changes sound like you, not like generic AI copy.
Your structure, so a new event or a new landing page goes in the right place, in the right shape.
The right tools, so it makes the actual change to the site rather than handing you text to copy and paste.
Guardrails, so it stays inside what it’s allowed to touch, and changes are checked before they go live.

Put together, that turns a clever but clueless AI into something that genuinely knows your website.

Why AI recommends the fashionable option, not the right one

Here’s something people don’t realise. An AI has been trained on more or less every website ever put online, which means it knows every way there is to build one. That sounds like a strength, and it is, but it also means that if you’re vague, it just reaches for whatever was most fashionable in the data it learned from.

I see this a lot. Someone comes to me with a plan for their new site, and it reads like a top-ten list of the trendiest tools of the moment. I ask why those, and the answer is almost always “that’s what the AI recommended”.

But the AI didn’t recommend it in any considered sense. Underneath, it isn’t really thinking. It’s predicting the next word that tends to follow, based on everything it read. Ask it a vague question and you get the popular answer, not the right one. Ask it a sharp question, such as which option is the most stable, or which will run on my own server, or which handles this particular situation, and you get something far closer to what you actually need.

The snag is that you have to know enough to ask the sharp question. It’s like walking into a doctor and saying “I feel ill”. Until you can be specific, the best they can do is guess. They can’t read your mind. And if you don’t know what’s wrong, that’s exactly when you want an expert to make the diagnosis for you.

That’s a lot of what I do. I know the options, the trade-offs, and where each one bites. If you want the shorter version of one of those trade-offs, I’ve written about two common choices in WordPress or Astro: the scribe or the printing press. Nothing is perfect. The job is finding the best fit for you, then telling the AI to stick to it.

A harness in action: keeping AI on the current version

Structure helps enormously here. On a built-ahead site like Astro, the content and the templates are clear and predictable, so the AI can see exactly where a change belongs, make it cleanly, and the site rebuilds the same way every time. Predictable structure is exactly what an AI needs to work reliably.

Astro is the tool I use for a lot of static sites, and one of the first things I do when building on it is create a harness specific to Astro. For example, I point the AI at the current Astro documentation for the exact version we’re running, so it works from up-to-date best practices rather than from memory.

Without that, it would still make a decent go of it, but because it learned from years of web content, it might reach for an older version of Astro, miss newer features, or mix up commands that changed between versions. It would run, but it wouldn’t be right. Newer versions bring real speed improvements, and if the AI is going from memory instead of checking the current docs, it quietly leaves those on the table. A small thing that makes a big difference, and just one harness example among many.

Why it’s easier than editing the site yourself

Editing through a content management system is really filling in a form. You translate what you want into the right fields, one by one. It works, but you’re the one doing the translating.

With a harnessed AI, you describe the outcome and it handles the how. “Add an event on the 12th, doors at seven, tickets twenty pounds” becomes a properly formatted event, in the right place, in your house style. You talk to it the way you’d brief a secretary or a contractor, plainly, in your own words, and with a good harness it picks it up quickly and gets it right. It will even flag things you’ve missed and suggest additions.

What about the cost?

You can use plenty of AI tools for free. But the ones doing real work on your behalf, actually operating the tools that change your site, are worth paying a little for. A more capable, current model understands what you’re after and gets it done, rather than leaving you fighting a weaker one that keeps missing the point.

For most people that is a modest monthly subscription, the sort of thing that runs around twenty pounds a month. It is fair to ask whether you get that back, especially if you barely touch your site today. The honest answer is that the value isn’t in the number of edits, it’s in how little friction there is to make them. You stop having to remember how to do things or type out long instructions. You just say what you want. For a lot of businesses, that is the difference between a site that quietly goes stale and one that stays current.

If you’re comfortable with the tools, you can run an AI you manage entirely yourself, kept in line by a strict harness. If you’re not, a cheap subscription to a capable one is the sensible place to start.

What AI won’t do for you

Worth being straight about the edges, beyond the tool-not-a-replacement point already made.

It won’t invent a brand new look for you. Fresh page designs and layout work still need a human. This is for the steady stream of everyday updates: events, offers, prices, copy, and new pages that fit the design you already have.

And it’s not the generic chatbot stuck in the corner of other websites. It’s a setup made for your site and your business specifically, with a person kept in the loop so changes are checked before they go live.

The upshot: a website you can talk to

Used the right way, an AI turns your website from a chore you log in and fight with into something you can just talk to. You ask for a change in the same words you’d use with a member of staff, and it happens. You stay in charge of the voice and the decisions. The tool takes care of the fiddly parts.

That’s how I’d rather my clients worked. You own the site, it’s built properly, and keeping it current is as easy as sending a message.

Want this on your site?

Want a website you can update just by asking?

I build this into the sites I make. Tell me about your project and I'll show you how updating it could work for you and your team.

Talk to me about your project See Astro development

WordPress or Astro: The Scribe or the Printing Press

Tue, 14 Jul 2026 00:00:00 GMT

When you’re having a website built, you’ve usually been recommended something to build it with by a friend, or by someone you trust. Or sometimes you’ve just seen lots of adverts on the Tube. The name that comes up most is WordPress, and often it’s the right one, in part because it’s open and you end up owning what you’ve paid for. That’s why I build on open platforms rather than Wix, Squarespace, or Shopify.

It isn’t the only one, though, and there are alternatives that might suit you better. The one I reach for most is Astro, and most people haven’t heard of it.

So this is what’s different between the two, and why you might want Astro instead. It’s not a small difference. It decides how fast your site is, what it costs to run, and how easily you can change it later.

Printed once, or copied out for every reader

Think of your website as a book, and every visitor as someone who wants to read it.

There are two ways to get it to them.

One is a scribe. Every time someone asks for the book, the whole thing gets copied out by hand, first page to last, while the reader waits at the counter. Every copy is made to order. But you’re paying a scribe to sit there all day, and nobody reads a word until the copying is finished.

The other is to print it. You set the type once and do that job properly, with all the care and equipment it takes. After that, anyone can take a copy off the shelf and walk out with it the moment they ask. Same book, same words.

The printed copy isn’t the lesser one. It’s your book, all of it, set exactly how you wanted it, not a summary and not someone else’s book with your name on the cover. You’re not getting a template. All that changes is that the work was done once and kept, instead of repeated from scratch for every single reader.

Websites work these same two ways. You could say this is the difference between WordPress and Astro.

A WordPress site is the scribe. Every time someone visits a page, it writes that page out again from the top, and it needs the whole setup running the entire time to do it. The industry word for this is dynamic.

A site built with a tool like Astro is the printed book. Every page is made once, ahead of time, then handed straight over with almost nothing running behind it. The word for this is static.

That’s the whole idea. Everything else follows from it.

You can see the difference in how many steps each one goes through when someone opens a page:

flowchart LR
    subgraph DYN["WordPress: built on every visit"]
        direction TB
        A[/"Visitor opens the page"/] --> B["The site starts building it"]
        B --> C["Finds your content"]
        C --> DB[("Your content")]
        DB --> E["Puts the whole page together"]
        E --> F[\"Sends the finished page"\]
    end
    subgraph STAT["Astro: built ahead of time"]
        direction TB
        G["Pages built in advance"] -.-> I[\"Sends the ready-made page"\]
        H[/"Visitor opens the page"/] --> I
    end

    classDef io fill:#0b3b2e,stroke:#34d399,stroke-width:1.5px,color:#d1fae5;
    classDef process fill:#172334,stroke:#3f4a5f,color:#e2e8f0;
    classDef store fill:#1e2a4a,stroke:#818cf8,color:#e0e7ff;
    classDef prebuilt fill:#0f2019,stroke:#34d399,stroke-dasharray:4 3,color:#a7f3d0;

    class A,H,F,I io;
    class B,C,E process;
    class DB store;
    class G prebuilt;

What that means for you

Because a static site is already built, it loads faster. There’s nothing to put together, the page is simply there. A well-built static site is about as quick as a website gets.

It’s also cheaper to run and safer. A WordPress site needs a fair amount of machinery running behind it all the time to do that build-on-every-visit work, and that machinery has to be kept updated and protected, and the upkeep never stops. A static site has almost none of that. Hosting can cost a few pounds a month, and there’s very little that can break or be broken into.

The trade-off is that sometimes you really do want the scribe. More on that in a moment.

Same look, different delivery

Worth being clear about one thing: this is a choice about how the site is built, not how it looks. The same design works either way, so your visitors get the same pages and the same look.

What they do notice is speed, because the static one arrives faster. Behind the scenes the two are quite different, even when the end result on the screen is the same.

So why not always static?

This is where the printing analogy gets a bit thin, so let me be straight about it.

Plenty of websites have parts that need to actually do something: take a payment, sell a ticket, handle a contact form, show a live calendar. Those bits need a little machinery behind them, and a printed book can’t do that on its own.

Most of the time, though, you don’t build that machinery yourself. You use a trusted service that specialises in it, something like Stripe for payments or a dedicated ticketing platform, and it slots neatly into a static site. Better still, it handles the sensitive parts, card details and personal information, so that data stays off your own site and out of your hands. A fast static site can still sell, take bookings, and handle enquiries perfectly well.

Where a static site starts to strain is when the whole experience is personal. If people log into an account and every page changes depending on who they are, their orders, their preferences, their own data, then every reader really does need a different book, and that’s genuine scribe territory. A membership site or a full online shop is the usual example: alongside the ordinary marketing pages, there’s a personalised layer that has to respond to each customer. That’s where a dynamic platform like WordPress is the right tool.

Even then, WordPress isn’t automatically the right answer for the most app-like projects. That’s a call to make job by job, and one I’m happy to make with you rather than defaulting to a favourite.

Can I still update the website myself?

This is the question I get asked most, so here’s the straight answer: yes, either way.

With WordPress you log in and edit through a built-in editor, and different people can be given different levels of access. If you want a full drag-and-drop experience, where you change the page and see the result exactly as it will look, there are page builders like Elementor for that too. You can update your content and add new pages yourself.

A site built with Astro doesn’t come with a visual editor of its own. Left as it is, you’d edit the page’s text files directly. They’re written in markdown, which is just plain text with a few simple formatting symbols, and it’s friendlier than it sounds, but it’s still not something most business owners want to be doing. So we pair the site with a content management system: a place to log in and edit your content by filling in fields, much like filling in a form. It doesn’t give you the exact live preview a WordPress page builder does, and there’s a small learning curve to see which field controls what, but if you can fill in a form, you can update your site.

For the everyday updates, a bit of text, a price, a photo, a new event, both are easy once it’s set up. The one thing that always takes a little skill is a brand new page with a new layout, whichever way the site is built, and that’s normally a quick job for me rather than something you’d want to wrestle with yourself.

There’s also a newer way I’m increasingly using, where you update the site just by asking a custom AI assistant, in your own words, with no fields to fill in at all. It works especially well with this kind of setup. I’ve written about how it works in update your website by just asking an AI.

Which one is right for you?

Roughly:

A static site suits most small business sites: brochure sites, hotels, restaurants, portfolios, anything that’s mainly there to inform, where speed and low running costs matter and updates are occasional.
WordPress suits sites with more going on behind the scenes: shops with complex needs, membership or account areas, or a big team editing every day.

Plenty of sites sit in between, where you get the speed of a static site with an easy way to edit it. That’s often the best of both.

The right answer depends on what your site actually needs to do. I pick the one that fits, and either way you own the site outright, with no platform holding the keys.

Planning a website?

Not sure whether Astro is right for your project?

If you're weighing up how to build or rebuild your site, I'm happy to talk it through and point you to the right approach for what you actually need.

Talk to me about your project See Astro development

Migrating from WordPress to Astro: What to Think About Before You Start

Thu, 09 Jul 2026 00:00:00 GMT

I build and maintain WordPress sites for a living, and I also move sites off WordPress onto Astro. That puts me in an odd position for this article: I have no interest in convincing you WordPress is bad. For a lot of businesses it’s still the right tool.

But if there’s no team of editors behind your site, it barely changes once it’s live, and you can’t justify the hosting and maintenance overhead for the couple of hours of updates you actually make, Astro is worth understanding. Here’s what a migration actually involves, and the decisions you’ll need to make before anyone writes code.

How Astro is different

WordPress builds your pages when someone asks for them. A visitor requests a page, PHP runs, the database is queried, and HTML comes back. Caching plugins exist to avoid doing that work on every request, which tells you something about the model.

Astro is a static site generator. It builds every page once, ahead of time, and the result is plain HTML files served from a CDN. There’s no server-side language running, no database, and by default no JavaScript sent to the browser at all. Interactive parts, like a search box or a booking widget, are added as isolated components only where you need them. Astro calls these islands.

Side by side, the two models look like this:

flowchart TB
subgraph wpp["WordPress: when you publish"]
direction TB
E1[/"You edit in wp-admin"/] --> S1[("Saved to the database")]
end
subgraph wpv["WordPress: when someone visits"]
direction TB
V1[/"Visitor requests a page"/] --> P["PHP runs"] --> DB[("Database queried")] --> T["Theme and plugins assemble HTML"] --> C1["Caching layer softens the repeat work"] --> R1[\"Page delivered"\]
end
S1 ~~~ V1
classDef io fill:#0b3b2e,stroke:#34d399,stroke-width:1.5px,color:#d1fae5;
classDef process fill:#172334,stroke:#3f4a5f,color:#e2e8f0;
classDef store fill:#1e2a4a,stroke:#818cf8,color:#e0e7ff;
class E1,V1,R1 io;
class P,T,C1 process;
class S1,DB store;

flowchart TB
subgraph asp["Astro: when you publish"]
direction TB
F[/"You edit content files in git"/] --> B["Build runs once"] --> H["Static HTML and assets"] --> U[\"Uploaded to the CDN"\]
end
subgraph asv["Astro: when someone visits"]
direction TB
V2[/"Visitor requests a page"/] --> CDN["CDN serves the ready-made file"] --> R2[\"Page delivered"\]
end
U ~~~ V2
classDef io fill:#0b3b2e,stroke:#34d399,stroke-width:1.5px,color:#d1fae5;
classDef process fill:#172334,stroke:#3f4a5f,color:#e2e8f0;
class F,U,V2,R2 io;
class B,H,CDN process;

The practical consequences are what matter. Pages are fast without a caching layer. There’s no admin login to attack and no plugin updates to run, so the security and maintenance story shrinks to almost nothing. Hosting becomes cheap, often a few pounds a month on a CDN.

What about the dynamic parts?

The trade-off: anything that changes per visitor, like a cart, a members’ area, or live availability, needs deliberate work rather than a plugin install. To be fair, that’s no harder in Astro than in any headless or API-driven setup. An island can be a React component talking to a third-party API, loaded only on the page that needs it, and something like a small ticketing widget works fine that way. Session management gets trickier, but it’s not impossible.

It’s a question of proportion. A couple of dynamic components on a content site is comfortable Astro territory. If you’re building something app-like, a dashboard, say, where most of the site is logged-in and interactive, you’re better off in Next.js or React from the start.

Most sites are less dynamic than they look

In practice, most small business sites have less of that than you’d think. Look at what’s actually interactive on the page and it’s usually the contact form. The rest of what feels dynamic, animations, a clever menu, is visual. There’s no data behind it.

Even the serious integrations rarely live in WordPress. Clients don’t run their CRM in WordPress, they use something like HubSpot or Salesforce, and the connection is an embedded snippet, an iframe, or at most a plugin that authenticates with the service. Those embeds work exactly the same on a static site.

Be honest about how often your site actually changes

WordPress earns its overhead when its machinery gets used: multiple editors, frequent publishing, a visual editing experience for people updating content every day. That’s what it’s built for.

Here’s what I actually see. I deliver a WordPress site, provide training, and for most clients the day-to-day reality is updating a bit of content on a page or publishing a blog post every now and then. Most small businesses aren’t publishing daily with a team of editors. Once the site is live, not much changes except the blog and the odd landing page.

The machinery keeps costing you either way. Plugin updates, security patches, user accounts, a database, hosting that can run PHP. It all needs looking after whether you edited the site this month or not.

And yes, WordPress is free and cheap hosting exists, so you can get a site up for almost nothing. But that route usually means an off-the-shelf theme, a page builder like Elementor, and a stack of plugins, and the bloat that comes with all of it. The site is slow, and the work to keep it updated and maintained never goes away.

That’s the calculation that has shifted for me. A couple of hours of edits every few months doesn’t justify a platform that needs care every week.

Astro is not the same as going headless

These two get muddled together, and they’re different decisions.

A headless setup keeps a CMS running as a content API, often WordPress itself, and puts a JavaScript front end in front of it, usually React through something like Next.js. You still have the CMS to host, secure, and update. You’ve also added a front-end application on top.

You can pay a cloud platform like Sanity or Contentful to run the CMS for you, and they’ll maintain it well. But it’s still a service that has to be online and available for your site to work, with a monthly bill attached. More overhead, more cost, and more cogs to think about.

The thing to notice is that headless WordPress doesn’t change the editing experience at all. You still log into the same admin and update pages the same way as on a normal install. So if your team barely edits the site, going headless gives you nothing: you’ve kept all the WordPress overhead and added a second system in front of it. It suits large editorial teams who live in the WordPress admin and need it to stay exactly as it is.

Astro’s default model is simpler. Your content lives in files in the same repository as the site, the build turns them into pages, and there’s nothing running in production except a CDN. For a marketing site, a portfolio, or a content site with a small team, that simplicity is the point.

You can use Astro headlessly against WordPress if there’s a genuine reason to keep the admin. It’s just not where I’d start for most small businesses.

Decide how you’ll edit content before anything else

This is the decision that shapes the whole project, and it’s the one people leave until last.

In WordPress, editing is built in. In Astro, editing is a choice. Content lives in markdown and data files, and the question is how non-developers change it. The options range from editing files directly, to Git-based CMS tools like Pages CMS or Keystatic that give you a friendly editing screen on top of the same files, to API-first platforms with monthly fees.

I’ve written up the options properly in Choosing a CMS for an Astro Website. The short version: for most small teams a Git-based CMS is the sweet spot. No subscription, no separate database, and your content stays in files you own. On WestEnd.com the team manages 50 or so shows and 40 venues through Pages CMS without touching code, and without a CMS bill.

Files beat a database for a small site

For a small site, content in files beats content in a database in ways you feel every month. Every change is version controlled, so you can see what changed, when, and roll it back. There’s no database to back up or fall out of sync. And the whole site, content included, moves between machines with a git clone.

If your editors need scheduled publishing, complex workflows, or dozens of concurrent users, that’s when the paid platforms earn a look.

Getting your content out of WordPress

How hard this is depends entirely on how your content was put in.

Clean WordPress content, posts and pages written in the block editor or classic editor, comes out well through the REST API or an XML export. A migration script can pull titles, body content, dates, categories, and featured images into markdown files fairly directly.

Page-builder content is the trap. Elementor, Avada, WPBakery, and Divi store your copy inside their own shortcodes and blocks, so what the API returns is builder markup, not your actual words. When we migrated WestEnd.com off Avada, we had to scrape the rendered pages to recover the real text. Budget for this if your site was built with a page builder, and treat it as a chance to clean up as you go.

If you have access to the hosting, WP-CLI makes this much easier. It can take full backups, export the database, and run queries directly against the content, which is often quicker than going through the API. You can supercharge the extraction further by having an AI tool write and run the migration scripts with you. Be careful with that, though: work from a cloned backup rather than the live site, and keep an eye on what it’s doing so it doesn’t go off the rails.

The media library needs its own plan. You’ll want the images your content actually uses, moved into the repository or object storage, with URLs rewritten. It’s mechanical work, but skipping it leaves you hotlinking a WordPress install you’re trying to switch off.

Mapping custom post types to content collections

If your site uses custom post types, this part is genuinely satisfying.

In WordPress, everything lives in the database. Custom post types all follow the same storage format, and even copy that never changes gets pulled from the database on every page, because you’d never hardcode it into the theme. For a content site, that’s a whole layer you’re forced to think about without getting much back from it.

Astro’s answer is files. Content collections: folders of content with a schema that defines what fields each entry must have. A WordPress custom post type maps onto a collection almost one to one. Your ACF fields become frontmatter fields, your taxonomies become properties you can filter on, and the schema is checked at build time. If an entry is missing a required field, the build fails and tells you, rather than the page quietly rendering wrong.

On WestEnd.com, shows and venues became two collections. A show is a record with ticketing details, a venue reference, cast, and images. Templates render the records. Compared with a custom post type held together by ACF and template parts, it’s the same idea with the guesswork removed.

The mapping exercise is worth doing on paper before the build: list your post types, their fields, and their relationships, and sketch the collections they’ll become. It usually takes an afternoon and it surfaces every awkward decision early.

The things WordPress gives you that you’ll have to replace

A stock WordPress install with a decent SEO plugin quietly does a lot. None of it is hard to replicate in Astro, but every piece is a deliberate choice rather than a default, and a migration checklist should name them all.

The usual list looks like this:

Metadata and schema. Yoast or Rank Math handled titles, descriptions, Open Graph tags, and structured data. In Astro these come from your layouts and frontmatter, which means they end up more consistent, but someone has to build them.
XML sitemap. The official @astrojs/sitemap integration generates one at build time.
Redirects. Every URL that changes needs a 301, and old URLs search engines know about need mapping to new routes. This is the single biggest factor in whether you keep your rankings, and it deserves a spreadsheet, not an afterthought. There’s a catch on a static site too: there’s no Apache layer processing redirect rules any more. Astro can define redirects, but it handles them by loading a page that then forwards you on, which isn’t a clean 301. The better place is the host, on bunny.net that’s an edge rule, and every host does this slightly differently.
RSS feeds. There’s an official Astro package if your readers use them.
Forms. WordPress form plugins post to the database. A static site needs a form endpoint, either a small serverless function or a service. The same applies to search, which becomes either a build-time index or a hosted service.
Comments. I’d be surprised if you actually use WordPress comments. The only time I see them on a site is when nobody turned them off, and then they’re full of spam. If discussion genuinely matters to you, build it properly with a forum as a fully fledged part of the website rather than a comments box under each post.

The tooling is smaller than you’re used to, on purpose

The WordPress instinct is to reach for a plugin. Astro has integrations, but the honest answer is you need far fewer of them, because the platform isn’t fighting you. Astro has its own way of doing things, but it’s intuitive to pick up, and ideas like content collections are built into how it expects you to work rather than bolted on.

The ones that come up on nearly every project: the sitemap integration, MDX if you want components inside content, Tailwind for styling, and Astro’s built-in image handling, which resizes and converts images at build time and does the job several WordPress performance plugins are sold to do. Deployment is a pipeline that builds the site and pushes it to a CDN. On WestEnd.com that’s automated, so a content edit in the CMS goes live without anyone thinking about it.

What you won’t find is an ecosystem of ten thousand plugins. I’d call that a feature. Less to install means less to update, less to break, and less to audit when something goes wrong.

Should you migrate at all?

Sometimes the answer is no, and it’s better to know before you spend money.

E-commerce is the clearest case. WooCommerce is still my default for shops because so much is pre-built: products, carts, checkout, payments, emails, refunds. Astro has no equivalent ecosystem. You could build a shop on it against a headless commerce API, but I don’t think it’s the best tool for that job.

Membership sites and anything where logged-in users generate the content are in the same category, or at least need a much more careful conversation. The same goes for teams whose whole workflow lives in the WordPress admin and who have no appetite to change it.

The sites that gain the most are content and marketing sites where speed, security, and hosting costs matter more than dynamic features. If most of your plugins exist to make WordPress faster or safer, that’s the tell.

Put it this way. If a client told me they’d probably update the site every three months and write the odd blog post in between, I’d be hesitant to recommend WordPress for that now. All the maintenance and overhead, for a couple of hours of actual editing a quarter, is hard to justify when a trimmed-down static site does the same job faster and with less to go wrong.

If you’re weighing it up, the WestEnd.com case study shows what the finished thing looks like in practice, and the Astro development page covers how I approach these projects. And if your site is one of the ones that should stay on WordPress, I’ll say so. I look after WordPress sites every day, so I’ve nothing to sell you either way.

Why I Build on Open Platforms, Not Wix, Squarespace, or Shopify

Fri, 26 Jun 2026 00:00:00 GMT

Most people who come to me have already decided what they want their website built in. They’ve asked around, had a recommendation from a friend, colleague, or family member, or used something before on another project. What they often can’t tell you is why.

Because I market myself as a WordPress developer, most people come to me for WordPress already. Others are referrals, past clients, or friends of friends who just know I’m someone they can call. Sometimes they’ve got an existing Squarespace or Wix site that’s giving them grief. Sometimes they’ve seen Wix or Squarespace advertised and assumed that’s what they should ask for.

Either way, the platform usually gets picked before the reasons are clear. So here’s the why: why I build on open platforms like WordPress and Astro, and not on closed ones like Wix, Squarespace, or Shopify.

The short version

There are two kinds of website platform: open and closed, or owned and rented.

With an open platform like WordPress or Astro, you own the website. You have the full code, you can change anything, and you can take it anywhere.

With a closed platform like Wix, Squarespace, or Shopify, you’re renting. The site lives on their system, you can only change what they let you change, and you can’t take it with you if you leave.

For a small site that isn’t focused on growth, renting is fine. For a business website you want to build on for years, owning is usually the better deal. That’s the whole argument in a sentence.

If that’s enough for you, great. If you want to know why owning matters in practice, keep reading.

Rent versus own

A closed platform is like renting a flat where you’re not allowed to renovate or make major changes. It’s comfortable, someone else handles the maintenance, and for a while that’s lovely.

Then you want to knock two rooms together or do a major refurb, and you can’t. Not because it’s hard, but because it isn’t your flat. You’re limited to what the landlord allows.

An open platform is your own place. If you want to change something you can, or you can pay someone like me to do it for you. Nothing is off limits because you don’t need anyone’s permission.

But what about WordPress’s own ecosystem?

It’s a fair point. WordPress has its own trends, and its own vendor lock-in through paid plugins and subscriptions. It would be hypocritical of me not to address that.

Page builders and paid plugins

Page builders are the obvious example. Plugins like Divi and Beaver Builder have been around for a while, Elementor is the most popular one now, and a lot of developers have started talking about Bricks as their favourite. Each one turns up with a slick interface, builds a following, and becomes the thing everyone uses. Build your site in one and it’s tied to that tool, and you’re at the whim of its developers. You could say the same about WordPress core itself: it’s free, but you’re still working the way its developers think is right.

And there are real downsides. If you build a page in Elementor, you can’t move it to another builder, or to the standard editor, without redoing it, unless someone writes a tool to convert it. That’s a genuine form of lock-in, inside WordPress.

So what’s the difference? You still have the full source code, and the whole site is yours, which means you always have a choice.

Take a paid plugin. You’re usually buying the files plus a licence for that version, with six to twelve months of support. Once you have the files, you can keep running that version for as long as you like. If the company behind it folds, and a few page builders have, or it changes its business model, your site carries on, because you hold the files. On a closed platform they can switch a feature off and remove it from their systems, and you’re left with nothing, because you never had the files in the first place.

I’m not a fan of page builders myself, mostly because there’s no standard. I’m not keen on the default WordPress editor, Gutenberg, either, even though it’s the official way to build sites now. But because WordPress is open, nothing is forced on you. There’s always more than one way to do it.

My own preference is Advanced Custom Fields with the Roots Sage theme, because it suits how I like to build and how my clients like to edit. Someone else will choose differently, and that’s the point: the choice is yours.

On a rented platform you don’t get that choice. If they rebuild the editor, which happens more often than you’d think, and your site no longer works the way it did, or you lose a feature you relied on, you’re stuck with no other option.

You can always build it yourself

Those paid plugins I mentioned often bundle in a lot of extra features you’ll never use, which only adds weight to your site. But you’re never forced to use them. If a plugin does ten things and you only need one, you, or someone like me, can build just that one thing instead. There’s no rule that says you have to use the official plugin for something, or any plugin at all.

On a closed platform you don’t get that option. A lot of what you need on Shopify, for example, comes as paid apps from their App Store, often for things you could build yourself, except the platform is locked down enough to make that awkward. Even proper custom work happens on their terms, in their own templating language, Liquid, or their React framework, Hydrogen, on their hosting. Build an app that asks for certain permissions and it goes through Shopify’s review before it’s allowed near a store.

So on both sides the convenient option usually costs money. The difference is whether you’re allowed to go around it. On an open platform you always are, because you’re not tied to whether the platform has the feature, sells it, or will let you build your own.

You’re building on rented ground

This is the part that worries me most for a business.

Think about phone apps. A good mobile-friendly website can do most of what an app does, short of the deep native features. But the moment you’re in the App Store, you’re on Apple’s platform. You pay an annual fee just to publish, your app can be rejected, and if Apple decides to build something similar, yours can be made redundant overnight.

The same logic applies to any platform you build your business on. Shopify, Vinted, a marketplace, a social network: if they decide they don’t want your business any more, they can find a reason, and you’re stuck. You don’t own the relationship with your customers, they do.

When your site is yours, that off switch isn’t in someone else’s hands.

AI is widening the gap

This one is new, and it matters more every month.

The most useful AI tools now can read and change real code directly. Point them at a WordPress or Astro site and they can genuinely help build, fix, and improve it, because the code is open and they can see all of it.

You can already see it happening. Search Webflow on LinkedIn at the moment and a lot of what you’ll find is people moving to more open platforms. The closed tools will catch up and add their own AI features eventually, but there’s a ceiling to how far that can go.

Here’s why. Even if a closed platform gives you an AI interface, through their documentation, an APIApplication Programming Interface. A defined way for one piece of software to talk to another, exposing only the functions the provider chooses to offer., or an MCPModel Context Protocol. An open standard that lets AI tools connect to external systems and data in a structured way. server, it can only ever reach the parts they choose to expose. They’re never going to hand over the full source code. So whatever they offer, you’re working with a slice of the system, and you’re on the back foot.

An open platform has no such ceiling. You can download the WordPress core, run it on your own server, and let an AI work across every line of it. Add a third-party plugin and it can read all of that too. Astro is the same. You’re not boxed in by the tools the platform decided to give you, so there’s almost nothing you can’t change or build.

So as automation gets more capable, open sites get faster and cheaper to improve, and closed sites stay capped at whatever the platform allows. That gap is only going to grow.

Being honest about the limits

I’m not going to pretend open platforms make you completely independent. They don’t.

You still rely on payment providers

If you sell online with WooCommerce, WordPress isn’t touching the card payments. That goes through Stripe, Paddle, or another gateway, and they can freeze or close an account too. Card processing isn’t something a small business can realistically run itself, so that dependency is hard to avoid.

So it’s not all or nothing. It would be good to have more open options for things like payments, but we work with what exists. What you can control is where your site and your content live, and that is worth holding onto.

I rent hosting too

A WordPress site runs on a server, and you can own that server outright if you want, right down to a machine you’ve bought and sat in your own office. You can’t do that with Wix, Squarespace, or Shopify at all.

I’ll be straight though: for most of the sites I manage, I rent the hosting. Running a server reliably is a different job from building a website. It’s a DevOps skillset, it isn’t where my strengths are, and it isn’t what I enjoy. I’d rather leave server maintenance and tuning to people who do it full time and focus on the website itself, which is the part I’m good at. Even the servers I do run are a VPSVirtual Private Server. A slice of a physical server rented from a provider, with its own resources and full control over the software on it., which is still someone else’s computer when you get down to it.

The difference is that renting hosting doesn’t lock you in. If you’re on a care plan, your database and files are backed up off-site with full copies. If a host ever went down or let us down, we update the DNSDomain Name System. The system that points your domain at the server hosting your site, so moving hosts is mostly a matter of updating it., move the files to another provider, and you’re back up. The host is a managed service, not a lock-in, and switching is a few clicks and a couple of config changes, not a rebuild.

That’s the real difference. Leaving a closed platform means rebuilding from scratch. Moving a WordPress site between hosts is routine, and I keep that in mind. If a provider ever stops living up to what I expect, I can move a site without any trouble.

So, which should you choose?

Honestly, it depends on what you need the site to do.

When renting is the right call

I’m not against renting. If an off-the-shelf platform does what you need, that’s a good outcome, and honestly you probably don’t need a developer like me. With a bit of time and patience you could set up a Shopify or Squarespace site yourself and use the tools they give you.

Shopify in particular makes it genuinely easy for a non-technical owner to set up a shop. If you’re selling fairly standard products and don’t need anything unusual, it’s hard to beat: a monthly fee, no website to maintain, and the only thing you really manage is the shop itself.

These platforms do a great job for maybe 80% of the people who use them. That’s exactly why they’re so popular, and plenty of people are right to use them.

Who owning is for

The other 20% hit a wall. The tool won’t do the thing you actually need, or it’s locked behind a higher plan, or you slowly realise you’re shaping your business around the software instead of the other way round. If you’ve already looked at Shopify or Squarespace and felt they’re not quite enough for what you’ve got in mind, that feeling is the signal.

That’s the point where owning is worth it. You get far more flexibility, with more responsibility to match. WordPress asks more of you: good managed hosting usually costs a bit more, and you’re closer to the engine even with someone like me looking after it.

It’s also the work I most want to do. I’d rather build for someone who wants control and direction, who has a growth mindset, and who’s creating something that’s genuinely theirs and can scale with the business, than drop another shop into a template.

Closed platforms make you a tenant. Open platforms make you the landlord. So if you’ve been quoted a Wix, Squarespace, or Shopify site, you’re welcome to go that way, and sometimes it’s exactly right. But if it’s a business you want to grow and shape on your own terms, it’s worth knowing what you’re giving up before you sign up.

Happy to talk it through if you’re weighing it up. No sales pitch, just an honest view of the trade-offs.

Choosing a CMS for an Astro Website

Wed, 17 Jun 2026 00:00:00 GMT

Choosing a CMS for an Astro site sounds like it should be straightforward until you start looking.

The Astro docs list plenty of options. The wider Jamstack ecosystem lists many more. Some are API-first platforms. Some are visual page builders. Some are cloud products with their own admin interface, content database, permissions, pricing, and deployment assumptions.

They are not all solving the same problem.

For the kind of Astro sites I usually build, I do not need a whole content platform. I need a clean way to edit front matter, Markdown, blog posts, simple records, and structured fields that feed custom Astro components.

I want the CMS to make editing safer and easier. I do not want it to take over the architecture.

TL;DR

My current practical pick is Pages CMS for Astro sites with structured content relationships, especially if GitHub is already part of the deployment workflow. It is simple, works well, and its reference field can store one value while displaying a more useful human label from the related entry.

Keystatic is still the most interesting local-first option I tried, and I like a lot about it. But after testing it on a more relationship-heavy content model, its relationship fields are a blocker for some projects right now.

The rest of the article explains why I narrowed the field down to Git-based CMSs and why I am not focusing on API-first headless CMSs for this kind of project.

This is a first-pass practical review, not a definitive ranking of every CMS in the ecosystem. I spent roughly an hour looking into each serious candidate, setting up the ones that looked closest to the workflow I wanted, and noting my first impressions. If I have misunderstood a tool or missed something important, I would update the view after deeper testing.

My criteria

Content should stay in Git: I want the site code and content to remain version-controlled, portable, and easy to inspect.
The public site should stay static: The CMS can help create or edit content, but the live site should be served as static HTML, CSS, and assets after deployment where possible.
No permanent public admin by default: The CMS should not require an always-on public admin endpoint unless there is a strong reason. For these sites, there usually is not.
Local or agent-friendly workflow: Ideally, I should be able to clone the repo, run the CMS locally, edit content, commit the result, and deploy through a script.
Clear occasional editing: The client editing experience should be understandable for occasional updates. It does not need to be a full visual page builder.
Works with custom Astro components: In these builds, the CMS is usually managing fields and content values, not designing the page.
Avoid unnecessary lock-in: Hosted services are not automatically bad, but they need to justify the dependency.

Why I am not focusing on API-based CMSs

API-based headless CMSs make sense for some projects. If you are building a larger content platform, a multi-channel publishing system, a directory, a dynamic application, or a site with lots of editors and relationships between content types, a structured content API can be the right tool.

That is not the main use case here.

For a mostly static Astro site, the CMS content is usually fetched at build time. After that, the public site is just static output. If the API is only feeding the build process, the benefit of an always-available content API is much smaller.

API-first CMSs also tend to move the source of truth out of Git and into the provider’s content database. That adds another account, another platform, another pricing model, and another operational dependency.

If the site needs genuinely dynamic data, such as ticket sales, bookings, availability, stock, or live pricing, I would normally keep that separate from the CMS. The CMS can manage the editorial content around an event or service. The live data should come from the system that owns it.

That is why this review narrowed down to Git-based CMSs.

The shortlist

The four tools I ended up testing or seriously considering were:

I also looked at wider lists, including the Astro CMS guide and the Jamstack headless CMS list, but a lot of the options were either API-driven, cloud-first, too expensive, too immature, or tied to another static site generator.

Pages CMS

Website
Documentation
Astro guide
GitHub

Pages CMS is my baseline because I am already using it.

It is simple, Git-based, and easy to understand. You define the CMS structure in a YAML config file, including the navigation, collections, fields, and editable content. It publishes directly to GitHub, which means content changes can trigger a deployment if your GitHub workflow is set up that way.

The editing model feels a bit like Advanced Custom Fields for a static site. You define the fields, the client edits those fields, and Astro handles the actual templates and components.

I have not had any major problems with it. For a lot of small business Astro sites, I would be happy to use it.

The main caveat is that it is tied to GitHub. If GitHub is down, the CMS cannot update the site. In practice, that may not matter much, because the remote repository and deployment workflow often depend on GitHub anyway. If GitHub is unavailable, I have bigger problems than the CMS.

The deeper concern is strategic dependency. Pages CMS is a third-party service built around GitHub. If GitHub changes its pricing, organisation requirements, or workflow assumptions, or if Pages CMS changes its own model, that affects the setup.

Pages CMS is still a very good option. It is just not the fully local, self-controlled Git workflow I was curious to find.

Verdict: strongest current choice for my relationship-heavy Astro content models, especially if GitHub is already central to the workflow.

Keystatic

Website
Documentation
Astro guide

Keystatic is the most interesting local-first alternative I found in this first pass.

It has first-party Astro support, local mode, GitHub mode, and a clean configuration approach. The config file looked relatively minimal, and the local setup fitted the workflow I was looking for.

Once I got it running, it felt good. It loaded quickly. The UI was clean. It had dark mode. Search was built in. The settings and collections were grouped neatly. It felt similar in broad shape to Pages CMS and TinaCMS, but a little nicer for local editing.

The important point is that it can run locally inside the project. That means a developer, or a local AI agent, could start the web server, open the CMS at a local URL, edit the content, and commit the changed files to Git.

That is very close to the workflow I want.

The blocker I hit was relationships. In Keystatic, relationship fields store entry slugs and display those slugs in the editor. The docs also warn that if the slug of a referenced entry changes, the stored relationship value is not updated, so the relationship breaks. That is workable for simple sites, but it becomes a real content-management problem when you are dealing with related shows, venues, authors, categories, or other reusable records. In Pages CMS, the equivalent reference field can store a slug while showing a title, which is a better fit for editors and for relationship-heavy content.

This may be possible to improve in Keystatic with a custom field or upstream change, but it does not look like a small config option today. For now, that makes Keystatic harder to recommend for projects where relationships are central to the content model.

There is also a possible middle ground. If the hosting platform supports on-demand private containers, Keystatic could potentially run only when editing is needed rather than being exposed as a permanent public admin. I have not verified that as a Bunny.net production pattern yet, so I would treat it as an architecture to test, not the first recommendation.

The simpler workflow is to keep Keystatic as part of the repository. When an AI tool or developer works on the site, it can run Keystatic locally, open the admin URL, edit content, and commit the file changes. For a client, there are a few possible paths: they can ask for changes through an AI-assisted workflow, they can be shown the local editor during a working session, or Keystatic can be connected through GitHub mode if direct client access is needed.

Keystatic Cloud and GitHub mode may also be worth exploring for client access, but I would start with local mode. I do not want the hosted layer to become the reason for choosing it unless it clearly improves the workflow.

Verdict: promising, but not the current winner for relationship-heavy sites. It still looks like the best local-first editing direction if the relationship model improves or the project only needs simple references.

TinaCMS

Website
Documentation
Astro guide
Tina Astro framework guide

TinaCMS looked promising at first because it supports Astro and can run locally. It also has a richer editing model and visual editing options.

I got the local side working enough to see the shape of it. It can model content and run a local admin interface. It felt broadly similar to Pages CMS once the content model was visible.

The catch is that Tina feels heavier. TinaCloud is GitHub-based, which puts it in the same broad hosted GitHub-connected category as Pages CMS. Self-hosting Tina is possible, but it is not just a simple local file editor. It involves a data layer, authentication, a database adapter, a Git provider, and a GraphQL endpoint.

That may be technically sound, and it may be the right architecture for some teams. It just does not feel like the simplest answer for a mostly static Astro marketing site.

Tina also has visual editing for Astro, including contextual editing and click-to-edit behaviour. That is interesting, but it adds another layer of setup. For this use case, I am mainly trying to edit structured content and Markdown cleanly, not build a visual editing system.

Verdict: viable, but not compelling enough to replace Pages CMS or Keystatic for this workflow. I would use Tina if I specifically wanted its schema and editor model, but it is not my current first choice.

Decap CMS

Website
Documentation
Add to your site
Astro guide

Decap CMS is the mature open-source option in this space. It grew out of Netlify CMS, and it has a long history as a Git-based CMS for static sites.

I got it running, and it looked okay. It is usable, and it is clearly capable of managing Git-backed content.

My first impression was not as positive as Keystatic. The UI felt a bit chunkier. I did not find a dark mode. The default preview was turned on, and because the content was mostly Astro front matter, the preview did not look useful out of the box.

You can create custom previews, which could be powerful. In theory, you might be able to build something closer to a page preview. In practice, I suspect that would take quite a lot of work, especially if the site is built from custom Astro components. It may require rebuilding preview components or rendering logic separately, which is not what I want for this project.

There is an Astro guide on the Astro docs site, but I did not find a strong Astro-specific platform guide on the Decap site itself.

Verdict: credible and mature, but not the winner for this workflow. Keystatic felt better in the first pass.

Why I am not testing headless WordPress

WordPress
REST API Handbook

Headless WordPress is worth mentioning because it is a common answer to this question.

It is also worth mentioning because WordPress development is one of the services I offer. I am not trying to dismiss WordPress. For many projects, WordPress is still the right choice.

It can work. If a large organisation already has WordPress in place, multiple editors using it every day, and established workflows for publishing news, articles, or simple structured content, WordPress may still be the right editorial system.

That is not the situation I am usually designing for with lean Astro marketing sites.

In fact, a lot of clients looking at an Astro rebuild would be moving away from WordPress because they want the site to be leaner. They do not want to stay tied to an expensive hosting contract or keep a VPS online just so one person can log in a few times a year to make updates.

For this kind of site, a public WordPress server plus a public Astro site feels like two systems to host, secure, and maintain. It keeps a lot of the operational weight that the Astro rebuild was meant to remove.

The WordPress editor is also not an obvious fit for a component-based Astro build. It works well for posts and simple page content, but custom sections and structured layouts are less clear.

You could model content with Advanced Custom Fields, build custom blocks, or use WordPress privately as an internal publishing system that deploys static output. That might make sense for a larger organisation.

For a small business trying to run a fast, low-maintenance marketing site, it feels like too much machinery. If the client rarely updates the site, and the updates usually come from one person, a simple Git-based CMS can cover the need without keeping WordPress online as a headless backend.

That is the more interesting transition for me: move the public site to Astro, keep the content in version control, and give the client a lightweight editing workflow instead of preserving the WordPress hosting burden.

Verdict: mention it, but exclude it for this workflow unless WordPress is already deeply embedded in the client’s organisation.

Other tools I looked at

Sanity is a serious structured content platform with Astro support, but it is centred around Sanity Studio, Content Lake, APIs, collaboration, and hosted content infrastructure. It makes sense for larger content systems, but it is heavier than I need here.

CloudCannon is featured in the Astro CMS guide and looks polished, but pricing ruled it out for this use case. At roughly $49 per month paid annually, or $55 month to month, it costs more than the kind of lightweight server this workflow is trying to avoid.

Contentful and Storyblok are strong platforms, but they are not really in the Git-based local editing category I am reviewing.

Publii looks more like a desktop static site CMS and site builder than a CMS layer for an existing Astro project.

Statamic is flat-file and Git-friendly, but it is also a Laravel/PHP CMS with a control panel. That makes it too heavy for this specific workflow.

Sveltia CMS looks interesting as a modern Decap-style project, but the Astro integration story felt too light for a client-facing recommendation at this stage.

VaultCMS is interesting because it connects to an Obsidian vault. I may look at it for my own workflow, but I would not recommend it for client sites yet.

Current recommendation

For the kind of Astro sites I am building right now, I would keep using Pages CMS where content relationships matter. It already works, it is simple, and its reference field is better suited to editors because it can show a readable label while storing the value the site needs.

Keystatic is still the most promising local-first alternative. It runs locally, feels quick, has a clean UI, supports dark mode, and fits the idea of a developer or AI-assisted Git workflow very well. The relationship-field limitation is the main reason I would not make it the default yet.

The main thing I do not love about Pages CMS is the reliance on GitHub. If GitHub is already central to the repository and deployment workflow, that may be acceptable. But if I am choosing a CMS from scratch, I would still like a local-first option with stronger relationship handling.

TinaCMS is viable, but I do not yet see enough advantage over Pages CMS or Keystatic for this use case.

Decap CMS is mature and credible, but it felt less polished in the first pass.

For existing Astro sites I have already set up with Pages CMS, I would continue with that for now rather than migrate for the sake of it. For new builds, I would choose Pages CMS when the content model has important relationships, and keep watching Keystatic for simpler local-first workflows or future improvements to relationship fields.

Website Asset Checklist: What to Gather Before a Web Design Project

Thu, 04 Jun 2026 00:00:00 GMT

A website asset checklist is not a test you have to pass before a project can start.

Most business owners do not have every logo file, image, login, policy page, tracking code, and piece of copy neatly filed away. Some of it may be with a previous developer, designer, host, registrar, marketing agency, or internal team member. Some of it may not exist yet.

That is normal.

The point of the checklist is to make the invisible work visible. It gives you and your developer a shared map of the things a website project may need, so missing items can be found, recreated, replaced, or planned properly.

Using the interactive checklist

The interactive checklist is available as a separate full-width tool so the table has room for search, filtering, grouping, progress saving, notes, and a CSV export of your saved progress.

Open the interactive website asset checklist

You can export your saved checklist progress as a CSV from the interactive version.

Brand assets

Start with the core brand files if you have them.

The most useful items are logo files, logo variations, brand colours, fonts, and any brand guidelines. Vector logo files such as SVG, EPS, or AI are best because they can be resized cleanly, but a high-resolution PNG or PDF is still useful if that is all you have.

If you do not know what a vector file is, do not worry. Send what you have. A designer or developer can usually tell whether the file is good enough, whether a better version is needed, or whether the logo needs to be recreated.

Fonts are similar. Sometimes you have the font files. Sometimes you only know the font name. Sometimes the fonts are listed in a brand guide or old design file. If the font is commercial, check the licence before sharing the files directly.

Photos, video, and trust assets

Website projects often slow down when visual assets are left until the end.

Useful media can include:

Product, venue, service, or process photos.
Team and author photos.
Icons, diagrams, and illustrations.
Client, partner, award, or accreditation logos.
Testimonials, review quotes, and supporting photos.
Videos, animations, or hosted video links.
A favicon or square app icon.
A social sharing image for links shared online.

Original high-resolution files are better than images copied from an old website. If everything is only on the old site, that can still be a starting point, but it is worth checking whether better originals exist.

Social accounts and public contact details

The site should link to the right public profiles and show the right business information.

Gather the social profiles that are actually active and relevant. If the business has different accounts for different locations, teams, brands, or channels, decide which ones belong on this website.

Also confirm the public contact details: phone numbers, email addresses, physical addresses, mailing addresses, service areas, and where form submissions should go. These details sound simple, but they often affect contact pages, local SEO, structured data, maps, email routing, and enquiry workflows.

Access and integrations

Access details need more care than normal files.

Your developer may need to know where the domain is registered, where DNS is managed, where the site is hosted, who controls the existing CMS, and which tools are connected to the website. That can include analytics, Google Tag Manager, Search Console, CRM tools, newsletter platforms, booking systems, payment providers, live chat, reviews, maps, reCAPTCHA, SMTP, and other APIs.

Do not send passwords, API keys, or recovery codes by normal email or a standard upload link.

A good developer should give you a secure way to share sensitive access details, or ask you to invite them to the relevant account instead. Named user access is usually better than handing over a shared password.

If you do not know who controls something, that is useful information too. Domains, DNS, hosting, and analytics accounts are often held by a previous developer, agency, IT provider, or marketing supplier. Part of the project may be working out where those accounts live and getting ownership back into the right hands.

Content and page material

Content does not have to be final before the technical work starts, but it helps to know what exists.

Useful content assets include:

An initial page list or sitemap.
Existing page copy from the old website.
Draft copy in documents or notes.
Service, product, pricing, or offer details.
Team bios, author bios, credentials, memberships, and accreditations.
FAQs from real customer conversations.
SEO notes, target keywords, Search Console exports, or PPC terms.
Downloadable files such as brochures, menus, forms, white papers, or product sheets.

If copy still needs writing, mark it as a project task rather than pretending it is ready. That keeps the timeline honest.

Legal and policy pages

Policy content is easy to forget until launch week.

Depending on the site, you may need a privacy policy, cookie policy, terms and conditions, refund policy, delivery policy, booking terms, membership terms, or copyright and attribution notes.

Your developer can help identify where these pages are needed, but they cannot usually give legal advice. If a policy does not exist yet, flag it early so there is time to get the right wording from the right person.

What if you do not have everything?

You almost certainly will not have everything.

That is fine. The checklist is there to start useful conversations:

Do we already have this?
Who might have it?
Is the current version good enough?
Does it need to be recreated?
Should it be produced during the project?
Is it actually unnecessary for this website?

Some items can be gathered later. Some can be replaced. Some can be skipped. Some reveal important ownership or access issues that are better discovered early than during launch week.

If you are working with WildPress, I will help you work through this rather than expecting a perfect folder of assets on day one. If you are working with another developer or agency, they should provide a clear way to send normal project files and a secure method for sensitive access details.

For the wider delivery process, see my 6-step website build process. Once the project is closer to launch, the separate WordPress pre-launch checklist covers the final readiness checks before a site goes live.

WordPress Maintenance Checklist: How to Maintain a WordPress Website Each Month

Mon, 01 Jun 2026 00:00:00 GMT

This WordPress maintenance checklist is based on the monthly process WildPress uses for client websites.

It is here for two reasons. First, clients can see what is being checked as part of their care plan. Second, business owners searching for how to maintain a WordPress website can see the difference between basic maintenance, performance-focused support, and a more active growth plan.

The interactive version includes a care plan filter. Choose Maintenance, Performance, or Growth to see the checks included at that level and above.

If you are preparing a new website for launch, migrating a site, or taking over an existing WordPress site, start with the separate WordPress pre-launch checklist. Those foundation checks cover ownership, access, backups, analytics, email, Search Console, and recovery planning before monthly care begins.

If you are still deciding what level of support you need, the companion article What is a WordPress Care Plan? explains the difference between maintenance, proactive technical support, and a more active growth partnership.

Using the interactive checklist

The interactive checklist is available as a separate full-width tool so the table has room for search, grouping, care plan filtering, progress saving, and a CSV export of your saved progress.

Open the interactive WordPress maintenance checklist

You can export your saved checklist progress as a CSV from the interactive version.

What a WordPress maintenance routine should include

Maintaining a WordPress website is not just pressing the update button once a month.

Updates matter, but the real job is keeping the site reliable enough for the business using it. A useful maintenance routine should include updates, backups, security alerts, form testing, uptime, performance, Search Console, and the pages that generate enquiries or sales.

The easiest way to avoid missing important work is to split maintenance into two routines:

Foundation checks before launch, migration, or handover.
Recurring checks that happen every month once the site is live.

The checklist below focuses on the recurring monthly checks. The pre-launch checklist covers the foundation work that should already be in place.

What the Maintenance plan covers

The Maintenance plan covers the core monthly checks that keep a WordPress site stable and recoverable.

That includes WordPress core, plugin, and theme updates, backup checks, security monitoring, uptime review, PHP or application error checks, and a basic post-update review of the visible website. It also includes a monthly maintenance summary so the work is recorded rather than disappearing into the background.

For smaller business websites, this is often enough. The main goal is to avoid neglected updates, broken forms, missed security warnings, and unclear recovery routes.

What the Performance plan adds

The Performance plan adds more active technical review.

That means PageSpeed and Core Web Vitals checks, light crawl checks, broken link and metadata review, storage and database housekeeping, Search Console coverage checks, IndexNow submission checks, and schema.org structured data validation. These checks are useful for sites where performance, search visibility, and reliability have a direct effect on enquiries, campaigns, or sales.

The Performance plan is not just about a faster score. It is about noticing when technical quality is slipping and turning that into practical maintenance work.

How to maintain a WordPress website safely

Do not update blindly. A plugin update can change markup, JavaScript, checkout logic, form behaviour, page-builder output, or admin workflows. For low-risk sites, a simple update and visual check may be enough. For sites that handle orders, bookings, subscriptions, or leads, updates should be followed by real journey testing.

At minimum, after updates you should test:

The homepage and priority landing pages.
Contact forms and notification emails.
Checkout, booking, subscription, or account flows if they exist.
Navigation, search, filters, and menus.
Admin editing for the content types the team actually uses.

Backups also need to be treated as a recovery process, not just a plugin setting. You should know where backups are stored, how often they run, whether files and database tables are both included, and how quickly a usable version of the site could be restored.

Hosting quality affects this routine as well. A good managed WordPress hosting setup makes backups, restores, caching, PHP versions, logs, and server-level security easier to review each month.

Search Console and performance checks belong in the same rhythm. Google Search Console can show indexing issues, sitemap problems, query changes, and pages that appear often but get few clicks. PageSpeed and Core Web Vitals checks help spot performance deterioration before it becomes a bigger conversion or user-experience issue.

What the Growth plan adds

The Growth plan adds analytics, search opportunity review, improvement planning, and a monthly strategy rhythm.

That includes checking conversion tracking, reviewing analytics and conversion paths, looking at Search Console queries, spotting pages with impressions but weak clicks, and keeping a short improvement roadmap. This is for websites that are not just being maintained, but actively used for sales, publishing, lead generation, bookings, ecommerce, or operational workflows.

How clients should use this checklist

Clients are welcome to review the checklist and ask questions about what has been checked, what was found, or what should be prioritised next.

The checklist is also useful internally. A team member can run through the monthly checks, filter by the client’s care plan tier, add notes, and export the saved progress as a CSV record for that month.

If you want this handled for you, compare the current WildPress WordPress care plans or open the interactive monthly care plan checklist to see what is included at each level.

WordPress Pre-Launch Checklist for New and Existing Sites

Mon, 01 Jun 2026 00:00:00 GMT

A WordPress pre-launch checklist is different from a monthly maintenance checklist.

Pre-launch checks are the foundation checks you do before a new website goes live, before a migration, before a major rebuild is signed off, or before you take responsibility for an existing WordPress site.

These checks should not need repeating every week. They are the stable baseline: who owns the domain, where DNS lives, how backups work, whether email is reliable, whether forms send correctly, whether Search Console, IndexNow, structured data, and analytics are set up, and whether the site can be recovered if something goes wrong.

For recurring checks after launch, use the separate WordPress maintenance checklist. That covers updates, backups, security alerts, uptime, forms, PageSpeed, Search Console reviews, crawl checks, and content accuracy.

If you are planning a full new build rather than only checking an existing site before launch, the 6-step website build process shows how discovery, design, development, QA, deployment, and post-launch support fit together.

Using the interactive checklist

The interactive checklist is available as a separate full-width tool so the table has room for search, filtering, grouping, progress saving, and a CSV export of your saved progress.

Open the interactive WordPress pre-launch checklist

You can export your saved checklist progress as a CSV from the interactive version.

What to check before a WordPress site goes live

The most important pre-launch checks are the ones that reduce avoidable risk.

Access and ownership should be clear before launch. The client should own the domain account, DNS access should be documented, hosting should be understood, and named admin accounts should replace shared logins.

Hosting is worth checking early because it affects performance, backups, logs, staging, and support during launch. The WordPress hosting provider guide covers what to look for if the site is moving to a new platform.

Backups should be configured before the site matters. A backup is not enough on its own; the restore route also needs to be understood and tested.

Security should be treated as part of launch readiness, not something to bolt on later. Strong passwords, two-factor authentication, SSL, redirects, unused plugin removal, and user review all belong in the foundation work.

Search and analytics should also be ready before launch. Google Search Console should be verified, the XML sitemap should be submitted, IndexNow should be configured where useful, analytics should track meaningful actions, structured data should validate cleanly, and important pages should be crawlable and indexable.

Forms, email, and operational checks

Many WordPress launch problems are not visual. A site can look finished while forms fail silently, transactional email lands in spam, scheduled tasks do not run, or CRM handoffs are broken.

Before launch, test every important path:

Contact forms and notification emails.
Booking, checkout, subscription, or lead flows.
SMTP configuration and password reset emails.
Scheduled posts, cron jobs, imports, exports, and automations.
Analytics and conversion events.

These checks are especially important for ecommerce, booking, membership, subscription, and high-value lead generation sites.

Performance and content checks

Pre-launch is also the right time to record a baseline.

Run PageSpeed or Lighthouse checks on the main templates. Check page titles, meta descriptions, headings, image alt text, canonical URLs, redirects, and the mobile experience. Review pricing, service information, contact details, legal pages, and calls to action before the site is shared publicly.

The goal is not to chase perfect scores. The goal is to know what changed later. A baseline gives maintenance work something to compare against.

After launch

Once the foundation is in place, move to a regular maintenance rhythm. That means checking updates, backups, security, uptime, forms, performance, Search Console, crawl quality, and content accuracy on a schedule that matches the business risk of the site.

WildPress handles both foundation checks and recurring maintenance as part of our WordPress care plans.

My Top Laptop-Friendly Cafes in Battersea

Fri, 14 Jun 2024 00:00:00 GMT

I run WildPress as a web developer based in Battersea, and most of my work happens at my desk. Every so often, though, I want to get out of the house for an hour or two, and a good local cafe is often where I end up meeting a client for an informal chat or working through a build with a coffee in hand.

Over time I’ve built up a short list of places in SW11 I would actually use for that, and this is it. It’s not a roundup of every cafe in Battersea. It’s the handful of spots that work when you want a coffee, a quick bite, and enough comfort to get something done without feeling like you’ve taken over the room.

None of these are full-day office replacements or places for long calls. They’re for the times when a change of scene helps, or when meeting in person beats another video call.

What Makes a Cafe Worth Working From

When I’m weighing up whether a Battersea cafe works for a short laptop session, I look at the basics:

Wi-Fi availability and speed
Power outlets within reach
Comfortable, varied seating
Natural light
Noise levels and general atmosphere
Quality of the coffee and food
Proximity to transport and other amenities
Access to a toilet
How they feel about laptop users

No cafe gets all of these right. The useful ones get enough of them right without losing the atmosphere that made you want to go there in the first place.

What Rules a Place Out

A few things make me cross a cafe off the list fairly quickly:

Too little space: small venues feel cramped and uncomfortable to work in.
Always packed: if it’s constantly busy, I feel pressured to give up my seat, which is no good for getting anything done.
Wrong tables: rooms with only large tables make me feel like I’m hogging space when it’s just me and a laptop.
No-laptop policies: an obvious one, but worth checking.
Weak Wi-Fi: reliable internet is essential for most of what I do.
Restaurant-first hybrids: I’d rather a dedicated coffee shop than a restaurant that also happens to serve coffee.

District, Battersea Park

Location: 49 Parkgate Road, London SW11 4NP Best for: a comfortable work session close to Battersea Park.

District is probably my favourite spot in Battersea for getting work done. It’s a stylish coffee shop that pairs great coffee and proper brunch with comfortable seating and an environment you can actually settle into.

Key Features

Atmosphere: light and airy, with high ceilings and plenty of space
Seating: a long shared high table in the middle and a high countertop along the window
Wi-Fi: free BT Guest Wi-Fi, around 30 Mbps when I’ve used it
Power outlets: limited, only one or two on offer
Lighting: good natural light
Noise level: fairly quiet, with low music
Coffee quality: excellent
Food options: excellent, with freshly cooked brunch
Comfort: a nice ambience to sit in
Temperature: air conditioned

District strikes a good balance. It’s lively enough to feel energising, but rarely so busy that you feel you should leave. With the mix of seating, you can usually find a spot whether you’re on your own or meeting someone.

Location Perks

Close to Battersea Park
Near the river, so it’s easy to stretch your legs afterwards

Doppio Coffee Warehouse, Battersea

Location: 336 Battersea Park Road, Battersea Park, London SW11 3BY Best for: a coffee-led session with a no-nonsense setup.

Doppio Coffee Warehouse is a functional place to work, with good natural light, excellent coffee, and a distinctive industrial warehouse feel. The seating isn’t built for all-day comfort, but it’s fine for a shorter stint, and the mix of laptop users and casual visitors keeps the atmosphere balanced. The iced lattes are a highlight, though the food is more limited.

Key Features

Atmosphere: spacious, with an industrial warehouse character
Seating: unpadded wooden benches and window countertops with lots of light
Wi-Fi: the official network was down when I visited, but I connected to another at around 35 Mbps
Power outlets: a few dotted around
Lighting: plenty of natural light, especially at the front
Noise level: fairly quiet, with low music
Coffee quality: excellent
Food options: limited to baked goods and pre-made sandwiches
Comfort: functional rather than plush
Temperature: air conditioned

Location Perks

Near Sainsbury’s, a post office, and Battersea High Street
About 15 minutes’ walk to Battersea Park

Sendero Specialty Coffee, Battersea Park

Location: 37 Patcham Terrace, Nine Elms, London SW8 4EX Best for: laptop work near Battersea Park station and the Power Station.

Sendero Specialty Coffee is a lively option right by Battersea Park. With ample seating, plenty of power, and big windows letting in natural light, it’s well set up for a productive hour or two. The trade-off is noise: it sits on a busy junction, so expect a bit more background hum than the other two.

Key Features

Atmosphere: friendly and welcoming
Seating: lots of it, with small wooden tables and high countertops around the windows
Wi-Fi: decent but not especially fast, around 25 Mbps
Power outlets: plenty, with built-in USB sockets
Lighting: lots of natural light from the big windows
Noise level: music can be on the louder side, with some traffic noise outside
Coffee quality: excellent
Food options: pre-made wraps, snacks, sandwiches, and baked goods
Temperature: has air conditioning, though the door was open and it didn’t feel like it was running

Location Perks

Next to Battersea Park
Right by Battersea Park train station
Around eight minutes’ walk to Battersea Power Station and the Tube

A Word on Laptop Etiquette

If you haven’t worked from cafes much before and aren’t sure of the unwritten rules, a few pointers:

Stick to weekdays: these spots suit laptop work best from Monday to Friday. Weekends get busier and some places ask you not to use a laptop then.
Keep buying: if you’re settling in for a while, it’s only fair to order another drink, and maybe some food. My rule of thumb is one purchase per hour.
Read the room: mind your noise, don’t spread out more than you need to, and respect other customers. If it gets packed, the polite move is to leave and come back when it’s quieter.
Know the limits: these are for short sessions and informal meetings, not full-day offices or video calls.

Stick to that and cafes stay welcoming to the rest of us working on laptops too.

If you’re a Battersea business and want to talk websites over a coffee at any of these, get in touch. I’m always happy to meet locally.

Setting up as a Web Developer in Battersea

Thu, 09 May 2024 00:00:00 GMT

Hey there! I’m James, the guy behind WildPress. I’ve brought my web development business to Battersea, and I’m really excited to connect with local small to medium-sized businesses and creative agencies.

You know how crucial it is to have a strong online presence these days, right? That’s where I come in. I specialize in creating custom WordPress websites that not only look fantastic but also help you achieve your business goals. If you’re a local business, here’s more on my Battersea web design and development service.

Personalised Design & Development Services

What sets me apart is my focus on personalized service. I don’t believe in cookie-cutter solutions. Instead, I take the time to really understand your business, your target audience, and what you want to accomplish with your website. Then, I craft a tailored WordPress solution that fits your requirements.

I can handle the entire website process from planning to launch, or I can integrate with your existing team as a development resource. Whether you need a custom design or want to work from established branding guidelines, every site I build is bespoke, with custom functionality tailored to your specific needs.

Transition Your Business to Start Selling Online

One of the things I’m really excited about is helping local Battersea businesses transition to selling online. If you’ve been thinking about opening an ecommerce store, getting more online bookings, or starting a subscription service, I can help make that a reality. I’ve worked with a variety of businesses to create successful online sales platforms - check out my portfolio to see what’s possible.

Custom Themes & Plugins for Easy Content Management

I’m a big fan of creating custom themes and Gutenberg blocks for my clients. This way, you get the flexibility of a page builder without the complexity of a fully-fledged system like Elementor. I’ll train you and your team on how to use these blocks, so you can easily create and update on-brand layouts without needing to be a tech expert.

But that’s not all - I can also develop custom plugins to handle your specific use cases. This means you don’t need to rely on dozens of third-party plugins that can add bloat and overhead to your site. Instead, you’ll have a streamlined, efficient system that’s tailored to your exact needs. Whether you need a unique booking system, a custom integration with your CRM, or anything else, I can build a plugin that makes it happen.

Monthly WordPress Care Plans for Hassle-Free Maintenance

But I don’t just build your website and call it a day. I know that maintaining a website can be a hassle, especially if you’re not a tech whiz. That’s why I offer Monthly WordPress Care Plans. Basically, I handle all the technical stuff - updates, backups, security, performance - so you can focus on running your business. The monthly WordPress maintenance checklist shows the checks behind that ongoing work.

Collaboration and Communication

I’m all about collaboration and open communication. When you work with me, you’re not just a client - you’re a partner. I’ll keep you in the loop throughout the development process, and I’m always just a phone call or email away if you have any questions or concerns, and I’m happy to come visit you in Battersea.

Let’s Meet and Discuss Your Web Development Needs

Get Started if you’d like to discuss your next website project.

I’m happy to meet with you in person, not just in Battersea but also in the surrounding areas: Clapham, Tooting, Wandsworth, Fulham, and Chelsea.

If you don’t have an office, no worries. We can always find a convenient local spot to meet up.

I’m thrilled to be part of the Battersea business community, and I can’t wait to help more local businesses succeed online. If you have any questions or just want to learn more about what I do, don’t hesitate to reach out. Let’s work together and create a website that you’ll be proud to show off!

What is a WordPress Care Plan?

Mon, 01 Apr 2024 00:00:00 GMT

As a business owner with a WordPress website, you may have heard about WordPress care plans and wondered what they entail.

There are two main approaches to WordPress care plans:

Proactive Maintenance: This approach focuses on keeping your website up-to-date, secure, and performant as a preventative measure. It emphasizes regular maintenance and upkeep to minimize the risk of issues arising.
Technical Partnership: This approach includes all the benefits of proactive maintenance but adds a more active role for the care plan provider. In this case, the provider acts as a technical partner, helping you grow your site, providing suggestions, and actively supporting the website with data-driven insights to improve the site over time as it grows.

Ultimately, a WordPress care plan is a service provided by a developer or agency to keep your website running smoothly and to help you achieve your online goals.

If you already know you need ongoing help, see the WildPress WordPress care plans for current monthly maintenance packages, pricing, and support options.

If you want the practical version rather than the explanation, the WordPress maintenance checklist shows the monthly checks WildPress uses across Maintenance, Performance, and Growth care plan tiers.

How Care Plans Work

Most WordPress care plans operate on a monthly basis, where clients pay upfront to receive a set number of support hours, access to a help desk, and other services.

The Basics

A typical WordPress care plan includes:

Technical support and troubleshooting.
Emergency support.
Website maintenance.
Regular updates of WordPress core, plugins, and themes.
Security monitoring and protection against threats.
Backup and restore services.
Performance optimisations.
Monthly reports.

The First Month

The first month of a care plan is often more active, as additional time is spent:

Setting up monitoring and optimisation tools.
Establishing a baseline for analytics, search rankings, and performance scores.
Familiarising the developer with the client’s website and business goals.

This initial period helps the developer understand the website’s current state and identify areas for improvement.

Ongoing Monthly Tasks

On an ongoing basis, the care plan provider will perform regular maintenance tasks each month, such as:

Updating WordPress core, plugins, and themes to ensure security, compatibility, and access to the latest features.
Managing support requests from the client and providing timely assistance.
Monitoring the website using automated tools to detect and alert for issues as they arise.
Performing regular backups to protect the website’s data and allow for quick recovery in case of an incident.
Optimizing website performance to ensure fast loading times and a positive user experience.
Providing reports on website performance, uptime, and other key metrics.

By proactively maintaining the website and addressing issues promptly, a WordPress care plan helps to prevent potential problems and keep the site running smoothly. The care plan provider acts as a reliable partner, offering ongoing support and expertise to help the client achieve their online goals.

Why Updates Matter

Keeping your WordPress site updated is crucial for several reasons:

Security: Updates often include patches for vulnerabilities that could be exploited by hackers. WordPress is a popular target for attackers due to its widespread use, so it’s essential to keep your site updated to protect against known security issues.
Compatibility: As WordPress evolves, older versions of plugins and themes may become incompatible, leading to site breakage. Updating ensures that all components of your site work seamlessly together.
Features: Updates can introduce new features and improvements to enhance your site’s functionality, providing a better experience for your users and more options for customization.

WordPress Plugin Updates

WordPress’s strength lies in its vibrant community and the vast array of third-party plugins available to extend its functionality. However, this reliance on plugins can also introduce potential security risks:

The more plugins installed, the larger the attack surface becomes
Challenging to ensure every plugin follows best practices for security
Important to be selective about installed plugins, opting for well-maintained and trusted ones from reputable developers

Regular updates to WordPress core, plugins, and themes are essential for:

Addressing discovered security vulnerabilities
Maintaining compatibility between WordPress core and installed plugins and themes
Introducing new features, improvements, and bug fixes

Website Infrastructure Updates

When choosing a hosting provider, it’s important to select one that offers managed hosting with WordPress-specific support.

A good managed hosting provider will have designed their infrastructure and supporting software to be optimally compatible with WordPress and its plugins. This includes:

Server configurations tailored for WordPress performance and security
Automatic updates for WordPress core, plugins, and themes
Specialized caching and performance optimizations for WordPress
WordPress-specific security measures and monitoring

I cover this decision in more detail in the WordPress hosting provider guide, and WildPress can also manage hosting through the managed hosting service.

Support and Response Times

One of the main reasons to invest in a care plan is to have professional help on hand when issues arise, especially when it comes to critical problems that require immediate attention.

While regular maintenance and optimization are important, the true value of a care plan often lies in the peace of mind it provides, knowing that you have a dedicated team ready to jump in and resolve urgent issues as quickly as possible.

When considering a care plan, it’s crucial to understand the level of support offered and the response times you can expect. Plans typically include:

Emergency Support: This is the most critical aspect of a care plan. When your site experiences a major issue that impacts its functionality or visibility, you need to know that your care plan provider will be there to resolve the problem as quickly as possible. Look for plans that offer emergency support with guaranteed response times for critical issues.
Scope of Support: Understand what types of issues are covered under your care plan and during what hours support is available. Some plans may only offer support during business hours, while others provide extended coverage on weekends or even 24/7 support.
Response Times: In addition to emergency support, care plans should define guaranteed response times for different severity levels of issues. For example, a plan may guarantee a 2-hour response time for high-priority issues, a 4-hour response time for medium-priority issues, and a 24-hour response time for low-priority issues.
Communication Channels: Know how you can reach out for support when you need it. Care plans may offer various communication channels, such as a dedicated support email, a ticketing system, live chat, or even phone support for critical issues.
Expertise: When entrusting your website to a care plan provider, ensure that they have the necessary expertise to resolve issues efficiently. Look for providers with a track record of success and a team of experienced WordPress developers and sys admins.

Pricing Structures

Care plans are usually priced on a monthly or annual basis, with different tiers based on the level of service.

Factors that influence pricing include:

Website complexity and size: Larger and more complex websites often require more time and resources to manage, which can result in higher care plan prices.
Level of support: Plans with faster guaranteed response times typically cost more than those offering only business hours support.
Additional services: Care plans that include extras like content updates, SEO optimization, or performance audits may have higher prices than basic plans.
Hosting: Plans that bundle hosting with management services often have different pricing structures than those that manage your existing hosting setup.

Budget-friendly care plans

At the lower end of the pricing spectrum, you’ll find care plans that rely heavily on automation to keep costs down. These plans often use white-labeled WordPress management tools like MainWP or ManageWP to streamline processes and minimize manual intervention.

While these budget-friendly plans can be a good option for simple websites with minimal requirements, they may come with limitations:

Limited or no guaranteed response times for emergency support.
Fewer customization options for update schedules or backup frequencies.
Less proactive monitoring and optimization.

Premium care plans

On the higher end of the pricing scale, premium care plans offer a more comprehensive and proactive approach to website management. These plans often include:

Guaranteed response times for emergency support, often with 24/7 availability.
Dedicated account managers or support teams.
Custom update schedules and backup frequencies tailored to your site’s needs.
Proactive monitoring and optimization to catch potential issues before they cause problems.
Additional checks after automated updates to ensure no new issues were introduced.
More advanced security features and malware scanning.

While premium care plans come with a higher price tag, they can provide greater peace of mind and a more personalized approach to managing your website.

Choosing the Right Care Plan for Your Needs

When it comes to WordPress care plans, customers generally fall into two categories:

Basic Maintenance and Security

Some customers simply want peace of mind knowing their site is secure and that help is available if needed. They typically prefer a more hands-off approach, focusing on essential updates, backups, and security monitoring. These customers often opt for budget-friendly care plans that cover the basics.

Proactive Partnership and Growth

Other customers are looking for a more comprehensive solution that not only maintains their website but also helps it grow and succeed. These customers want a proactive partner to provide strategic guidance and support across various aspects of their website.

Premium care plans cater to these needs by offering additional services and benefits:

SEO Optimization: Premium care plans often include ongoing SEO support to help improve the website’s search engine rankings. This can involve keyword research, on-page optimization, and content strategy guidance to attract more organic traffic.
Performance Optimization: With a focus on enhancing the user experience, premium care plans may include regular performance audits and optimization tasks. This can involve caching configuration, image compression, and code minification to ensure the website loads quickly and efficiently.
Content Management: Some premium care plans offer assistance with managing and updating website content. This can include creating new pages, blog posts, or product descriptions, as well as optimizing existing content for better readability and SEO.
Analytics and Reporting: To help customers make data-driven decisions, premium care plans may provide regular analytics reporting and insights. This can include tracking key performance indicators (KPIs), identifying traffic sources, and monitoring conversion rates to continually improve the website’s effectiveness.
Marketing Support: Premium care plans may also offer marketing assistance to help customers grow their online presence. This can include social media management, email marketing campaigns, or even paid advertising support to drive more targeted traffic to the website.
Strategic Consulting: With a premium care plan, customers often have access to a dedicated account manager or support team that provides personalized recommendations and strategic guidance. This can involve regular meetings to discuss the website’s goals, identify growth opportunities, and develop action plans to achieve desired results.

When choosing a WordPress care plan, consider your specific needs and goals for your website. If you primarily want to ensure your site is secure and functional, a basic plan focusing on maintenance and security may suffice.

However, if you’re looking for a partner to help optimize and grow your online presence, a premium care plan with proactive support and additional services could be the better choice.

Other Considerations

Hosting and Infrastructure

The performance and security of your WordPress site are heavily influenced by the hosting infrastructure it runs on. When considering a care plan, it’s important to understand whether hosting is included or extra, or if the provider will manage your existing hosting setup.

Managed hosting can offer advantages such as WordPress-specific optimizations, automatic updates, and enhanced security measures. Have a look at my WordPress hosting guide for more information.

DNS & Email Management

Setting up a website involves more than just designing pages and creating content. Two crucial aspects often overlooked are email deliverability and DNS management.

To ensure that your website’s emails (e.g., contact form submissions, password reset emails) reach their intended recipients, your web server must use a trusted email provider (SMTP). Some care plans include email configuration and management to help you navigate this process.

Additionally, proper DNS management is essential for your website’s availability and functionality. DNS records control aspects such as domain pointing, email service configuration, and integration with third-party services. Incorrect DNS settings can lead to website downtime, email delivery failures, and other issues.

When choosing a care plan, consider whether the provider offers assistance with:

Configuring and managing email services for optimal deliverability.
Setting up and updating DNS records to ensure proper website functionality.
Troubleshooting DNS-related issues that may impact your website’s performance.

Choosing the Right Care Plan

When selecting a WordPress care plan, consider your website’s needs and your own technical capabilities. If you have a complex site or limited technical skills, a more comprehensive plan may be worthwhile. On the other hand, if you have a simple site and are comfortable handling minor updates yourself, a basic plan may suffice.

Ultimately, a WordPress care plan is an investment in your website’s long-term health and success. By entrusting the technical details to experts, you can focus on running your business with the confidence that your online presence is in good hands.

Get Started to learn more and we can discuss a Care Plan suited for you.

Choosing a WordPress Hosting Provider - The Ultimate Guide

Sun, 31 Mar 2024 00:00:00 GMT

Introduction

Welcome to this in-depth guide on selecting the right WordPress hosting provider. Drawing from years of experience working with various clients and evaluating numerous hosting options, I’ve compiled this resource to help you navigate the complex world of WordPress hosting.

Key points about this guide:

Use the Table of Contents to navigate. This guide is comprehensive, so focus on the sections most relevant to your needs.
Each section is designed to stand alone, allowing you to quickly find the information you need without reading the entire guide.
The things I’m pointing out are based on real-world experiences with multiple hosting providers over the years.
Your specific needs, budget, technical skills, and growth plans all play a role in determining the best hosting fit for you.
If you’re looking for a reliable hosting solution, consider my own hosting service provided with my partner Positive Internet, which I’ll discuss at the end of this guide.

Now, let’s dive into the world of WordPress hosting. Use the Table of Contents to jump to the sections that interest you most.

What Factors to Consider When Choosing a Hosting Provider

Customer Support

Evaluate the hosting provider’s support offerings, including the availability of expert WordPress support, response times, and communication channels (e.g., live chat, phone, email).

It’s incredibly frustrating dealing with an AI chatbot or first-level support person who doesn’t have in-depth knowledge of WordPress. You can find yourself going back-and-forth trying to debug an issue for days, which a WordPress expert would be able to resolve in minutes.

WordPress Expertise

Look for hosting providers that offer support, optimizations, and features specifically for WordPress, such as caching, SSL certificate management, and WordPress-specific security measures.

Pricing

The requirements to host a modern WordPress website are relatively minimal. The most basic requirements are a computer running a web server, PHP, and a database. The most popular “stack” is LAMP (Linux, Apache, MySQL, and PHP).

You can get away with purchasing a cheap hosting package, or rolling your own, but if you’re serious about scaling your website for growth and have little technical expertise, it’s better to choose a more expensive managed hosting plan.

Key differentiators for premium WordPress hosting providers include optimized performance, enhanced security measures, expert WordPress-specific support, automated backups and updates, staging environments, scalability options, and often bundled premium plugin licenses.

The high-performance managed hosting packages start from around $25 USD per month.

Performance

Performance is crucial for user experience, search engine rankings, and overall website success. When choosing a WordPress hosting provider, ensure they use high-performance infrastructure and optimizations:

Storage Technology:Fast SSDs (Solid State Drives) for improved read/write speedsSufficient storage capacity to accommodate your site’s growth. I generally go for 50Gb per site as standard.
Memory (RAM):Ample RAM to handle concurrent connections and database operationsLook for hosts that offer easy RAM upgrades as your site grows
Optimized Server Configurations:Servers fine-tuned for WordPress performanceLatest versions of PHP, MySQL, and web server software (e.g., Nginx or Apache)
Caching Solutions:Server-level caching to reduce load on expensive queriesObject caching (e.g., Redis or Memcached) for faster database operationsPage caching to serve static content quickly, e.g. Varnish
Content Delivery Network (CDN):Integrated CDN services to ensure fast loading times globallyEasy configuration and management of CDN settings
Database Optimization:Regular database maintenance (e.g., optimization, repair)Support for database replication for read-heavy sites
Network Infrastructure:High-bandwidth connections to handle traffic spikesLow-latency network for faster data transmission
Load Balancing:Distributed server architecture to handle high traffic loadsAutomatic scaling during traffic surges
Server Location Options:Multiple data center locations to choose fromAbility to select a server closest to your primary audience
Performance Monitoring Tools:Real-time performance metrics and analyticsTools to identify and resolve performance bottlenecks
Image Optimization:Built-in tools or plugins for automatic image compressionSupport for modern image formats like WebP
HTTP/2 and HTTP/3 Support:Implementation of latest HTTP protocols for faster content delivery

By prioritizing these performance factors, you can ensure that your WordPress site loads quickly and efficiently, providing a superior user experience and potentially improving your search engine rankings.

I recommend asking potential hosting providers about their specific performance optimizations and consider running performance tests on demo sites before making your final decision.

Security

Security is paramount when hosting a WordPress website. Dealing with a website breach or a defacement can be very costly, both financially and from a trust perspective.

Verify that the hosting provider implements robust security measures to protect your website from potential threats. Key security features to look for include:

Firewalls:Web Application Firewall (WAF) to protect against common web attacks. *I like to use Wordfence.*Network firewall to filter malicious trafficCustomizable firewall rules for specific security needs
Intrusion Detection and Prevention:Real-time monitoring for suspicious activitiesAutomated blocking of malicious IP addressesRegular security audits and penetration testing
Regular Security Updates:Automatic updates for server software and OSProactive patching of known vulnerabilitiesManaged WordPress core, theme, and plugin updates. Usually this isn’t something that hosting providers offer outside of automatic updates. A WordPress care plan will cover this, and the monthly maintenance checklist shows the recurring checks involved.
Malware Scanning and Removal:Regular malware scans of website filesAutomated malware removal toolsQuarantine system for infected files
SSL/TLS Certificates:Free SSL certificates (e.g., Let’s Encrypt)Easy installation and renewal processSupport for wildcard and EV certificates
DDoS Protection:Mitigation systems to handle Distributed Denial of Service attacksTraffic analysis to distinguish between legitimate users and attackers
Access Control:Two-factor authentication (2FA) for hosting account. *I recommend 2FA for your WordPress admin dashboard as well. I use Wordfence for this.*IP restrictions for WordPress admin areaStrong password enforcement
File Integrity Monitoring:Continuous monitoring of core WordPress filesAlerts for unauthorized file modifications
Database Security:Regular security audits of databaseProtection against SQL injection attacks
SFTP/SSH Access:Secure file transfer protocolsSSH access for advanced users with proper key management, Ideally, no password-based authentication.
Privacy and Compliance:GDPR compliance featuresData encryption at rest and in transitTransparent data handling policies
Security Headers Implementation:Proper configuration of HTTP security headersContent Security Policy (CSP) supportCross-Origin Resource Sharing (CORS) configurationImplementation of other crucial headers like X-Frame-Options, X-XSS-Protection, and Referrer-Policy
Isolated Environments:Account separation to prevent cross-site contaminationContainer or virtual machine isolation for enhanced security

By choosing a hosting provider with comprehensive security measures, you significantly reduce the risk of successful attacks, data breaches, and downtime due to security issues.

Remember to also maintain good security practices on your end, such as using strong passwords, two-factor authentication, keeping plugins updated, and limiting admin access.

Regular security audits and staying informed about the latest WordPress security best practices will further enhance your website’s protection.

Premium Add-ons

Specialist WordPress hosting providers will often partner with 3rd-party plugin developers to offer you bundles that you would normally need to pay a yearly license for.

For example, a caching plugin may be included as part of your package. The plugin will be optimised to work with the hosting provider’s systems, giving you the best performance you can expect out-of-the-box.

Other plugins may include free page builder tools, or security tools to help prevent bots and malware from scanning and hijacking your site.

Backups and Disaster Recovery

Confirm that the hosting provider performs regular backups and has a robust disaster recovery plan in place.

This is crucial for any website, regardless of the hosting type, to ensure quick restoration in case of an incident. Key aspects to consider include:

Backup Frequency:Daily automated backups at minimumOption for more frequent backups (e.g., hourly) for high-traffic or frequently updated sites
Backup Comprehensiveness:Full backups including all files, databases, and configurationsSeparate backups for files and databases for more granular restoration options
Retention Policy:Multiple backup versions retained (e.g., last 30 days)Option for longer retention periods for critical data
Storage Location:Off-site backup storage for added securityGeographically diverse backup locations to mitigate regional disasters
Backup Security:Encrypted backups to protect sensitive dataSecure transmission of backups to storage locations
Restoration Process:One-click restore options for ease of useAbility to restore to a specific point in timeOption to restore to a staging environment for testing
Backup Testing:Regular tests of backup integrityPeriodic restoration drills to ensure recoverability
User Access to Backups:Ability for users to initiate manual backupsOption to download backups for local storage
Disaster Recovery Plan:Documented procedures for various disaster scenariosClear communication channels during recovery processesRegular updates and testing of the disaster recovery plan
Recovery Time Objective (RTO) and Recovery Point Objective (RPO):Clearly defined RTO (how quickly the site can be restored)Clearly defined RPO (maximum acceptable data loss in case of an incident)
Scalability of Backup Systems:Ability to handle growing backup sizes as your site expandsNo significant performance impact on live site during backup processes
Compliance and Reporting:Backup systems that meet relevant compliance requirements (e.g., GDPR, HIPAA)Detailed logs and reports of backup and restoration activities

Remember, while hosting providers offer backup services, it’s always a good practice to maintain your own additional backups. This multi-layered approach ensures maximum protection for your valuable website data and quick recovery in case of unforeseen events.

Backups also need to be part of launch readiness and monthly maintenance. I have separated those into a WordPress pre-launch checklist for the foundation checks and a WordPress maintenance checklist for recurring care.

Resource Allocation and Limitations

When choosing a WordPress hosting provider, it’s crucial to consider the resources allocated to your site and any potential limitations. These factors can significantly impact your website’s performance, scalability, and overall cost-effectiveness. Key aspects to consider include:

Pricing Structure:Clear breakdown of costs for different plansTransparent pricing for renewals and upgradesAny hidden fees or charges for additional services
Storage Space:Amount of SSD storage providedScalability options for increasing storagePolicies on storage usage (e.g., what counts towards your limit)
Bandwidth Limits:Monthly data transfer allowanceOverage charges or policies if limits are exceededUnmetered vs. unlimited bandwidth (understand the difference).
CPU and RAM Allocation:CPU cores and RAM allocated to your hosting accountBurst capacity for handling traffic spikesUpgrade options for more intensive resource needs
Email Hosting:Number of email accounts includedStorage space for each email accountWebmail access and mobile sync optionsSpam filtering and virus protection featuresOutgoing SMTP server capabilities
Domain Management:Free domain registration with hosting (if offered)Domain renewal feesSupport for managing multiple domainsDNS management tools
Database Limitations:Number of MySQL databases allowedSize limits on databasesSupport for other database types (e.g., MariaDB, PostgreSQL)
Inodes Limit:Maximum number of files and folders allowedImpact on ability to install plugins, themes, and upload media
Concurrent Connections:Limits on simultaneous connections to your siteHow this affects high-traffic periods or bot activity
Backup Storage:Whether backups count towards your storage limitRetention period for hosted backups
CDN Usage:Integration with Content Delivery NetworksAny bandwidth or storage limitations for CDN usage
SSL Certificates:Inclusion of free SSL certificatesCharges for premium SSL options
Add-on Services:Costs for additional services like security scans, performance optimizationsManaged services fees (if applicable)
Scalability:Ease of upgrading or downgrading plansCosts associated with scaling resources
Fair Usage Policies:Any restrictions on resource usage, even on “unlimited” plansPolicies on CPU usage, script execution time, etc.

When evaluating these factors, consider not just your current needs but also your anticipated growth. A plan that seems sufficient now might become restrictive as your site grows.

Always read the fine print and don’t hesitate to ask the hosting provider for clarification on any limitations or restrictions.

Remember, the cheapest option isn’t always the most cost-effective in the long run if it restricts your site’s potential for growth and performance.

Uptime & Reliability

The reliability of your WordPress hosting is crucial for maintaining a consistently accessible website. When evaluating a hosting provider, consider the following aspects of uptime and reliability:

Service Level Agreement (SLA):Check for a clearly defined uptime guarantee (e.g., 99.9%, 99.99%)Understand how uptime is calculated (e.g., monthly, annually)Review compensation policies for failing to meet the guaranteed uptime
Historical Performance:Research the provider’s track record of reliabilityLook for third-party uptime monitoring reportsCheck user reviews and testimonials regarding reliability
Network Infrastructure:Multiple data centers in different geographic locationsRedundant network connections and power supplies
Monitoring and Support:24/7 server monitoring for quick issue detectionRapid response times for critical issues
Maintenance Windows:Scheduled maintenance during off-peak hoursClear communication about planned downtime
Transparency:Public status page showing real-time and historical uptime dataClear communication about any incidents or outages
Uptime Monitoring Tools:Provision of tools for customers to monitor their own site’s uptimeIntegration with third-party uptime monitoring services

Remember, while a 100% uptime guarantee might sound attractive, it’s generally unrealistic due to necessary maintenance and unforeseen issues. Look for providers that offer transparent, realistic uptime guarantees backed by a solid infrastructure and support system.

When reviewing the SLA, pay attention to how “uptime” is defined, what constitutes “downtime,” and what compensation (if any) is offered for failing to meet the guaranteed uptime. Some providers might exclude certain types of outages from their uptime calculations.

Control Panel and User Interface

The control panel is your primary tool for managing your WordPress hosting. A user-friendly and feature-rich interface is crucial for efficient site management. Consider the following aspects:

Ease of Use:Intuitive navigation and clear layoutUser-friendly design for users with varying technical expertise
Essential Functions:Backup creation and restorationEnvironment management (production, staging, development)Data migration between environmentsSoftware package and configuration management
Site Statistics:Easy access to key performance metricsInsights into site usage and visitor data
Log Management:Access to error logs and server access logsResource usage metrics (disk space, network traffic, etc.)
Team Collaboration:Ability to add team members with different permission levelsAvoid account sharing or overly permissive access
Security Features:Two-factor authentication (2FA) supportOther built-in security enhancements. Strong password requirements, public key management, etc.
Multi-Site Management:Single dashboard for managing multiple WordPress sitesEasy switching between different websites
Developer Tools:SFTP and SSH accessPublic key-based authentication supportAccount and key management for each site
Customer Support Access:Direct access to human support when neededSupport staff knowledgeable in hosting systems and WordPress
User Interface Customization:Options to personalize the dashboard layoutAbility to set preferred views or shortcuts
Mobile Compatibility:Responsive design for management on mobile devicesMobile app availability for on-the-go site management
Integration Capabilities:Support for popular third-party tools and servicesAPI access for custom integrations
Update Management:Easy WordPress core, plugin, and theme updatesOptions for scheduling or automating updates
Performance Monitoring:Real-time server resource usage displaysAlerts for unusual activity or resource spikes

When evaluating a hosting provider’s control panel, consider testing it through a demo or trial period if available. This hands-on experience can give you a better feel for the interface and help you determine if it meets your specific needs and preferences.

Developer Friendliness

For developers working on WordPress sites, certain features and tools can significantly enhance productivity and workflow efficiency. Consider the following aspects when evaluating a hosting provider’s developer-friendliness:

Command Line Access:SSH (Secure Shell) access to the serverSupport for popular command-line tools (Git, Composer, WP-CLI, etc.)
Version Control Integration:Git repository supportEasy deployment from Git repositoriesSupport for continuous integration/continuous deployment (CI/CD) pipelines
Staging Environments:One-click staging site creationEasy synchronization between live and staging sitesAbility to push staging to production
Database Management:phpMyAdmin or alternative database administration toolDirect MySQL/MariaDB accessDatabase backup and restore options
Customization Capabilities:Ability to modify PHP versions and settingsSupport for custom Nginx or Apache configurationsAccess to server-side caching configurations
Development Tools:Built-in or easy-to-install development tools (e.g., Xdebug)Support for task runners and build tools (Gulp, Webpack, etc.)Local development tools or integrations (e.g., Local by Flywheel)
API Access:RESTful API for managing hosting account and sitesWebhooks for automating tasks and integrations
Performance Testing:Built-in tools for load testing and performance profilingEasy integration with external performance monitoring services
Multilingual Support:Tools for managing multilingual WordPress sitesSupport for internationalization and localization workflows
Collaboration Features:Team member access controls and permissionsCollaborative coding environments or integrations
Scalability Options:Easy resource scaling (CPU, RAM, storage)Support for high-traffic configurations (load balancers, clusters)
Debugging and Logging:Detailed error logs with easy accessDebug mode toggle for WordPressLog retention and search capabilities
Security Tools for Developers:Easy SSL certificate management (including wildcard SSL)IP whitelisting for development accessTwo-factor authentication for SFTP/SSH
Compatibility and Testing:Multiple PHP version support for testingEasy creation of temporary URLs for client previews
Documentation and Resources:Comprehensive developer documentationAPI references and code examplesCommunity forums or knowledge bases for developers

When evaluating a hosting provider’s developer-friendliness, consider the specific tools and workflows you commonly use in your development process. A provider that aligns well with your preferred development practices can significantly enhance your productivity and the overall development experience.

Scalability

As your WordPress site grows, your hosting needs may change. A scalable hosting solution can accommodate this growth without requiring a complete migration. Consider these aspects of scalability when choosing a hosting provider:

Resource Scaling:Easy upgrades for CPU, RAM, and storageOption to scale resources up or down as neededAutomatic resource allocation during traffic spikes
Bandwidth Management:Flexible bandwidth limitsAbility to handle sudden traffic surgesClear policies on bandwidth overages
Vertical Scaling:Seamless upgrades to higher-tier plansMinimal downtime during plan changesClear upgrade paths and pricing
Horizontal Scaling:Support for load-balanced environmentsOptions for adding multiple servers or nodesDatabase replication and clustering capabilities
Database Scalability:Support for database optimization as site growsOptions for dedicated database serversDatabase caching mechanisms
Containerization and Microservices:Support for containerized environments (e.g., Docker)Ability to scale individual services independently
Elastic Storage:Expandable storage optionsSupport for external block storage solutions (e.g., Amazon S3, DigitalOcean Volumes)
Cost Management:Clear pricing for scaled resourcesTools to monitor and optimize resource usageFlexible billing options for variable resource needs

Migration Assistance

Some managed hosting providers offer free website migration services or tools, which can be helpful when switching from another hosting provider.

Automated migrations aren’t super complicated, but some issues can arise during a migration. Websites with large disk space requirements, millions of database rows, custom dependencies, legacy PHP support, or legacy plugins, sometimes need a helping hand and a bit of manual intervention from a WordPress developer.

Interoperability With Other Software Packages

I don’t want to go into too much detail with this point, but I think it’s an added bonus if you can find a managed hosting provider that offers support for services that you would often find alongside a WordPress website.

For instance, being able to run a Laravel application, a Discourse forum, or a Node.js server alongside your WordPress site. If these apps are supported and their underlying dependencies are kept up-to-date and secure, it makes things a lot easier for you to manage, as you aren’t switching between providers for each service.

A few unmanaged hosting providers, like DigitalOcean or Hetzner, allow you to run any software you like, but you are responsible for keeping the servers and applications operational and up-to-date. If you have an IT team supporting you, this can be a good option.

What Types of WordPress Hosting Are There?

The performance, security, and user experience of your WordPress site heavily depend on the quality of the hosting infrastructure it runs on.

When you are looking for a hosting provider, there are two options, managed and unmanaged. You can also self-host, but I won’t cover that here.

Unmanaged Hosting

Unmanaged hosting is usually cheaper - a hosting provider gives you a server and lets you do whatever you want, but you need to set it up yourself.

This option is great for experienced IT people who are comfortable managing servers and have the time to do so.

With unmanaged hosting, you are responsible for:

Installing and configuring the operating system
Setting up the web server (e.g., Apache or Nginx)
Configuring the database (e.g., MySQL or MariaDB)
Installing and configuring WordPress
Implementing security measures, such as firewalls and SSL certificates
Monitoring server performance and troubleshooting issues
Performing regular backups and updates

While unmanaged hosting provides more control and flexibility, it also requires more technical expertise and time investment.

Managed WordPress Hosting

Managed hosting can be quite pricey, depending on the level of service and the specific features included. However, it offers a more hands-off approach to hosting, as the provider takes care of many aspects of server management for you.

Managed hosting providers typically offer:

Server setup and configuration
WordPress installation and optimization
Automatic updates for WordPress core, plugins, and themes
Regular backups and easy restore options
Enhanced security features, such as firewalls, malware scanning, and intrusion detection
Performance optimization, such as caching and content delivery networks (CDNs)
Expert support and troubleshooting
Website migrations to their platform

Managed hosting is ideal for those who want to focus on their website and business, rather than worrying about the technical aspects of server management. It can save time and provide peace of mind, knowing that experts are taking care of the hosting infrastructure.

By carefully considering your hosting options and selecting a provider that meets your needs, you can ensure that your WordPress site has a solid foundation for performance, security, and reliability.

My Personal WordPress Hosting Provider Recommendations

In my experience as a freelance WordPress developer, I have worked with a wide array of hosting providers, including Cloudways, WP Engine, Siteground, IONOS, GoDaddy, and many others.

However, I have found a particularly strong partnership with The Positive Internet Company, a boutique WordPress hosting provider based in Carnaby Street, London.

Why choose Positive Internet?

Positive Internet owns and operates their own 100% green energy data centers, which aligns with my values of sustainability and reducing the environmental impact of web hosting.

They have been providing top-notch hosting services since 1998 and have a deep understanding of the Linux and WordPress ecosystem.

Some key advantages of partnering with Positive Internet include:

Fully managed WordPress hosting with expert support from their small, highly skilled technical team.
High-performance infrastructure optimized for WordPress.
Robust security measures and regular backups.
100% green energy data centres at their Positive Park location.
UK-based support team.
Scalable solutions to accommodate growth.

While every project has unique requirements, I have found Positive Internet to be an excellent choice for many of my clients, delivering fast, secure, and reliable WordPress hosting.

If you decide to partner with me, either for your next website build or as part of a Care Plan, I would highly recommend choosing a hosting package with Positive Internet. Get Started and we can discuss.

Transparent, Flexible Pricing at WildPress

Tue, 27 Feb 2024 00:00:00 GMT

Hi I’m James, the owner and lead developer at WildPress.

If you’ve worked with me before, you know I believe in simplicity and transparency.

Let’s talk about how I approach billing for the web development work you count on me to deliver.

When Fixed Rates Make Sense

Large, well-defined projects work great with a fixed rate.

I draw from over a decade of experience to give you a quote that considers all the nuts and bolts of your project’s scope. It’s upfront, fair, and aligns with the goals we set together.

Approximately 80% of my web development projects are undertaken at a fixed-rate basis.

The Flexibility of Hourly Rates

But what about those smaller jobs, where things are a bit more fluid or less predictable?

Maybe it’s adding a new feature, integrating a third-party service, or handling some ad-hoc website maintenance. In these cases, hourly billing gives us the flexibility to adapt as needed.

You don’t pay for full hours you don’t need; I work in 15-minute increments - one-quarter of an hour. That means more precise billing for you based on the actual time spent - with a minimum charge of £22.50 plus VAT.

If you’re a new client, the first piece of work has a minimum charge of one hour to cover initial setup, familiarising myself with your system, obtaining access, and verifying or setting up backups. The last thing either of us wants is an avoidable issue, so this protects both sides, acts as insurance if something goes wrong, and sets you up for a more secure and stable site going forward.

I offer flexible payment options for hourly invoices, via bank transfer, card payment, or Direct Debit.

Invoices are sent monthly in arrears, along with detailed timesheets.

Notes On Other Billing Structures

Day-Rate Billing

While day rates offer a clear-cut model for some, they don’t suit the way I like to work at WildPress - nor the value I want to provide to you.

Day rates are based on the premise of an uninterrupted eight-hour stretch, and the reality is, that’s not how creativity or coding always happens.

My workdays include necessary breaks for maintaining overall wellness and productivity, which don’t fit neatly into billable hours.

I prefer not to charge you a full day when my day also involves essential activities that aren’t directly client work - like keeping skills sharp with new training, or the unavoidable admin that comes with running a tight ship here at WildPress.

It’s about honesty and integrity; I bill you only for the time your project actively requires. This approach encourages a laser focus on your tasks at hand, ensuring you get premium service without paying for downtime or routine side activities.

Monthly Retainers

While I don’t offer traditional monthly retainers for ad-hoc work, I do offer WordPress Care Plans for ongoing technical upkeep.

Care Plans are designed around essential recurring needs: core updates, plugin and theme updates, backups, security monitoring, performance checks, and proactive maintenance to reduce risk before issues become incidents.

They also give you predictable support for the work that keeps your website stable, secure, and performing properly over time, without using a broad “bucket of hours” model.

For a more concrete view of what is included, see the WordPress maintenance checklist or the broader explanation of what a WordPress care plan covers.

All Care Plans are on monthly rolling terms from day one. There is no lock-in, and you can cancel at any time.

Your WordPress Development Partner

I’m committed to maintaining the high standards I’ve set for WildPress, and I believe that offering flexible and fixed-rate billing is part of how I do that.

Your projects deserve clarity and precision, and that’s what I strive to provide.

Got any questions or want to discuss an upcoming project? Get Started.

A Short Guide to WordPress Video Hosting

Mon, 18 Sep 2023 00:00:00 GMT

“How should I host videos on my website?” is a common question from my clients.

Whether it’s a background video, long-format content or a short animation introducing their product, they often receive high-definition, unoptimized files from their designers.

They want these files on their site - all with the guarantee of great quality and optimal performance, ensuring the videos aren’t buffering or pixelated.

This guide explores the pros and cons of different hosting options to help achieve that.

Self-Hosted Vs. External Video Hosting

Self-Hosted Videos

A self-hosted video is one where the video file, often in MP4 format, is uploaded directly to your website primarily through the WordPress Media Manager. The serving, streaming, and functionality of these videos are usually managed by the video player, either the one bundled with the browser or one enabled by a plugin/theme.

Sometimes an option to add varying formats like WebM might be available, but this requires encoding the video into these formats beforehand. Some plugins might let you do this automatically by uploading the video and having a third-party service encode it, similar to an image optimization plugin. However, I haven’t personally used any of these plugins.

Do note, storing multiple formats of the same video can significantly increase storage requirements. While third-party video hosting services streamline this process, self-hosting offers a degree of control they do not.

However, there’s an exception to these drawbacks if you anticipate needing custom features and have access to an experienced developer familiar with video encoding.

For instance, if you want a short, simple looping background video or custom JavaScript-related animations linked to the scroll bar, self-hosting can be ideal. Once your video is properly encoded, a developer could write a custom section for the embedded video that circumvents the drawbacks of coding, costs, and branding associated with external video hosting solutions.

In this way, self-hosting provides not just greater control, but also design freedom for these more intricate needs.

Pros:

Greater control over the video player and branding
Absence of external branding or end credits

Cons:

Large, unoptimized files can slow down your site or exceed your storage limits
Standard players do not dynamically adjust video quality based on the viewer’s connection, unlike Vimeo and YouTube
Content created in non-standard formats (e.g., .MOV files) might not be compatible across all devices

If self-hosted video is important to the design, treat it as part of the wider performance plan for the site. Hosting, caching, image/video compression, and Core Web Vitals all need to be considered together, which I cover more broadly in the WordPress hosting provider guide and the monthly WordPress maintenance checklist.

External Video Hosting

Among the options for external video hosting, Vimeo and YouTube are the most popular choices, with Vimeo usually being the favored one.

While YouTube offers the “modest branding” query parameter to reduce some of its branding and functionality like end cards, this feature isn’t as effective as it once was, causing the platform to display more of its branding than some users might prefer. On the other hand, Vimeo, though a paid platform, allows more options for you to personalize your video player and remove all of its branding.

Both platforms handle the encoding for you and provide their own players. This means they serve videos to viewers based on their internet speed and can even handle background videos. You have fewer styling options with these players, and once you choose a platform, you may feel somewhat locked in. However, they offer ease of use as they take care of most technical aspects for you.

Pros:

Handles large files and automatically adjusts video quality
Takes care of encoding and different video formats

Cons:

YouTube’s videos cannot be fully de-branded
Vimeo requires a paid subscription
Limited control over video player’s styling
Limited interactions with JavaScript for custom functionality like scroll play, auto-pause, or looping; bound by platform-specific APIs

Different Video Formats

When considering video formats, WebM and MP4 are the best choices for web use.

WebM: The preferred format due to its superior compression capabilities. Although it boasts broad compatibility with modern and updated browsers, it is not supported by certain legacy browsers, such as Internet Explorer.
MP4: Universally supported by all browsers, it provides a balance between quality and file size. It is not only perfect for older devices but also serves as an excellent fallback option for minor instances where WebM is not compatible.

Given the proprietary and dated nature of formats like MOV and AVI, their general lack of broad browser support, and their typically large file sizes, it’s best to focus on using WebM and MP4.

Looking to Add Video to Your WordPress Site?

If you’re reading this, you’re likely already contemplating integrating background video, creating a video library, or showcasing unique JavaScript animations on your WordPress site.

From managing a high volume of videos, upholding best practices in video encoding, or setting up accounts on YouTube or Vimeo - I’d be able to help.

With my extensive experience in WordPress-specific services, I can help optimize your site with the video content you need.

Get Started with me to discuss your needs further. I look forward to speaking with you.

Why I Use Astro More Than Hugo for Modern Marketing Websites

Tue, 12 Sep 2023 00:00:00 GMT

When I first wrote this article in 2023, I was much more enthusiastic about Hugo for new website builds.

I still think Hugo is an excellent tool. It is fast, stable, simple to deploy, and very good at turning structured content into a static website. For the right project, especially a simple blog or documentation-style site, it can still be a brilliant choice.

But I use it much less than I used to.

The reason is not that Hugo became worse. It is that I was trying to repurpose Hugo for websites that were always more complex than a traditional static blog.

The marketing sites I build need reusable sections, flexible page layouts, forms, analytics, integrations, and sometimes dynamic components that talk to APIs or internal systems. Hugo can be pushed in that direction, but I found myself adding more frontmatter, more template logic, and more project-specific workarounds than I wanted.

For that kind of work, Astro has become my default.

What Hugo is still good at

Hugo is very strong when the website is mostly a straightforward blog.

If you need a fast, simple publishing workflow built around Markdown files, Hugo still makes a lot of sense. It compiles quickly, produces static output, and keeps the runtime footprint very low.

That is a useful set of tradeoffs. For a very simple blog, I would still happily consider it.

It also encourages a clean separation between content and presentation. Editors can focus on Markdown content while the templates control the layout. For some teams, that is exactly what they need.

For documentation sites and knowledge bases, I would now usually start with Astro and Starlight instead. Starlight is Astro’s documentation framework, and it gives you a much stronger foundation for navigation, search, content structure, and documentation-specific UI without needing to build all of that yourself.

Where Hugo started to feel limiting

The friction appeared when I tried to use Hugo for marketing websites with lots of reusable sections and page variations.

Most business websites are not just a collection of blog posts. They need service pages, landing pages, case studies, comparison sections, testimonials, pricing blocks, forms, calls to action, product cards, resource hubs, and campaign-specific layouts.

Hugo can do this, but I found myself fighting the structure more often than I wanted to. Building and reusing flexible page sections was possible, but it often meant pushing more information into frontmatter, adding conditional template logic, and creating conventions that only really made sense for that one project.

That added complexity made the build harder to maintain. The site could work well, but the route to getting there felt more fragile than it needed to be.

That matters because consistency is one of the main things clients are paying for. I want to be able to create a section once, reuse it across different page types, adjust it safely, and keep the design system coherent as the site grows.

For simple blogs, Hugo’s model is elegant. For modern marketing sites with lots of varied sections, I found Astro easier to manage.

Why Astro became my default

Astro gives me the static-first performance benefits I liked about Hugo, but with a component workflow that fits the way I build websites now.

I can create reusable sections, layouts, cards, buttons, image components, and content templates in a way that feels natural. I can keep most pages lean and static, then add interactivity only where it is genuinely needed.

That island architecture is useful. If a page needs a React or Preact component, a calculator, a filterable interface, a search tool, or something that talks to an API, Astro handles that without forcing the whole site to behave like a heavy JavaScript application. Interactive pieces can be loaded only where they are needed, which protects performance instead of making every page pay for every possible feature.

The tooling also fits my current workflow better. Astro works nicely with TypeScript, Tailwind, content collections, image optimisation, component libraries, SEO integrations, sitemap generation, and modern build workflows. It is quick to start, but it does not feel limiting when the project grows.

I have even built a reusable WildPress Astro boilerplate for new static builds. It includes reusable components, Tailwind, Preact islands, image optimisation, validation scripts, sitemap generation, Pagefind search, and optional deployment support.

That kind of foundation makes it easier to start a project with good defaults instead of rebuilding the same decisions every time.

How this fits small business websites

Most WildPress clients are hands-on business owners. They are not usually asking for a static blog in isolation.

They need websites that support sales, marketing, enquiries, content publishing, campaign landing pages, analytics, automations, and internal workflows.

That is why Astro has become such a good fit. It lets me build fast marketing websites with reusable sections and clean templates, while still leaving room for dynamic functionality where the business needs it.

It also works well with modern client editing workflows. When Astro is paired with a Git-backed CMS such as Pages CMS, clients can update structured content while the site stays in version control. That makes changes easier to review, roll back, and deploy through separate environments.

For some clients, this now extends into AI-assisted editing. They can use tools such as Codex or Claude Code through a desktop workflow to request content and layout changes in plain language. Because the project has validation checks, version control, and deployment environments around it, I can give clients more control without removing the guardrails that keep the site stable.

Hugo can be used in similar workflows, and it may continue to improve for that kind of work. But for my current projects, Astro gives me the better balance of performance, structure, and flexibility.

Where WordPress still fits

Astro is not a replacement for WordPress in every situation.

For many business websites, WordPress is still the better choice because it gives non-technical teams a familiar editing experience, a mature admin area, and a broad plugin ecosystem. I cover that side of the decision in Why choose WordPress? and on the WordPress development service.

The right choice depends on the workflow.

If the client needs a full CMS, complex editorial permissions, WooCommerce, or lots of admin-managed content, WordPress may be the more practical foundation. If the client needs a fast marketing site, a cleaner frontend, and a more component-led build, Astro is often the better fit.

My current recommendation

I would still consider Hugo for a simple static publishing project, a blog, or a documentation-style website where the content model is clear and the layout needs are modest.

For most new marketing websites, I now reach for Astro first.

It keeps the speed and simplicity I liked about static-site generators, but gives me a better way to build the kind of reusable, flexible, business-focused websites that clients tend to need now.

If you are planning a new marketing website or considering a move away from an older static or WordPress setup, read more about Astro website development at WildPress.

My 6-Step Process for New Website Builds

Sat, 22 Jul 2023 00:00:00 GMT

Most custom website projects take 30-80+ hours of focused delivery. The difference between a stressful build and a smooth one is almost always process.

This is the exact 6-step framework I use on WordPress development projects, from initial scope through to launch and long-term support.

Gantt Chart Breakdown

The timeline I use is usually a 4-6 week shape, with overlap between discovery, design, development, QA, and content population.

The key point in the Gantt is dependency: design and copy sign-off control delivery speed, and final launch quality depends on enough time allocated to QA and deployment prep.

gantt
title Typical WordPress Project Timeline (Week 1-6)
dateFormat  YYYY-MM-DD
axisFormat  Week %-W
excludes    weekends
section Week 1
Discovery call                                           :milestone, a1, 2026-01-05, 0d
Initial high-level design review                         :a2, after a1, 2d
Scope review and proposal QA                             :a3, after a2, 2d
Contract signed                                          :milestone, a4, after a3, 0d
Deposit paid                                             :milestone, a5, after a4, 0d
section Week 2
Detailed design review and technical feedback            :b1, after a5, 2d
Dev and staging setup                                    :b2, after b1, 1d
Build Gutenberg blocks and components                    :b3, after b2, 5d
Build desktop layouts                                    :b5, 2026-01-19, 5d
Weekly client call - review and feedback                 :milestone, b4, 2026-01-16, 0d
section Week 3
Content migration (if needed)                            :c2, 2026-01-26, 5d
Weekly client call - review and feedback                 :milestone, c3, 2026-01-23, 0d
section Week 4
Build mobile layouts                                     :d1, 2026-01-26, 5d
Third-party integrations                                 :d2, 2026-01-26, 3d
Weekly client call - review and feedback                 :milestone, d3, 2026-01-30, 0d
section Week 5
Training call for non-technical managers                 :milestone, e3, after d1, 0d
Content updates                                          :e5, after e3, 5d
Weekly client call - review and feedback                 :milestone, e4, 2026-02-06, 0d
section Week 6
Final QA                                                 :f1, after e5, 2d
Pre-launch content updates and SEO checks                :f2, after f1, 2d
Weekly client call - launch readiness                    :milestone, f3, 2026-02-13, 0d
Deployment to Production                                 :milestone, f4, after f3, 0d
Performance optimizations                                :f5, after f4, 1d
Launch                                                   :milestone, f7, after f5, 0d
Final payment                                            :milestone, f6, after f7, 0d
section Ongoing
Post-launch call and review                              :milestone, g2, after f7, 1w
Ongoing support with a WordPress Care Plan               :active, g1, after f7, 1w

Step 1: Project Scoping

This stage defines what we are actually building and why. We map business goals to required pages, user journeys, integrations, and constraints.

Core outputs:

Scope boundaries and priorities
Page / template list
Required integrations and functional requirements
Delivery milestones and review points

If this step is rushed, everything downstream gets more expensive.

Step 2: Web Design and Copywriting

Design and messaging are developed in parallel, then validated against the agreed journeys from scoping.

Core outputs:

Wireframes and page-level hierarchy
Visual direction and component styling
Conversion-focused copy and CTAs
Mobile-first layout decisions

This is where projects either gain clarity or start accumulating revision debt.

Step 3: Web Development

Development turns approved design and copy into a production-ready build.

Core outputs:

Custom WordPress theme implementation
Reusable block/component setup
Form, CRM, analytics, and third-party integrations
Technical SEO foundations and performance setup

The Gantt overlap here is deliberate: content prep and QA begin before every page is 100% complete, which keeps momentum high.

Step 4: Manager Training

Before launch, stakeholders need confidence managing the site without developer dependency.

Core outputs:

CMS training sessions for your team
Editing workflows for key templates
Publishing and content governance guidance
Short handover documentation

Good training prevents post-launch bottlenecks.

Step 5: Deployment

Deployment is controlled and checklist-driven, not a last-minute push.

Core outputs:

Production environment validation
DNS / SSL / caching checks
Redirect mapping and launch QA
Go-live monitoring and rollback readiness

A calm launch is usually the result of disciplined prep in the previous phases.

For the detailed launch checks, use the WordPress pre-launch checklist. It covers ownership, access, backups, forms, analytics, Search Console, structured data, IndexNow, and recovery planning before a site goes live.

Step 6: Ongoing Support and Maintenance

Launch is the start of optimisation, not the finish line.

Core outputs:

Security and update management through a WordPress Care Plan
Performance and uptime monitoring
Iterative UX and conversion improvements
Priority fixes and roadmap support

For teams that want continuous improvement, this is where the real long-term value compounds. You can see the full support scope on the WordPress Care Plans service.

If you want to see the recurring work behind that support, the WordPress maintenance checklist breaks down the monthly checks across Maintenance, Performance, and Growth care plan tiers.

Why This Process Works

The Gantt structure keeps work visible, dependencies clear, and expectations realistic. Every step has a defined purpose and measurable outputs, so projects stay aligned and move forward without guesswork.

If you are planning a new build, you can see how this is applied in practice on my WordPress Development service.

Why choose WordPress?

Thu, 20 Jul 2023 00:00:00 GMT

WordPress continues to be my go-to for all website development, allowing me to offer my clients an infinitely scalable and practical solution for fully integrated and sales-focused website designs.

WordPress is my preferred platform for several reasons:

Open Source

It’s open-source, which means I can do anything I like with it without being restricted to a particular vendor (e.g. Shopify, Wix, Squarespace).

Active, Diverse Community

WordPress is one of the most popular content management systems (CMS), powering over 65% of all CMS-based websites.

It has a rich community and lots of plugins, allowing you to extend common functionality (e.g. event management, ecommerce, CRM integration) without having to write it from scratch.

Low Barrier to Entry

It’s low barrier to entry means clients often already have experience using it and don’t need to reskill to learn a new platform.

Cheap to Host & Maintain

It’s cheap to host and maintain, meaning less overhead for clients and myself. If you want to understand what that maintenance looks like in practice, I have published the monthly WordPress maintenance checklist I use as the basis for ongoing care plan work.

Flexible and Extensible

It’s very flexible, it can be used for almost any type of website, from a small blog, to eCommerce shops, to large scale international news/media sites, to multi-vendor marketplaces, etc.

For new builds, the platform choice is only one part of the decision. The delivery process matters just as much, so I have also written up my 6-step website build process and a separate WordPress pre-launch checklist for the checks that should happen before a new site goes live.