Editorial Policy - How We Write and Review

This policy explains who writes the guides, what sources we rely on, how claims are checked, and what you can do when we get something wrong.

Last updated October 4, 2026

Scope of this policy

This policy covers the long-form guides on SiteDownCheck, the explanatory text shown beside tool results, and the help pages. It does not cover the tool output itself, which is produced by automated checks and is described on the methodology page. The guides cover about 32 topics in seven categories: Downtime and errors, Monitoring, DNS and domains, Email, SSL and security, Performance, and Web basics.

The aim is simple. A site owner who reads a guide should come away knowing what is happening, why, and what to do next, and should be able to trust that the technical details are accurate.

Who writes the guides

Guides are published under the name "SiteDownCheck Editorial". We do not attach individual bylines, and we do not invent author personas, credentials or biographies. The editorial team works for Your Name or Company Name, who operates SiteDownCheck.

What we commit to is a process rather than a list of credentials: every guide is drafted against primary documentation, checked against how our own tools behave, and reviewed before publication. You can judge a guide by its sources and its accuracy, and we try to make both easy to inspect.

What a guide should contain

  • A direct answer near the top, before background.
  • Concrete steps a reader can follow, including commands or settings where they help.
  • The conditions under which advice does not apply, such as different hosting setups or CDN behaviour.
  • A short FAQ for the questions readers most often ask next.
  • Links to the relevant tools, so a reader can verify the situation on their own domain.
  • An "Updated" date showing when the page was last reviewed or changed.

We avoid padding. If a topic needs 600 words, it gets 600 words, not 1,500 words of repetition. We also avoid manufactured urgency, invented statistics and unsourced claims about how many sites are affected by a problem.

Sourcing standards

We prefer primary sources over commentary. When a guide states how a protocol or product behaves, the statement should trace back to one of these:

  • Standards documents: RFCs and other specifications, for example for HTTP semantics, DNS, SMTP, SPF, DKIM, DMARC, TLS and RDAP.
  • Vendor and platform documentation: documentation from DNS providers, CDNs, hosting platforms, browsers and mail providers, when the subject is that product's own behaviour.
  • MDN Web Docs: for web platform features, HTTP headers and browser behaviour.
  • Browser, certificate authority and CA/Browser Forum documents: for certificate lifetimes, validation rules, root programme requirements and browser policy.
  • Registry and registrar policy: for domain lifecycle rules, such as grace and redemption periods.

Blog posts, forum answers and social media threads can help us find a topic or reproduce a problem, but they are not enough to support a technical claim on their own. Where a claim depends on a particular vendor or version, the guide says so. Where practice varies, we describe the variation instead of stating one rule.

How technical claims are tested

Where it is practical, we reproduce what a guide describes before publishing. For example:

  1. We run the relevant commands, such as curl, dig, openssl s_client or nslookup, against test domains we control.
  2. We confirm that the SiteDownCheck tool related to the guide reports the same behaviour.
  3. We check edge cases that commonly confuse readers, such as redirects that loop, chains that include a missing intermediate certificate, or SPF records that exceed the 10-lookup limit.
  4. We read the sections of the specification that govern the behaviour, not only summaries of them.

Some topics cannot be fully tested by us, for example how a particular mailbox provider filters mail or how a specific hosting company configures its firewall. In those cases the guide states what is documented, what is commonly observed, and where results may differ. We do not present an assumption as a verified fact.

Use of AI assistance

Drafting tools, including AI-based writing tools, may be used when preparing content, for example to produce an outline, suggest wording or check readability. We disclose this because readers have a right to know how content is made.

AI assistance does not replace review. Content is reviewed against primary documentation before publishing, and statements that cannot be supported by a source are removed or rewritten. We do not claim that every guide has been reviewed by a named specialist, because we do not want to over-state what the process delivers. We do not publish fabricated quotes, fake case studies, or made-up data, and we do not use generated content to impersonate people or organisations.

Updates and review cadence

Internet standards, browser rules and vendor products change. We handle this in three ways:

  • Scheduled review: guides are re-read periodically, with priority given to those that cover fast-moving topics such as certificate rules, email authentication requirements and browser behaviour.
  • Event-driven updates: when a relevant standard, vendor policy or tool behaviour changes, or when a reader reports a problem, the affected guides are checked soon after.
  • Visible dates: the "Updated" date on each guide changes only when the content has been reviewed or materially changed, not as a cosmetic refresh to look current.

We do not guarantee a specific review interval for every page. If you find a guide that seems out of date, please tell us.

Corrections

We want to hear about mistakes. To report one, email contact@sitedowncheck.com with the page address, the sentence you think is wrong, and, if you can, a source that supports your view.

  • We read corrections and aim to respond within a few working days.
  • If the report is right, we fix the page and update its date.
  • For significant errors, where following the advice could cause harm or an outage, we may add a short note describing what changed.
  • If we disagree, we will explain our reasoning where we can.

Independence and advertising

Editorial decisions are made independently of advertisers. Specifically:

  • There is no paid placement in tool results, and nobody can pay to change what a tool reports.
  • Guides are not sponsored. We do not accept payment to recommend a product, host or service in a guide.
  • If advertising is enabled, for example through Google AdSense, ads are labelled and kept apart from tool results and from the body of the guides. They do not alter what we write.
  • Where consent is required before showing personalised ads, we ask for it. See the Privacy Policy.

If we ever add affiliate links or sponsored content, they will be clearly marked at the point they appear, and this policy will be updated first.

Conflict of interest: our own product

SiteDownCheck operates an uptime monitoring product. Several guides, especially those on monitoring, status pages and alerting, mention it because it is relevant and readers can try it for free. This is a conflict of interest, and we want you to see it plainly.

To limit the effect:

  • Guides explain the concept first, so the advice is useful whichever monitoring service you use.
  • We describe what our monitoring does and does not do, including limits such as the free plan having 3 monitors and checks from our own servers.
  • We do not disparage other services or make unsupported comparative claims.
  • The Pro plan is described as coming soon, not as an available feature.

Reader feedback

Feedback of any kind helps, whether it is a correction, a topic request or a note that a section was confusing. Use the contact page or write to contact@sitedowncheck.com. We cannot respond to everything individually, but feedback is read and it shapes what we update next.