Managed WordPress hosting on Google Cloud in London

Every site runs in Google Cloud’s London region, in its own isolated space on Google Kubernetes Engine. Each WordPress site has its own database and database user, and network rules stop sites reaching each other or the platform’s internal services. Production sites run as two copies, and if one stops, Kubernetes starts a replacement without you noticing.

Images, PDFs and downloads are served from Google’s content delivery network, from a location near each visitor. WordPress itself sits behind two caches: Memcached keeps the results of database queries, and a page cache serves finished pages without running PHP each time.

If you want smaller images, I can turn on WebP for your site. New uploads then get a WebP copy, which is usually 20 to 30 percent smaller than the original.

The WordPress login and admin pages sit behind Google’s Identity-Aware Proxy. Before WordPress shows a login form, the visitor has to sign in with a Google account that you have listed. Bots that scan the internet for WordPress login pages get nothing back from yours.

All traffic passes through Google Cloud Armor, which blocks common attacks such as SQL injection before they reach your site. The web server also refuses requests for the files attackers probe for, including readme files, hidden files and PHP files in the uploads folder.

I keep WordPress, plugins and themes up to date for you. In September 2026 a serious flaw in WordPress core was published that could let an attacker run code on a site. Every site I host was already on the fixed version. I then added a second lock to every WordPress site: PHP can only open files inside that site’s own folders, so a future flaw of the same kind has much less to reach.

Every site has a certificate from Google, renewed automatically, and the platform only accepts TLS 1.2 or newer.

A checker in a different Google region, on another continent, loads every site’s home page and health check every 5 minutes. After three failures in a row it alerts me. The dashboard shows 90 days of uptime history for each site. An external monitor can also check your site from several locations, and clients with several sites can have a public status page to share with their own users.

Everything I can safely hand over is in your dashboard, behind the same Google sign-in as your WordPress admin. From it you can:

• browse and upload files
• read access logs, error logs and the mail WordPress sends
• choose who gets copies of WordPress notices
• take a snapshot, clear the caches or flush the content delivery network
• manage who can sign in to the site
• edit your DNS and check your email authentication
• make short links and QR codes
• raise and follow support tickets

The dashboard includes an AI assistant you can ask about your site in plain English, such as why the site was slow at lunchtime or which plugins are installed. It has read-only access to your site’s logs, database, caches and resource use, so it can look things up and report back. It can’t change anything. It can fetch and screenshot a page, and if it finds something that needs me, it can raise a ticket from the chat. Each person has a daily usage limit, and it only sees data from your own sites.

Tickets and emails come to me. I reply within 24 hours, and a site that’s down gets my attention as soon as the monitoring alerts me. I know how every part of the platform fits together, because I built it.

Not every site needs WordPress. Brochure sites, landing pages and documentation sites can run as static sites for £5 a month, on the same content delivery network. They include contact forms with spam protection, and you can keep a section private for people with a Google account you have listed.