# WordPress website down? What to check before making changes > Check who is affected, record the error and review recent changes before attempting repairs. A practical outage checklist for business website owners. Language: British English (en-GB). Canonical page: https://kbyte.co.uk/wordpress-website-down/ Last updated: 2026-10-30 By [KByte IT Services](https://kbyte.co.uk/about-us/) Published: 2026-10-30 ## What should you do first if your WordPress website is down? Check whether the problem affects another device or connection, record the exact error and time, and check your hosting provider’s status page. Note any recent changes before attempting repairs. A website outage does not always start in WordPress, so avoid changing plugins, DNS and hosting settings at the same time. This checklist is for business owners and staff gathering the information needed for a useful investigation. It separates checks you can make without changing the site from recovery work that needs an authorised administrator, a backup and an agreed plan. ## 1. Find out who and what is affected Open the public website on a second device and, where practical, a different connection such as mobile data. Compare the homepage with one ordinary internal page. Use public pages for these checks; do not enter customer details or place a test order on a live shop. - **Only one device is affected:** record the browser and connection. The result may point towards a local issue, but is not proof of its cause. - **Several devices cannot load the site:** give the host the affected URLs and times. - **The homepage works but another page fails:** record the specific page and action. A working homepage does not establish that the whole site is healthy. - **The website works but a form fails:** treat that as a separate workflow fault. Our [website enquiry integration guide](https://kbyte.co.uk/website-enquiry-integration/) explains the responsibilities behind form delivery and follow-up. If other websites also fail on your office connection, record that distinction. Our [office Wi-Fi troubleshooting guide](https://kbyte.co.uk/office-wifi-keeps-disconnecting/) covers connection problems rather than website recovery. ## 2. Record the error before making changes Save a screenshot, the page address and the time, including your time zone. Keep a short note of what you expected and what appeared instead. Remove customer information before sharing screenshots outside your business. The [official WordPress error guide](https://developer.wordpress.org/advanced-administration/wordpress/common-errors/) distinguishes blank screens, database connection errors, timeouts and critical errors. These symptoms can have different causes; an error heading alone is not enough to select a repair. - **Critical error or blank page:** record whether the public website, dashboard or both are affected. - **Database connection error:** ask the host to check database availability and the relevant server logs. - **Timeout or server error:** provide the time and affected URL so the host can match the request with its records. - **Certificate or domain warning:** keep the wording and investigate the hosting or domain layer before changing WordPress. Do not bypass a browser certificate warning to enter administrator credentials. If the site redirects somewhere unexpected, report that behaviour before trying to log in. ## 3. Check hosting and domain status Visit the hosting provider’s status page through its known website. Check for incident notices or planned maintenance. Sign in to your usual hosting and domain accounts through saved bookmarks, rather than links in an unexpected message about the outage. Ask the provider to confirm the account’s status, whether the domain points to the intended service and whether a recent server change is relevant. Give it the error and timestamp. If you cannot access an account, identify the person who owns it rather than creating a replacement service immediately. Changing domain records as a guess can affect other services. Record existing settings and agree the intended result and recovery route before anyone changes them. ## 4. If the website went down after an update, record what changed A WordPress website down after an update needs a clear timeline. Record the plugin, theme or WordPress version changed, the approximate completion time and who performed the update. Include hosting changes, custom code and deployment activity in the same timeline. A recent change is a useful lead, not proof that a particular plugin is responsible. For example, if the homepage loads but a booking page fails after an update, send the booking page address and error to the person investigating. This is an illustrative troubleshooting example, not a KByte client case study. Agree one change at a time and record its result. Avoid installing repair plugins, deleting components or repeatedly running updates without understanding the fault. A staging copy can help an administrator investigate compatibility without repeatedly changing the live site. ## 5. Check whether WordPress Recovery Mode is available [WordPress Recovery Mode](https://wordpress.org/documentation/article/recovery-mode/) can help an administrator access the site when certain fatal errors occur. WordPress may send the administration address an email with error details and a recovery link. Check the correct mailbox and spam folder; not receiving an email does not identify the cause of the outage. Treat the recovery link as sensitive. An authorised administrator should review the reported component and decide how to investigate it. Recovery Mode is a troubleshooting aid, not proof that the public website is repaired. If it is unavailable, ask the hosting provider for the relevant error logs through an agreed private channel. WooCommerce’s [site-down guidance](https://woocommerce.com/document/troubleshoot-my-site-is-down/) also recommends identifying the error and checking the administration email or PHP logs. Ask the host for help if you are unfamiliar with those records. ## 6. Agree a recovery plan before restoring a backup Confirm what the backup contains and when it was created. [WordPress backup guidance](https://developer.wordpress.org/advanced-administration/security/backup/) covers both website files and the database. A copy of one does not necessarily provide everything needed to restore the site. For a business website, list the changes since that backup: orders, enquiries, bookings, content edits and account changes. Agree how those records will be protected before replacing any live data. Keep a copy of the current state where possible so the investigation does not erase useful evidence. Our [backup restore testing checklist](https://kbyte.co.uk/business-backup-recovery-checks/) covers the separate task of checking that recovery works. This article focuses on the immediate outage; it is not a substitute for a tested recovery process. ## 7. Send a useful fault report and check the recovery Use this short checklist when contacting your host or developer: - Website address and the specific pages or actions affected. - First observed time, time zone and last known working time. - Exact error wording and a screenshot without private information. - Results from another device or connection. - Recent changes, including versions where known. - Business impact, such as interrupted bookings or enquiries. - Backup date, account owner and checks already attempted. After recovery, agree checks for the affected journey as well as the homepage. Forms, sign-in, scheduled tasks and payment notifications may need separate verification. Use staging or provider test modes where available; agree any live transaction or customer notification before testing. For help investigating an existing site, explore [KByte’s WordPress repairs and support](https://kbyte.co.uk/wordpress-support-services/). We can discuss suitable remote assistance across the UK. [Send your website address and a description of the outage](https://kbyte.co.uk/contact/), without passwords or recovery links. Consultancy is always free; investigation and repair work are scoped and agreed separately. ## Support with this topic - [WordPress support services for repairs and speed optimisation](https://kbyte.co.uk/wordpress-support-services/) ## Frequently asked questions ### What should I check first when my WordPress website is down? Try a public page on another device or connection, record the exact error and time, and check your hosting provider’s status page. Note recent changes before attempting repairs. These checks help distinguish a local connection problem from a website fault. ### Does a WordPress critical error mean the website has been hacked? A critical error alone does not establish that a website has been hacked. An administrator needs to review the error details, logs and recent changes. Report unexpected redirects or other suspicious behaviour and preserve evidence before making changes. ### What if I cannot access the WordPress dashboard? Check whether the administration mailbox received a Recovery Mode email. Recovery Mode is available for some fatal errors, not every outage. If it is unavailable, contact the hosting provider or authorised developer with the error and timestamp. ### Should I restore a backup straight away? First confirm the backup’s date, contents and recovery procedure. Identify orders, enquiries, bookings and other changes made since that backup, and agree how to preserve them before replacing live data. ### What should I send to someone investigating the outage? Send the affected URLs, exact error, timing, recent changes, business impact and the checks already attempted. Provide screenshots without customer information. Arrange secure access separately; do not include passwords or recovery links in an enquiry.