Lecciones de SEO al corregir nuestro propio sitio

Pasamos unos días leyendo nuestro propio sitio como lo lee un buscador y encontramos seis cosas que valía la pena corregir. Cada página declaraba dos bloques de preguntas frecuentes, Google usaba como miniatura un halo decorativo del fondo, un grupo de páginas de plantillas aparecía en búsquedas que no respondían, y una nueva sección del sitio estaba bloqueada por nuestro propio edge en staging. Nada fue dramático. Todo nos costaba visibilidad sin que lo notáramos.

El sitio en un párrafo

mythex.ai es una aplicación de una sola página que prerenderizamos durante la compilación: un script recorre cada ruta, escribe un archivo HTML estático para cada una e inserta el título, la descripción y los datos estructurados de la página (el bloque JSON-LD que indica a los buscadores de qué trata una página; consulta qué son los datos estructurados). La mayor parte de lo que sigue se encuentra en ese paso de prerenderizado, porque es el HTML que realmente lee un rastreador.

1. Cada página decía ser la página de preguntas frecuentes

Síntoma. Nuestra plantilla HTML incluía en sus datos estructurados un bloque FAQPage para todo el sitio, con su URL apuntando a /faq. Después, el prerenderizado añadía el FAQPage propio de cada página. Así, todas las páginas del sitio tenían dos, y nuestra política de privacidad le decía a Google que era la página de preguntas frecuentes.

Por qué importa. Google espera como máximo un FAQPage por página. Un segundo que apunta a otro lugar es el tipo de cosa que hace que el marcado de la página se descuente, no solo que se ignore.

Solución. El bloque global ya no existe. El marcado de preguntas frecuentes de cada página ahora sale de un único lugar, incluida la propia /faq, que lo construye a partir de la lista completa de preguntas. Las páginas sin preguntas frecuentes ya no declaran ninguna, que es la respuesta honesta. Y el prerenderizado falla la compilación si alguna página vuelve a tener más de un FAQPage. Una regla que solo vive en la memoria de alguien se rompe; una regla que la compilación impone, no.

2. Google usaba otra imagen para representarnos

Síntoma. En los resultados de búsqueda, la miniatura de Mythex era el halo que palpita suavemente detrás del héroe de nuestra página de inicio, una imagen decorativa de fondo, en lugar de nuestra tarjeta para compartir.

Por qué ocurría. Nunca le indicamos a Google qué imagen representaba cada página, así que eligió una que encontró.

Solución. Dos caras del mismo problema:

• Indicar cuál es la imagen de la página. La página de inicio ahora tiene un nodo WebPage con un primaryImageOfPage que apunta a la tarjeta para compartir, y los datos estructurados de cada página prerenderizada llevan su propia imagen (la imagen para compartir de la página o la predeterminada).
• Ocultar la decoración. Las imágenes de fondo ahora están no permitidas en robots.txt y se sirven con una cabecera noindex, noimageindex, así que quedan fuera de la búsqueda de imágenes y de las miniaturas.

3. Los buscadores solo conocían nuestro logotipo

Nuestro marcado Organization tenía un nombre, un logotipo y algunos enlaces a redes sociales: marca, nada más. Los buscadores construyen el panel de conocimiento de una empresa a partir de datos de tipo registral, así que añadimos los que figuran en nuestra licencia comercial: razón social, fecha de fundación, fundador y dirección registrada. Dejamos deliberadamente fuera el número de teléfono.

4. Las páginas de plantillas respondían a la pregunta equivocada

Síntoma. Search Console mostraba tres páginas de plantillas que acumulaban impresiones y ningún clic. Una aparecía para «portfolio de content strategist» y sus variantes, otra para «mejor diseño web de restaurante italiano» y otra para un grupo alrededor de «agile board»; la mitad de esas búsquedas incluían la palabra «gratis». Las posiciones iban de la 20 aproximadamente a la 50.

Por qué. Cada página respondía a una pregunta distinta de la que se hacía. Alguien que quería ver cómo es un buen diseño para un restaurante italiano aterrizaba en una página que le vendía un constructor.

Solución. Cada una de las tres tiene ahora una sección escrita para la búsqueda y no para el producto, un título y una descripción con las palabras que la gente escribe, y preguntas frecuentes que merecen el marcado que ya emitían.

El mismo cambio corrigió un problema más discreto. El bloque de «plantillas relacionadas» tomaba las cuatro primeras plantillas de una categoría, así que todas las plantillas de portfolio apuntaban a los mismos cuatro portfolios, y el resto de la categoría no tenía ningún enlace interno. Lo sustituimos por un anillo ordenado por subcategoría: cada página de plantilla recibe exactamente cuatro enlaces de entrada y cuatro de salida. Además, el HTML prerenderizado ahora imprime esos enlaces; antes solo existían después de ejecutarse JavaScript, algo que un rastreador puede no hacer nunca.

5. Avisar a Bing de las páginas nuevas en cuanto se despliegan

Google ignora IndexNow, un protocolo para avisar a los buscadores cuando cambia una URL. Bing, Yandex y Seznam lo usan, y el índice de Bing es el que lee la búsqueda de ChatGPT. Un creador de aplicaciones con IA que los asistentes de IA no pueden encontrar es un fallo de un tipo particular.

El enfoque obvio, enviar el sitemap completo en cada despliegue, es la forma de que te limiten la tasa de envíos, y la mayoría de los despliegues no cambian nada que a un buscador le importe. Así que un script compara el sitemap que el sitio sirve ahora con el recién compilado y envía solo la diferencia.

Dos detalles hicieron que funcionara:

• Haz la instantánea antes de desplegar. La línea base tiene que capturarse antes de que la nueva compilación esté en línea. Después, el sitemap «en vivo» ya es el nuevo y cada diferencia sale vacía.
• Solo páginas nuevas, por ahora. Nuestro sitemap no tiene fechas lastmod, así que el script anuncia páginas nuevas pero no reescrituras. Poner la fecha de compilación en cada URL marcaría todo el sitio como cambiado en cada despliegue, justo el spam que estábamos evitando.

Se ejecuta solo en los despliegues de producción y nunca hace fallar la compilación: para cuando se ejecuta, el sitio ya está en línea, y un aviso a un buscador no merece un despliegue en rojo.

6. Nuestro propio edge decía «no encontrado»

Al lanzar las páginas /ai (hablamos de ellas en una página de inicio para cada tipo de negocio), el staging mostraba «Not found» en todas ellas mientras el host estático las servía bien.

El servicio que está delante de nuestros hosts de marketing solo reenvía una lista blanca de rutas; cualquier otra cosa recibe un 404 directo. /ai era nueva y no estaba en la lista. Añadimos /ai y /ai/*, con una prueba que verifica que pasan. Un fallo pequeño, pero exactamente del tipo que vuelve invisible una sección nueva para los rastreadores sin que nadie lo note.

Lo que aprendimos

• Lee el HTML que lee un rastreador. La mayoría de estos problemas eran invisibles en un navegador y obvios en el archivo prerenderizado.
• Convierte las reglas de SEO en comprobaciones de compilación. «Un FAQPage por página» ahora se impone, no se recuerda.
• Dile a los buscadores lo que quieres decir. Si no indicas qué imagen o qué datos te representan, ellos lo adivinarán.
• Search Console te dice qué pregunta hizo la gente. Impresiones sin clics suelen significar que la página respondía otra pregunta.
• Envía las diferencias, no todo. Avisar solo de lo que cambió te mantiene dentro de los límites de uso.

Si haces lo mismo con un sitio que construiste, nuestras guías sobre SEO para sitios web creados con IA y cómo configurar Google Search Console cubren lo básico.