Review Site Hosting

Review site hosting where every rating is counted once.

A review site is a publishing site with a write queue bolted on. The reading is cacheable and the writing is not, and the average score sitting on the page is what breaks when those two are configured as if they were the same thing.

Aggregates recalculated in the backgroundSubmission endpoints never cachedFree migration
Rating-aware cachingRedis object cachePlatform cronDaily backupsFree SSL24/7 support
Built for user-submitted content

Everything a ratings site asks of a host.

Reviews arrive in bursts, are read thousands of times each, and change a number that is printed on every page they touch. Each of those is a different problem.

Aggregates that do not run on the request

Recomputing an average over every review of a product while a visitor waits is the classic review-site stall. The recalculation is moved to a background job and the stored value is what pages read.

Stored aggregatesRecalculated in the background

Submission endpoints excluded from cache

The form that accepts a review, the endpoint that records a helpful vote and the nonce that protects both are dynamic by definition. They are excluded from the page cache rather than fighting it.

Never cachedNonces stay valid

Spam rejected before WordPress loads

Review forms attract automated submissions at a volume unrelated to your real traffic. Rate limiting happens at the edge, so a flood costs bandwidth rather than PHP workers.

Moderation queues that drain on schedule

Pending reviews, notification emails and reminder digests are scheduled work. Platform cron runs them at the time they are set for rather than when the next visitor happens to arrive.

Structured data that survives the cache

Rating markup is generated with the page, so a cached page carries the score it was built with. Purging on a new review is what keeps the markup and the number in agreement.

Staging for scoring changes

Changing how a score is weighted rewrites numbers across the whole site. Do it on a clone, compare the output, then push it.

Operations

Watch the queue, not just the traffic.

On a review site the interesting metric is not visitors. It is how many submissions are waiting, how long the aggregate job took, and whether the last purge covered every page the score appears on.

  • One-click admin login, no shared passwords
  • Per-site resource and storage view
  • Plugin and core updates with per-item status
  • Restore any daily backup from the dashboard
Moderation queue
Drained hourly
0 waiting
Aggregate job
Background, off-peak
04:10
Edge rate limit
Form endpoints
active
Nightly backup
Replicated offsite
02:22
Performance

A product page with four hundred reviews.

The page is cacheable. What decides whether it can be built at all is how the reviews are counted and how they are paginated, and both are configuration rather than content.

Stored
aggregates, not live SUM()
Redis
object cache, on by default
14
edge regions
MagicWP130 ms
Averages computed per request1100 ms
All reviews rendered on one page640 ms

Illustrative comparison of a heavily reviewed product page. Your numbers depend on review count and how aggregates are stored.

Configuration

What we change for a review site

These differ from a standard WordPress site on the same plan, and each one follows from the same fact: the number on the page is derived from rows that keep arriving.

SettingWhat we doWhy
Rating aggregatesStored and recalculated by a background job rather than summed on readAn average computed across every review row on each page view gets slower with every review the site succeeds in collecting, which turns popularity into a performance problem.
Cache purgingScoped to the pages a new review changes, including listings and category rollupsA score printed on a product page also appears in listings and top-rated widgets, so purging only the product leaves the same review showing two different averages.
Submission endpointsExcluded from the page cache and from bot challengesA cached submission form serves a stale nonce, which rejects the review and reads to the visitor as the site being broken.
Edge rate limitingApplied to review and vote endpoints specificallyAutomated submissions target the form rather than the site, so a limit that protects everything equally either throttles readers or lets the flood through.
Review paginationServer-side, with comment splitting enabledRendering hundreds of reviews into one response spends memory on markup nobody scrolls to, and it is the memory limit rather than the query that fails first.
Plans

Simple, transparent pricing.

Every plan includes free migration, daily backups, SSL and 24/7 support.

MonthlyYearly
Starter
For personal sites, blogs, and portfolios.
$20/mo
Billed $240 yearly · save $60
  • 1 WordPress site
  • 10 GB NVMe disk
  • Free SSL
  • Daily backups
  • One-click deployment
  • Support tickets
Start free trial
Pro★ Most popular
For growing businesses and busy stores.
$80/mo
Billed $960 yearly · save $240
  • 5 WordPress sites
  • 50 GB NVMe disk
  • Free SSL
  • Daily backups
  • One-click deployment
  • Priority support tickets
Start free trial
Enterprise
For agencies and high-traffic platforms.
$250/mo
Billed $3000 yearly · save $600
  • 20 WordPress sites
  • 200 GB NVMe disk
  • Free SSL
  • Daily backups
  • One-click deployment
  • Dedicated support
Start free trial
FAQ

Questions, answered.

Why do my average ratings sometimes look wrong?
Almost always a purge that missed a page. The score lives on the product page, in listings and in top-rated widgets, so a new review has to invalidate all of them or two pages will disagree until something else clears the cache.
Can the site handle a few hundred reviews on one product?
Yes, provided the average is stored rather than summed on every request and the reviews themselves are paginated. Both are set up here by default, because that combination is what stops a popular product becoming the slowest page.
How do you handle spam review submissions?
Rate limiting at the edge on the submission endpoints, so automated traffic is rejected before it reaches PHP. It costs bandwidth instead of workers, which is the difference between a nuisance and an outage.
Will the rating markup in search results stay accurate?
It is generated with the page, so a cached page carries the score it was built with. Keeping it accurate is a purge question rather than a markup question, and the purge rules are configured for it.
Can I change how scores are weighted without breaking the site?
Do it on a clone. A weighting change rewrites numbers across every page at once, so the useful move is to compare the new output against the old before it becomes live.

Collect the reviews without slowing down the page.

Start in minutes, or let our team move your review site across - no card, no commitment.