Active domain status: what the WHOIS and RDAP record signals for SEO

Domain status explained Last reviewed ≈ 14 min read

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.

Auto-renew default on:GoDaddyNamecheapCloudflareDynadot

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

ActiveOperating1-10 years
ExpiredRenewal due0 days
Auto-Renew GraceOwner reclaim30-45 days
RedemptionRestore via fee30 days
Pending DeleteLocked5 days
DroppedPublic poolAvailable
ActiveOperating · 1-10 years
ExpiredRenewal due · 0 days
Auto-Renew GraceOwner reclaim · 30-45 days
RedemptionRestore via fee · 30 days
Pending DeleteLocked · 5 days
DroppedPublic pool · Available
Figure 1. The active label persists through the auto-renew grace window. Once the redemption period begins, the active state is replaced by the redemptionPeriod code, and the domain enters the registry-managed deletion sequence.

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
Reversible by registrar

SERVER codes

Set by the registry, override registrar
  • serverTransferProhibited
  • serverUpdateProhibited
  • serverDeleteProhibited
  • serverRenewProhibited
  • serverHold
Removable by registry only

PENDING codes

Mark transient transitions
  • addPeriod (5d)
  • autoRenewPeriod (45d)
  • pendingTransfer
  • redemptionPeriod (30d)
  • pendingDelete (5d)
Auto-clear at transition end

CLIENT codes

Set by the registrar at registrant request
  • clientTransferProhibited
  • clientUpdateProhibited
  • clientDeleteProhibited
  • clientRenewProhibited
  • clientHold
Reversible by registrar

SERVER codes

Set by the registry, override registrar
  • serverTransferProhibited
  • serverUpdateProhibited
  • serverDeleteProhibited
  • serverRenewProhibited
  • serverHold
Removable by registry only

PENDING codes

Mark transient transitions
  • addPeriod (5d)
  • autoRenewPeriod (45d)
  • pendingTransfer
  • redemptionPeriod (30d)
  • pendingDelete (5d)
Auto-clear at transition end
Figure 2. The Extensible Provisioning Protocol organises status codes into three categories. Each category coexists with the active label and qualifies what the registrar or registry permits at any moment.
CodeCategoryMeaningDNS effect
okServerDomain operates normally with no restrictionsResolves
inactiveServerNo nameservers configured for the domainDoes not resolve
clientTransferProhibitedClientRegistrar blocks outbound transfer at registrant requestResolves
clientUpdateProhibitedClientRegistrar blocks contact or nameserver changesResolves
clientDeleteProhibitedClientRegistrar blocks deletion of the registrationResolves
clientRenewProhibitedClientRegistrar blocks renewal of the registrationResolves
clientHoldClientRegistrar removes the domain from the zone fileDoes not resolve
serverTransferProhibitedServerRegistry blocks outbound transferResolves
serverUpdateProhibitedServerRegistry blocks contact or nameserver changesResolves
serverDeleteProhibitedServerRegistry blocks deletion of the registrationResolves
serverRenewProhibitedServerRegistry blocks renewal of the registrationResolves
serverHoldServerRegistry removes the domain from the zone fileDoes not resolve
addPeriodPendingFirst five days after registration, refund-eligibleResolves
autoRenewPeriodPendingForty-five days after auto-renew, refund windowResolves
pendingTransferPendingTransfer request awaiting registrar approvalResolves
pendingUpdatePendingUpdate request awaiting completionResolves
pendingDeletePendingFinal five-day window before dropDoes not resolve
redemptionPeriodRGPThirty-day window to restore at elevated feeDoes not resolve
pendingRestoreRGPRestore request submitted, awaiting documentationResolves
renewPeriodRGPStandard post-renewal grace windowResolves
transferPeriodRGPFive-day window after inbound transferResolves
pendingCreatePendingCreate request received, registry processing the registrationDoes not resolve
pendingRenewPendingRenew request received, awaiting registry confirmationResolves

Tip: swipe horizontally on mobile to view all columns.

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

StatusDNS resolves?Admin actions?Buyer concern?
ACTIVEYesFullNone - proceed
HOLDNoRenewal onlyCritical - investigate
LOCKYesRestrictedAnti-theft (intentional)
PENDINGVaries by codeAwaiting transitionMonitor closely
ACTIVE
DNS resolves?Yes
Admin actions?Full
Buyer concern?None - proceed
HOLD
DNS resolves?No
Admin actions?Renewal only
Buyer concern?Critical - investigate
LOCK
DNS resolves?Yes
Admin actions?Restricted
Buyer concern?Anti-theft (intentional)
PENDING
DNS resolves?Varies by code
Admin actions?Awaiting transition
Buyer concern?Monitor closely
Figure 3. The four status families differ along three axes that matter most for an aged-domain buyer: DNS resolution, administrative-action permission, and operational risk.

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

1. Active labelregistry "ok"
2. Zone presenceincluded in DNS
3. DNS answerNS returns A/AAAA
4. Crawl requestGooglebot fetch
5. RenderHTML + JS
6. Indexadded to corpus
7. RankSERP position
1. Active labelregistry "ok"
2. Zone presenceincluded in DNS
3. DNS answerNS returns A/AAAA
4. Crawl requestGooglebot fetch
5. RenderHTML + JS
6. Indexadded to corpus
7. RankSERP position
Any hold status breaks the chain at step 2 (zone presence).DNS returns no answer, crawl fails, cached URLs drop from the index after the next refresh.
Figure 4. The active registration label gates the entire SEO indexing chain. Removing the active state at the registry severs the chain at zone presence, the second step.

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.

Active status due diligence checklist

Eight verification steps an aged-domain buyer completes before placing a bid on SEO.domains.

0 of 8 complete

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
SEO Domains marketplace dashboard listing aged domains with filterable Domain Authority, Referring Domains, Ahrefs Domain Rating, Trust Flow, Citation Flow, country flags, TLD, category, and active registration status indicators for SEO professionals and domain investors
Figure 5. The SEO Domains marketplace lists aged domains with verified active registration status, filterable by country, TLD, metrics, and category. Visit the marketplace to browse the live inventory.