Your WooCommerce Developer Disappeared? How to Take Back Your Store

If your WooCommerce developer has stopped answering, don't start by looking for someone to fix bugs. First find out which accounts you control and which ones sit in the developer's name. Then reclaim the domain, hosting, WordPress admin, payment gateway and Google accounts, in that order, and take a full backup before anyone changes anything.

Most of the stores we take over are not broken. The problem is that nobody inside the business can log in to the things the store depends on. This guide shows how to fix that, and how to make sure it does not happen again.

What should you do in the first 48 hours?

Don't panic, and don't let a new developer start "fixing" things yet. Work through this list in order:

1. Send one clear, written request to the developer (email plus any chat channel you used). Ask for admin access, hosting access, the code repository and all credentials by a specific date. Keep it polite. You may need this message later as evidence.
2. List every account the store touches. Use the table in the next section. Check old invoices and your email inbox for "welcome" messages from hosts, registrars and plugin vendors. They show who registered each account.
3. Check who owns the domain. A domain that expires takes the whole store offline, including email. This is the most urgent item.
4. Check that orders and payments still work. Place a small test order. If payouts still reach your bank account, the business is safe for now and you can work calmly.
5. Don't cancel anything. Cancelling a hosting plan or card the developer used can take the site down before you have a copy of it.

Which accounts do you need to recover?

A WooCommerce store depends on more accounts than most owners realise. This is the list we work through on every takeover.

Account	Why it matters	Who should own it
Domain registrar	Controls the domain, DNS and often email	Your company, your email
DNS provider (if separate, e.g. Cloudflare)	Points the domain to the server	Your company
Hosting / server	Holds files, database and backups	Your company, developer as a user
WordPress admin	Runs the store	You as Administrator, developer as a separate user
Payment gateways (Stripe, PayPal, etc.)	Money flows through them	Your company as account owner
Google Analytics, Search Console, Merchant Center, Ads	Tracking, SEO and product feeds	Your Google account as owner/admin
WooCommerce.com and other plugin vendor accounts	Licences and updates for paid extensions	Your company
Code repository (GitHub, GitLab, Bitbucket)	The custom code and its history	Your organisation
Transactional email (SMTP, Mailgun, SendGrid)	Order emails and password resets	Your company

If any row says "the developer's personal account", that is where you start.

How do you get your domain back?

Look up the domain's registrant at the registrar. The registrant (the holder named in the record) is the legal owner, whoever pays the bill. If your company is the registrant but the developer holds the login, the registrar's support team can usually move the account to you after checking your identity.

If you want to move the domain to a registrar you control, you need the transfer code (often called the auth code or AuthInfo code). Under ICANN's Transfer Policy, a registrar that does not let you generate the code yourself must give it to the registered name holder within five calendar days of the request. The same policy lets registrars block transfers for 60 days after a domain was registered or last transferred, and requires a 60-day transfer lock after a change of registrant, unless you opted out beforehand. So fix the registrant details first, and expect to wait before a transfer if you had to change them.

If the developer registered the domain in their own name, it is legally theirs until they transfer it. Ask in writing. If they refuse or never answer, you need a lawyer, and ICANN's registrant FAQ explains how to file a complaint when a registrar does not follow the rules.

How do you regain hosting and WordPress admin access?

Hosting. If the hosting account is in your company's name, contact the host with proof of identity and billing. If it is in the developer's name, you cannot take the account over. You can still ask the host to help you export a copy, but most will only act on the account holder's instructions. In that case, the safer path is to get a copy of the site by any legitimate route (a WordPress backup plugin, if you still have admin access) and move it to new hosting that you own.

WordPress admin. If you still have any Administrator login, create a new Administrator account for yourself with your company email. If you only have hosting, database or SSH access, WordPress documents several ways to reset an admin password: through phpMyAdmin, WP-CLI, a temporary line in the theme's functions.php, or an emergency reset script. For example, with SSH access:

wp user update 1 --user_pass='a-long-new-password'

Once you are in, don't delete the developer's user straight away. Change its role to Subscriber or reset its password first. Deleting a user in WordPress asks you what to do with their content, and a wrong click can remove pages or products attributed to them.

What about Stripe, PayPal and other payment accounts?

Payment accounts are the most sensitive part, because money moves through them. In Stripe, there can only be one Owner per account, and only the Owner can transfer ownership. Administrators can invite and remove users, but cannot change the account owner.

• If your company is the owner and the developer is an Administrator or Developer user, remove them and roll the API keys.
• If the developer created the Stripe account and is the owner, contact Stripe support. Payouts go to the bank account on file, so the verified business details matter. Prepare company registration documents.
• In WooCommerce, check WooCommerce > Settings > Advanced > REST API for keys the developer created, and revoke any you don't recognise or need.
• Check webhooks in both WooCommerce and the gateway dashboard. An unknown webhook URL can send order data to a server you don't control.

How do you recover Google Analytics, Search Console and Merchant Center?

Google accounts are often created by the developer "for convenience". Ask for Administrator access to your Analytics account or property, which is the role needed to manage users. Then make your own Google account the owner everywhere.

Search Console needs extra care. Removing a verified owner does not remove their verification token. Google's own owner management guide warns that a removed owner can re-verify as long as their token stays on the site. Remove the old owner, then remove their HTML file, meta tag or DNS record. Check first that no other Google service (Merchant Center, Workspace) relies on the same token.

Do you own the code your developer wrote?

Not automatically. In the UK, the Copyright, Designs and Patents Act 1988, section 11 makes the author the first owner of copyright, and the employer owner only when the work is made by an employee. A freelancer or agency is not your employee, so unless your contract assigns the rights to you, the developer may still own the custom code. Many other countries have similar rules. Check your contract for an assignment or licence clause, and ask a lawyer if there is a dispute.

Two things work in your favour. First, WordPress is licensed under GPLv2 or later, and WordPress.org states that plugins and themes are derivative works that inherit the GPL. In practice, code running on your WordPress site usually comes with the right to use and modify it. Second, you already have the running code on your server. Even without the repository, a developer can rebuild version control from the files.

Paid plugins are a separate issue. If the developer bought WooCommerce extensions on their own WooCommerce.com account, WooCommerce's guide on managing subscriptions as a developer explains that they can transfer them to your account. If they never do, you will need to buy your own licences to keep getting updates.

Why do you need a full backup before changing anything?

Everything above involves changing passwords, users and settings. If something goes wrong, you need a clean copy to return to. Take a backup of:

• The full database (orders, customers, products, settings)
• All files, including wp-content/uploads and any custom plugins or themes
• A list of active plugins and their versions
• Server settings you can see: PHP version, cron jobs, redirects, SSL configuration

Store the backup somewhere the developer never had access to, such as your own cloud storage. A backup on the same server doesn't count.

What should you secure once you are back in?

Once you control the accounts, assume every old credential is known to someone outside the business. That is not an accusation. Freelancers reuse tools, laptops get lost, and passwords sit in old chats.

• Change passwords for hosting, SFTP/SSH, database, WordPress admins and email/SMTP services
• Remove or downgrade old WordPress users, and use "Log Out Everywhere Else" on each profile
• Roll payment gateway API keys and revoke unknown WooCommerce REST API keys
• Remove SSH keys and application passwords you did not create
• Update WordPress, WooCommerce, plugins and themes on a staging copy first, then on live
• Run a malware scan and review recently modified files. If you find injected code, get a proper malware cleanup rather than deleting files one by one

Updates matter more than they seem. Patchstack's State of WordPress Security in 2026 report counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 91% of them in plugins. For heavily targeted flaws, the median time to mass exploitation was 5 hours. A store left without updates for months while the developer was silent is a real risk.

What should a proper handover include?

Whether the old developer comes back or you hire a new one, ask for this list. It is also a good standard to include in any future contract.

• All account logins transferred to company-owned emails
• Code in a repository owned by your organisation, with full history
• Written list of custom plugins, theme changes and where each lives
• List of paid plugins, the account each licence is on, and renewal dates
• Hosting and server notes: PHP version, cron jobs, caching, CDN, SSL
• Integrations: ERP, CRM, shipping, email marketing, with API keys listed (not the keys themselves in plain text)
• Deployment process: how code gets from the repository to staging to live
• Known issues and unfinished work
• Written confirmation of IP assignment for custom code, if your contract provides for it

How do you stop this happening again?

The rule is simple: the business owns every account, and developers get their own user with only the access they need. Keep a shared password manager vault that the company controls. Review users in WordPress, hosting and payment accounts at least once a year. And don't rely on one person who holds all the knowledge. Ask for documentation as part of the work, not as a favour at the end.

When to get help

If you cannot reach your developer and the store is down, taking payments incorrectly or showing signs of a hack, treat it as an emergency first and a handover second. Our WooCommerce emergency support team can triage the problem, and our WooCommerce takeover service covers access recovery, a code and security review, and the handover documentation you should have had from the start.