Prepare for publishing disruption by identifying dependencies, preserving authorized recovery copies and agreeing how your team will communicate if the main site becomes unavailable. No hosting location, mirror or CDN makes a website immune to blocking or legal restrictions. This is a continuity-planning workflow, not a guarantee of access or a personal-safety assessment.
WebCare360 publishes this guide and sells hosting. It describes work for the publisher and its operators; it does not promise that a hosting plan includes additional domains, replication, legal support or automatic failover.
Define the disruption you are planning for
Separate a hosting outage, lost administrator access, a domain problem, regional network interference and a service restriction following a complaint. Those events affect different dependencies. A second origin does not repair a lost registrar account, and a restored page does not settle a legal dispute.
Write a short scenario with the affected function, audience, acceptable interruption and person authorized to respond. If publication could endanger sources or staff, involve qualified security and legal help before testing or announcing a fallback. Access Now's Digital Security Helpline offers assistance to eligible civil-society users, subject to its intake and mandate. That is a specialist support option, not a WebCare360 service commitment.
Map dependencies and recovery access
| Dependency | Evidence to retain securely | Failure question |
|---|---|---|
| Domain and DNS | Responsible account owner, recovery method and DNS configuration | Can an authorized operator reach the control plane if the website is down? |
| Origin and application | Deployment instructions, required versions and operating owner | Can the site run elsewhere without an unavailable proprietary dependency? |
| Database and media | Recovery-copy scope, creation time and restore-test result | Which updates would be missing after restoration? |
| Identity and integrations | Login, email, payment and external-service dependencies | Which functions fail even if the front page loads? |
| Audience communication | Approved channel and its separate recovery access | Can the team publish an update without the affected site? |
Restrict access to this record. Store secrets through the team's approved credential process, not in a public runbook. Maintain required account information and renewal arrangements; an unreachable contact address can undermine recovery.
Evaluate a fallback against the actual failure
An independent recovery copy helps only if its content, credentials and restore procedure are usable. A second provider may reduce one dependency while still sharing a registrar, identity system or upstream service. Record those remaining dependencies instead of counting suppliers as proof of resilience.
A read-only mirror may suit a limited publication, but it can expose stale or withdrawn material. Define who approves its contents, how corrections and removals propagate and which interactive features must be disabled. Do not copy personal or disputed data into another service without the required authority. An alternative domain also introduces renewal, authentication and audience-verification work; it is not an automatic bypass or legal remedy.
A CDN can serve permitted cached responses within its configuration and service scope. Do not assume it stores the entire site, preserves authenticated functions or remains reachable during every restriction. Choose the fallback for a documented failure, and check its terms and operational limits before relying on it.
Rehearse without causing a public incident
- Use an authorized staging environment and non-sensitive data where possible. Define the scenario and test boundaries in advance.
- Restore the required content and exercise representative functions. Record the recovered data point and unavailable dependencies.
- Have a second authorized operator follow the runbook. Note inaccessible accounts, missing instructions and steps requiring provider assistance.
- Check the proposed audience update through the approved channel without announcing a real outage. Verify who can approve, publish and correct it.
- Record the result, unresolved gaps and rollback steps. A rehearsal shows what worked under those conditions, not guaranteed availability.
Distinguish observation from a censorship claim
A site that fails in one region is not automatically evidence of deliberate blocking. OONI's Web Connectivity documentation describes comparison of DNS, connection and HTTP behavior and warns about false positives. Review existing observations first; assess safety, authorization and measurement disclosure before collecting new tests. Do not ask a vulnerable user to test merely to confirm a hypothesis.
For an actual regional reachability fault, use the regional website reachability guide. For a received complaint, use the notice-response workflow and appropriate advice. Keep technical recovery separate from decisions about publishing disputed material.
Maintain the continuity record
Keep the scenario, dependency map, recovery evidence, authorized actions and communication owner together. Revisit them after an account, provider, application or publication-policy change. During an incident, communicate confirmed impact and the next update point; do not promise a restoration time that has not been established. The outcome is a rehearsed, bounded response plan, not a claim that censorship or disruption has been solved.
