Fix My Website — Fast Broken Website Repair

Platforms I repair

If it runs on a web server and you can give me access, it's probably fixable:

• WordPress — by far the most common, including WooCommerce. See WordPress-specific repair.
• Shopify — theme and Liquid issues, app conflicts, custom storefront code.
• Laravel and other PHP applications — including bespoke systems built by a developer who has since left.
• React, Next.js and static sites — build failures, hydration errors, broken deploys.
• Plain HTML/CSS/JS and custom PHP — including very old sites nobody wants to touch.

Errors I see most often

If your error is on this list, it is a known quantity rather than a mystery:

• 500 Internal Server Error — usually a PHP fatal error, a bad `.htaccess`, or a permissions problem.
• 502 / 504 Gateway errors — the web server cannot reach PHP, or a request is timing out. See 502 and 504 gateway errors.
• 503 Service Unavailable — often a stuck maintenance mode after a failed update, or a resource limit.
• White screen / blank page — PHP fatal error with display disabled. See WordPress white screen of death.
• Redirect loops — conflicting HTTPS or www rules between the application, the server and a CDN.
• Database connection errors — wrong credentials, a crashed database, or a host that has suspended it.
• Mixed content and SSL warnings — the certificate is fine but assets are still loading over HTTP.
• Broken layout after an update — a theme or plugin update that changed markup or dropped a stylesheet.

How an emergency repair actually runs

For a site that is down, this is the order things happen in. Nothing destructive occurs before step three.

1. 1

   Reproduce and capture the real error

   Server error logs first, not guesswork. A 500 page tells you nothing; the log line behind it usually names the exact file and line. If error display is off, I turn on logging rather than debugging blind.

2. 2

   Establish what changed

   Almost every broken site was working recently. An update, a deploy, a DNS change, an expired certificate, a full disk, or a host-side change. Finding the change usually finds the fix.

3. 3

   Take a backup before touching anything

   Files and database, stored off the server, before any change is made. This is not optional and it is not billed as an extra. If the site is too broken to back up cleanly, I say so before proceeding.

4. 4

   Fix the cause, not the symptom

   Disabling the plugin that throws the error gets the site up; understanding why it started throwing it stops it recurring next month. You get both — the immediate restore and the underlying cause in writing.

5. 5

   Verify and hand back

   Check the pages that were broken, the forms, the checkout if there is one, and the error log again to confirm it is quiet. You get a short written summary of what was wrong and what changed.

What access I need

The more of this you can provide, the faster it goes — but I can usually start with the first two:

• The URL and the exact error text (a screenshot is fine). Often enough for a diagnosis before any access at all.
• Hosting control panel or SFTP/SSH access. Error logs live here, and so does the fix.
• WordPress or application admin login, if the problem is inside the application.
• Registrar or DNS access, only if the problem is domain or email related.
• Create a separate admin account for me rather than sharing your own, and remove it when the work is done. If you have lost the logins entirely, that is a recoverable situation.

Typical turnaround and cost

Based on the published pricing tiers. A firm quote comes before work starts, not after.

Emergency and out-of-hours work can be arranged; say so in the form and it gets prioritised.

Representative examples

Anonymised patterns from typical jobs — client details and figures are omitted deliberately. They are here to show the shape of the diagnosis, not as testimonials.

1. 1

   500 error after a routine plugin update

   Site went down mid-morning with a bare 500. The error log named a PHP fatal in a caching plugin that had just auto-updated and was calling a function removed in PHP 8.2. Rolled the plugin back to restore the site inside ten minutes, then pinned the PHP version and reported the incompatibility upstream so the next auto-update would not repeat it.

2. 2

   Intermittent 502s under normal traffic

   The site worked most of the time and failed under bursts. Not a code bug — PHP-FPM was configured with too few workers for the plan's memory, so requests queued until the web server gave up. Fixed by right-sizing the worker pool to the available RAM. The reasoning behind that arithmetic is in how much RAM WordPress actually needs.

3. 3

   Site "broken" that was actually a DNS change

   Reported as a broken website; the site was fine. A nameserver change made days earlier had not fully propagated, and the old records pointed at a decommissioned server. No code was touched at all — see fixing DNS issues.

What I can't fix, and when to expect that

Being straight about the limits saves everyone time:

• Problems inside your host's infrastructure. If the host's server or database is down, the fix is their escalation, not mine. I will identify it and give you the evidence to push with.
• Third-party services that are themselves down. A broken payment gateway or a failing API on the vendor's side is theirs to resolve.
• Sites with no backup and irreversible data loss. If content was deleted and no backup exists anywhere, I can often recover some of it but I will not promise all of it.
• Licensing. If a premium theme or plugin licence has lapsed, someone has to renew it — I can't work around that legitimately.
• Guaranteed rankings or traffic recovery. Fixing a broken site restores what it was; it is not an SEO campaign.

Broken website questions