This is part 7 of an 8-part series on migrating a fleet of roughly 40 WordPress sites from two shared-hosting providers (A2 Hosting and SiteGround) onto a self-managed Hestia Control Panel VPS with Cloudflare as the DNS layer. “Self-managed Hestia Control Panel VPS” does not imply exotic or special-purpose hardware: Hestia runs on any generic x86_64 Linux box. Our own instance is a Hetzner Cloud CPX32 (4 vCPU, 8GB RAM, roughly 160GB SSD disk, running Ubuntu 24.04), reachable over Hetzner’s standard shared datacenter network like any other cloud VPS, not a dedicated line or special connection.
This series is written for the sysadmin who is considering doing this themselves and wants to know exactly how hard it actually is before they start.
Part 7: Redirect-only and alias domains
Not every domain in a fleet needs a real hosting account. Defensive brand registrations, old domains whose content has genuinely moved elsewhere, and typo-variant domains all just need to 301 somewhere real.
The pattern we settled on: point the root and www records at Cloudflare’s documented placeholder IP (192.0.2.1), switch those two records to Proxied (the one deliberate exception to the DNS-only default described in Part 2, since Redirect Rules only evaluate proxied traffic), and create a Cloudflare Redirect Rule matching the hostname:
(http.host eq "olddomain.com") or (http.host eq "www.olddomain.com")with a static 301 redirect to the real destination URL. This is a clean, zero-maintenance pattern: no web server config on your own box at all for these domains, and Cloudflare handles the redirect at the edge.
Two things to watch for specifically with this pattern:
It inherits the same nameserver-pair fragility as everything else. If a redirect-only domain’s registrar nameservers point at the wrong Cloudflare pair for that zone, the domain doesn’t “redirect to nothing,” it fails to resolve at all, because there’s no live zone answering for it. From the outside this looks identical to the domain being completely dead, which is a worse-looking failure than a broken redirect would be.
Sometimes the redirect survives independently of the DNS records around it. On one domain in this fleet, the DNS zone had accumulated over 30 stale, unrelated leftover records from a previous, unconnected hosting arrangement (pointing at an old cPanel host that had nothing to do with the current setup), while the Redirect Rule itself, set up correctly at some earlier point, had been sitting there active the whole time, just unable to fire because the DNS records it depended on had drifted. The fix was a full DNS cleanup, deleting everything unrelated and re-adding just the two placeholder records, at which point the pre-existing Redirect Rule started working immediately. Check for an existing rule before assuming you need to build one from scratch.