Averiguar cuándo se registró por primera vez un dominio es una tarea sencilla con una cantidad sorprendente de casos límite. Para un .com basta un comando. Para muchos dominios de código de país la respuesta no se publica en absoluto y, en el caso de un dominio que ha cambiado de manos, la fecha que obtienes puede no significar lo que supones. Esta guía explica cómo hacer la consulta correctamente, cómo interpretar el resultado y qué hacer cuando la entidad de registro no devuelve nada.
TL;DR / IDEAS CLAVE
- Dos protocolos responden a la pregunta: WHOIS (texto, heredado) y RDAP (JSON, actual). RDAP es la mejor opción para cualquier tarea automatizada.
- El nombre del campo varía: «Creation Date», «Created On», «registered», «Domain Registration Date»; en RDAP es el evento con
eventAction: "registration". - No todas las entidades de registro la publican: muchos ccTLD omiten por completo las fechas de creación y algunos ni siquiera tienen servidor RDAP, lo que produce el error «no registry RDAP server was identified».
- La fecha describe el registro del dominio, no el negocio: las transferencias, las eliminaciones y los nuevos registros pueden reiniciarla, y un cambio de marca rompe por completo el vínculo con la organización.
- Las consultas masivas no son viables por WHOIS/RDAP: las entidades de registro limitan la tasa por IP y ambos protocolos responden, por diseño, un dominio cada vez.
- Para trabajar a escala poblacional, usa datos de zona: 1,538 paquetes — 716 archivos de zona de TLD, 716 conjuntos de zona enriquecidos (NS, MX, IP, CMS), 79 listas de sitios por tecnología y 27 datasets seleccionados — que cubren 285,582,781 dominios. Las fechas de registro solo están presentes cuando la zona de origen las publica.
- Sin datos de contacto: los paquetes solo incluyen atributos de dominio e infraestructura.
ÍNDICE
- Por qué se consulta la fecha de registro
- Cómo consultar una fecha de registro
- Qué puede y qué no puede decirte la fecha
- Trabajar a escala poblacional
- Errores habituales
- Preguntas frecuentes
- Conclusión
- Recursos relacionados
Por qué se consulta la fecha de registro
La fecha de creación de un dominio es uno de los pocos datos de registro que sobrevivieron a la ocultación de los registros WHOIS tras el RGPD, y en parte por eso se utiliza tanto. Los campos de contacto han desaparecido; las fechas, el registrador y los servidores de nombres siguen ahí.
Tres preguntas concentran la mayoría de las consultas. La primera es la verificación: un sitio afirma llevar operando desde 2009 y una fecha de creación de 2021 es motivo para hacer una pregunta de seguimiento. La segunda es la evaluación de riesgo: los dominios registrados hace pocos días están sobrerrepresentados en el phishing y el fraude, así que la antigüedad es una entrada habitual en una puntuación de riesgo, aunque débil por sí sola. La tercera es la compra de dominios: al valorar un nombre caducado o del mercado secundario, la antigüedad del registro es una señal más, entre varias, sobre si el nombre tiene un historial que merezca la pena heredar.
Lo que las tres tienen en común es que la fecha es una entrada, no una conclusión. Indica cuándo empezó el registro de un dominio. Todo lo demás —quién gestionaba el dominio, qué se publicaba en él, si ha cambiado de manos— exige otras pruebas.
Cómo consultar una fecha de registro
RDAP, el protocolo actual. RDAP devuelve JSON, lo que evita tener que analizar texto libre. La fecha está en el array events:
curl -s https://rdap.org/domain/example.com | jq '.events[] | select(.eventAction=="registration")'
rdap.org actúa como redirector de arranque: resuelve el servidor autoritativo del TLD a través del registro de IANA y reenvía la consulta. La respuesta incluye además los eventos expiration y last changed, el registrador patrocinador y los códigos de estado del dominio.
WHOIS, el protocolo heredado. Sigue siendo omnipresente y útil, sobre todo para los ccTLD que nunca desplegaron RDAP:
whois example.com | grep -i -E 'creat|regist'
Cuenta con la variación. Cada entidad de registro etiqueta el mismo campo como «Creation Date», «Created On», «created», «Domain Registration Date» o «registered», y los formatos de fecha también difieren. Cualquier parser que escribas debe contemplar varias grafías y, como mínimo, ISO-8601 más un par de formatos regionales.
Un ejemplo con un ccTLD. Toma aajtak.in. El espacio de nombres .in lo administra NIXI y la consulta va a su servicio WHOIS:
whois aajtak.in
Normalmente obtendrás las fechas de creación, actualización y caducidad, el registrador patrocinador, los códigos de estado y los servidores de nombres, con el bloque de contacto del titular ocultado. Ese patrón —campos técnicos presentes, campos de contacto retenidos— es ya la norma tanto en los gTLD como en la mayoría de los ccTLD.
Cuando no hay servidor RDAP. El error «no registry RDAP server was identified for this domain» significa que el TLD no tiene entrada en el registro de arranque de IANA, así que un cliente RDAP no tiene adónde enviar la consulta. RDAP es obligatorio por contrato para los gTLD, pero opcional para los ccTLD, que se rigen por la política de cada país. Recurre a WHOIS para ese TLD o a la consulta web de la propia entidad de registro. Reintentar la consulta RDAP no servirá de nada: el endpoint no existe.
Cuando la fecha no se publica en absoluto. Varias entidades de registro omiten deliberadamente las fechas de creación en sus respuestas públicas. En ese caso, las alternativas son indirectas y ninguna es autoritativa: la primera captura en la Wayback Machine de Internet Archive fija un límite superior de cuándo el sitio estaba activo, y la primera entrada del log de Certificate Transparency para el hostname muestra cuándo se emitió por primera vez un certificado. Ambas te dan pruebas del tipo «no más tarde de», que a menudo bastan, pero ninguna es la fecha de registro.
Qué puede y qué no puede decirte la fecha
Refleja el registro del dominio, no la organización
Una empresa fundada en 2003 puede tener un dominio creado en 2018 porque cambió de marca, compró un nombre mejor o se consolidó en uno nuevo. Un dominio creado en 2003 puede estar hoy en manos de un propietario completamente distinto. La fecha es una propiedad del registro, y el registro sobrevive a los cambios de propietario sin reflejarlos necesariamente.
La eliminación y el nuevo registro la reinician
Si un dominio caduca, completa el ciclo de redención y borrado pendiente, y vuelve a ser registrado por otra persona, el nuevo registro suele mostrar la nueva fecha de creación. La vida anterior del dominio es invisible en el registro actual. Esto importa sobre todo en la valoración del mercado secundario, donde un nombre presentado como «registrado desde 2006» puede haber caducado y reiniciado por el camino.
La antigüedad es una señal de riesgo débil por sí sola
Los dominios registrados recientemente están sobrerrepresentados en los abusos, lo que convierte la antigüedad en una característica razonable dentro de un modelo de puntuación. Es una mala regla de forma aislada, porque todo negocio legítimo nuevo tiene también un dominio registrado hace poco. Combínala con señales que aporten información independiente: si el dominio resuelve, si tiene correo configurado, cuál es la red de alojamiento, si sirve un sitio real.
La antigüedad no es un factor de posicionamiento SEO en el sentido en que suele describirse
Los motores de búsqueda han dicho de forma constante que la antigüedad del dominio por sí sola no es una señal de posicionamiento. Lo que correlaciona con la antigüedad es la acumulación de enlaces, contenido e historial de uso con el tiempo, que es un efecto real, pero pertenece a lo que el dominio ha hecho, no a cuánto tiempo lleva existiendo. Un dominio antiguo que nunca publicó nada no acumula nada de eso.
Lo que sí establece con claridad
Una fecha de creación es una prueba sólida de una única afirmación acotada: este registro no existía antes de esta fecha. Eso basta para contradecir una afirmación del tipo «establecidos en», para acotar una cronología en una investigación o para separar los dominios registrados en una ventana concreta al agrupar una campaña.
Trabajar a escala poblacional
Todo lo anterior se refiere a un solo dominio. En cuanto la pregunta es sobre muchos dominios —cuántos se registraron en una zona el trimestre pasado, qué redes de alojamiento usan los dominios más nuevos—, WHOIS y RDAP dejan de ser una opción. Ambos responden un dominio por consulta, las entidades de registro limitan la tasa por IP y un trabajo sobre siquiera cien mil dominios quedará estrangulado mucho antes de terminar.
La alternativa son los datos a nivel de zona distribuidos como archivos. El catálogo de WebTrackly contiene 1,538 paquetes: 716 archivos de zona de TLD, 716 conjuntos de zona enriquecidos que añaden servidores de nombres, registros MX, IP resueltas y CMS detectado, 79 listas de sitios por tecnología y 27 datasets seleccionados. En conjunto, los paquetes de zona cubren 285,582,781 dominios, de los cuales 163,422,083 son .com; el dataset de todos los dominios registrados contiene 272,614,863 filas. WordPress se detecta en 21,639,326 dominios y Joomla en 567,680.
Qué contiene un paquete
El formato de descarga depende del paquete y se indica en la página del producto.
| domain | ns | mx | ip | cms |
|---|---|---|---|---|
| examplecorp.com | ns1.cloudflare.com | aspmx.l.google.com | 104.21.x.x | WordPress |
| techsolutions.in | ns-1234.awsdns-56.org | mx1.zoho.in | 13.234.x.x | |
| securetech.de | ns1.hetzner.de | mail.securetech.de | 88.198.x.x | Joomla |
Las fechas de registro aparecen solo cuando la zona de origen las publica: en muchos ccTLD no están disponibles y la columna se omite en lugar de estimarse. No hay columna de titular ni columna de contacto: sin direcciones de correo, sin números de teléfono, sin datos personales de ningún tipo.
Derivar la actividad de registro sin columna de fecha
Cuando faltan las fechas, todavía puedes medir la actividad de registro comparando instantáneas. Compra el mismo paquete en dos momentos distintos: los dominios presentes en el archivo más reciente pero no en el anterior son los que se registraron en ese intervalo:
-- domains added between two snapshots
SELECT n.domain, n.ns, n.mx
FROM read_csv_auto('snapshots/com-2026-07-01.csv') n
LEFT JOIN read_csv_auto('snapshots/com-2026-04-01.csv') o USING (domain)
WHERE o.domain IS NULL;
-- and which name servers the new registrations chose
SELECT ns, count(*) AS new_domains
FROM (
SELECT n.domain, n.ns
FROM read_csv_auto('snapshots/com-2026-07-01.csv') n
LEFT JOIN read_csv_auto('snapshots/com-2026-04-01.csv') o USING (domain)
WHERE o.domain IS NULL
)
GROUP BY ns ORDER BY new_domains DESC LIMIT 20;
Esto suele funcionar mejor que una columna de fecha para las preguntas que la gente hace realmente, porque llega con los atributos de infraestructura adjuntos. El único requisito es que conserves y feches cada archivo que descargues.
Cómo obtener los archivos
Explora /zones/ para archivos de zona y conjuntos enriquecidos, /datasets/ para colecciones seleccionadas y /packages/ para el catálogo completo; el número de filas se muestra antes de la compra. Los paquetes parten de $3.50 y se descargan al instante, exportados en el momento de la compra. Pro cuesta $29/mes (50 paquetes, 10 datasets, 30,000 llamadas a la API) y Enterprise, $99/mes (200 paquetes, 50 datasets, 300,000 llamadas a la API); consulta /pricing/.
unzip com-enriched.zip
head -3 com-enriched.csv
wc -l com-enriched.csv
# list zone-file packages via the API
curl -H "Authorization: Bearer YOUR_API_KEY" \
"https://webtrackly.com/api/v1/packages/?type=zone"
# technology packages matching a keyword
curl -H "Authorization: Bearer YOUR_API_KEY" \
"https://webtrackly.com/api/v1/packages/?type=technology&q=wordpress"
# details for one package
curl -H "Authorization: Bearer YOUR_API_KEY" \
"https://webtrackly.com/api/v1/packages/com-zone/"
La API expone el catálogo de paquetes: qué existe, cuánto cuesta y cuántas filas tiene. No acepta un nombre de dominio para devolver datos sobre él; los datos de registro por dominio provienen de WHOIS o RDAP. Referencia en /api/.
Errores habituales
Error 1: leer la fecha de creación como la fecha de fundación de la empresa
El registro describe el alta del dominio, no la organización. Los cambios de marca, las compras en el mercado secundario y las consolidaciones rompen el vínculo. Contrástalo con un registro mercantil o con el propio historial del sitio antes de afirmar nada sobre el negocio.
Error 2: dar por hecho que todas las entidades de registro publican la fecha
Varios ccTLD omiten por completo las fechas de creación de sus respuestas públicas. Cuando eso ocurre, las capturas de Wayback y las entradas de Certificate Transparency te dan un límite del tipo «no más tarde de», que es útil pero no es la fecha de registro y no debe presentarse como tal.
Error 3: reintentar cuando RDAP indica que no hay servidor
«No registry RDAP server was identified for this domain» significa que el TLD no está en el registro de arranque de IANA. No hay ningún endpoint al que llegar. Recurre a WHOIS para ese TLD en lugar de añadir lógica de reintentos.
Error 4: montar un pipeline masivo sobre consultas por dominio
Las entidades de registro limitan la tasa por IP y ambos protocolos son, por diseño, de un dominio cada vez. Un trabajo grande quedará estrangulado y producirá resultados parciales que no puedes usar para afirmaciones porcentuales. Toma la población de los datos a nivel de zona y reserva las consultas para el subconjunto que necesite un estado autoritativo.
Error 5: usar la antigüedad como regla de riesgo independiente
Los dominios registrados recientemente están sobrerrepresentados en los abusos, pero también lo está cualquier negocio legítimo que haya arrancado este mes. Usa la antigüedad como una característica más entre varias —resolución, configuración de correo, red de alojamiento, presencia de contenido real— y no como regla de rechazo.
Error 6: exagerar lo que muestra una sola instantánea
Un archivo describe un estado. El crecimiento, la rotación y la migración requieren dos observaciones. Archiva y fecha cada descarga; una instantánea que descartaste es una comparación que ya no puedes hacer.
Preguntas frecuentes
P: ¿Cómo averiguo cuándo se registró un dominio?
R: Consulta RDAP y lee el evento con eventAction: "registration", o ejecuta whois y busca un campo llamado «Creation Date», «Created On», «created» o «registered». RDAP es preferible para automatizar porque devuelve JSON estructurado.
P: ¿Por qué el nombre del campo cambia de un TLD a otro?
R: WHOIS no impone ningún esquema de respuesta, así que cada entidad de registro etiqueta y formatea los campos a su manera. RDAP lo estandariza, que es la principal razón práctica para preferirlo.
P: ¿Por qué algunos dominios no tienen fecha de creación?
R: Algunas entidades de registro no la publican. No existe ningún atajo que produzca la fecha real; las capturas de Wayback y las entradas de Certificate Transparency dan un límite superior de cuándo estaba en uso el dominio.
P: ¿Qué significa «no registry RDAP server was identified for this domain»?
R: El TLD no tiene entrada RDAP en el registro de arranque de IANA, así que el cliente no puede determinar adónde enviar la consulta. RDAP es obligatorio para los gTLD, pero opcional para los ccTLD. Usa WHOIS para ese TLD.
P: ¿Cambia la fecha de registro cuando se vende un dominio?
R: Una transferencia normal suele conservarla. Un dominio que caduca, se elimina y vuelve a registrarse muestra por lo general la nueva fecha de creación, con el historial anterior invisible en el registro actual.
P: ¿Puedo consultar fechas de registro de forma masiva?
R: No a través de WHOIS ni de RDAP. Ambos van dominio a dominio y con límite de tasa. Para trabajar a escala poblacional, usa archivos a nivel de zona y compara instantáneas fechadas para derivar la actividad de registro.
P: ¿Ofrece WebTrackly una consulta de dominios?
R: No. El formato de descarga depende del paquete y se indica en la página del producto. No hay servicio de consulta por dominio.
P: ¿Incluyen los paquetes fechas de registro?
R: Solo cuando la zona de origen las publica. Cuando la entidad de registro no expone fechas, la columna se omite en lugar de estimarse.
P: ¿Incluyen los paquetes datos de contacto?
R: No. Contienen dominio, servidores de nombres, MX, IP resuelta y CMS detectado. Sin direcciones de correo, números de teléfono ni identidades de titulares.
P: ¿Cuánto cuesta?
R: Paquetes desde $3.50 como compra única. Pro cuesta $29/mes (50 paquetes, 10 datasets, 30,000 llamadas a la API); Enterprise, $99/mes (200 paquetes, 50 datasets, 300,000 llamadas a la API). Consulta /pricing/.
Conclusión
Para un solo dominio, consultar la fecha de registro es una única consulta RDAP o una única llamada a whois, con las salvedades de que el nombre del campo varía, algunas entidades de registro no publican nada y algunos TLD no tienen ningún endpoint RDAP. Interpreta el resultado de forma estricta: establece cuándo empezó el registro del dominio, no cuándo se fundó una empresa ni quién controla hoy el nombre.
Para muchos dominios, los protocolos por dominio son directamente la herramienta equivocada. Los archivos a nivel de zona te dan toda la población de una vez, con servidores de nombres, enrutamiento de correo, direcciones resueltas y CMS detectado incluidos, y comparar instantáneas fechadas reconstruye la actividad de registro incluso en zonas que no publican ninguna fecha. El esquema es deliberadamente estrecho y no contiene datos personales: saberlo de antemano es lo que evita que un proyecto fracase en el último paso.
Explora el catálogo de archivos de zona →
Recursos relacionados
- Catálogo de paquetes — 1,538 bases de datos de dominios descargables
- Archivos de zona por TLD — .com, .net, .de y más de 700
- Datasets seleccionados — todos los dominios registrados, servidores MX, e-commerce
- Documentación de la API — acceso al catálogo con un bearer token
- Precios — compras únicas desde $3.50