New 24/7 monitoring and daily cloud backups now included in every Shield Pro plan.
WordPress downtime case study
A UK consultancy site became unreliable after an incomplete hosting migration. This case study follows the outage from conflicting DNS responses and certificate warnings through correction, external testing, and same-afternoon recovery.
Prospects hitting the site saw browser SSL errors and intermittent DNS failures. Hosting status looked green while the domain still pointed at a retired server IP from an incomplete migration earlier that week.
The in-house team had changed nameservers and expected propagation to complete without further action. When email and the brochure site both became unreliable during a client workshop, they needed a developer who could separate the DNS, SSL, and WordPress symptoms without introducing another change blindly.
They did not want a full redesign or a multi-week migration project. They wanted the existing WordPress site reachable on HTTPS with the correct host, that afternoon, at a confirmed price.
Before the repair
The visible problem appeared in several places, while other parts of the WordPress site continued to look normal.
Visitor experience
Some visitors saw certificate warnings, others received a DNS error, and www did not behave like the root domain. That inconsistency pointed beyond a single WordPress page or plugin failure.
What hosting showed
The new host could serve WordPress correctly when reached directly. Public DNS still sent part of the traffic to a retired server, while the active certificate did not cover every hostname visitors used.
The emergency request got a confirmed quote and a BugShield developer in chat. DNS records at the registrar, SSL certificates on the new host, and WordPress siteurl/home values were checked against where traffic actually needed to land.
Wrong A records were corrected, SSL was reissued and verified for apex and www, HTTPS redirects were confirmed, and key landing pages were smoke-tested from mobile and desktop networks with flushed local DNS where needed.
Mail records that had been altered by accident were called out clearly so the consultancy’s email provider could finish that piece. BugShield did not silently take over the registrar account beyond the Vault session required for the repair.
Stage 1
Site unreachable for prospects mid-client meetings. Emergency fix requested with screenshot of SSL warning and dig output.
Stage 2
Developer assigned within an hour. Vault held registrar and hosting access for a limited session.
Stage 3
A records pointed at the live host. Certificates reissued. Mixed content and redirects verified on key pages.
Stage 4
Same-afternoon confirmation from multiple networks. Short runbook left for any future host move.
WordPress core on the new host was largely fine; traffic never consistently arrived there.
A records still referenced a decommissioned VPS from the previous host for the apex domain.
Certificate matched the wrong hostname combination after www was added mid-migration.
siteurl in WordPress already showed HTTPS on the new domain, which hid the DNS problem from people only checking inside wp-admin when it briefly resolved.
One mail TXT record had been overwritten while editing DNS, which explained separate email complaints.
The outcome
Same afternoon
Recovery timeframe
The site was reachable again the same afternoon. Prospects could open the consultancy’s pages over HTTPS without being sent to the retired server or shown a certificate warning. Future migrations would now include external DNS, certificate, redirect, and email-record checks before the old host was retired.
Get a confirmed emergency recovery priceWhat changed
Incomplete migrations fail outside WordPress. Always verify A/AAAA, www, SSL SAN coverage, and redirects from an outside network before decommissioning the old host.
When the panel says the site is healthy but browsers disagree, check DNS first. Not every WordPress site down event is a plugin fatal.
Visitors can experience WordPress downtime even when PHP, the database, and the files on the active server are healthy. If the domain resolves to an old address, the working server never receives the request. A hosting dashboard can therefore stay green while the public site remains unavailable.
This WordPress downtime case study began by comparing public DNS answers, certificate coverage, and the expected host. That established whether traffic reached WordPress before any plugin or theme changes were considered.
Stale A records after a host move
Certificate missing www or apex
Propagation lag mistaken for a code outage
siteurl already correct while DNS still wrong
Collateral MX or TXT edits during DNS surgery
A migration changes more than the WordPress files. The root domain and www hostname must resolve to the intended server, the TLS certificate must cover both, and redirects must send visitors to one canonical HTTPS address. A mismatch at any stage can look like a WordPress outage.
DNS also carries mail records. Every change was documented so the website records could be corrected without treating unrelated MX and TXT values as disposable migration settings.
A successful check on one laptop was not enough because DNS resolvers can hold different answers during and after a migration. The repaired site was checked through more than one network and across the root and www hostnames.
The homepage, contact page, and service pages were opened over HTTPS, redirects were followed, and the certificate was checked against the final hostname. These checks confirmed that public visitors reached the same working WordPress installation.
External monitoring observes the site from outside the hosting account. That makes it useful for detecting resolution failures, certificate problems, and unavailable pages that an internal server status may miss.
The consultancy added Shield monitoring after the incident. A short migration runbook also recorded the DNS, certificate, redirect, and mail checks needed before an old server is removed in future.
Continue reading
WooCommerce checkout case study
A UK fashion store lost Stripe and PayPal payments after a plugin update. This case study follows the checkout failure from the first report through diagnosis, repair, and successful test orders.
Read case studyWordPress malware removal case study
A UK agency site was showing defaced content, injected links, and browser security warnings. This case study follows the cleanup from containment through malware removal, access hardening, and review preparation.
Read case studyWordPress critical error case study
A UK charity site stopped loading after weekend WordPress updates. This case study follows the PHP error from inaccessible pages and wp-admin through plugin isolation, recovery, and live donation-form testing.
Read case studyFAQ
Answers about the DNS and SSL failure, hosting migration, email records, repair price, testing, and recovery timeframe.
An incomplete hosting migration left the root domain pointing at a retired server while the certificate did not cover the hostname combination visitors used. WordPress on the new host was largely healthy, but traffic did not reach it consistently.
No significant WordPress core fault was found. The active site could load when reached directly. The public outage was caused by DNS and certificate configuration around the migration.
The dashboard checked the new server, which was running. Public visitors depended on DNS to find that server, and some DNS records still directed them elsewhere.
A developer was assigned within an hour and the site was restored the same afternoon. Another outage may take a different amount of time depending on access, DNS control, propagation, certificate issuance, and the underlying cause.
The confirmed price for this emergency recovery was £99.99. It covered investigating the outage, correcting the website DNS records, restoring certificate coverage, and verifying the public site.
The two hostnames can have separate DNS records and both must be covered by the certificate. During this migration, they did not consistently point to or validate against the same destination.
A mail-related TXT record had also been overwritten, which helped explain separate email complaints. The affected record was identified so the consultancy and its mail provider could complete that part of the correction.
No. Registrar access stored in the Vault was used only for the repair where required. The consultancy retained ownership and received a record of the relevant changes.
The site was checked through multiple networks and on both the root and www hostnames. Key pages were loaded over HTTPS, redirects were followed, and the final certificate and DNS destination were verified.
Yes. BugShield can investigate WordPress downtime caused by DNS, SSL, hosting, PHP errors, plugins, themes, configuration, or failed migrations. The repair plan is based on the evidence found for the registered site.
Describe the outage, warning, or recent hosting change and see the confirmed price before a WordPress developer begins.
Request emergency recovery