Me he encontrado más de una vez con webs donde el nombre del sitio o el favicon aparecen mal en Google, o directamente no aparecen, y el propietario no entiende por qué: la web funciona, tiene datos estructurados, tiene la etiqueta title bien puesta. El problema, en varios de esos casos, no estaba en el código de la web sino en algo mucho más silencioso: la versión HTTP del dominio respondía con un 200 en vez de redirigir a HTTPS, y Google estaba rastreando esa versión paralela sin que nadie lo supiera.
Ese detalle pequeño puede arruinar la señal que Google usa para asignar el nombre del sitio y el favicon, que son elementos de las SERP que afectan directamente al CTR de tu marca. Y lo peor es que no lo ves en el navegador, porque Chrome lo oculta.
Por qué una página HTTP residual confunde a Google sobre el nombre de tu marca
Para mostrar el nombre del sitio en los resultados, Google cruza varias señales: el marcado WebSite en datos estructurados (con la propiedad name), la etiqueta title, el H1 de la página de inicio y metadatos de Open Graph como og:site_name. Cuando esas señales son coherentes entre sí, el sistema las interpreta sin problema y muestra tu marca correctamente.
El conflicto aparece cuando el servidor sirve dos versiones de la página de inicio: la HTTPS que tú cuidas y optimizas, y una versión HTTP que nadie ha tocado y que responde con código 200. Google no es un navegador; no toma la decisión automática que toma Chrome de actualizar la petición a HTTPS. Si accede a http://tudominio.com y recibe una respuesta válida, la procesa. Si esa versión HTTP tiene contenido genérico del hosting, carece de datos estructurados o tiene un title distinto, las señales que Google extrae de ella contradicen las de tu versión segura, y el sistema puede quedarse sin un valor de confianza suficiente para mostrar el nombre o el favicon.
John Mueller lo ha mencionado en varias ocasiones como un problema infradiagnosticado, precisamente porque los propietarios de webs comprueban su sitio con Chrome y no ven nada raro. La redirección automática del navegador hace invisible el fallo. He visto esto en auditorías de sitios migrados a HTTPS hace años, donde el servidor quedó mal configurado desde el principio: nadie lo detectó porque, desde el navegador, todo parecía funcionar.
Cómo detectar si tu versión HTTP está sirviendo contenido en vez de redirigir
La forma más directa de comprobarlo es con curl desde la línea de comandos. El comando es curl -I http://tudominio.com, y lo que quieres ver en la respuesta es un 301 Moved Permanently apuntando a la versión HTTPS. Si en cambio ves un 200 OK, tu servidor está sirviendo contenido en esa URL y tienes el problema.
Si no tienes acceso a una terminal, puedes usar la herramienta de inspección de URLs de Google Search Console: introduce la URL en versión HTTP de tu página de inicio y ejecuta la prueba en directo. Lo que veas ahí es exactamente lo que Google renderiza cuando rastrea esa URL; si aparece contenido real en vez de un redireccionamiento, ya sabes por dónde va el fallo. Esta es la clase de comprobación que suelo incluir en la parte técnica de cualquier auditoría, porque el problema no aparece en los rastreadores convencionales si no configuras expresamente que prueben el protocolo HTTP por separado. Si quieres entender mejor cómo encaja esto con el rastreo general, en este artículo explico cómo funciona el proceso de rastreo e indexación de Google con bastante detalle.
 (1).jpg)
Otro sitio donde a veces aparece esta página fantasma es directamente en el servidor, como archivo de bienvenida del hosting que tiene prioridad sobre tu index.php cuando el protocolo no está gestionado correctamente. Si tienes acceso al panel de hosting, revisa si hay algún archivo de ese tipo en la raíz del dominio.
Cómo solucionarlo y qué revisar en los datos estructurados
La corrección técnica va en la configuración del servidor, no en el HTML. En Apache, el bloque habitual en el .htaccess es una regla RewriteRule que capture todas las peticiones HTTP y las redirija con 301 a la versión HTTPS equivalente. En Nginx, se gestiona con un bloque server separado que escuche en el puerto 80 y devuelva el redireccionamiento. Si usas un proveedor de hosting gestionado o un CDN como Cloudflare, muchas veces tienes esta opción directamente en el panel, sin tocar configuración del servidor a mano.
Una vez cerrado ese agujero, conviene revisar que los datos estructurados de tipo WebSite estén presentes en la página de inicio de la versión HTTPS e incluyan la propiedad name con el nombre exacto de tu marca; si tienes una versión alternativa del nombre con la que los usuarios también te buscan, puedes incluirla en alternateName. El nombre debe ser corto, único y reconocible, sin palabras clave de relleno que lo alarguen innecesariamente. Google usa esto como señal para el nombre del sitio, pero solo si el resto de señales (título, H1, Open Graph) apuntan en la misma dirección; la coherencia entre todas ellas es lo que le da confianza suficiente al sistema para asignar el valor correcto.
Para el favicon, la situación es similar: Google lo toma de la versión canónica de la página de inicio, así que si esa versión HTTP estaba interfiriendo, eliminar el conflicto de protocolo suele ser suficiente para que el favicon vuelva a mostrarse en los resultados en el siguiente ciclo de rastreo. No hay un mecanismo de forzado inmediato; el cambio tarda en reflejarse porque depende de cuándo Googlebot vuelva a rastrear la URL. Si llevas semanas con el nombre o el favicon mal después de haber hecho cambios, comprueba primero que la corrección del servidor esté funcionando con curl antes de buscar el problema en otro sitio. Y si quieres entender qué más puede estar limitando cómo Google rastrea tu web, este artículo sobre los límites de rastreo de Googlebot te da contexto útil para interpretar lo que ves en Search Console.
¿Necesitas mejorar el posicionamiento de tu web?
Si quieres aplicar estas estrategias y obtener resultados reales, puedo ayudarte. Llevo años trabajando el SEO de empresas y proyectos digitales con un enfoque técnico y orientado a resultados.
Solicitar consulta SEOPreguntas frecuentes
¿Por qué Google muestra el nombre de dominio en lugar de mi nombre de marca?
Esto sucede cuando Google no tiene suficiente confianza en las señales de vuestra página de inicio. Puede deberse a la falta de datos estructurados WebSite o a contradicciones entre la versión HTTP y HTTPS de vuestra web.
¿Cómo puedo ver qué contenido sirve mi web en HTTP si Chrome me redirige?
Debéis usar herramientas externas como el comando curl en la terminal o la función de inspección de URLs en Google Search Console para ver la respuesta bruta del servidor sin las redirecciones automáticas del navegador.
¿Cuánto tarda Google en actualizar el nombre del sitio tras corregir el error?
El proceso no es inmediato y depende de la frecuencia de rastreo de vuestra página de inicio. Por lo general, los cambios pueden tardar desde unos pocos días hasta varias semanas en reflejarse en todas las SERP.