Domain Status Codes Explained (for Buyers)

Run a WHOIS or RDAP lookup on almost any established domain and you will meet a row of status codes: clientTransferProhibited, serverDeleteProhibited, and a handful of others. At first glance they read like a wall of no, a set of barriers put up to keep you out. For a buyer, that first impression is almost always wrong. Most status codes are protective, not prohibitive, and a few of them are quietly some of the best news a buyer can find. This guide walks through what status codes are, what each common one means in plain language, and, most importantly, what it tells you about how, and when, a name might be acquired.

What status codes are

Status codes, formally known as EPP status codes, describe the current state of a domain at two levels, the registry and the registrar. They tell you which operations are currently locked and where the name sits in its lifecycle. They come in two families that are worth telling apart. Client codes, which all begin with the word client, are set by the registrar on the owner's account, usually at the owner's request or as a default protection. Server codes, which begin with the word server, are set by the registry itself, often for lifecycle or policy reasons. Most of the time both families exist for the same underlying purpose, to protect a valuable name from accidental change, unauthorized transfer, or outright theft. Reading them as protection rather than prohibition is the single most useful mental shift a buyer can make.

Why client and server codes differ

The distinction matters more than it looks. A client code is something the owner or their registrar chose and can undo relatively easily, so it tends to reflect the owner's own caution. A server code is imposed by the registry and usually cannot be lifted by the registrar alone, which is why server-level locks often relate to disputes, policy actions, or a name's position in its lifecycle. When you see a name wrapped in client-level protections, you are usually looking at a careful owner. When you see server-level codes that are not simply routine lifecycle markers, it is worth understanding why the registry itself has stepped in.

The transfer locks

The code buyers notice most is clientTransferProhibited, often shown in a tool as Transfer locked. It means the registrar currently prevents the domain from being moved to another registrar without proper authorization. This is completely standard practice on any name of value, and it is a sign of a careful owner, not a closed door. It does not mean the domain cannot be acquired, and it does not mean the owner will not sell. It simply means that, as part of any agreed transfer, the owner will lift the lock and provide an authorization code at the right moment. serverTransferProhibited is the registry-level equivalent, set by the registry rather than the registrar, and it behaves the same way inside a proper, agreed transaction. Neither is a barrier to a legitimate deal, and treating them as one is how nervous buyers talk themselves out of good names.

The delete and update locks

clientDeleteProhibited and clientUpdateProhibited, along with their server-level counterparts serverDeleteProhibited and serverUpdateProhibited, prevent the domain from being deleted or having its details changed while they are set. Far from being a warning sign, these usually indicate exactly the kind of owner a serious buyer expects on a good name: careful, deliberate, and actively managing the asset. They are not obstacles to a sale. They are removed or worked through as a normal part of a legitimate transfer and the due diligence around it. If anything, seeing this cluster of protective locks on a name tells you the owner treats it as something worth guarding, which is useful context when you plan how to approach them.

The lifecycle codes that matter to a buyer

Some codes describe not what is locked but where a name sits in its life, and these are the ones a buyer should watch most closely, because they can signal opportunity. redemptionPeriod means the domain has already expired and is sitting in a grace window before deletion, still recoverable by its owner but no longer safely in their hands. pendingDelete means the name is scheduled to drop and will soon be released. Both can signal that a name you want may be about to become available, which changes your strategy entirely, from negotiating with an owner to timing a registration and, often, competing for it. On the other end, autoRenewPeriod and renewPeriod are routine, they simply mean a renewal has recently happened and the name is firmly in its owner's hands for another term. addPeriod means a name was only just registered and is still in its opening grace window. Learning to separate the opportunity codes from the routine ones is most of the skill.

The hold codes

clientHold and serverHold are worth their own mention because they do something visible, they remove a domain from the DNS entirely, so the name stops resolving and any website or email on it goes dark. These holds often relate to a billing lapse, an unresolved verification, or a dispute. For a buyer, a hold is a nuance worth understanding rather than a clear signal in either direction. A name that has suddenly stopped resolving may point to an owner who is disengaging, forgetting, or in some kind of difficulty, all of which can matter to how and when you approach. It can equally be a temporary administrative hiccup that will be gone next week. As with every code, a hold means far more in combination than it does alone.

A quick reference for buyers

Here is the short version worth keeping in mind:

• clientTransferProhibited and serverTransferProhibited: standard transfer lock, lifted during an agreed transfer, not a barrier.
• clientDeleteProhibited and clientUpdateProhibited: protective locks, usually a sign of a careful, engaged owner.
• redemptionPeriod: expired and in a grace window, a possible signal the name is slipping from its owner.
• pendingDelete: scheduled to drop, a possible chance to register it soon.
• autoRenewPeriod and renewPeriod: routine renewal, the name is firmly held for another term.
• clientHold and serverHold: removed from DNS, often billing or dispute related, read with care.
• addPeriod: recently registered, still in its opening grace window.

Reading them together

No single code decides anything, and the real skill is reading the whole set as a pattern. A long-established name carrying transfer and update locks alongside an active, well-run website is a well-managed asset whose owner is clearly engaged. That name is harder to acquire, though far from impossible with the right, patient approach. The very same locks on a name that shows only a parked page, sits on a marketplace nameserver, and has a long-dormant history read completely differently, as protective habits on an asset the owner may well be open to selling. Context turns identical codes into opposite conclusions. Westmore's free tool does this reading for you, translating every code into plain language and folding it into a single acquisition-readiness read, so you are never left decoding jargon on your own.

Codes that are simply routine

Not every code carries strategic weight, and a buyer who treats all of them as meaningful will exhaust themselves reading noise. addPeriod, renewPeriod, autoRenewPeriod, and transferPeriod are lifecycle housekeeping, they mark that a registration, renewal, or transfer recently happened and the name is in a short grace window around that event. inactive simply means no nameservers are set, which is common on freshly registered names that have not been pointed anywhere yet. ok, sometimes shown as active, means the name has no special locks or pending operations at all. None of these should change your read of a name on their own. They are the background hum of a normal registration, and the skill is learning to let them fade so the meaningful codes stand out clearly.

When a code should give you pause

A few situations genuinely warrant caution rather than optimism. Server-level actions that are not routine lifecycle markers, such as a serverHold applied by the registry, can indicate a dispute, a policy action, or a legal issue attached to the name, and a name under that kind of shadow deserves careful diligence before you invest time or money in pursuing it. pendingTransfer means a transfer is already underway, so the name may be about to change hands to someone else entirely. pendingDelete on a name you assumed was safely owned may mean the current holder has already walked away from it. None of these are reasons to panic, but all of them are reasons to slow down, look closer, and understand the story behind the code before you act on it.

How status changes across a deal

It helps to picture how these codes move during an actual acquisition, because it makes their protective purpose obvious. Before a deal, a well-run name typically sits behind clientTransferProhibited and often clientUpdateProhibited, quietly guarding the asset. When terms are agreed, the seller lifts the transfer lock and issues an authorization code, so for a short, deliberate window the name becomes transferable. Once it has moved to the buyer, the locks go straight back on to protect the new owner. Seen this way, the codes are not obstacles that appear and disappear at random, they are a security posture that relaxes for exactly as long as a legitimate transfer needs and not a moment longer. A name with no protective locks at all can, oddly, be the one to question, because it suggests an owner who is not actively guarding the asset.

Reading codes alongside the rest of the record

Status codes are most powerful when you stop reading them in isolation and start reading them against age, nameservers, website state, and ownership visibility. A cluster of protective locks on a decade-old name with a live site and enterprise nameservers describes an entrenched, engaged owner. The identical locks on a short-held name with a marketplace nameserver and a for-sale page describe an investor protecting inventory they fully intend to sell. The codes did not change, the context did, and the context is what tells you whether to expect a patient courtship or a straightforward purchase. This is precisely the synthesis Westmore's tool performs on your behalf, so a buyer is handed a conclusion rather than a puzzle to solve alone.

What to do next

If the codes tell you a name is entrenched, protected, actively used, and recently renewed, the answer is a patient, confidential approach rather than a cold, exposed offer that tips your hand. If they tell you a name is expiring, in redemption, or pending delete, timing becomes everything, and speed and discretion matter more than negotiation. Either way, the record is the start of a plan, not the plan itself. The codes are evidence, and what you build on that evidence, quietly and on the buyer's side, is what actually secures the name.

“Status codes look like a wall of no. Read them properly and most are simply a careful owner saying this name matters to me, which is exactly what a serious buyer wants to hear.”