When your WordPress developer disappears, the playbook has a fixed order: secure what you can still reach, copy the live site before anything changes, take inventory of what you actually control, and only then decide between recovering the old setup and rebuilding onto something you own outright. The order matters because the assets decay at different speeds, a live site can be copied today regardless of who holds the passwords, while a lapsed domain or an unpaid hosting account can vanish next month, and because panic-driven first moves, like disputing charges or emailing ultimatums, regularly make the technical rescue harder. We run this rescue at WPBuildAI often enough to have it systematized: the crawl-first scan copies everything the public site serves before negotiations, deadlines, or expiry dates can touch it, and the rebuild lands the business on infrastructure registered to the owner, which is the part that prevents the sequel.
First 48 hours: copy the site while it still serves
Whatever else is uncertain, the live site is still publishing your content, and that makes it recoverable without any password: a front-end crawl records every page, title, meta description, image, and internal link exactly as served, and WordPress’s public REST API hands over structured JSON of every public post on standard sites, no login required. Do this first, before contacting anyone, because the one irreversible failure in these situations is the site going offline, hosting lapses, developer pulls the plug, invoice dispute escalates, with no copy in your hands. The plugin-free export routes cover the mechanics; the strategic point is sequencing: copy first, negotiate second, so every later conversation happens with your content already safe.
While the crawl runs, screenshot the site’s key pages, pull any historical copies from the Internet Archive as a secondary record of how the site looked over time, and note traffic patterns from any analytics you can still open. If the relationship deteriorates into a dispute, contemporaneous records of what existed and what it earned are worth more than recollections.
Inventory: find out what you actually own
The disappeared-developer situation is really an ownership audit wearing a crisis costume, and four assets decide everything. The domain: run it through ICANN’s registration lookup and learn who the registrant is, because a domain registered to you is leverage and a domain registered to the developer is the single most urgent problem on the list, the one asset that expires into genuine loss. Hosting: find the bill, whoever pays controls more than whoever configured, and your card on file gives you standing with the host’s support even without panel credentials. The site itself: your crawl now holds the public layer, and wp-admin access, if any team member retains any account, adds drafts and settings. And the email: if mail runs through the same hosting or domain, it outranks the website in urgency, since losing the domain means losing the inbox that everything else resets through.
| Asset | Check | If the developer holds it | Verdict |
|---|---|---|---|
| Domain | ICANN lookup registrant | Written transfer request, registrar escalation | Most urgent, expires into loss |
| Hosting | Who pays the bill | New hosting, repoint when recovered | Billing is standing |
| Site content | Crawl + REST pull | Public layer cannot be withheld | Already yours, copy today |
| MX records, who administers | Migrate before any confrontation | Outranks the website |
The written-request step matters even when you expect silence: registrars and hosts have processes for unresponsive-party transfers, and those processes start with documented, dated requests from the business owner.
Reach out once, properly, then proceed without them
One professional message to the developer, then the plan proceeds on your timeline rather than theirs: state what you need, credentials, a transfer authorization, final invoices settled against deliverables, give a reasonable deadline, and say what happens after it, that you will restore access through the providers directly. Most disappearances are overwhelm, illness, or a folded business rather than malice, and a calm exit path recovers more accounts than an ultimatum. What you should not do while waiting: dispute old charges reflexively, since chargebacks can freeze exactly the hosting account you need cooperative, or attempt access through guessed credentials, which crosses lines that turn a civil mess into something worse. The providers, registrar, host, are the legitimate route, they deal with this weekly, and your position as the paying business owner is stronger than it feels.
Where real money or the domain itself is stuck with an unreachable party, a solicitor’s letter is the proportionate escalation, and the earlier inventory is exactly the evidence it attaches.
Recover or rebuild: the fork, decided honestly
With the content safe and the ownership map drawn, the fork is a business decision rather than an emergency. Recovering the old setup, new credentials, same site, makes sense when the ownership audit came back clean, the site is healthy, and the only thing missing was the person; expect a security pass, all passwords rotated, unknown admin accounts removed, plugins updated, since an unmaintained install has been accumulating the standard WordPress security debts the whole time. Rebuilding is the answer when the audit found the classic disappeared-developer estate: the site slow under an abandoned page builder, plugins unlicensed and unupdatable, hosting on the developer’s reseller account, and nobody left who understands how it fits together. In that state, recovery restores your access to the problem, while a rebuild converts the crisis into the modernization that was overdue anyway, and the crawl already in your hands is precisely the input a crawl-first migration starts from: the new site is built to match the recorded inventory, URLs preserved or redirected, rankings carried, on hosting and accounts registered to you.
The deciding question is not sentiment but stewardship: which path leaves the business able to survive the next departure? A recovered install with rotated passwords still depends on finding another WordPress caretaker; a rebuilt static site removes most of what needed caretaking.
The week-by-week shape of a typical rescue
For calibration, the rescue runs faster than the anxiety suggests. Week one: the crawl and REST copy on day one, the ownership audit by day three, the professional message sent with a fortnight’s deadline, and, where email is at risk, mailbox migration started immediately. Week two: provider processes in motion, registrar transfer request filed, hosting support engaged with billing evidence, while the recover-or-rebuild decision gets made against the audit’s findings rather than under time pressure, because the content copy already removed the urgency. Weeks three to six: on the recovery path, credentials restored and rotated with the security pass; on the rebuild path, the crawl-first build proceeds in parallel with the domain recovery, so the new site is ready to point at the moment the DNS is back in the business’s hands. The pattern worth internalizing: everything technical moves in days once the copy exists, and the calendar is set almost entirely by provider processes and the other party’s silence, which is precisely why the copy comes first and the deadlines get written down.
The ownership rules that prevent the sequel
Every rescue ends with the same short constitution, and adopting it is what makes this a story you tell once. The domain is registered to the business, at a mainstream registrar, in an account with the owner’s email and payment method, auto-renew on, and no service provider ever becomes the registrant. Hosting and every critical account, DNS, email, analytics, are opened by the business and shared with contractors, never the reverse, because access is grantable and revocable while ownership is neither. Credentials live in a password manager the business controls, with contractor access scoped and removable in minutes. An independent copy of the site exists on a schedule, even just a quarterly crawl archived to storage you hold, so the business is never again in the position of hoping a stranger kept backups. And every engagement, including ours, is judged partly on this axis: a provider who wants to own your accounts is quoting for leverage, not service, and the WPBuildAI rebuild hands over a site whose accounts, code, and content sit under the owner’s keys because that is the only version of done that survives audits like the one you just ran.
None of this requires technical depth, only the habit of asking, for each new service, whose email is on the account, and refusing every answer that is not yours.
Key takeaways: when your WordPress developer disappears
Run the order, not the panic: copy the live site immediately via crawl and REST, since the public layer cannot be withheld and going offline is the only irreversible failure; audit ownership of the four assets, domain first through ICANN lookup, then hosting, content, and email; make one professional request with a deadline, then work through registrar and host processes rather than ultimatums or guessed passwords. Decide the fork on stewardship: recover a clean, healthy setup, rebuild the classic abandoned estate, and let the crawl already in hand seed the crawl-first migration onto infrastructure registered to you. Then adopt the ownership constitution, business-registered domain and accounts, scoped contractor access, scheduled independent copies, so the next departure is an inconvenience instead of a crisis.
Quick answers
What should I do if my WordPress developer disappears?
In order: copy the live site today, a front-end crawl plus the public REST API captures every page, image, and metadata field without any password; audit what you own, domain registrant via ICANN lookup first, then hosting billing, remaining access, and email; send one professional request with a deadline; then proceed through registrar and host support, who handle unresponsive-party cases routinely. With content safe, decide between recovering the old setup and rebuilding onto accounts you own, which is the rescue WPBuildAI systematizes: the crawl becomes the inventory a crawl-first rebuild starts from.
Can I get my website content without the developer’s passwords?
Yes, the public layer cannot be withheld: a crawl of the live site records every page, title, meta description, image, and link exactly as served, and standard WordPress installs expose all public content as structured JSON through the core REST API, no authentication needed. What stays out of reach without credentials is the private layer, drafts, unpublished pages, user data, which usually matters far less than owners fear. Copy the public site before any negotiation begins, because content in hand changes every later conversation.
The domain is registered in my developer’s name. How bad is that?
It is the most urgent item on the list: the domain is the business’s address, email backbone, and the asset that expires into real loss, and a registrant who cannot be reached is a countdown. Confirm the registrant through ICANN’s lookup, request a transfer in writing with a deadline, and escalate to the registrar’s processes for unresponsive parties, with a solicitor’s letter as the proportionate next step where silence continues. Meanwhile capture the site content immediately, and treat the eventual recovery as the moment the domain moves into a business-owned account permanently.
When should you not rebuild, and just recover the old site?
Recover rather than rebuild when the audit comes back clean: assets already yours, the site fast and healthy, and only the person missing, with a security pass budgeted and a new caretaker lined up. Rebuild when the audit finds the classic estate, slow under abandoned plugins, on reseller hosting nobody understands, because recovering that only restores access to the problem, while the crawl-first rebuild converts the crisis into the overdue modernization on infrastructure that survives the next departure.
How do I make sure this never happens again?
Adopt the ownership constitution: the domain registered to the business with auto-renew and the owner’s payment method, every critical account opened by the business and shared with contractors rather than the reverse, credentials in a business-controlled password manager with revocable contractor access, and a scheduled independent copy of the site, even a quarterly crawl in your own storage. The test for every provider, ours included: whose email is on each account, and any answer that is not yours is leverage accumulating. Access is grantable; ownership should never leave the business.
