Llegar a un servidor mediante su IP solo demuestra que la red y un servicio web predeterminado responden. No confirma que DNS resuelva bien ni que el servidor asigne ese hostname al virtual host de WordPress. Además, WordPress guarda su dominio canónico y puede redirigir una visita directa por IP.
Conserva la configuración DNS y del hosting antes de tocar ambas a la vez.
Define el fallo con precisión
Anota resultados para raíz y www, HTTP y HTTPS, código, certificado y cuerpo. Compara redes y resolvers distintos.
Captura:
respuestas A, AAAA y CNAME
nameservers y TTL
Host y SNI solicitados
respuesta del virtual host
dominio del certificado
home y siteurl de WordPressUna URL de vista previa del panel no sustituye la prueba del dominio final.
Verifica el DNS autoritativo
Confirma que el registrador delega en los nameservers previstos y revisa los registros en ese proveedor autoritativo.
Un AAAA antiguo puede enviar a otro servidor a los visitantes con IPv6 aunque el A sea correcto. www puede tener un CNAME independiente.
Elimina duplicados conflictivos con cuidado. Bajar el TTL después del cambio no borra respuestas ya almacenadas.
Comprueba DNSSEC y caché negativa
Si DNSSEC está activo, confirma que el DS del registrador coincide con las claves del proveedor. Un DS antiguo tras migrar nameservers puede causar SERVFAIL en resolvers validadores.
Las respuestas NXDOMAIN también se almacenan durante el TTL negativo definido en el SOA. No desactives DNSSEC sin planificar la transición; coordina claves y delegación.
Descarta resolución local
Revisa el archivo hosts, VPN, DNS corporativo, caché del router y DNS seguro del navegador. Una red interna puede usar split DNS intencionadamente.
Registra primero la respuesta y luego limpia solo la caché relevante. No mantengas IPs de producción en los archivos hosts del equipo: fallarán silenciosamente en la próxima migración.
Prueba el hostname contra el servidor correcto
Utiliza temporalmente un archivo hosts o un cliente que envíe tanto la IP de destino como el hostname y SNI:
curl --resolve example.com:443:203.0.113.10 https://example.com/Emplea valores reales autorizados localmente y no publiques la IP de origen. Esta prueba separa DNS de la configuración web.
Revisa el virtual host
cPanel o Plesk debe asociar dominio y alias al document root correcto. Apache o Nginx necesita ServerName o server_name y su raíz correspondiente.
Una página predeterminada indica que la petición llegó, pero ganó otro host. Corrige la suscripción o dominio adicional antes de mover WordPress. Evita dos virtual hosts reclamando el mismo nombre.
Valida SSL y SNI
HTTPS debe presentar un certificado que incluya la raíz y www usados. Un certificado predeterminado suele revelar una selección incorrecta por SNI.
Instala o renueva Let’s Encrypt desde el panel después de que DNS llegue al servidor y funcione la validación ACME. No desactives la verificación ni uses un certificado para IP como solución permanente.
Alinea las URLs canónicas
Comprueba que home, siteurl y las constantes usan el dominio HTTPS y ruta previstos. Que la IP redirija al dominio puede ser el comportamiento correcto.
No sustituyas esas URLs por la IP: romperías cookies, enlaces, correos y SEO. Detrás de Cloudflare, configura el reenvío HTTPS de fuentes confiables.
Inspecciona proxy y cortafuegos
Si Cloudflare está proxificado, comprueba que el origen acepta sus peticiones y que el modo SSL coincide con un certificado válido. Compara cuidadosamente pruebas proxificadas y DNS-only.
El cortafuegos puede permitir las redes documentadas de la CDN sin quedar abierto globalmente. No lo desactives para conseguir una respuesta puntual.
Verifica más que la portada
Prueba login, recursos, REST, medios, redirecciones canónicas, raíz y www. Confirma respuestas DNS desde varias ubicaciones tras el TTL y elimina overrides temporales.
La monitorización recurrente debe comprobar DNS, certificado y virtual host por hostname. Un ping a la IP no representa cómo acceden los visitantes.