El posicionamiento cae después de una migración. Una persona del equipo culpa a las redirecciones, otra empieza a revisar los canonical, alguien abre Search Console.
Yo reviso primero el DNS. Ese pequeño hábito me ha ahorrado horas auditando la capa equivocada. Si el dominio apunta a un servidor antiguo, si www y el dominio raíz resuelven de forma distinta o si un resolver público todavía conserva una respuesta obsoleta, editar las etiquetas title no arreglará el problema inmediato.
El DNS no es una métrica SEO ni indica si una página merece posicionar. Me dice adónde van las solicitudes, por eso, una consulta DNS es una de las formas más rápidas de separar un problema del sitio web de un problema de infraestructura.
Contenido
¿Qué me dice realmente una consulta DNS?
El sistema de nombres de dominio traduce un hostname como example.com en los registros técnicos que utilizan los navegadores, crawlers, servidores de correo y otros servicios. Los registros se alojan en los nameservers autoritativos, que son la fuente de referencia de la zona DNS del dominio. Los resolvers recursivos, como Google Public DNS y Cloudflare, obtienen esas respuestas y las guardan en caché.
Una consulta desde el navegador resulta práctica porque permite revisar esas respuestas públicas sin abrir una terminal. Uso la herramienta gratuita de consulta DNS de Karma.Domains cuando quiero ver los registros más comunes en un solo informe y comparar las respuestas de Google, Cloudflare, OpenDNS y Quad9.
Para monitorizar migraciones o revisar una cartera de dominios, Expired Domains API y MCP de Karma.Domains pueden ejecutar la consulta DNS desde un script o un agente de IA cuando las comprobaciones manuales en el navegador dejan de ser manejables.
Esa comparación importa. Durante un cambio de DNS, dos resolvers pueden devolver temporalmente respuestas distintas porque cada caché caduca según su propio calendario. El panel de control puede mostrar el valor nuevo mientras los usuarios reales, y también Googlebot, siguen recibiendo el antiguo.
Los registros que reviso primero
Un informe DNS puede parecer una sopa de letras, en el sentido de que casi nunca necesito todas las filas. Para comprobar un sitio o una migración, empiezo por los registros que deciden adónde va el tráfico web.
A y AAAA
Un registro A asocia un hostname con una dirección IPv4. Un registro AAAA hace lo mismo con IPv6. Comparo ambos con el destino indicado por el proveedor de hosting o la CDN.
Un caso fácil de pasar por alto es tener un registro A correcto junto a un AAAA antiguo. El sitio puede funcionar en una red y fallar en otra porque los clientes compatibles con IPv6 toman la ruta obsoleta. Google también puede rastrear mediante IPv6, así que «en mi portátil funciona» no demuestra que todo esté bien.
CNAME
Un CNAME convierte un hostname en alias de otro. El host www suele usarlo para apuntar a una CDN o a un destino de hosting. Compruebo el valor exacto, incluido cualquier hostname específico del proveedor. Un error tipográfico puede dejar www sin destino aunque el dominio raíz funcione.
NS y SOA
Los registros NS identifican los nameservers autoritativos. Si el registrador delega el dominio a un proveedor DNS antiguo, los cambios realizados en el panel del proveedor nuevo no afectan al tráfico público. El registro SOA también indica qué zona es autoritativa e incluye datos de temporización utilizados por los servidores DNS.
MX y TXT
Los registros MX enrutan el correo. Los TXT suelen contener SPF, DKIM, DMARC y valores de verificación de propiedad. No son señales de ranking, pero un correo roto o una verificación fallida pueden complicar un lanzamiento, una campaña de outreach o el acceso a herramientas de búsqueda. Los compruebo antes de retirar una zona DNS antigua.
CAA y SRV
CAA limita qué autoridades de certificación pueden emitir certificados TLS para un dominio. SRV ayuda a los clientes a localizar determinados servicios mediante hostname y puerto. No espero encontrar ambos registros en todos los dominios. Que falte una fila no implica automáticamente un error.
5 situaciones SEO en las que reviso el DNS antes que el sitio
#1 Una migración de hosting, plataforma o CDN
Antes del lanzamiento, guardo las respuestas actuales de A, AAAA, CNAME y NS. Después del cambio, repito la misma consulta. Así tengo un pequeño registro del antes y el después, en lugar de una discusión basada en capturas de distintos paneles.
También compruebo por separado el dominio raíz y www, son hostnames distintos y pueden tener registros diferentes. Si el host preferido llega a la plataforma nueva, pero el alternativo todavía apunta a la antigua, las redirecciones pueden comportarse de forma irregular o desaparecer por completo.
#2 Una caída repentina que empezó a una hora concreta
Cuando el tráfico cae de golpe el mismo día que se modifica la infraestructura, el DNS aparece entre las primeras comprobaciones. Comparo la hora de la caída con cambios de nameserver, direcciones IP, certificados y CDN. Esto no demuestra causalidad, pero permite poner a prueba rápidamente una causa plausible.
Una bajada gradual durante varias semanas suele apuntar a otra cosa. Un desplome a las 14:15 merece una revisión de infraestructura.
#3 Googlebot y los usuarios ven sitios distintos
Un split DNS, cachés obsoletas en los resolvers, una dirección IPv6 antigua o una CDN mal configurada pueden generar respuestas distintas según el cliente. Consulto varios resolvers públicos y, con el equipo de desarrollo, pruebo directamente los hosts devueltos. Quiero comprobar si todas las rutas llegan al mismo origin.
#4 Un staging o un host antiguo aparece en Google
Un subdominio olvidado puede seguir activo durante años. Una consulta DNS no descubre por sí sola todos los subdominios, pero ayuda a verificar los encontrados en un crawl, logs del servidor, backlinks, registros de certificados o Search Console. Compruebo si cada hostname todavía resuelve y si apunta a producción, staging o a un servicio externo que nadie recuerda haber contratado.
#5 La compra o reconstrucción de un dominio
El DNS actual es una pieza pequeña, aunque útil, del due diligence de un dominio. Puede mostrar si el nombre está aparcado, si todavía está vinculado al hosting anterior, si usa nameservers de un marketplace o si conserva registros antiguos de correo y verificación.
No puede decirme si el sitio anterior estaba limpio. Cuando un candidato supera la revisión básica de infraestructura, uso Karma.Domains para investigar dominios expirados con su historial archivado y el contexto de backlinks antes de comprarlo o planificar su reconstrucción. Las respuestas DNS describen el dominio actual; las páginas históricas y los enlaces explican lo que hubo antes.
¿Por qué comparo más de un resolver?
A menudo se dice que hay que «esperar a que se propague el DNS». La frase es cómoda, aunque el funcionamiento real depende sobre todo de la delegación, las consultas recursivas y la caducidad de las respuestas almacenadas en caché.
Cada registro tiene un TTL o tiempo de vida. Un resolver recursivo puede reutilizar el valor guardado hasta que se agote ese contador. Si cambio una IP mientras sigue vigente un TTL largo, algunos resolvers pueden mantener la respuesta antigua más tiempo que otros.
Por eso separo dos preguntas:
- ¿Qué publica ahora mismo el nameserver autoritativo?
- ¿Qué están devolviendo ahora mismo los principales resolvers recursivos públicos?
Una herramienta como MXToolbox puede servir para consultar directamente el DNS autoritativo. Un comprobador global de propagación es útil cuando la ubicación geográfica importa. Para un triaje SEO rápido, prefiero comparar en una sola vista las respuestas de varios resolvers públicos conocidos. Las herramientas responden a preguntas relacionadas, aunque diferentes.
Si todos los resolvers coinciden en un valor incorrecto, reviso la zona y la delegación. Si solo uno devuelve algo distinto, miro el TTL y la caché antes de volver a cambiar la configuración. Hacer modificaciones repetidas por pánico puede prolongar la confusión.
Mi triaje DNS de 10 minutos
Mantengo el proceso lo bastante sencillo como para usarlo durante una llamada de lanzamiento:
- Consultar por separado el dominio raíz y el hostname www.
- Comparar A, AAAA y CNAME con el destino esperado del hosting o la CDN.
- Confirmar que los registros NS coinciden con el proveedor DNS que el equipo está editando realmente.
- Comparar Google, Cloudflare, OpenDNS y Quad9 para detectar respuestas obsoletas o divididas.
- Revisar MX y TXT antes de retirar una zona antigua, sobre todo si importan el correo o las verificaciones de plataforma.
- Anotar el resultado y la hora. Un timestamp convierte «el DNS parecía correcto» en algo que otra persona puede verificar.
Si encuentro una discrepancia, no edito todos los registros de inmediato. Primero identifico quién controla el registrador, el DNS autoritativo, la CDN y el servidor de origen. Pueden ser cuatro proveedores distintos. Después cambio la causa confirmada más pequeña y vuelvo a comprobarlo cuando termina la ventana de TTL correspondiente.
¿Qué no puede diagnosticar el DNS?
El DNS confirma la ruta, pero no evalúa la página que espera al final. Unos registros correctos no demuestran que las redirecciones estén bien, que robots.txt sea accesible, que los canonical sean coherentes, que el certificado TLS cubra todos los hostnames o que el servidor entregue el contenido previsto.
Cuando el DNS está correcto, subo a la siguiente capa:
- Códigos de estado HTTP y cadenas de redirección
- TLS y cobertura de hostnames
- robots.txt, sitemaps XML, canonical y hreflang
- HTML renderizado y paridad de páginas entre la plataforma antigua y la nueva
- Logs del servidor para confirmar cómo llega Googlebot al sitio
Ese orden evita una pérdida de tiempo muy común: auditar el SEO on-page mientras las solicitudes todavía llegan a la máquina equivocada.
La regla práctica
Uso la consulta DNS como comprobación de enrutamiento, no como auditoría general del sitio. Resulta especialmente útil cuando el momento exacto importa, la infraestructura ha cambiado o distintas personas obtienen resultados diferentes.
Antes de tocar la página, hago una pregunta sencilla: ¿el dominio, el resolver y el servidor apuntan al mismo lugar? Si la respuesta es no, ese es el primer problema que hay que resolver.
Redactora SEO y especialista en GEO (Generative Engine Optimization) con más de 8 años ayudando a marcas, emprendedores y nicheros a posicionarse en buscadores y, ahora, en los motores de IA generativa. Licenciada en educación en matemática mención informática, MSc. en educación abierta y a distancia, Doctorante en Ciencias de la Comunicación.
