A small website disaster recovery plan is a short written document that tells you who to call, what to check first, and how to restore the site when something breaks. It lists your hosting provider, domain registrar, DNS provider, developer, and decision maker, and it points to a backup you have already tested. Run the same seven steps every time: Identify, Contact, Contain, Restore, Test, Communicate, Document.<\/p>\n\n\n\n
Most owners have never written any of this down. They find out at 2 a.m. that nobody remembers which email address controls the domain, or that the backup lives on the same server that just died.<\/p>\n\n\n\n
We have hosted more than 700,000 websites over 20+ years, and the longest outages are rarely the ones with the worst technical cause. They run long because nobody knows who owns which piece. The plan below fixes that first. When everything breaks, you should not be working out what to do. The plan should already say.<\/p>\n\n\n\n
A small website disaster recovery plan needs five parts: an emergency contact list, an inventory of everything the site depends on, a safe way to reach critical logins, tested backup and restore steps, and a ranked list of the website functions your business cannot lose. Keep the whole thing to a few pages. A plan nobody reads in the middle of an outage is only a file.<\/p>\n\n\n\n
Start with names and numbers, because that is what you will reach for first. Write down your hosting support channel, your registrar, your DNS provider, your developer or agency, and the one person in the business who can approve spending money. <\/p>\n\n\n\n
Add a backup contact for each, since the primary person will be on a flight or asleep when it matters. Include the hours each contact works. We run 24\/7 support, but even round the clock support can only help someone who can prove they own the account, so record the account email and any verification PIN beside each entry. Check every number twice a year. The most common failure in these lists is a contact who left the company months ago.<\/p>\n\n\n\n
An inventory is a plain list of every moving part behind the site. Record the domain name, where it is registered, where DNS is managed, the hosting type, the server location, the content management system and its version, the plugins that matter, the CDN, the email provider, and the payment gateway. <\/p>\n\n\n\n
A typical small business site is rarely one thing. Picture a WordPress store on shared web hosting<\/a>, with Cloudflare in front, email at a separate provider, and a payment plugin talking to an outside gateway. That is four places the site can fail, and four different companies to call. Writing the list takes an hour. Rebuilding it during an outage takes much longer, usually while customers are emailing you.<\/p>\n\n\n\n Your plan needs a way to reach the logins, but the plan itself must never contain them. Put credentials in a business password manager, give each recovery role its own access, and turn on multi factor authentication for the registrar, the host, and the DNS provider. Then solve the part people forget. <\/p>\n\n\n\n Decide who else can get in if you cannot. Store recovery codes in the password manager’s emergency access feature or in a sealed envelope held by a second trusted person. A lost or replaced phone that holds the only MFA codes can lock an owner out of the registrar for days while identity checks run. Plan for that before it happens.<\/p>\n\n\n\n Two terms keep this section honest. Recovery point objective is how much recent data you can afford to lose, such as the last day of orders. Recovery time objective is how long the site can stay down before the business is hurt. Pick both numbers, then check that your backups meet them. <\/p>\n\n\n\n A nightly backup cannot give you a one hour recovery point. Store at least one copy somewhere other than the web server, because a backup on the failed server fails with it. Write the restore steps in plain language, including who starts them. Tools like the Softaculous auto installer<\/a> can create backups of installed applications, but you still need to confirm where those files are stored and whether anyone has ever restored one.<\/p>\n\n\n\n Not every page deserves the same urgency. List the functions that earn or protect money: checkout, booking, quote forms, the phone number on the contact page, and business email. Rank them. <\/p>\n\n\n\n A dental clinic can live without its blog for a week but not without its appointment form for an hour. Mark each function with the longest outage you can tolerate. This ranking decides the order of restoration later, and it settles arguments when everyone wants their own page fixed first. <\/p>\n\n\n\n It also shapes what you spend. If checkout cannot be down for more than an hour, a single cheap server with weekly backups is not a plan. It is a hope.<\/p>\n\n\n\n Call the party that controls the layer that is failing, and work out which layer that is before you dial. Start with your hosting provider if the whole site and its email are down, your registrar or DNS provider if the domain does not resolve, and your developer if only the website application is broken.<\/p>\n\n\n\n Call your host first when the whole site is unreachable and email on the same account has stopped too. That pattern points at the server or the account rather than your website’s code. <\/p>\n\n\n\n Give support the account ID, the domain, the exact error message, the time the problem began, and anything you changed in the last day. That last item matters more than owners think, because a plugin update an hour before the crash is often the answer. Our team handles tickets 24\/7, and you can see how end user support<\/a> works on its own page. <\/p>\n\n\n\n Be clear about one limit. Hosting support can fix the server and restore its own backups, but it cannot repair a broken theme.<\/p>\n\n\n\n Call the registrar when the site shows a domain not found error, when the domain looks parked, or when a nameserver change did not take effect. <\/p>\n\n\n\n Expired domains cause more panic than almost any other failure, and they are entirely preventable. Registrars send renewal warnings to the contact email on file, and that address is sometimes a former employee’s inbox or a freelancer’s old account. Check the expiry date today. Turn on auto renew, and confirm the payment card on file has not expired. <\/p>\n\n\n\n f the domain did lapse, act the same day, because many registrars move expired domains through grace and redemption stages whose rules and fees differ by company and by extension.<\/p>\n\n\n\n DNS translates your domain name into the server address. If it is wrong, visitors reach nothing even though your server is perfectly healthy. Contact your DNS provider when records changed unexpectedly, when only some visitors can reach the site, or after a server move. If a CDN sits in front of the site, check it too. <\/p>\n\n\n\n With Cloudflare, an error such as 522 means the CDN reached out but your origin server did not answer in time, which sends you back to hosting. We offer CloudFlare CDN<\/a> with our plans, and its dashboard login belongs in the same recovery vault as the registrar. Know where your DNS is managed. Many owners assume it is the host, discover it is the registrar, and lose precious time.<\/p>\n\n\n\n Call your developer when the server is up and the domain resolves but the site shows a white screen, a database connection error, a broken layout, or a 500 error. Those point at the application. Send the developer the error, the time, and the last change made. <\/p>\n\n\n\n Agree in advance what an emergency call costs and whether they answer evenings. Freelancers get sick and agencies get busy, so name a second person who knows the stack. <\/p>\n\n\n\n If you manage client sites yourself, a reseller hosting<\/a> account gives you one control panel to start from, and your clients are reading this section from the other side. They want to know you will pick up the phone.<\/p>\n\n\n\n Bring in a security specialist when you see redirects to spam sites, pages you did not publish, unknown admin users, or a warning from the browser or a search engine. Do not clean it alone and hope. <\/p>\n\n\n\n Verizon’s 2026 Data Breach Investigations Report<\/a> found ransomware in 48% of breaches, and a summary from the Cyber Readiness Institute<\/a> says small organizations made up 96% of ransomware victims. Treat that second number carefully. <\/p>\n\n\n\n Ransomware mostly hits business networks, while a compromised website more often means injected malware or spam pages. The lesson still carries over. Verizon also found software vulnerabilities were the most common way in, ahead of stolen passwords, so your specialist should check both, and your plan should name that person before you need them.<\/p>\n\n\n\n Technical people can fix the site, but only a business owner can make the decisions that cost money or customers. Name that person in the plan. They approve emergency spending, decide whether to take the site offline, and choose between restoring last night’s backup or repairing the live site. <\/p>\n\n\n\n That last choice is real. Restoring an older backup erases orders and form entries made since, and someone has to accept that loss. Give the decision maker a one page summary format: what broke, what it affects, what the options cost, and when the next update arrives. Also decide who tells customers. Silence during an outage does more damage than bad news.<\/p>\n\n\n\n Spend the first 30 minutes confirming the problem, narrowing it to one layer, saving evidence, and opening tickets with the right people. Do not start restoring anything until you know what failed, because a rushed restore can overwrite the very files and logs that explain the problem.<\/p>\n\n\n\n Before you raise an alarm, check that the site is down for everyone and not only for you. Load it on your phone using mobile data, ask someone on a different network to try, and run it through a free uptime checker. <\/p>\n\n\n\n Your own browser cache, a local DNS cache, or a company firewall can all make a healthy site look dead. This takes three minutes and saves you from waking your developer over nothing. <\/p>\n\n\n\n It also tells you something useful. If the site loads on mobile data but not on your office network, the problem sits with your connection. If it fails everywhere, write down the time and move on.<\/p>\n\n\n\n Open the status pages for your host, registrar, DNS provider, CDN, payment gateway, and email service. Bookmark them in advance, since you cannot search for them calmly during an incident. <\/p>\n\n\n\n A published provider outage changes your plan completely. You stop troubleshooting and start communicating, because nothing on your side will fix it. Status pages lag, though. Some providers update them only after the incident is confirmed internally, so a quiet page does not prove everything is fine. <\/p>\n\n\n\n Providers with many locations, as we have with 25 worldwide, can have a problem in one place and none in another. Look for your own server’s location rather than one global status.<\/p>\n\n\n\n Most outages belong to one of three layers, and the symptom usually tells you which. Use the table to decide who to call first, and expect a few cases to straddle two rows.<\/p>\n\n\n\nCritical Account Access Information<\/h3>\n\n\n\n
Backup and Recovery Procedures<\/h3>\n\n\n\n
Business-Critical Website Functions<\/h3>\n\n\n\n
Who Should You Call When Your Website Suddenly Goes Down?<\/h2>\n\n\n\n
Hosting Provider<\/h3>\n\n\n\n
Domain Registrar<\/h3>\n\n\n\n
DNS and CDN Provider<\/h3>\n\n\n\n
Developer or Web Agency<\/h3>\n\n\n\n
Security or Malware Specialist<\/h3>\n\n\n\n
Internal Business Owner or Decision Maker<\/h3>\n\n\n\n
What Should You Do During the First 30 Minutes of a Website Disaster?<\/h2>\n\n\n\n
Confirming the Outage From Multiple Locations<\/h3>\n\n\n\n
Checking Hosting and Service Status Pages<\/h3>\n\n\n\n
Identifying Whether DNS, Hosting or the Website Is Failing<\/h3>\n\n\n\n