Emergency website repair, and a rebuild that keeps your site up.

What does emergency website repair involve?

Emergency repair means four things: confirm what is broken, stop further damage, restore a clean copy and close the hole that let the attacker in. Start by loading your homepage, an inner page and your admin login. Note which pages return errors, which show strange content and which still work. And write it all down (under stress your memory blurs, and a written list tells you which kind of repair you face).

Is your site hacked? Start by assessing the damage. Google's guidance tells you to check your site for modified files and suspicious activity on your server, and to contact your hosting provider immediately. Run the same checks on your own server. Maybe an update broke your site instead. In that case, find the change and reverse it. If your site has disappeared, you need a source for its content, whether that is your backup, your database or an archived copy. The free assessment helps here. Even when your live site does not answer, it reads the Wayback Machine's public index for you. So a dead site is not a dead end: you still have something to work with.

What should you do in the first hour after your site goes down or gets hacked?

In your first hour, confirm what is down, copy your logs and backups somewhere safe, change every credential you hold, and do not reinstall over the evidence. Check your homepage, an inner page and your admin login from a different network. That tells you whether your whole site is failing or only one part. Before anyone touches your server, download its logs and your latest backups. As Google advises, contact your hosting provider immediately. Then change your passwords for hosting, the admin area, the database and FTP.

If your site is hacked, take it offline or serve a 503 status code. Google says that beats blocking crawling with robots.txt, because it stops malware reaching your visitors. Copy your files and logs before you reinstall anything. Most people throw them away, yet those copies show you how the attacker got in. Google's best recovery step for your server is a full OS reinstall from a trusted source, followed by a restore from your clean backup. Once your site is back, request a review. And keep watching.

Can you recover a website from the Wayback Machine?

Yes, you can often recover the visible front end of your website from the Wayback Machine, but only the pages, images and files its crawler captured. Open your homepage snapshot and you will see a 14-digit timestamp (YYYYMMDDhhmmss) after web.archive.org/web/. Add a modifier there. You can then pull the raw file (id_), a screenshot (im_), the JavaScript (js_) or the CSS (cs_).

Your captures sit in the public CDX index, which lists timestamp, original URL, mimetype, status code, digest and length. The assessment reads that index for you, so you see how many months have a homepage capture, your first and last good capture, and how many unique pages, images and PDFs are archived. That read works whether or not your live site answers. If your site is down, you see the archive record instead of a score. Check your captures before you rebuild, because then you will know exactly what you still have.

What can an archived copy restore, and what is lost for good?

An archived copy of your site restores what your visitors saw: rendered HTML, images and files. It loses your database, your user accounts, your form handling and your server code. Open an archived inner page and view its source. You will find finished markup, not the templates or queries that built the page. Public captures hold front-end code only. Think of a photograph of the building (nice to have, useless to live in), not the building you ran.

Expect gaps in your copy. If the crawler missed a CSS file or an inner page, nobody can regenerate it, and you will not find every page or update saved. Dynamic content is often absent. Videos, scripts and interactive content may not load, and some snapshots may be missing images. Blocked archiving or restrictive robots.txt rules will leave holes. If your site was a React, Vue or Angular app, your capture may be incomplete. But snapshots from a period when your site was server-side rendered may be better quality.

Should you repair the old site or rebuild it?

Repair your old site if you run a small brochure site and your fault is one identifiable change. Rebuild it if you keep seeing the same failure, or if your software is past end of life. Check your version first. Drupal 7 reached end of life on January 5, 2025, so your core, contributed modules and themes no longer get security advisories. Running Adobe Commerce 2.3? Your regular support ended September 8, 2022. Are you on either today? Then nobody is watching your door.

Repair suits you if your site was healthy until one update or one stolen password. The fix may be only a clean backup, a patch and new passwords, and you can stop there. Rebuild suits you if you have already restored the site more than once, or if an archive holds the only copy of your content. The evidence behind each pillar in your assessment helps you tell which case you are in. Its job is to settle your question (not to stretch it out).

Why do plugin-based sites keep breaking?

Your plugin-based site keeps breaking because every plugin you run is third-party code on your request path, updated on someone else's schedule, not yours. Open your plugin list and count the authors: you gave each one a say in your site. Any two plugins can conflict after an update. Patchstack's 2026 report puts 91% of new vulnerabilities in plugins, 9% in themes, and only 6 in WordPress core, all low priority. Your core is rarely the weak point. Your plugins and themes are. So your plugins, your risk.

Patchstack reports that 46% of vulnerabilities had no developer fix by the time of public disclosure, so you can't rely on plugin updates as a security measure. If you run WordPress, you faced 11,334 new vulnerabilities in 2025, up 42% from 7,966 in 2024. For the most heavily targeted vulnerabilities, the median time to mass exploitation is 5 hours. That is shorter than your workday. And your patching has to beat it.

How do Next.js, Astro, Sanity and Supabase avoid the same failures?

Your visitors get pre-built pages, with no database or PHP on your request path, while your editing and your data live in separate hosted services. Astro renders most of your page to static HTML and strips client-side JavaScript by default, so you add it only for interactive components. With Next.js Incremental Static Regeneration, your content updates without a full site rebuild. If background regeneration fails, you keep serving the old page, unaltered. Sanity keeps your content as structured JSON documents with revision history, served through a CDN-distributed API.

Supabase holds your data and your logins behind row-level security. Without it, any role with a grant can read and write a table in an exposed schema, so check your policies. On your host, you see a change in your preview deployment before it ships. Vercel Instant Rollback reverts you to a previous production deployment in seconds. Dependencies still need updating, and your builds can still fail. But what you gain is a smaller blast radius, not zero maintenance.

Can you move a WordPress, Drupal, Magento or Wix site to a modern headless stack?

Yes, if your site runs on WordPress, Drupal, Magento, Wix, Squarespace or Joomla, I can move it to a modern headless stack. I repair broken sites and rebuild them on this stack, so you get your site rebuilt with your content taken from your live database or, when that is gone, from your site's archive. Your rebuild uses no CMS plugins at all. Every feature you ask for is code in your site's own repository, reviewed and versioned. Nothing third-party is left to go stale, conflict or carry a vulnerability on your pages.

None of these platforms is your problem. The code around them usually is, and you can check that on your site. Wix is the exception, where you start your layout again. Your site must be hosted on Wix's servers, you can export your contacts and your product information, and your Wix Stores product export limits you to 5,000 rows per CSV and does not support digital products. If your site is already gone, run the free assessment first (it costs you two minutes). You will see how many pages, images and PDFs the archive holds for your site. Then decide what to do next.

Questions, answered.

Your next read.

1. 01Website redesign SEOBaseline before, reconcile after.
2. 02Legacy CMS consultantWhat a consultant checks first on an ageing platform.
3. 03Headless CMS SEO auditRendering, canonicals, previews, schema from the template.
4. 04Vibe coding security: what shipped AI sites leak, and how to see it from outsideWhat Ships · Security