Active domain status: what the WHOIS and RDAP record signals for SEO
Active domain status describes the normal operational state of a domain name at the registry layer. The WHOIS or RDAP record shows the registration as current, unrestricted, and eligible for full administrative action.
For the aged-domain marketplace, active status is the first verifiable indicator that a domain remains under continuous control and qualifies for evaluation.
Buyers, investors, and brand owners reading an aged domain listing on SEO.domains encounter the active status field before any backlink metric or traffic estimate.
This article covers the active state end to end:
- what the active state means in WHOIS and RDAP records
- how registries assign and remove the label
- which EPP codes describe an active domain
- how active status differs from hold and lock states
- why the label gates SEO indexing
- what signals an aged active history carries for search
- how SEO.domains buyers act on the field during due diligence
What does active domain status mean in WHOIS and RDAP records?
Active registration status marks a domain in its normal operating state at the registry layer. The record is current, the registrar holds full modification rights, and the domain resolves in the DNS zone when at least one nameserver is configured.
The WHOIS response prints the label as "active" and the RDAP response returns the corresponding "ok" code.
The registry sets and publishes the active label as the single source of truth
The registry is the source of truth for the active label.
ICANN policy requires every gTLD registry to publish current status codes through both the legacy WHOIS protocol and the modern RDAP successor, so any lookup tool reads the same registry-issued value.
The technical record stores the state in the Extensible Provisioning Protocol vocabulary defined by RFC 5731, where the canonical token for the unrestricted active state is the lowercase string "ok".
WHOIS interfaces translate "ok" into the human-readable label "active" for buyer-facing displays.
For a deeper look at the protocol mechanics, the companion article on WHOIS: protocol and how to read the data explains the field layout used across registrars.
Example WHOIS response (aged active .com domain)
Domain Name: EXAMPLE.COM
Registry Domain ID: 2336799_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.example-registrar.com
Updated Date: 2026-04-15T08:22:00Z
Creation Date: 2008-01-12T15:00:00Z
Registry Expiry Date: 2027-01-12T15:00:00Z
Registrar: Example Registrar, Inc.
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
Name Server: NS1.EXAMPLE-DNS.COM
Name Server: NS2.EXAMPLE-DNS.COM
DNSSEC: unsigned
The absence of a hold or pending code in the Domain Status lines signals the registry treats the record as active.
The clientTransferProhibited and clientUpdateProhibited codes are anti-theft locks. The registrar sets them at the registrant request. They coexist with the active state and protect the registration from unauthorised modification.
The active state guarantees a current and unrestricted record, nothing beyond that
The active state carries one structural property that determines all downstream behaviour. The registration record is current and unrestricted. Current means the registrar paid the wholesale fee on time and the registry recorded the renewal.
Unrestricted means no concurrent code blocks transfer, update, deletion, or DNS resolution. Any qualifying code, such as a hold or a prohibited action flag, sits alongside the active label and narrows the operational envelope.
A buyer reading the WHOIS record finds the active label alongside any qualifying codes; a non-active label such as inactive signals a different lifecycle state that requires further evaluation before any acquisition decision.
How does the registry assign and remove the active status?
The registry assigns the active label automatically when a registration is created and the registrar settles the wholesale fee. Removal happens at expiry, when a hold status is applied, or when a deletion sequence begins.
The assignment workflow runs as a registry-side transaction at the moment the EPP create command completes.
The registry assigns the active label automatically at the EPP create transaction
Registrars trigger the create command on behalf of the registrant during checkout. The registry validates the requested label against its zone database, confirms the wholesale fee was settled, writes the record, and returns the "ok" status.
The domain becomes immediately active. The registrar configures nameservers, transfer locks, and contact records through subsequent EPP commands.
Four scenarios strip the active label from the registry record
The registry strips the active label in four scenarios:
- Expiry. The registration term ends without renewal. The record transitions into an auto-renew grace or registrar-defined grace window. The companion guide on Grace period and auto-renew grace covers that transition.
- Hold flag. The registrar or the registry applies clientHold or serverHold, removing the domain from the zone file.
- Deletion sequence. The registrar initiates EPP delete and the record enters pendingDelete.
- UDRP transfer order. The registry locks the record and reassigns ownership through dispute resolution.
Auto-renew preserves the active label across each renewal cycle
Auto-renew settings preserve the active label across the renewal cycle. Major registrars enable auto-renew by default. Registrants leave it on unless they opt out manually in the registrar account.
When auto-renew runs, the renewal extends the registration term. The active state continues without interruption.
When auto-renew fails, the domain enters the auto-renew grace window. The active label persists for 30 to 45 days, depending on registrar, before the registry transitions the record into the official redemption sequence.
Domain lifecycle from active registration to drop
Which EPP status codes describe an active domain in technical detail?
The Extensible Provisioning Protocol exposes the "ok" code for an unrestricted active domain. Adjacent codes such as clientTransferProhibited, clientUpdateProhibited, addPeriod, and autoRenewPeriod each qualify the active state with a specific operational constraint.
EPP organises codes into three categories:
- Client codes set by the registrar
- Server codes set by the registry
- Pending codes that mark transitions between states
Client codes apply registrar-set constraints alongside the active label
Client codes carry the prefix "client". They indicate a constraint applied by the registrar at the registrant's request. The two common active-state combinations below are reversible by the registrar and prevent unauthorised modification while the registration stays active and resolving.
- clientTransferProhibited blocks outbound transfer to another registrar.
- clientUpdateProhibited blocks changes to contact records or nameservers.
Server codes apply registry-set constraints that override registrar controls
Server codes carry the prefix "server". The registry itself applies them, usually in response to a policy violation, an abuse report, a UDRP order, or a court order.
Server-level holds and locks supersede registrar-level controls. A serverHold removes the domain from the zone file regardless of the registrar configuration. A serverTransferProhibited blocks transfer even when the registrant requests it.
The RDAP record exposes both client and server codes, so a lookup tool prints the complete code set. The companion article on RDAP: the successor to WHOIS walks through the JSON response format that returns these codes alongside contact and nameserver data.
Pending codes mark transient transitions that coexist with the active label
Pending codes mark transient transitions. Each one coexists with the active label and clears once the transition completes.
- addPeriod runs for the first five days after registration and protects the registry from add-grace abuse.
- autoRenewPeriod runs for forty-five days after auto-renew and signals the renewal record is settling.
- pendingTransfer marks an active transfer request awaiting registrar approval.
Example RDAP response (machine-readable format)
{
"objectClassName": "domain",
"handle": "2336799_DOMAIN_COM-VRSN",
"ldhName": "example.com",
"status": [
"client transfer prohibited",
"client update prohibited"
],
"events": [
{ "eventAction": "registration", "eventDate": "2008-01-12T15:00:00Z" },
{ "eventAction": "expiration", "eventDate": "2027-01-12T15:00:00Z" },
{ "eventAction": "last changed", "eventDate": "2026-04-15T08:22:00Z" }
],
"nameservers": [
{ "ldhName": "ns1.example-dns.com" },
{ "ldhName": "ns2.example-dns.com" }
],
"secureDNS": { "delegationSigned": false }
}
The ICANN RDAP profile standardises the JSON output above. RDAP returns status values in space-separated lowercase form, while WHOIS uses the camelCase form. Both forms point at the same underlying EPP code defined in RFC 5731.
Registry variations: how gTLDs and ccTLDs expose the active state differently
Registry behaviour varies by TLD. The active state surfaces under different vocabularies across registries:
- Verisign .com and .net publish a simplified status set of eight codes: ACTIVE, REGISTRAR-HOLD, REGISTRY-HOLD, REGISTRAR-LOCK, REGISTRY-LOCK, redemptionPeriod, pendingRestore, and pendingDelete.
- Legacy gTLDs .org, .biz, .us, .info, and .name expose the full EPP code set of fifteen codes, including the granular client and server prohibited-action variants.
- Country-code registries such as Nominet for .uk and DENIC for .de publish their own status vocabularies, mapped to EPP equivalents in the WHOIS response.
Buyers comparing aged domains across TLDs read each registry's documentation for the exact label semantics. SEO.domains lists the registry of record alongside the WHOIS status for every aged listing in the catalogue.
Three EPP categories that qualify the active state
CLIENT codes
Set by the registrar at registrant request- clientTransferProhibited
- clientUpdateProhibited
- clientDeleteProhibited
- clientRenewProhibited
- clientHold
SERVER codes
Set by the registry, override registrar- serverTransferProhibited
- serverUpdateProhibited
- serverDeleteProhibited
- serverRenewProhibited
- serverHold
PENDING codes
Mark transient transitions- addPeriod (5d)
- autoRenewPeriod (45d)
- pendingTransfer
- redemptionPeriod (30d)
- pendingDelete (5d)
CLIENT codes
Set by the registrar at registrant request- clientTransferProhibited
- clientUpdateProhibited
- clientDeleteProhibited
- clientRenewProhibited
- clientHold
SERVER codes
Set by the registry, override registrar- serverTransferProhibited
- serverUpdateProhibited
- serverDeleteProhibited
- serverRenewProhibited
- serverHold
PENDING codes
Mark transient transitions- addPeriod (5d)
- autoRenewPeriod (45d)
- pendingTransfer
- redemptionPeriod (30d)
- pendingDelete (5d)
How does active status differ from hold, lock, and pending states?
Active status permits resolution and standard administrative actions. Three other status families behave differently:
- Hold statuses suspend DNS resolution at the registrar or registry level.
- Lock statuses block transfers, updates, or deletions.
- Pending states mark transitions between active and a future terminal state.
Reading the WHOIS or RDAP record correctly requires distinguishing each layer. They carry different implications for a buyer.
Hold statuses suspend DNS resolution
Hold statuses break public access to the website entirely. That makes them the highest-impact non-active state for an aged-domain buyer.
A clientHold removes the domain from the registry zone file at the registrar's request, after payment failure, fraud suspicion, or a registrant request.
A serverHold removes the domain from the zone file at the registry's initiative, in response to an abuse report, a court order, or a policy violation. The domain stays registered, but no DNS query resolves until the hold is lifted.
Lock statuses block administrative changes while preserving resolution
Lock statuses leave DNS resolution intact while blocking administrative changes:
- clientTransferProhibited stops outbound transfers.
- clientUpdateProhibited stops nameserver and contact edits.
- clientDeleteProhibited stops deletion.
The server-level equivalents apply the same restrictions at the registry layer and override registrar controls.
Aged domains under proactive management carry clientTransferProhibited as a deliberate anti-theft measure. The lock indicates security posture instead of a problem with the registration.
Pending states denote in-progress transitions
Pending states denote in-progress transitions and clear automatically once the transition completes. Two pending codes carry direct weight for an aged-domain buyer:
- pendingTransfer marks an inbound transfer awaiting registry confirmation.
- pendingDelete signals the final 5-day window before the registry releases the name back into the available pool.
The detailed mechanics of that final window appear in the companion guide on Pending Delete: duration and mechanics, and the redemption window that precedes it is documented in Redemption period (RGP) explained.
Active vs Hold vs Lock vs Pending: at-a-glance effects
| Status | DNS resolves? | Admin actions? | Buyer concern? |
|---|---|---|---|
| ACTIVE | Yes | Full | None - proceed |
| HOLD | No | Renewal only | Critical - investigate |
| LOCK | Yes | Restricted | Anti-theft (intentional) |
| PENDING | Varies by code | Awaiting transition | Monitor closely |
Why does the active registration status matter for SEO and search indexing?
Active registration keeps the domain inside the DNS zone, the prerequisite for crawler access. Once Googlebot reaches a resolving page, indexing and ranking pipelines proceed. A non-active status removes the domain from the zone and stops crawling.
The chain runs in strict sequence: active label, zone presence, DNS answer, crawler request, render, index, rank.
Zone presence operates as the binary gate for crawler access
Search engines treat zone presence as a binary gate.
A clientHold or serverHold removes the domain from the zone file. The authoritative nameserver returns no answer, the crawler records the failure, and the index drops cached URLs after a registry-configurable interval.
The effect is identical whether the cause is a registrar billing dispute or a content abuse takedown. The active label is the SEO professional's first signal that crawl access remains available.
Continuous active status preserves accumulated SEO history
For an aged domain, continuous active status across multiple renewal cycles preserves the historical data that search engines accumulate.
The companion article on How search engines treat re-registered expired domains documents the difference between an aged domain with unbroken active history and one whose active label lapsed before re-registration.
SEO.domains lists aged domains where the active history is verified through cached WHOIS records and external archives. Buyers acquire domains where the indexed page count and the backlink graph stayed live across the entire registration history.
The active field functions as the marketplace entry condition for aged inventory
The aged domain marketplace treats the active field as an entry condition. A domain whose active status sits at clientHold or serverHold signals a registrar dispute or an abuse takedown that the buyer inherits on transfer.
An aged active domain with clean status codes passes the first SEO due diligence gate. The buyer information packet on SEO.domains highlights any non-active state before the bid window opens.
The SEO indexing chain depends on the active label
What signals does an aged active registration history carry for search?
Continuous active history accrues three kinds of data across renewals:
- backlink graph stability across the operating term
- indexed page count held live in the corpus
- search behaviour recorded against the resolving domain
The SEO Domains analytical desk treats an unbroken active label as the structural precondition for that accrued history. Aged active history therefore carries link equity and accumulated authority signals that a freshly registered domain cannot replicate.
Unbroken active history preserves the redirect equity an aged domain accrued
The practitioner consensus across the technical SEO field holds that a clean 301 redirect from an aged active domain forwards the authority the original registration accrued, provided the active label persisted across the registration history.
The relevance for a buyer is direct. An aged domain whose active label held across renewal cycles retains the backlink relationships built during its operating term. A single clean redirect to a destination site forwards that equity without resetting the history.
An active label that lapsed and was re-registered breaks the chain. The SEO Domains desk verifies continuity before it lists any aged domain.
The 27 May 2024 Content Warehouse documentation referenced registration-history features
The Content Warehouse documentation surfaced on 27 May 2024 listed feature names that draw on long registration history:
- hostAge
- siteAuthority
- siteFocusScore
Read as a neutral data point inside the SEO Domains analytical frame, each feature computes against a continuous active registration window. An aged domain whose active label persisted without interruption carries fuller history than one whose active status lapsed.
The aged-domain disambiguation guide covers the terminology distinction the industry uses to label these cohorts.
The March 2024 expired-domain abuse update defines the legitimacy boundary for aged inventory
The March 2024 spam-policy update, dated as a neutral industry reference point, drew a boundary between legitimate aged active domains and re-registered abuse patterns.
The targeted pattern is a domain that loses continuous active history, returns through re-registration, and re-launches with content engineered to exploit residual authority.
The SEO Domains desk reads continuous active history as the dividing line. A domain whose active label held across its registration history sits on the compliant side. A lapse-and-re-register sequence sits on the flagged side.
Verification of continuous active history therefore separates curated aged inventory from inventory that carries that risk. The registration date is documented through the WHOIS creation field.
How do aged-domain buyers use active status during due diligence on SEO.domains?
Buyers read the active status field first to confirm the registration record is current and unrestricted. They cross-reference WHOIS history, registrar identity, and nameserver records to verify continuous ownership before backlink and traffic analysis. The active label is the gate. The supporting fields populate the buyer's risk model.
Buyers inspect the WHOIS active status field first at listing review
The first WHOIS field a buyer inspects on SEO.domains is the status field. A current active label confirms the registration record is in good standing, payment is settled, and no court order, abuse takedown, or registrar dispute encumbers the domain.
The status field pairs with four supporting fields in the listing detail view on SEO.domains:
- the expiry date
- the registrar of record
- the nameserver list
- the registrant contact
Lifecycle tracking refreshes the status field and notifies buyers automatically
The lifecycle tracking workflow documented in Lifecycle tracking workflow and tools describes the daily WHOIS and RDAP polling that SEO.domains operates against every listed inventory item.
The verification table refreshes the active label, the EPP code set, and the nameserver record at a defined interval. Any code change triggers a buyer notification.
The buyer who placed a watch on a domain receives an alert the moment the active label drops or a hold code appears. The listing flags the change at the top of the detail view.
Registrar identity cross-reference completes the post-policy risk model
Buyers cross-reference registrar identity using the comparison guide at Registrar lifecycle policies compared, which documents grace and redemption variations across major registrars.
The registrar of record determines how the active label transitions on the next expiry, what auto-renew defaults apply, and which restore fees would apply during the redemption window.
The companion guide on How a domain drops and becomes available closes the lifecycle loop. It explains the conditions under which a previously active domain returns to the registry pool.
The March 2024 expired-domain abuse policy informs the final risk assessment. SEO.domains marks any inventory item where the previous active term ended in a takedown.
What questions do buyers and registrants ask about active domain status?
Buyers and registrants raise four recurring questions about the active status field. The four answers below address four distinctions:
- active versus OK
- active versus registered with content
- active during the grace period
- how a buyer confirms active status before purchase
Each answer reflects the practitioner conventions used across registrars and the verification workflow operated by SEO.domains.
Active and OK denote the same underlying state in two different vocabularies
Active and OK label the same underlying state in different vocabularies. Active is the human-readable WHOIS label written for buyer-facing displays.
OK is the corresponding EPP code returned by RDAP servers in machine-readable JSON. Both confirm that the domain operates without restrictions and resolves in the DNS zone. A buyer reads them interchangeably.
Active status carries no implication about hosted content or deployment
Active registration status confirms the registry-level record is current. The label carries no implication about hosted content. A domain sits at active status with no nameservers, no website, and no email if the registrant chose not to configure them.
The active label reflects the state of the registration record, not the deployment of any application on top of it.
The active label flips to a renewal-pending code the moment the term expires
The moment the registration term expires, the registry transitions the record into the auto-renew grace or registrar-defined grace window.
The active label flips to a renewal-pending code while the domain remains technically usable for a registrar-defined window.
The full sequence is documented in the grace period guide linked earlier and in the redemption period guide for the window that follows.
Marketplace buyers confirm active status through a fresh WHOIS or RDAP query
Marketplace buyers confirm active status by running a fresh WHOIS or RDAP query against the domain at the moment of inspection.
SEO.domains automates this verification at listing time and re-checks the field at every transfer initiation, so a buyer sees verified active status across the entire acquisition workflow, from first browse through final transfer confirmation.
How does active registration status anchor the aged-domain acquisition workflow on SEO.domains?
Active status is the first checkpoint for every aged domain on SEO.domains. Verified active registration history qualifies a domain for marketplace listing, ICANN-compliant transfer, and downstream SEO use.
Buyers acquire only domains with documented active lifecycle records, and the marketplace flags any inventory item where the active label has lapsed within the historical window.
SEO.domains verifies active status before every listing goes live
SEO.domains operates as an ICANN-accredited marketplace. Every aged domain in the catalogue passes an active status verification before listing.
The verification draws on registry WHOIS, RDAP polling, and external archives. The buyer information packet attached to each listing confirms the active label, the EPP code set, and the verified registration history across the entire aged window.
The marketplace publishes the verification timestamp inside the listing detail view. The catalogue refresh updates the verification on a defined interval.
The acquisition workflow progresses from active confirmation to ICANN-compliant transfer
The acquisition workflow on SEO.domains progresses through four stages:
- active status confirmation
- due diligence checklist completion
- bid placement
- ICANN-compliant transfer
The transfer step requires the active label to persist throughout the transfer window. SEO.domains re-verifies the active status at transfer initiation and again at AuthCode exchange. A drop in status at any point pauses the transfer and triggers buyer notification.
Active aged inventory serves as the buyer entry point on SEO.domains
For an SEO professional, a domain investor, or a brand owner ready to evaluate aged expired domains with verified active history, the entry point is the active aged inventory on the SEO Domains marketplace.
The catalogue exposes three layered filters that surface aged active domains with clean lifecycle records before any further commercial diligence:
- Active status field as the first filter
- EPP code set as the secondary filter
- Verified registration age as the tertiary filter
