The site will not load, the store stops taking orders, or the dashboard locks you out after an update. I start from the facts, take a backup, isolate the layer that failed and test the fix on the same paths where it broke. I am Mariusz Szatkowski, a WordPress developer since 2006, and I do this work myself. This page also covers ongoing care: the updates, backups and monitoring that make failures less frequent.
Who you are hiring
- Shipping commercial WordPress since 2006, before Gutenberg and the REST API
- Senior-led: the engineer at discovery is the engineer at the keyboard at week six
- No offshore handoff, no PM layer billed back to you
- WordCamp Europe organiser, WordPress Foundation Credits mentor
- Shopify Academy: CRO learning path plus Partner Marketing (Credly, 2025)
Fix a WordPress site: symptom, cause and a safe first step
The most common failures have causes documented by WordPress itself. The table shows what usually sits behind each symptom and what you can check yourself without making things worse. If the first step does not help, or you have no access to the files, stop there and send a description.
| Symptom | Most common cause | Safe first step |
|---|---|---|
| White screen with no message | A PHP error in a plugin or theme, often right after an update | Over SFTP, rename the wp-content/plugins folder, and if that does not help, the active theme’s folder |
| ”There has been a critical error on this website.” | A fatal PHP error caught by WordPress (since version 5.2) | Check the admin email inbox: the message contains a recovery mode link that pauses the faulty plugin |
| 500 Internal Server Error | A corrupted .htaccess file, a plugin or the memory limit | Rename .htaccess, and once the site is back, save Settings, Permalinks again |
| Error establishing a database connection | Wrong credentials in wp-config.php or a database server that is down | Compare DB_NAME, DB_USER, DB_PASSWORD and DB_HOST with your hosting panel, ask your host about the MySQL status |
| Allowed memory size exhausted | A PHP memory limit set too low, or code that eats memory in a loop | Raise WP_MEMORY_LIMIT in wp-config.php, then find out what uses that much, because the limit alone only postpones the problem |
| Site stuck in maintenance mode | An interrupted update left a .maintenance file behind | Delete .maintenance from the root folder and finish the update that was interrupted |
| Redirects to unknown sites, spam in Google results | A hack, usually through an outdated or abandoned plugin | Do not delete files blindly: take a backup as evidence, change the dashboard, SFTP and database passwords, then clean up as described on the WordPress malware removal page |
| WooCommerce store not taking orders | A plugin conflict, caching on the cart, or an error on the payment gateway side | Open WooCommerce, Status, Logs and check at which step the order stops |
Sources: Common WordPress Errors, Debugging in WordPress, Fatal Error Recovery Mode in 5.2, FAQ My site was hacked.
WordPress theme maintenance
A custom WordPress site built from a layout you supplied is, in practice, a custom WordPress theme. I maintain such themes alongside updates of core and plugins, backups, uptime checks and repairs.
Technical faults, code errors and break-ins are the usual reasons a WordPress site stops working. If your site was built or heavily modified by an AI tool, the cleanup is different: generated code tends to hide broken assumptions rather than throw obvious errors, so I treat it as a separate track described on the AI-built website rescue page.
See what your site shows in public
Give us the address of a site you run. We fetch it the way a browser would and show what follows from it, together with exactly what we read.
Paste your site’s address. The tool fetches it the way a visitor’s browser does and shows the response code after redirects, the headers, the weight of the initial page load and traces of WordPress. It does not log in and cannot see the dashboard, so it will not replace a diagnosis, but pasting the result into your request shortens the first conversation. A full description of what it measures is on the WordPress site check page.
Why does a WordPress site need technical care?
A WordPress site that nobody looks after gets slower, collects plugins with known vulnerabilities and one day stops working after an update that ran on its own. Care means the updates happen on staging first, a backup exists before every change, and an outage shows up in monitoring before a customer writes to you about it.
WordPress support service: what technical care includes
I keep updates, backups, monitoring and performance checks on one schedule, so a speed fix does not undo a security setting and the other way round.
Theme and plugin updates
Core, theme and plugin updates, tested on staging before they go to production.
Technical care
Updates, backups and monitoring on a monthly plan, with repairs when something breaks.
Backups
Copies of files and database kept for at least 30 days, stored in EU countries.
Uptime monitoring
The site is checked every 1 to 5 minutes, so an outage is visible before customers report it.
Version control
Theme and custom code live in a Git repository, so a broken change can be rolled back.
Security
Two-factor login for administrators, file editor off, unused plugins and accounts removed.
Website repair
Diagnosis and repair of a broken site, starting from a backup.
Before I get access to a site with personal data, I sign a data processing agreement under Art. 28 GDPR. I do not sell hosting: you choose the provider and I work with the stack you have.
How quickly is an urgent WordPress failure handled?
I do not run a 24/7 on-call service and I do not promise response or repair times. An urgent failure on a site I already look after goes ahead of planned work on that site. For a site I do not know yet, the first step is a written description and access, and I tell you by email when I can start. When the same failure keeps coming back, such as an outage after every update or repeated malware, the WordPress specialist page explains how I look for the cause.
How does the WordPress repair process work?
1
A request with facts
The page URL, when the failure started, recent changes and what is blocked: checkout, login or publishing.
2
Backup before any change
A restore point for files and database, and when the incident allows it, reproducing the fault outside production.
3
Isolating the layer
Hosting, core, theme, plugin, custom code, external API, cache or DNS. I fix the smallest layer responsible.
4
Testing and a written record
The reported scenario and neighbouring paths run again, and the change and the rollback point go into a note.
A useful request starts with facts, not guesses. I note the affected URL, when the problem first appeared, recent deployments or updates, the expected behaviour, and whether checkout, login, publishing or another path that earns money is blocked. Screenshots help, but browser and server logs, request IDs and exact steps to reproduce shorten the diagnosis much more.
Before I change production, I take a backup I can restore and, whenever the incident allows it, reproduce the fault on a copy. Then I isolate the smallest layer responsible: hosting, WordPress core, theme, plugin, custom code, external API, cache or DNS. That keeps a visible symptom from turning into an unnecessary rebuild.
A repair is done only when the original scenario and the paths next to it pass again. For a checkout fault, a loading cart page is not enough: I test the hand-off to the payment provider, the confirmation, the email, the stock change and the analytics events that matter. For an editorial fault, I test preview, publishing, media, permissions and cache clearing. I write down what changed, what I deliberately left alone and where the rollback point is. If the cause sits outside my reach, such as a third-party service, you get the evidence and a safe way to contain the problem, and I do not present a workaround as a permanent fix.
WordPress support: what to prepare for your request
Most of the time at the start of an incident goes into getting access and working out what changed. These things speed up the start more than anything else:
Description of the failure
- the URL of the page where the problem shows
- when it first appeared
- what changed just before: an update, a new plugin, a migration, a DNS change
- the exact error message or a screenshot
Access
- a separate administrator account in WordPress, not your own
- SFTP or SSH to the site files
- the hosting panel with access to the database and error logs
- for a store: read-only access to the payment gateway dashboard
Send credentials through a separate channel, not in the form message. When the work is done, delete the account you created for me and change the SFTP password: good practice with any contractor. WordPress guidance on passwords, accounts and permissions is collected in the Hardening WordPress guide.
WooCommerce repair: when the store stops selling
A store outage costs more than an outage on a company site, because every hour means orders that never came in. With WooCommerce, a working homepage proves nothing: the repair is done only when a test order goes through the cart, payment, the confirmation email and the stock update. WooCommerce writes errors to logs in the dashboard (WooCommerce, Status, Logs), and the system status report in the same section shows the environment, versions and overridden templates. Attach both to your request.
When the store runs but has been losing orders, payments or integrations for a while, a time-boxed WooCommerce rescue sprint works better than a one-off repair.
If the site works but is slow, or you are not sure what is running on it, you can ask for a free written review. I check it from the outside, without dashboard access: what it runs on, speed from PageSpeed Insights and Chrome field data, security headers. You get an email with the three biggest risks and the order to fix them in.
Your WordPress site is down. Describe what you see
The address, when it broke and recent changes are enough to start. Pricing is individual and follows the incident description, and work starts once the scope is written down.
Send a failure descriptionRelated delivery work sits under WordPress maintenance.
