rdap
Domain Age: What RDAP Actually Tells You (and What It Can't)
Domain age is one RDAP event: the current registration's creation date. Why some registries omit it, why re-registration resets it, and why Google doesn't rank on it.
Ask a dozen “domain age” sites how old a domain is and you can get a dozen answers, because some of them are guessing from web archives or search-engine crawl dates. The official answer is a single timestamp: the registration event in the registry’s RDAP record. It gives the date the current registration was created. It doesn’t tell you when the name first existed, when a website first went up, or how long the current owner has held it. This post covers where that date comes from, which registries leave it out, what resets it, and why it has less to do with SEO than domain-broker listings suggest.
Our domain age checker reads that same event live from the registry. Everything below about “what our tool does” comes from its source code.
Where the date comes from: one event in an events array
RDAP, the JSON-over-HTTPS replacement for WHOIS (the switch is covered in WHOIS is now RDAP), describes a domain’s history as an events array. Here is what Verisign’s .com RDAP server returned for example.com on 30 September 2026:
"events": [
{ "eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z" },
{ "eventAction": "expiration", "eventDate": "2027-08-13T04:00:00Z" },
{ "eventAction": "last changed", "eventDate": "2026-08-14T08:01:43Z" },
{ "eventAction": "last update of RDAP database", "eventDate": "2026-09-30T22:43:28Z" }
]RFC 9083 §4.5 defines each event as a required eventAction and a required eventDate, and notes that “events can be future dated”, which is how expiration sits in 2027. The allowed actions are listed in §10.2.3 and in IANA’s RDAP JSON Values registry. These are the ones that matter for age:
eventAction | Official description | Is it “age”? |
|---|---|---|
registration | ”The object instance was initially registered.” | Yes. This is the one. |
reregistration | ”registered subsequently to initial registration” | No |
reinstantiation | ”reregistered after having been removed from the registry” | No |
transfer | ”transferred from one registrar to another” | No, and it doesn’t reset age |
last changed | ”when the information in the object instance was last changed” | No, it’s any edit (nameservers, contacts) |
expiration | ”has been removed or will be removed at a predetermined date” | No, it’s the paid-through date |
last update of RDAP database | when the RDAP copy was “last synchronized from the authoritative database” | No, it’s basically the query time |
The last row is the one people get wrong. It’s a timestamp from minutes ago, and any tool that just takes the first date it finds can report a decades-old domain as brand new.
What real registries actually return
The event list is standardized. Which events a registry chooses to publish is not. We queried each registry’s RDAP server (directly, or through rdap.org’s redirect where the table says “via bootstrap”) for the registry’s own domain or a well-known one, on 30 September 2026:
| TLD | Registry RDAP server | registration | expiration | Notes |
|---|---|---|---|---|
.com | rdap.verisign.com | ✅ | ✅ | Full set, shown above |
.uk | rdap.nominet.uk | ✅ | ✅ | bbc.co.uk: registered 1994-12-13 |
.fr | rdap.nic.fr | ✅ | ✅ | Also publishes a separate transfer event |
.nl | rdap.sidn.nl | ✅ | ❌ | Registration and last changed only |
.no | via bootstrap | ✅ | ❌ | Registration and last changed only |
.pl | rdap.dns.pl | ✅ | ❌ | Registration and last changed only |
.is | via bootstrap | ✅ | ⚠️ | Uses soft expiration, which isn’t in the IANA registry |
.de | rdap.denic.de | ❌ | ❌ | Only last changed. Not in IANA’s bootstrap file |
.ch | rdap.nic.ch | ❌ | ❌ | Empty events array. Not in IANA’s bootstrap file |
The .de row shows how a registry can run RDAP and still not help you here. DENIC operates rdap.denic.de, but its response for denic.de contained exactly one event (last changed, 2024-12-19), plus a notice that the service “doesn’t disclose any information concerning the domain holder”. There’s no creation date to compute an age from.
The bigger gap: registries missing from the bootstrap file
RDAP clients find the right registry through IANA’s bootstrap file, which maps TLDs to RDAP base URLs. The copy published 30 September 2026 lists 1,203 TLDs. IANA’s full TLD list has 1,438. The gap is almost all country codes: only 72 of the 248 two-letter ccTLDs appear in the bootstrap file. .de, .ch, .io, .co, .eu, .jp, .it, .es and .us are all missing from it.
This affects our tool directly. Our server doesn’t talk to registries itself. It asks rdap.org, which follows the bootstrap file and redirects to the right registry. For a TLD that isn’t in the file, rdap.org answers 404. We checked: rdap.org/domain/denic.de and rdap.org/domain/google.io both return 404. A bare 404 would look exactly like an unregistered domain, so our checker keeps a list of the TLDs we found missing from the bootstrap file (the nine above). When a lookup under one of them 404s, it doesn’t say “not found”. It says, for example, “The .de registry does not publish RDAP through IANA’s bootstrap, so we cannot look this domain up”, notes that this doesn’t mean the domain is unregistered, and links to IANA’s root zone database so you can use the registry’s own lookup. For other TLDs, “not found” still can’t tell an unregistered domain from a registry with no RDAP at all.
When a registry is reachable but leaves out the registration event, our tool doesn’t guess. It shows “Registration date not published” and still shows whatever it did get (last updated, expiry, registrar). When there’s no expiration event, it falls back to .is’s non-standard soft expiration, so a .is domain shows both an age and an expiry date.
Age restarts when a domain drops, not when it’s sold
The registration date belongs to the registry object, not to the name. RFC 5731, the EPP domain mapping registries use internally, defines the creation date (crDate) as “the date and time of domain object creation”, and it keeps transfers in a separate field (trDate, “the most recent successful domain-object transfer”). You can see both in the .fr response above: afnic.fr shows registration 2001-12-10 and, separately, transfer 2017-07-18.
So there are two cases:
- Sale or registrar transfer: the object survives, and so does its date. A 20-year-old domain bought last month still shows 20 years. The date tells you the name has been held continuously, not that the same person has held it.
- Expiry and drop: RFC 3915 §3 lays out the end of the grace-period lifecycle. After redemption the name sits in
pendingDelete, then “the domain name is purged once the pending delete period elapses” and “the domain name is available for re-registration.” Whoever registers it next creates a new object with a new creation date. That includes drop-catchers bidding on expired names. Years of history turn into “brand new” overnight.
(How long each stage lasts, including auto-renew grace, redemption and pending delete, is in the lifecycle table in WHOIS is now RDAP.)
In practice, when a domain listing says “aged domain, 15 years” and RDAP shows a registration date from last spring, trust RDAP. The name may be 15 years old, but that registration isn’t.
Does domain age help SEO? Google has said no since 2009
The claim goes back to Google’s patent US 7,346,839, “Information retrieval based on historical data”. It was filed 31 December 2003, published as an application on 31 March 2005, and granted in 2008, with Matt Cutts among the inventors. Its domain passage is really about expiry, not age: “Valuable (legitimate) domains are often paid for several years in advance, while doorway (illegitimate) domains rarely are used for more than a year. Therefore, the date when a domain expires in the future can be used as a factor in predicting the legitimacy of a domain.”
Registrars then started selling multi-year registrations as an SEO boost, and Cutts answered the question in a 2009 webmaster video. Google’s own blog published transcripts of it in Spanish and German. In our translation of the German transcript, his short answer was not to worry about it much, “actually hardly at all”. He said the registrar emails claiming a ranking bonus for three-plus-year registrations were “not something we ever said”. He explained that filing a patent that could look at registration history “doesn’t mean all of it is used in our ranking”. And he said what actually makes the difference is “the quality of your site and the kind of links pointing to it”.
Two caveats. First, that video answers the registration-length question (how many years you’ve prepaid) as much as the age question. Second, Google staff have repeated the point many times since, but we couldn’t load the original posts to read them, so we only quote the transcript above. What you can say with confidence is that no Google statement we could read treats the registration date as a ranking input. An old domain tends to rank well because of what built up over those years (links, content, reputation). If the domain dropped and was re-registered, much of that is gone even when the name looks the same.
How our checker turns a timestamp into years, months and days
The math is the same calendar method as our age calculator, done in UTC because that’s how registries stamp events:
- Both the registration instant and “now” are truncated to UTC midnight, so partial days don’t count.
- The tool counts whole months from the registration date, clamping to the end of the month when the target month is shorter. It takes the largest month count that doesn’t pass today, then counts the leftover days.
- Total days is a plain difference between the two midnights, so leap days are included.
We ran our library (src/lib/domain-age.ts) on some edge cases:
registered 2025-01-31, checked 2025-02-28 → 1 month (28 days total)
registered 2025-01-31, checked 2025-03-01 → 1 month, 1 day (29 days total)
registered 2024-02-29, checked 2025-02-27 → 11 months, 29 days (364 days)
registered 2024-02-29, checked 2025-02-28 → 1 year (365 days)
registered 2024-02-29, checked 2028-02-29 → 4 years (1,461 days)A Jan 31 registration turns one month old on Feb 28, because February has no 31st. A leap-day registration has its anniversary on Feb 28 in common years. That matches the age calculator’s default “Feb 28” mode. Its optional “Mar 1” mode would call that same day 11 months and 30 days, and the domain checker doesn’t have that option. Checked on 30 September 2026, example.com comes out at 31 years, 1 month, 16 days (11,370 days), with 316 days to its 2027 expiry.
There’s one side effect of using UTC. AFNIC stamps afnic.fr’s registration as 2001-12-10T23:00:00Z, which is exactly midnight on 11 December in Paris (UTC+1 in winter). Our tool reports it as 10 December, the UTC date, which is correct for the timestamp but one day off from the registry’s local calendar. If your date is off by one against a registry’s web WHOIS, this is usually why.
The result also gets an age bucket. The cut-offs are our own heuristic, not an industry standard:
| Bucket | Age |
|---|---|
| Brand new | under 3 months |
| New | 3–11 months |
| Young | 1–2 years (under 36 months) |
| Established | 3–9 years (under 120 months) |
| Veteran | 10 years or more |
The boundaries are exact to the day: a domain registered on 1 July is “brand new” at 2 months, 29 days on 30 September and “new” on 1 October.
What leaves your browser
Most of our tools run entirely on your device. This one can’t, because the answer lives with the registry. When you click Check age, the domain names (and nothing else from the page) go to our API. Our API asks rdap.org, and rdap.org redirects to the registry. The server code logs that a lookup happened, along with country, device type and referrer, but deliberately not the domain. Responses are sent with a one-hour cache header. The checker takes up to 10 domains at once, strips URLs down to the bare domain (https://www.Example.com:443/path becomes example.com), converts internationalized names to punycode (münchen.de becomes xn--mnchen-3ya.de), and never has more than two lookups in flight.
Checking a domain in practice
- Paste the domain into the domain age checker. If it says not found, the TLD isn’t on our list of known bootstrap gaps, but that list isn’t exhaustive, so check the registry’s own lookup before you assume the domain is unregistered.
- If the age looks wrong for a site you’ve known for years, it probably dropped and was re-registered. Compare the registrar and nameservers in the full WHOIS lookup, and look at archived snapshots of the site.
- To see what the domain actually serves today, which is separate from what the registry says, use the DNS lookup. If records don’t match what you just changed, it’s caching. See DNS propagation is not real.
- For vetting a shop or sender, a “brand new” result is a reason to look more closely. A “veteran” result only tells you someone has kept renewing the name.