Your web developer stopped responding. Here's how to regain control of your website.
Developers go quiet for all sorts of reasons, and it isn't always bad faith. Either way, what matters is getting your domain, hosting and logins into your own hands without breaking anything. Here's the order that works.
It usually starts small. An email goes unanswered, then a phone call. The site is still up, so it doesn't feel urgent, until something breaks, a renewal comes due, or you need a simple change and realize you can't make it yourself.
A developer who goes quiet isn't necessarily trying to hold anyone hostage. They're overloaded, ill, winding down a business, or embarrassed about a job that slipped. That's worth remembering, because the calm route is usually the fast one. But you shouldn't need anyone's cooperation to control your own business's website, and with the steps in the right order, a lot of it can be done without them.
Start with one clear, written request
Before going around anyone, send a short message that lists exactly what you need. A specific list is easier to act on than "please call me," and it gives you a record if this turns into a dispute. Ask for:
- The login for the registrar account that holds your domain, or a transfer of the domain into an account in your business's name
- Administrator access to the hosting account, or a complete backup of the site's files and database
- An administrator account on the website itself, under your name and your email address
- Access to anything else they set up for you: DNS, business email, your Google Business Profile, Analytics, Search Console, forms or payment accounts
Give a reasonable deadline, send it through every channel you have for them, and keep copies.
Find out what you already control
While you wait, work out where everything lives. You may control more than you think, and every answer here tells you which conversation comes next.
| Piece | How to find out where it lives | What you want |
|---|---|---|
| Domain | ICANN's free lookup at lookup.icann.org shows the registrar for .com, .net, .org and other generic domains | An account at that registrar in your business's name |
| DNS | The same lookup lists the domain's nameservers, which tell you which company answers for it, often the registrar, the host or Cloudflare | A login where you can see and edit the records |
| Hosting | Your card statements, or the host your developer named in invoices | Your own account with the host, or at least a complete backup |
| Website | The admin login for your platform, such as /wp-admin on WordPress | An administrator account under your own email |
| The domain's MX records show which provider handles your mail, such as Google Workspace or Microsoft 365 | An administrator login for that provider | |
| Google accounts | Business Profile, Analytics and Search Console each list their owners and users in their settings | Owner or administrator access on your own Google account |
Look at your card statements too. If you've been paying a registrar or host directly, you're the customer there, and that's a much easier conversation than if the developer was billing you for hosting that sits inside their own account.
Secure the domain first
The domain matters most, because everything else hangs off it. Whoever controls it controls where your website and your email go.
If you pay the registrar yourself but the developer set up the login, contact the registrar's support, prove you're the customer or the domain's registrant, and have the account moved to your own email address.
If the domain sits inside the developer's registrar account, ask them to move it to an account in your business's name, or to give you the transfer authorization code so you can move it to a registrar you choose. ICANN's transfer rules make the registrant, the person or business the domain is registered to, the only party who can approve a transfer, and the registrar has to provide the code within five calendar days of a request. A registrar may refuse a transfer within 60 days of the domain being registered or last transferred, and changing the registrant usually triggers a 60 day transfer lock unless you opt out beforehand, so if you plan to move registrars too, ask about that before the change. If a registrar won't provide a code the registrant is entitled to, ICANN takes complaints. ICANN has approved changes to these transfer rules, but they aren't in effect yet.
The hard case is a domain registered in the developer's own name rather than your business's. On paper they're the registrant, and the registrar will treat them as the owner. If they won't cooperate, the route runs through your agreement with them and possibly an attorney. If they're willing to hand everything over for a reasonable fee, paying it is often quicker and cheaper than a dispute. Either way, note the expiration date now. A domain that lapses during a standoff is a much bigger problem than the standoff.
Then the hosting
If you're the hosting customer, the host can verify you and give you access. If your developer hosts the site inside their own account, which is common when a studio bundles hosting with its work, the host's contract is with them rather than you, and the host usually can't hand you the account.
If the site was built on a hosted builder such as Wix or Squarespace inside the developer's own account, ask the builder's support how a site is moved to another account, and what they need from you. Builders generally don't let you export a complete site to another platform, so moving away from one usually means rebuilding.
For a WordPress site on the developer's hosting, what you need is a complete backup: every file and the full database, not just a copy of the pages. With that, the site can be moved to hosting you control and run as it did before, without a rebuild. Our migration checklist covers what to check during the move, including the email and DNS details that tend to get lost.
Getting into the website itself
If you control the hosting but not the website's admin, you're in a good position. On WordPress, try the password reset link with every email address your developer might have set up for you. If that doesn't work, anyone with access to the hosting can reset an administrator's password through the database, or reset one or create a new administrator with WP-CLI, a command line tool many hosts provide. These are routine for a developer and easy to get wrong for everyone else, so it's worth having someone experienced do it.
Once you're in, add yourself as an administrator under your own email before changing anything else. Don't delete the developer's account straight away. Change its password or lower its role instead. Deleting a WordPress user means deciding what happens to everything that account created, and the safest time to make that call is after you know exactly what it created.
Email and the Google accounts
Business email is often the quietest risk. If the developer set up Google Workspace or Microsoft 365, they may be the only administrator. Google Workspace has an admin recovery process that asks you to add a DNS record proving you own the domain. Microsoft 365 handles a locked-out administrator through its support team, or through a DNS-based takeover for accounts that were never fully set up. Controlling the domain and DNS makes either route easier, which is another reason to secure them first.
The same goes for your Google Business Profile, Analytics and Search Console. Each has its own way to add an owner. Search Console can verify a new owner through a DNS record without anyone else's permission, though the old owner stays verified until their verification is removed. A Business Profile has a formal ownership request for when the current owner doesn't respond, and Analytics has a recovery process that asks you to prove you control the website.
Once you're back in, lock it down
- Change every password the developer knew, starting with the registrar, the hosting and email.
- Turn on two-factor authentication everywhere it's offered.
- Remove the administrator role from accounts you don't recognize, once you've confirmed your own access works.
- Review the domain's DNS records and the site's plugins for anything nobody can explain.
- Make sure you have a recent backup stored somewhere other than the server it came from.
Old logins that nobody removed are one of the quieter ways websites get compromised, which is covered in how websites actually get hacked.
Access and ownership aren't the same question
Getting your logins back doesn't settle who owns what. The domain belongs to whoever it's registered to. Text, photos or code a developer created for you, such as a custom theme or plugin, can remain theirs under copyright law unless your agreement transfers them to you, and stock photos are usually licensed rather than owned. If the agreement doesn't say, ask an attorney before assuming either way. We're a web company, not a law firm, so treat this as a reason to check rather than as legal advice.
Set it up so this can't happen again
The fix is simple and a little boring. Keep the domain in a registrar account in your business's name, with an email address you control. Keep every login in a password manager the business owns. Know where the site is hosted, and what your agreement says about getting a complete copy of it. When someone works on your site, add them as a user you can remove rather than handing over your own login.
None of that requires distrust. It just means a developer leaving, retiring or disappearing for a month is an inconvenience instead of a crisis.