Redirect hosting where rules resolve before WordPress loads.
A redirect plugin evaluates its rules by booting WordPress on every miss. After a site restructure that means the busiest requests on the site are the most expensive ones.
A miss is the expensive path.
Redirects only run on requests that did not match anything, which is exactly the path nobody optimises.
Rules answered without booting the application
A restructure produces thousands of rules evaluated on every 404. Resolving them at the edge turns the most frequent request on the site into the cheapest one.
A 404 log that cannot fill the disk
Logging every miss is genuinely useful and grows faster than anything else on the site, because most misses are bots. Retention is bounded deliberately.
Loops and chains caught before launch
A rule pointing at a URL that another rule redirects is a chain, and two rules pointing at each other is a loop. Both are checked rather than discovered by a crawler.
Rules that survive a migration
Redirect tables are plugin data, so they are easy to leave behind in a move. They are carried over deliberately, because losing them undoes years of link equity.
Regex rules kept off the hot path
Pattern rules are evaluated in order against every miss, so a long list of them makes every 404 progressively slower.
Optimised last, requested most.
After a restructure the highest-volume route on a site is often the redirect path - old URLs from search results, old links, and bots working through a stale index.
- Redirect rules resolved at the edge
- 404 log retention bounded
- Chains and loops detected before launch
- Rules migrated deliberately
The old URL should be fast too.
Search results and inbound links keep sending traffic to old URLs for years, so the redirect path is a permanent part of the site rather than a migration artefact.
What we change for redirect management
Redirects live on the request path nobody tunes, and they stay there for years after the migration that created them.
| Setting | What we do | Why |
|---|---|---|
| Rule resolution | Answered at the edge ahead of the application | A plugin evaluating thousands of rules requires booting WordPress on every miss, which makes the most frequently requested path the most expensive one. |
| 404 log retention | Bounded with a stated window | Logging every miss is useful and grows faster than any content table, because the overwhelming majority of misses are automated. |
| Chain and loop detection | Checked before rules go live | A rule pointing at a URL another rule redirects wastes a hop on every request, and two pointing at each other is an outage for those URLs. |
| Migration handling | Redirect tables carried across deliberately | They are plugin data rather than content, which makes them easy to lose in a move - and losing them discards years of accumulated link equity. |
| Pattern rule ordering | Regex rules kept short and ordered | Pattern rules are tested in sequence against every miss, so a long list makes each 404 progressively slower than the last. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Do thousands of redirects slow a site down?
Should I log 404s?
What is a redirect chain and why does it matter?
Will my redirects survive a migration?
Make the old URLs fast too.
Move the site across. Migration is free, redirect rules included.