How we fact-check

Most content sites say they fact-check. Few explain what that actually involves. We’re publishing our process so you can evaluate our standards for yourself - and so you can tell us when we fall short of them.

Blogger Nova is a one-person publication. Aman Singh (Founder & Editor) researches, tests, writes, fact-checks, and publishes every article himself. Because there is no second reviewer, the fact-check is a separate, deliberate pass rather than something done while writing.

Roles

• Drafting - Aman researches and writes the article, recording where each factual claim comes from as he goes.
• Fact-checking pass - Aman returns to the finished draft with fresh eyes and checks it claim by claim against our testing log and the original sources: speed, uptime, plans, and pricing or limit claims, as well as setup, performance tuning, and troubleshooting steps.
• Final check - a last read-through against the fact-checking notes confirms every flagged item has been resolved before the article is published.

No article is published without all three stages being completed.

Every article

Regardless of content type, the fact-check verifies:

• Review specifics - speed and uptime numbers, plans and pricing, resource limits, renewal costs, exceptions, and support channels are cross-referenced against an account we pay for and the host’s published terms at the time of publication.
• Claims attributed to our testing - any figure we present as tested (a load-time number, a renewal price, a CPU limit) is traced back to the corresponding entry in our internal testing log and its source URL. If the log doesn’t support the claim, the claim is revised or removed.
• Claims attributed to third parties - any data or finding we cite from an external source (an official status page, a published SLA, independent uptime monitoring) is verified against the original source. We do not rely on secondhand reporting of third-party data.
• Comparisons and rankings - when we say one host is faster or better value than another, we confirm the comparison is based on each host’s current plans and our own tests, run on comparable dates.
• Dates and currency - every review carries a “Last tested” date confirmed on the publication date. Because hosts change their plans and hardware, we note the test date and re-test during scheduled refreshes.

Content-type-specific checks

Different article types have additional verification requirements:

Host review hubs - we confirm the source of every figure (the host’s official pricing page, docs, or our own dashboard and benchmarks), verifies the “Last tested” date is current, and cross-checks that the speed, pricing, and limit numbers match the host’s plans and our measurements as they stand today.

Host comparisons - we verify that every host in a ranking was tested within the current cycle, that head-to-head comparisons use each host’s current plans and our latest tests, and that no host has quietly changed its pricing or hardware since it was last tested.

How-to and process guides - we confirm that the described steps match the host’s current dashboard and tooling (setup, migration, caching, backups), that screenshots and command guidance are accurate, and that any version-sensitive guidance (PHP versions, plugin compatibility) is current.

Hosting-types and concept articles - we verify that definitions (shared, VPS, managed WordPress, CDN, staging) are accurate, that plan and limit descriptions reflect how hosts actually apply them, and that examples cite a real, tested host.

Troubleshooting articles - we confirm that each described fix or remedy traces to current behavior or official guidance (the host’s docs, status page, the host’s own support), and that any escalation steps (support tickets, migrations, rollbacks) are accurate and current.

Not all sources carry equal weight. We use a tiered system to evaluate the reliability of information:

Tier 1: primary sources (preferred)

• Our own hands-on testing on an account we pay for - dashboard, benchmarks, and screenshots - documented in our testing log with the source URL and date recorded.
• The host’s own published plans, pricing, and official documentation.
• Official status pages, published SLAs, and uptime histories.
• Independent uptime and performance monitoring we operate or can reproduce.

Tier 2: trusted third-party sources

• Named monitoring and benchmarking services we have explicitly vetted and trust (e.g., established uptime-monitoring providers).
• Reputable reporting that cites a primary performance or pricing source we can trace back.
• On-the-record statements from host representatives, attributed by name and role.

Tier 3: contextual sources (not cited as evidence)

• Forum posts, Reddit threads, and user communities - may be quoted for color or to illustrate a common reader experience, but the underlying factual claim must be independently verified through a Tier 1 or Tier 2 source before publication.
• Support chat or phone answers - useful as a lead worth verifying but not treated as authoritative until confirmed against the host’s written plans or our own testing.
• Other media outlets’ roundups - we may reference for context but do not treat another publication’s figures as a substitute for our own hands-on testing of the host.

If a claim cannot be supported by a Tier 1 or Tier 2 source, it is either removed from the article or explicitly qualified with language that communicates the uncertainty (e.g., “reports suggest” or “based on user accounts, though we haven’t independently verified this”).

Here is the step-by-step process an article goes through:

1. 1Draft completion - Aman finishes the draft along with a source list documenting where each factual claim originated.
2. 2Step back from the draft - the draft is set aside before checking begins, so the fact-check is done as a reader working from the source list, not from memory.
3. 3Line-by-line review - Aman reads the article and flags every verifiable claim. Each flag is categorized as confirmed, needs source, needs revision, or remove.
4. 4Source verification - each flagged claim is checked against the cited source itself, and Aman records whether the source supports the claim as written. Where the source doesn’t fully support the claim, revised language is noted.
5. 5Revision - the draft is revised against the fact-checking notes. A claim that still can’t be settled is qualified or removed, following the source tiers above.
6. 6Final review - Aman re-reads the revised draft and confirms every flag has been resolved before publishing.
7. 7Publication - the article goes live under Aman’s byline.

The entire process typically takes 2–4 business days after the draft is finished, depending on the complexity of the article and the volume of claims that require verification.

Not every question has a clear, sourceable answer - especially when a host’s documentation is silent on an edge case or its performance varies in practice. When we encounter genuine uncertainty, we follow these principles:

• We say what we know and label what we don’t. If a detail hasn’t been verified through our own testing, we say so rather than presenting it as confirmed.
• We don’t speculate as fact. Predictions, expectations, and educated guesses are clearly framed as such, using language like “we expect,” “early indications suggest,” or “based on last year’s plans.”
• We revisit and update. If we publish with a qualified claim, we flag the article for follow-up once better information becomes available.

Fact-checking doesn’t end at publication:

• Reader-reported issues submitted through our contact page are read by Aman and checked against the same source standards described above.
• Scheduled refreshes (on a regular cadence for host review hubs, at least yearly for host comparisons) include a full re-test of speed, uptime, pricing, limits, and any claims that may have been affected by a host changing its plans or hardware.
• Corrections, when warranted, follow our corrections policy. Every substantive correction is logged publicly.

To be transparent about the boundaries of this process:

• Subjective assessments - when we describe a host as “fast” or its setup as “painless,” those are editorial judgments informed by experience. They reflect how the host compares, not a figure that can be checked against our test log. We don’t fact-check opinions, but we do ensure they’re grounded in the tested results.
• Future claims - we don’t verify predictions about plan changes a host hasn’t announced, future pricing, or upcoming feature launches beyond attributing them to their source.
• Third-party ad content - advertisements displayed on our site through programmatic ad networks are not subject to our editorial fact-checking process.