Publisher hosting where the archive earns more than the homepage.
Most of your traffic lands on something written years ago, from a search result, on a phone, with an ad stack loading on top of it.
The back catalogue is the product.
Publishers are unusual in that the majority of value sits in content nobody is currently editing.
Fifteen years of URLs that still work
Every redesign, CMS move and category rename leaves a layer of redirects behind. Those are resolved at the edge and kept as a permanent record rather than as a plugin's database table.
An ad stack with a stated budget
Header bidding, consent and measurement scripts all compete with the article. Their weight is visible, so the revenue-versus-speed conversation is based on numbers rather than on instinct.
Syndication that costs nothing
Feeds, AMP-style endpoints and partner exports are polled constantly by machines. They are cached and revalidated, so aggregators are not a second audience the origin has to render for.
An archive that stays queryable
Two hundred thousand articles with tags, authors and series is a large dataset. Archive and author pages are indexed rather than left to scan the post table.
Corrections without collateral damage
Editing a decade-old piece should update one page, not invalidate the whole archive at the edge. Purges are scoped to what actually changed.
Traffic from things nobody is editing.
A newsroom's attention is on today. Its traffic is spread across everything published since the site launched, and that mismatch decides what the hosting has to be good at.
- Redirect history preserved and resolved at the edge
- Third-party ad and measurement weight surfaced
- Feeds cached with validators
- Archive queries indexed
The score is set by the ad stack.
A publisher's Core Web Vitals are rarely decided by the server. They are decided by what loads on top of a page the server already delivered quickly.
What we change for publishers
Every row follows from the archive being both the asset and the traffic source.
| Setting | What we do | Why |
|---|---|---|
| Redirect history | Retained across every past move and resolved at the edge | A publisher accumulates layers of redirects from years of redesigns, and evaluating them in PHP on every miss makes the oldest URLs the slowest ones. |
| Third-party budget | Ad and measurement script weight reported | Server response is rarely what fails a publisher's Core Web Vitals, and without a number the revenue-versus-speed argument has nothing to stand on. |
| Feed delivery | Cached with validators for aggregators and partners | Syndication endpoints are polled by machines on a timer, which makes them more frequently requested than any article on the site. |
| Archive indexing | Author, tag and date queries indexed | Section and author pages scan a post table with hundreds of thousands of rows, and they are exactly where search traffic lands. |
| Purge scope | Narrowed to the content that changed | Correcting one old article should not invalidate an archive that took hours of traffic to warm. |
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.
Will my old article URLs keep working?
Why are my Core Web Vitals bad when the server is fast?
Do syndication feeds cost me traffic capacity?
Does editing an old post clear the whole cache?
Make the back catalogue fast.
Move the publication across. Migration is free, redirects included.