The Layershift Logbook

You won't realise it at the time, but the hundreds of decisions you silently make (or these days, maybe your AI agent makes on your behalf?) when starting a new project determine how painful you'll find the inevitable security patching it needs throughout the rest of its lifetime.

Five hours. That is the activity-weighted median time from disclosure to first exploit that Patchstack recorded in 2025 for the WordPress vulnerabilities attackers targeted most heavily (Patchstack, State of WordPress Security in 2026).

Look up how much RAM a WordPress VPS needs and two figures appear again and again: 4GB, or 8GB to be safe. Both are sensible starting points, but neither tells you whether it's enough for your website.

If you're considering a move to a new hosting provider, there's usually a good reason behind it, and often a fair bit of hesitation alongside it. That's understandable. Your website or application matters to your business, and the idea of moving it somewhere new naturally raises questions. What if something breaks along the way? What if customers notice? What if it all takes longer than expected?

Not every AI bot is the same problem. Some make your content discoverable in search and AI answers. Some act on a real person's behalf, fetching a page because somebody asked an AI assistant to do something with it. Others exist purely to train a model, with no visit at the end and no benefit back to you. Treating all three as one "AI bot" toggle, block everything or allow everything, throws away the information you need to make a sensible decision.

Robots.txt tells cooperative crawlers what you want. It doesn't enforce anything: a robots.txt file is a request, not a lock, and it only works on crawlers that read it and identify themselves honestly. Our earlier post in this series covers whether to allow Search, Agent and Training crawlers; the bot-by-bot guide covers what each named crawler does.