TL;DR -- Right now, open a private/incognito browser window and load your site. If you see nothing, check downdetector.com or run ping yourdomain.com from a terminal. That one step tells you whether the problem is your site, your host, or your local network. Once you know what broke, you can fix it in the right order instead of guessing. If you need hands-on help immediately, our emergency website repair team typically responds within 1 to 2 hours during business hours and within 4 hours overnight.

How do I tell what actually broke?

A site can go dark for half a dozen different reasons, and each one looks slightly different. Before you touch anything, run through this checklist. It takes about five minutes and saves hours of misdirected panic.

1. Host / server outage

Visit your hosting provider's status page (every major host has one). If they report an incident, the fix is on their side. You wait, or you migrate. Average resolution for major hosts: 30 minutes to 4 hours.

2. DNS misconfiguration

Run nslookup yourdomain.com or use a free DNS checker like whatsmydns.net. If the A record or CNAME points to the wrong IP -- or shows no result at all -- DNS is the culprit. This often happens after a domain transfer, a nameserver change, or when someone lets the domain expire (see below).

3. Expired domain or SSL certificate

If your browser shows "This site can't be reached" or a big red "Not Secure" warning, check your domain registrar's dashboard. Expired domains can be renewed within a grace period (usually 30 to 45 days, depending on the registrar). Expired SSL certificates are faster to fix -- most can be reissued and installed in under 15 minutes if you use Let's Encrypt or a similar automated provider.

4. HTTP 500 or other server error codes

A 500 Internal Server Error means something on the server itself crashed -- a bad .htaccess file, a PHP fatal error, a database connection failure. The MDN HTTP Status reference is the single best resource for understanding what each code actually means. Check your server's error log first: on most Linux hosts, it lives at /var/log/apache2/error.log or /var/log/nginx/error.log.

5. Plugin or theme conflict (WordPress)

If the site broke right after an update, this is almost certainly the cause. Connect via SFTP or your host's file manager, navigate to wp-content/plugins/, and rename the folder of the most recently updated plugin (e.g., bad-plugin to bad-plugin-disabled). Reload. If the site comes back, you found it. Our emergency WordPress support team handles 10 to 15 of these cases every week -- it is one of the most common WordPress failures.

6. Hack or malware

Signs: unfamiliar redirects, defaced pages, Google Search Console warnings, new admin users you did not create. Do not log in from your main browser -- use incognito. Do not delete files yet. You need forensic evidence to close the hole before you clean up. We will cover recovery below.

What are the first stabilization moves?

Resist the urge to start reinstalling everything. Stabilization means stopping the bleeding without making it worse.

  1. Take a snapshot. If your host offers server snapshots or you have SSH access, create one right now -- even of the broken state. This preserves evidence and gives you a rollback point.
  2. Put up a maintenance page. A simple static HTML file served at the root tells visitors (and search engines) that you are aware of the issue. Return an HTTP 503 status code with a Retry-After header so Google knows to come back later. The Google Search documentation explains how search engines handle temporary downtime.
  3. Disable the broken component. If it is a plugin, rename its folder. If it is a theme, switch to a default theme via WP-CLI (wp theme activate twentytwentyfour). If it is a server config issue, revert the last change to .htaccess or nginx.conf.
  4. Change passwords. If there is any chance of a hack, change your WordPress admin password, database password, SFTP/SSH credentials, and hosting panel password -- in that order. Enable two-factor authentication if you have not already.

Typical stabilization time: 15 minutes to 2 hours, depending on access and complexity.

How do I recover safely using backups and rollback?

Backups are only useful if they are recent, complete, and stored somewhere separate from the server that broke.

  1. Locate your most recent clean backup. Check your host's automatic backup system, any backup plugin you run (UpdraftPlus, BlogVault, etc.), or your own offsite storage. "Clean" means it was taken before the problem started.
  2. Restore to a staging environment first -- not production. If your host offers a staging area, use it. If not, spin up a temporary subdomain or local environment. Verify the restored site works, the database connects, and no malware is present.
  3. Push to production. Once staging looks good, swap it live. On most managed WordPress hosts, this is a one-click operation. On a VPS, you are looking at a file sync and database import -- budget 30 to 60 minutes.
  4. Verify everything post-restore. Check forms, checkout flows, login, media files, and third-party integrations. Broken images and missing API keys are the most common post-restore surprises.

If you do not have a backup -- and roughly 30% of the emergency cases we see have no usable backup -- recovery is still possible but takes longer. We can often reconstruct from cached versions (Google Cache, Wayback Machine) and database fragments. Expect 1 to 3 days for a full reconstruction versus a few hours for a clean restore.

When should I call for professional help?

Call now if any of these are true:

  • Your site is an e-commerce store losing revenue every hour it is down.
  • You see signs of a hack and are not sure how the attacker got in.
  • You have no backup and no clear path to restoring content.
  • The site serves a regulated industry (healthcare, finance) where downtime or data exposure has compliance implications.
  • You have a hard launch deadline -- a rebrand, a product drop, a media moment -- and the site is not ready.

For deadline-driven situations, our emergency web design service can stand up a production-ready site in 3 to 5 business days, or a stabilized landing page in under 24 hours.

For ongoing WordPress issues that keep recurring -- monthly plugin conflicts, slow performance, security patches you never get to -- a WordPress maintenance plan typically costs between $150 and $500 per month and prevents roughly 80% of the emergencies we see.

Be honest with yourself about your skill level. There is no shame in calling for help at step one. The most expensive emergencies we handle are the ones where someone spent 6 hours making the problem worse before reaching out.

How do I prevent the next outage?

Surviving one emergency is good. Not having the next one is better.

Set up real monitoring

Use an uptime monitor (UptimeRobot, Pingdom, or similar) that checks your site every 60 seconds and alerts you by SMS or Slack the moment it goes down. Pair that with performance monitoring tied to Core Web Vitals so you catch slowdowns before they become full outages. We offer this as part of our Core Web Vitals optimization work.

Use a staging environment for every change

Never update plugins, themes, or server configs directly on production. A staging site takes 10 minutes to set up and saves you from the single most common cause of WordPress downtime: a bad update pushed to a live site.

Keep backups automatic, offsite, and tested

Daily automated backups stored in a separate cloud account (not on the same server). Test a restore at least once per quarter. If you have never tested a restore, your backup is a hope, not a plan.

Consider a less fragile stack

If your WordPress site has been hacked twice, crashes after every plugin update, or requires constant babysitting, it may be time to move to a static-first framework like Next.js or Astro. These stacks have a dramatically smaller attack surface (no PHP, no database exposed to the web), load faster, and cost less to host. A full migration typically takes 2 to 4 weeks depending on content volume and custom functionality.

Document your infrastructure

Write down -- in a shared document your team can access -- your registrar, DNS provider, hosting provider, backup locations, SSL provider, and all admin credentials (in a password manager, not a spreadsheet). When the next emergency hits at 11 PM, you will not be hunting for login details.

Frequently asked questions

How long does it typically take to get a hacked WordPress site back online?

For a straightforward malware infection with a clean backup available, we usually have the site restored, patched, and hardened within 4 to 8 hours. Without a backup, expect 1 to 3 business days for full recovery including malware removal, file reconstruction, and security hardening to prevent re-infection.

Will my Google rankings suffer if my site is down for a few hours?

A few hours of downtime rarely causes lasting ranking damage. Google expects occasional outages and will re-crawl. If your site is down for more than 24 to 48 hours, you may see temporary drops. Serving a proper 503 status code with a Retry-After header during maintenance signals Google to check back soon rather than de-indexing pages.

How much does emergency website repair cost?

Our emergency triage and stabilization typically runs $300 to $800 depending on complexity. Full recovery from a hack or a site rebuild with no backup ranges from $1,500 to $5,000. We scope and quote before we start so there are no surprises -- you approve the cost before we touch anything.