Get Your Website Back From a Previous Developer

Nothing on this list is unrecoverable. The order decides how long it takes

There are two ways to be locked out of your own website, and from the inside they feel identical. Either you had access once and lost it, or you never had it at all: whoever built the site registered everything under their own name and their own email, and sent you a link when it was finished.

The recovery is the same job either way, and it starts by giving up a comfortable idea. Your website is not one thing you own. It is eight or nine separate accounts, held at different companies, each with its own registered owner, and most people chase them in the wrong order. They start with what they can see, which is the website, and ask for the WordPress password. That is the fifth item on this list, not the first.

Start at the domain. Whoever controls the registrar account can point your name at any server on earth, which means they can replace your hosting, your website and your email in an afternoon. Everything downstream of the domain can be rebuilt. The domain cannot. It is the address your customers type, your invoices carry, your Google listing points at, and every link anyone has ever made to you resolves through.

So the principle for everything below is: work from the asset that controls the others, downwards. Get the domain and you are negotiating from a position where the worst case is a weekend of rebuilding. Leave the domain for last and the worst case is that you lose the business's name.

Copy everything you can still reach, before you ask for anything

Do this first, today, before a single message goes out. The moment you ask for your accounts the relationship changes, and whatever you can see right now is the most you will ever be able to see without someone else's cooperation.

None of this requires the developer's help:

• The current registration record for your domain. Save it as a file, not a memory. For most domains this is the fastest way to find out which registrar you are actually dealing with and whose name is on the registration. The WHOIS lookup gives you both. ICANN sunset the old WHOIS protocol on 28 January 2025 and RDAP is now the definitive source for generic domains, which is also why a lot of older lookup sites quietly return less than they used to.
• The live DNS zone, every record of it. A, AAAA, CNAME, MX, NS and all the TXT records, including SPF, DKIM and DMARC. The DNS checker will read them for you, starting with the NS records, which tell you which panel holds the zone that is actually in force. This is the single most valuable thing on the page and the one almost nobody saves, because DNS is invisible until it is gone. If the zone disappears before you have copied it, your website goes down loudly and your email goes down silently, and reconstructing a DKIM record from nothing is not a thing you can do.
• Proof of who paid. Card statements, bank transfers, the registrar's invoice, the hosting invoice. If the argument ever becomes a formal one, the person who paid the registration fee has a very different conversation from the person who merely believes they should have.
• The paper trail of the agreement. The quotation, the scope email, the WhatsApp thread where somebody wrote "we will register the domain for you". Screenshot it and store it somewhere the other party cannot edit.
• Everything behind any login you still have. Export the content and the database from the CMS, download the media library, and pull the last sixteen months out of Search Console and your analytics before anybody removes you. Access you have today is not access you will have next week.

That is an hour of work and it changes the entire negotiation, because from here on you are asking for things you can already describe exactly.

The recovery order, and why it is this order

1. The domain registrar account

Find out two things before you ask anybody for anything: which registrar holds the name, and who is listed as the registrant. The lookup above answers the first for certain. The second depends on the ending.

For .com, .net, .org and the rest of the generic domains, the registrant's contact details are usually redacted in public lookups under ICANN's Registration Data Policy, so you will see the registrar and the nameservers but not the name. You can still request the non-public data through ICANN's Registration Data Request Service, though that is built for law enforcement and intellectual-property work rather than for a business chasing its own domain. The faster route is to contact the registrar directly with your invoices.

Then there are three outcomes, in descending order of pain.

You are the registrant and you can get into the account. Change the password and the recovery email, turn on two-factor authentication, and remove any other user or delegate on the account. You are done with step one in ten minutes.

You are the registrant but the account email is the developer's. Contact the registrar, not the developer. Registrars have an identity-verification process for exactly this and will usually want government photo identification, the original payment instrument, and proof that you are the entity named in the registration. It is slow and it works.

The developer is the registrant. This is the one that needs a transfer, and the mechanics are worth knowing precisely, because they constrain what you can ask for and when.

Two different moves exist and people confuse them constantly. A change of registrant changes whose name is on the domain and leaves it at the same registrar. An inter-registrar transfer moves the domain to a registrar you choose and needs an authorisation code. If you can get both, do the change of registrant first and then the transfer, so the name is yours before it moves.

ICANN's Transfer Policy governs the second move for generic domains, and two of its rules are worth memorising. Where the registrar does not offer self-service, it "must provide the Registered Name Holder with the unique 'AuthInfo' code ... within five (5) calendar days" of the request. And a registrar "must not refuse to remove the 'ClientTransferProhibited' status or release an 'AuthInfo Code' ... solely because there is a dispute ... over payment". A hosting bill you disagree about is not grounds to hold a domain.

The same policy lists the reasons a transfer may legitimately be denied, and it is a short list: evidence of fraud, a reasonable dispute over the registrant's identity, non-payment for the current or an expired registration period, an express objection by the authorised registrant, a pending UDRP or court order, or the domain being within 60 days of its creation or of a previous transfer. Note what is not on it.

A change of registrant on a generic domain usually applies a 60-day lock against moving registrar afterwards, which can normally be opted out of at the moment the change is confirmed. Ask for the opt-out explicitly if you intend to move registrar straight after, or you will wait two months.

If your registrar misses the five-day window or denies the transfer for a reason that is not on that list, ICANN takes a formal transfer complaint and its registrant FAQ sets out when to file one. This is free, it goes to the registrar's compliance team rather than its support queue, and it is remarkably effective at unsticking a request that has been ignored for a month.

2. DNS and the nameservers

The registration record tells you which nameservers are authoritative for your domain. They are very often not at the registrar: a site built in the last few years is quite likely to be on Cloudflare or on the hosting provider's own nameservers, and whoever holds that account controls where every service at your domain resolves, even after the registrar account is yours.

So the moment you control the registrar account, stand up a DNS zone you own, recreate every record from the copy you took earlier, and repoint the nameservers at it. Keep the record values identical. This changes nothing a visitor can see and takes the single most dangerous dependency out of somebody else's hands.

Changing nameservers is also the lever that unlocks several steps further down this list, which is why it sits so high. Verification of a domain in Google's services, a mail provider's setup, an SSL certificate issued by DNS challenge: all of them are decided by whoever can write a TXT record.

3. Hosting, the files and the database

Now the website itself. Ask for the hosting control panel, and ask specifically for: a full file archive of the document root, a database dump, the cron jobs, and any environment or configuration file holding API keys. A WordPress export on its own is not a backup. It omits the theme, the plugins, the uploads directory and the configuration, which between them are most of what makes the site look like your site.

If the hosting account belongs to the developer and will not be handed over, you do not actually need it. With the domain and the DNS in your control you can rebuild the hosting anywhere and repoint. A static or brochure site can be captured with a crawler well enough to rebuild from; an application cannot, and that is what makes the database dump the item to push hardest for.

Taking an application off somebody else's server and onto infrastructure you own is ordinary work. It is also where the URLs tend to change, and changing URLs is how businesses lose rankings that took years to earn, so read moving a website without losing search traffic before anybody starts. If the stack is unfamiliar and nobody internally has done this before, it is the kind of thing our cloud and DevOps work exists for.

4. Email, and the MX records nobody mentions

This is the step that is missing from almost every guide to this problem, and it is the one that causes the real damage. Websites go down visibly and somebody complains within an hour. Email goes down invisibly: messages bounce at the sender's end, or worse, keep flowing to a mailbox you no longer read.

Three separate things have to be true for your email to be yours.

The MX records point at a mail service you control. They live in DNS, so step two already fixed the ability to change them. Changing them before the mailboxes exist on the other side, however, loses mail.

You are an administrator of the mail service. If your addresses are on Google Workspace or Microsoft 365, the tenant is an account with its own super administrator, and that may be the developer. Google documents the route back for its own services: if someone else signed up using email verification, "when you verify your domain, you take over management of the Google service for your organization" (Google Workspace Admin Help). Domain verification is a DNS record. This is step two paying for itself.

The mail itself has been exported. Mailboxes are not covered by any transfer of a domain or an account. Export them to PST or MBOX, or run an IMAP migration into the new tenant, before anything else changes.

While you are in the zone file, keep the SPF, DKIM and DMARC records intact through the move. Dropping them does not break mail immediately, which is exactly why it goes unnoticed until your invoices start landing in customers' spam folders weeks later. If that has already happened, why business emails go to spam has the record syntax for the common setups and an ordered way to find which of the three is actually missing.

5. The CMS or application admin

Compared to everything above this is easy, because once you hold the hosting or the database the CMS user table is just data. Create a new administrator, demote or remove the old accounts, rotate the database password and every API key in the configuration file, and look at what else has a login: a staging site, a plugin licence, a form service, a chat widget.

The item people forget is the SSL certificate. If it was issued through the hosting panel it renews with the hosting. If somebody bought it separately, or it is issued automatically from a service tied to the old account, it will expire at a moment of its choosing and put a browser warning in front of every visitor.

6. The source repository

Custom work lives in a Git repository somewhere, and that repository almost always belongs to the developer's personal account. Ask where it is by name: GitHub, GitLab or Bitbucket, the organisation and the repository.

A transfer is the clean outcome and it is a documented, one-click operation. GitHub's own documentation says you need administrator access on the repository to move it, that "issues, pull requests, wiki, stars, and watchers are also transferred", and that links to the old location redirect to the new one. Two limits are worth knowing in advance: the destination cannot already have a repository of the same name, and a repository forked from a private upstream network cannot be transferred at all.

If a transfer is refused, a clone is the fallback. git clone --mirror takes the entire history, so the code is safe. What it will not take with it is the issue history, the pull-request discussion and the deployment settings, which is the part that is genuinely gone.

Then there is the case where there is no repository, because the site was edited directly on the live server over FTP for three years. That is a real answer and a common one. Take the file archive from step three, put it in a repository of your own on day one, and treat that as the baseline. Everything after it will be recoverable even if nothing before it was.

7. Search Console, Analytics, Tag Manager and the Business Profile

Four separate Google products, four separate permission systems, and every one of them has a trapdoor.

Search Console. Verify the property yourself using a DNS TXT record, which you can now write. Then remove the old owners properly: Google's documentation is explicit that after removing a verified owner you must "delete all verification tokens for this user in this property. If you do not delete these tokens, the removed owner will be able to re-verify ownership." Removing the user and leaving the HTML file or meta tag in place is not removal, and this is the single most commonly botched step on this list. Export your performance data before you change anything, because Search Console only keeps sixteen months.

Analytics. A GA4 property sits inside an account, and the account is the thing with an owner. You need the Administrator role at account level to remove users at all. If the property is inside the developer's account, the right outcome is to move the property rather than start a new one, which Google allows when you have the Administrator and Editor roles on both the source and destination accounts. It is worth the effort: the data moves rather than being copied, and the measurement ID does not change, so nothing on the site has to be retagged. The change history from before the move stays behind with the old account.

Tag Manager. Permissions are split between the account and the container, and if the analytics tag is deployed through GTM then whoever administers the container controls your measurement regardless of who owns the Analytics property. Google's own guidance is to keep at least two active administrators, which is advice worth taking the moment you have one.

Google Business Profile. For a local business this is often worth more than the website, because it is what shows in Maps and it carries the reviews. If somebody else manages it, go to business.google.com/add, find the business and choose Request Access. Google's documentation says the current owner "is then notified by email and has 3 days to respond", and if they do not respond you may get the option to claim the profile yourself, though it notes that the option is not always available. If the request is denied you can appeal. Start this one early, because it runs on Google's clock rather than yours.

8. Payment gateway, SMS and transactional email

The last tier is the one that quietly keeps charging somebody. A payment gateway, an SMS sender, a transactional email service, a maps or storage API key: each is a separate vendor account, each is attached to somebody's identity, and on an Indian payment gateway that identity is a KYC record, so an account cannot simply be reassigned on request.

Check your gateway's own documentation rather than guessing, because the good ones have built the handover in. Razorpay, for example, documents changing the registered email from Account and Settings with two-factor authentication, and transferring the account owner through Manage Team by selecting a team member and choosing Change Owner.

Where an account genuinely cannot move, open your own, rotate the keys in the application, and let the old one be closed. Then check the card the subscriptions renew on, because an API key you no longer use is cheaper than an API key you no longer control.

When the developer simply stops replying

Silence is the common case and it is not usually malice. Small studios close, individuals change jobs, and an account nobody is paid to maintain stops being anybody's problem.

Work the route that does not need them. Almost every step above has one.

• The registrar will deal with you directly on identity and payment evidence. So will the hosting company.
• ICANN's transfer complaint applies to any generic domain where a registrar is not following the Transfer Policy.
• Google's access-request flows for Business Profile and Workspace are designed for exactly the case where the current holder is unreachable.
• DNS control gets you the mail, the verifications and the certificates.

Keep one written request on the record before you escalate: a single email listing each account by name, the access you are asking for, and a reasonable deadline. Not because it will necessarily be answered, but because every escalation after it goes better when you can show you asked plainly once.

A formal dispute is the last resort, and for a domain that genuinely belongs to your business and is registered to someone else, it exists. For .in and .भारत that is the INDRP, below. For generic domains it is the UDRP, or a civil claim. Both cost more than the recovery usually does, so they are where this ends rather than where it starts.

What is different about .in and .भारत

If your domain is Indian the rules above change in ways that mostly work in your favour, and almost nothing written on this subject says so.

.in is run by NIXI, not by ICANN, so ICANN's Transfer Policy and its complaint forms do not apply to it. What applies instead is NIXI's own Terms and Conditions for Registrants, and three clauses in it matter here.

The registrant's email must be the registrant's. Clause 1 states that "the email address submitted in the contact information will be that of the Registrant only", that it should be visible in the .IN registry's WHOIS, and that "it is the duty of the Registrant to check this information from time to time and make sure that it is up-to-date".

Privacy masking is not allowed, and masking costs you ownership. Clause 3 is blunt: "Any kind of proxy services are not allowed, and if the data is wrong or masked out by any proxy/privilege protection services, the Registrant shall not be recognized as the owner of the domain name." This is the practical difference from a .com. Look up a .in domain and you should actually see who holds it, rather than a redaction. Look yours up now.

Wrong data is a breach. Clause 2 makes a registrant's willful or grossly negligent provision of inaccurate information "a material breach of the Registrant's Registration Agreement with the Registrar and be a basis for cancellation of the Registered Name".

On process, the registry is clear that it does not deal with registrants at all: "NIXI is not allowed to change records directly for registrants", and "NIXI does not give out authorization codes to registrants". Both go through your sponsoring registrar. A transfer, once initiated by the gaining registrar with a valid authorisation code, completes "in five 24-hour periods". And from NIXI's policy framework, a domain cannot be transferred in the 60 days following its creation, and a registrar-to-registrar transfer adds a year to the term, charged to the gaining registrar, so a transfer is also a renewal.

Where a .in or .भारत domain has been registered against your name or trademark in bad faith, the INDRP is the dispute route. It covers both .IN and .BHARAT, the complainant has to establish all three of the usual limbs, the remedies are cancellation or transfer of the name, the complainant pays the costs, and it runs as mandatory arbitration before a NIXI-empanelled arbitrator under the Arbitration and Conciliation Act, 1996.

The three registrars we are asked about most

The procedures below come from each registrar's own current documentation. Check them against the page on the day, because registrars change their panels more often than they change their policies.

GoDaddy. To move a domain to a different GoDaddy account, the holder opens the domain's settings and chooses Transfer to another GoDaddy account, entering your email address. You then accept it from your own Transfers page, acknowledging the Universal Terms of Service and the Change of Registrant Agreement. Two details decide whether this works: the request expires if it is not accepted within 10 days, and connected products do not come with it. DNS settings are kept, but "any connected products, such as a website or email, do not transfer with the domain", so a GoDaddy-hosted site or mailbox is a separate conversation. Domains are not eligible while a contact update is pending approval, within a day of expiry, expired, or already pending another transfer. On a straight registrant change rather than an account move, both the old and new registrant are emailed and have to click through, and the prior registrant has to opt out of the 60-day transfer lock if the plan is to move registrar afterwards.

BigRock. The structure is different and this is the one that surprises people. BigRock sells through a customer control panel, and a domain bought for you by a studio sits inside that studio's panel rather than in an account of your own, which is why there is no login to hand over in the first place. The documented fix is moving an order from one customer control panel to another: the current holder signs in, finds the domain under orders, uses Move Services, and supplies your customer ID and the email address on your account. You need an active BigRock account first, and the domain has to be unlocked and unsuspended before it will move. A change of registrant is separate and sits under ICANN's rules for generic domains: BigRock's domain registration agreement confirms that material changes to the registrant name, company or email are subject to the Transfer Policy, that both the prior and new registrant or their designated agents must confirm, and that the 60-day transfer lock applies unless you opt out at the time.

Hostinger. Moving between Hostinger accounts is the simplest of the three and needs no authorisation code at all: "You do not need a transfer authorization code (EPP key) to move a domain between Hostinger accounts", and it is free. The holder opens the domain's Domain Ownership page and uses Move to another Hostinger account with your email; you accept from your own Domains section and enter the contact details, and both addresses confirm by email. It covers generic domains plus .in, .co.in, .gen.in, .ind.in, .net.in and .org.in directly. The constraints are worth planning around: a domain can only be moved once every 10 days, must have been registered for at least 96 hours, and must not be expiring within 10 days. To leave Hostinger entirely, the authorisation code is shown on the domain's overview page.

Proving the handover is actually finished

A handover that has been promised and a handover that has happened look identical from your inbox. These checks tell them apart, and every one of them is something you do rather than something you are told.

• Log in to every account from a browser you have never used for it, using credentials you set yourself. Borrowed access is not access.
• Change the password and the recovery email on each one, and turn on two-factor authentication. A recovery email you do not control is a key you have not taken back.
• Look at the user list on every account and remove everyone who should not be there, including the old administrator, old API tokens, old SSH keys and old deploy keys.
• Confirm you are the registrant, not merely a user of the account. Re-run the WHOIS lookup and read the registrant field.
• Compare today's DNS against the copy you took on day one. The DNS checker makes this a one-minute job. Every A, MX and TXT record should match, or differ for a reason you can name.
• Send and receive a real email at a real address on the domain, in both directions, from outside the organisation.
• Do a test deploy. Change one word on one page, push it, and watch it appear. This is the only proof that the repository, the build and the server are all actually yours.
• Check the whole site answers correctly. The website health checker covers the certificate, the redirects, the headers and the indexability in one pass, which catches the certificate that was renewing on somebody else's account.
• Verify you are a verified owner in Search Console, and that the old owner's verification tokens are deleted rather than merely their account removed.
• Find the renewal dates and the cards they bill to. A domain that renews on an ex-developer's expired card is a problem with a date on it.

Keep the answers in one document with the account names, the login URLs and who holds the recovery address. That document is the actual deliverable of this whole exercise.

The clauses that stop this happening twice

Most of this is caused at the start of a project rather than at the end of one, in a week when nobody is thinking about the end. Four lines in the agreement would prevent nearly all of it.

Name the registrant. The contract should say that all domains are registered in the client's legal name, with the client's email as the registrant contact, and in an account belonging to the client. If a developer registers on your behalf as a convenience, that is fine, but the registrant field is yours from day one. This is one line and it removes the hardest step on this page entirely.

List the accounts and who holds them. An appendix with every account the project will create: registrar, DNS, hosting, mail, repository, analytics, gateway. Who is the owner of record, who gets administrator access, and who holds the recovery email. An account that is not on that list is an account nobody will remember to hand over.

Assign the intellectual property in writing, and name the repository. A verbal understanding that the code is yours is not an assignment. Put the assignment of the custom work in the signed agreement, and require the code to live in a repository owned by your organisation from the first commit rather than being transferred at the end. Code that was never in somebody else's account does not have to be recovered from it.

Write the exit into the contract, not into the argument. A handover clause stating what is delivered, in what format and within how many days of termination, plus a requirement to keep credentials in a shared vault throughout. Agree it while everyone is pleased with each other, because the alternative is agreeing it while nobody is.

If you are about to commission new work, these belong in the brief rather than being raised later as an awkward amendment. Writing a software brief that gets an accurate quote covers what else belongs in that document.

The four lines above are the what. If a developer has already sent you a draft and you need the actual wording, what to change in a website development agreement sets each of them out as a clause you can paste in, with the Copyright Act formalities an assignment has to meet, and adds the five this list does not cover: credentials in a shared vault from day one, the reusable library carve out, milestones that turn on acceptance rather than on dates, how a change is priced, and what the maintenance line actually commits to.

Start here

1. Look up your domain and find out which registrar holds it and whose name is on it.
2. Save the full DNS zone, every record, to a file.
3. Gather the invoices and the email thread that show who paid and what was agreed.
4. Send one written request listing every account by name, with a deadline.
5. Work down the eight assets in order, starting at the registrar, and verify each one yourself rather than accepting that it was done.

Most of these recoveries are finished in a week or two and never become a dispute. The ones that drag on are almost always the ones where somebody started at the website and worked upwards, or where a transfer request sat unanswered for a month because nobody knew a registrar's compliance team is a different queue from its support team.

If the accounts are scattered and you would rather not spend a fortnight on hold, this is routine work for us: tracing the assets, getting the domain and the DNS under your name, and leaving you with a document that says where everything lives. That is website fixes and maintenance. If what is actually needed is to lift an application off somebody else's server onto infrastructure you own, that is cloud and DevOps.

Either way, do step one today. Everything else on this page is easier once the domain is yours.