The standards behind a recommendation
We separate published facts, hands-on observations and editorial judgement. If a plan has not been purchased and tested, the page must not imply that first-hand performance testing has occurred.
- Identify the reviewer and the date of the check.
- Link changing plan and price claims to official provider material.
- Record limitations as clearly as benefits.
- Explain who a provider fits and who should avoid it.
- Do not let an affiliate relationship determine inclusion or verdict.
1. Source and market research
Before purchase, we record the publicly available plan name, term, checkout total, renewal information, data-centre choices, payment methods, support channels, control panel, backups and migration claims. Changing facts are dated and linked to the provider’s official source where possible.
This stage creates a research candidate. It can support a comparison of published offers, but it is not proof of uptime, speed or support quality.
2. Purchase and configuration record
A completed hands-on review should identify the purchased product, billing term, test date, selected region and material configuration. The record should also disclose whether the provider supplied the account or whether it was purchased independently.
The test website must be documented well enough to interpret results: platform version, theme or application, caching, CDN, PHP or runtime version, page composition and any important plugins.
3. Performance and reliability checks
Performance is measured on the configured website, not inferred from the company’s country or marketing. A useful test set includes server response, a representative page load, repeat views through cache, relevant test regions and behaviour under a documented level of concurrent traffic.
Results should show the date, tool, location and configuration. Short tests cannot establish long-term uptime, so availability observations must be described within the period actually monitored.
4. Support, backups and migration
We inspect the available support route and record what happened in a real interaction: channel, time, question, response time and usefulness. A fast greeting is not the same as solving the issue.
Backup claims are checked against the account experience where possible: whether backups can be found, retention is visible and restoration is clear. Migration evaluation records what is included, what the customer must do and whether email or DNS requires separate work.
5. Turning evidence into a verdict
A useful verdict names the audience, the strongest reason to choose the provider, the most important limitation and the cost context. It avoids a universal star score that hides different needs.
6. Updates and re-checks
Prices, product names, included resources and policies can change. Material facts display a checked or updated date. A meaningful update changes the visible date; cosmetic edits should not be presented as fresh research.
A provider can move up, move down or be removed when the evidence changes. Older results are not silently treated as current performance.
Corrections and conflicts
Readers and providers can send a correction with the page, disputed statement, source and date to contact@webhostingsrilanka.com.lk. Substantiated corrections are assessed against the same evidence standard. Commercial pressure does not justify removing a documented limitation.
Read the complete editorial, affiliate and corrections policy or learn more about reviewer Alston Antony.