WordPress help: what to do before you report a fault

#Before you write: ten minutes of triage

Four questions, in this order. The answers usually point at the cause faster than any tool does.

What exactly is not working. The whole site, a single page, or only the admin panel? Open the address in a private window and on a different connection, for example on a phone using mobile data. If the site works in a private window, the problem sits in your browser cache or your session, not on the server. If it works on the phone but not in the office, check DNS and the firewall on your side before anyone starts digging around in WordPress.

What is the exact message. “It is not working” covers five different faults. A white screen is usually a PHP error with error display turned off. A 500 error is a server error, most often a plugin, a theme or a memory limit. “Error establishing a database connection” is the database, which is an entirely different path. A 403 on login is usually a security rule rather than a fault. Note the code and the full text, including the line number if there is one.

What changed just before. Faults rarely arrive on their own. A plugin update, a core update, a PHP version change by the host, an expired certificate, a changed DNS record, an expired domain, a limit exceeded on the hosting. The date and time of the last change is usually the most valuable piece of information in the whole report.

Whether you have a backup. Do not restore it by reflex, but establish that it exists and when it is from. If your host takes nightly copies, check in the panel when the last one ran. This is the piece of information that decides whether the repair is risky or reversible.

#Error message, layer, first action

This table shortens the longest stage of every fault, which is guessing where to look at all.

The middle column matters more than the right one. Most of the time lost during a fault goes into fixing the wrong layer: someone deactivates plugins when the problem sits in DNS, or moves hosting when the culprit is a single plugin querying an external API.

#Where the logs are and what to look for

Without a log, diagnosis is guesswork. There are three places, in this order of usefulness.

The PHP error log. On most shared hosting it sits as error_log in the site directory, or in the panel under logs. You are looking for the most recent PHP Fatal error entries from the hour of the fault. An entry like that contains the file and line number, and that usually names the guilty plugin in the first second.

The WordPress log. If your host does not give you a PHP log, turn on your own. In wp-config.php, above the line commented “That’s all, stop editing”:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Errors land in wp-content/debug.log and visitors see nothing. Once you are done diagnosing, turn it off and delete the file; a log left on production for a month can grow to gigabytes and become a fault in its own right.

The web server log. Nginx and Apache write access and errors separately. The second one is what you want, from the hour of the event. On hosting with shell access, tail -n 100 /path/to/logs/error.log is enough. If you only have a panel, download the file and open it in a text editor, not in a spreadsheet, because long lines get truncated.

What to look for in all three: a timestamp matching the moment of the fault, the same line repeating (that is usually a loop, not a coincidence) and a plugin directory name in the file path. What not to do: do not paste a ten thousand line file into your report. Twenty lines around the first occurrence of the error are worth more than the complete file.

#The four most common faults and first aid

The steps below are safe, reversible and do not need a developer. If any of them goes beyond what you are comfortable with, stop and write to us; an interrupted repair is easier to finish than a repair that has gone deeper.

White screen or 500 error after an update. First deactivate the plugin you updated last. If you cannot reach the admin panel, rename its directory in wp-content/plugins/ through the hosting file manager or FTP; WordPress will then deactivate it. If that does not help, rename the whole plugins directory to plugins-off, check the site and put the name back. That settles in a minute whether the plugin or the theme is at fault. If you have command line access, wp plugin deactivate --all does the same thing more cleanly and lets you switch plugins back on one at a time.

Site suddenly slow. Check whether it is the front end that is slow or the admin panel. A slow panel with a fast front end is usually the database or an external API, for example a plugin querying a licence server on every page load. A slow front end with a fast panel is usually caching, images or hosting. Measure before you optimise: PageSpeed Insights shows the lab result and real user data from CrUX at the same time, and the second one matters more, because it describes what people actually experience rather than a simulation. Check the raw server response time separately, for example curl -o /dev/null -s -w "%{time_starttransfer}\n" https://yourdomain.com/. A result above one second means a problem on the server side, not in images or scripts.

I cannot log in. Before you call this a fault, check three things: whether the login address was changed by a security plugin, whether your IP was blocked after failed attempts, and whether the server clock has drifted, because that breaks sessions. A password reset through the form needs working mail, so if mail is not going out it will not work. The emergency exit: wp user update admin --user_pass=NewPassword from the command line, or changing the password directly in the database with the MD5 function, which WordPress accepts on the first login and immediately replaces with its own hash.

Suspected infection. Symptoms: redirects to an unfamiliar domain only from search results, new administrators you did not create, a warning in Search Console, spam in the content visible only to Googlebot. Check the list of users with the administrator role and the file modification dates, for example find . -type f -mtime -7 -name "*.php", to see what changed in the last week. Do not delete files and do not restore a backup until you have established the date of the first intrusion; a week-old copy usually already contains the same hole. Change the passwords, including the database and FTP ones, and write to us noting the infection.

#A fault in a WooCommerce shop has a different order

In a shop the reflex to “deactivate all plugins” is expensive, because along with the diagnosis it switches off payments, shipping and stock integrations. The order is the reverse of the one you would use on a brochure site.

First establish whether orders are coming in. The list of orders from the last hour answers that faster than any log. If they are coming in and customers are reporting a problem, the fault sits in notifications or in payment, not in the shop itself. If nothing is coming in at all, check the cart and checkout pages in a private window, because both are excluded from caching and break differently from the rest of the site.

Email notifications are a separate and very common fault that looks like a shop fault. Check whether mail is going out at all, and whether it is landing in the recipient’s spam folder. Three DNS records decide this almost entirely: SPF, DKIM and DMARC. If the shop sends mail straight from the hosting server without those records, some messages will not arrive and no plugin change will fix it.

If the fault affects a single payment method, check in the provider’s panel whether an API key or an integration certificate has expired. This is the situation where the site works correctly, the logs are clean and sales are stopped, so without checking on the provider’s side you can spend hours searching your own code.

#When it is not a site fault at all

Four cases where WordPress is innocent and diagnostics on its side only waste time.

The domain expired. Symptom: instead of the site you see a registrar offer or nothing at all. You check this in the whois database, with a single query, and you see the expiry date. Renewal usually takes effect within minutes, although in extreme cases the domain enters a redemption period and costs many times more than an ordinary renewal.

A DNS change has not propagated yet. Symptom: some people see the new site, some the old one. dig yourdomain.com +short shows which address the domain points to from your perspective. Changes propagate according to the TTL value, so if someone set it to a day, that is how long it will take and nothing on the site side can speed it up.

The certificate expired. Symptom: a browser warning about an untrusted connection. You can read the expiry date with openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates. Automatic renewal can fail when DNS changed in the meantime or a redirect was added that blocks the verification.

The host suspended the account. Symptom: a hosting message instead of the site, sometimes after a bandwidth limit was exceeded or an invoice went unpaid. There is nothing to fix in code here, only a conversation with the host, but it is worth checking afterwards what generated the traffic, because just as often it is a bot rather than customers.

#What to send in your report

The more of this list you give us up front, the fewer rounds of questions there are and the sooner you get a substantive answer rather than a request for more details.

What not to send in the first message: passwords. Access is agreed after the scope, and preferably as a separate administrator account that you delete once the work is finished. If the matter is urgent, say so plainly and say what urgent means here: a shop that cannot take orders is not the same thing as a contact form that sends twice.

#What happens on our side

The report goes to one person, not to a first-line queue, so you do not explain the case twice. The first reply contains what we could establish from your description, and a question only about what is genuinely missing.

Then the diagnosis. It is a separate, finite stage with its own price, so you know what you are agreeing to before anyone touches the site. Its output is the cause, the scope of the repair and the cost, in writing. Work starts once the scope is confirmed, not on a verbal “go ahead”. If something outside the scope comes up along the way, we stop and quote it separately rather than adding it to the bill after the fact.

We do the repair on a copy or on a staging environment wherever that is possible, and changes reach production as a single deployment that can be rolled back. When it is done you get a description of what the cause was and what to do so it does not come back. That last part is usually more important than the repair itself, because a fault that returns in three months costs a second time.

#What we do not do

We do not do graphic design. The layout and the placement of elements on a view, that is the wireframe, comes from the client; we build the responsive interface, the integrations and the performance layer from it. We have a ready spreadsheet template for collecting the layout, and we send it at the start.

We do not run a night or weekend shift and we do not sell a response time we cannot keep. If your shop needs a guaranteed response window, that is a separate maintenance agreement, not a footnote on a fault report.

We do not do things “while we are in there”. Anything new that comes up along the way gets its own quote. That sounds rigid, and in practice it saves both sides a bill nobody expected.

We also do not sell a rebuild as the answer to a fault. If the site can be repaired in a few hours, we say so, even when proposing a migration would suit us better. A migration makes sense when the cost of keeping the current setup exceeds the cost of changing it, and that can be calculated rather than sensed.

#When the site came back on its own, the case is not closed

A fault that passed without intervention is worse than one that is still running, because it disappears along with the evidence and comes back at a worse moment. The three most common causes of intermittent faults look identical from the outside.

The first is a resource limit. Shared hosting allocates each site a set number of concurrent PHP processes and rejects further requests once that is exceeded, usually with a 503 or 508 error. A bot crawling a shop with filters is enough, and for three minutes the site answers nobody. In the access log you will then see a series of requests from a single address in the same second.

The second is a scheduled task. WordPress runs its own scheduler off the back of visits, so a heavy job, for example generating a report or synchronising with a warehouse, lands on a random user and blocks the site for them. Symptom: faults at regular times, or always after the same action in the panel.

The third is an external API with no timeout. A plugin queries the supplier’s server, the supplier has an outage, and your site waits for a reply for as long as the PHP configuration allows. The site is then not broken, only waiting, and it comes back on its own once the other server recovers.

What to do so you can catch it next time: turn on error logging to a file before it returns, note the exact times of the occurrences from the last few days and check whether they form a pattern. Three timestamps and a log are a complete set to work with. Without them, all that is left is waiting for the next time.

#Where to go next

If you already know what you need, go straight to the right page instead of writing a general report.

• A fault, an error, something stopped working: repair, service and technical support
• Ongoing care, updates, backups and monitoring: WordPress website maintenance
• Suspected break-in or an audit before launch: WordPress security audit
• The site works but it is slow: speed up your WordPress site
• A new project or a rebuild: contact page

#Two things worth doing today, before anything breaks

Check that your backup can actually be restored. Not whether it exists, but whether it works. A backup nobody has ever restored is an assumption, not a safeguard, and the moment of a fault is the worst time to find that out. The procedure takes half an hour: set up a staging environment with the same host, restore the latest copy onto it, log into the panel, open three random pages and check that the number of posts and orders matches production. Write down how long it took, because that is your real recovery time after a fault, and it is better to know it from a rehearsal than from an outage.

The second thing takes a minute: write down where the domain sits, where the hosting sits, who has access to them and when they expire. Surprisingly often a fault is not a fault at all but an expired domain or certificate, and answering “who is it with” takes half a day because the person who set it up left the company long ago. On the same sheet, note who has the administrator role in WordPress and whether each of those accounts is still needed. Accounts belonging to former collaborators are the most common way in that nobody watches.