Lecciones de SEO al arreglar nuestra propia web

Dedicamos unos días a leer nuestra propia web como lo haría un buscador y encontramos seis cosas que valía la pena arreglar. 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 de eso era dramático, pero todo nos restaba visibilidad en silencio.

El sitio en un párrafo

mythex.ai es una app de una sola página que prerenderizamos en el momento de compilar: un script recorre cada ruta, escribe un archivo HTML estático para ella e inyecta 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 está en ese paso de prerenderizado, porque es el HTML que un rastreador lee de verdad.

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

Síntoma. Nuestra plantilla HTML llevaba 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í, cada página del sitio incluía 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 sitio es el tipo de cosa que hace que el marcado de una página pierda valor, no solo que se ignore.

Solución. El bloque global ha desaparecido. 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. Además, 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 acaba rompiendo; una regla que impone la compilación, no.

2. Google usaba una imagen equivocada para nosotros

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

Por qué pasaba. Nunca le dijimos a Google qué imagen representaba cada página, así que eligió la 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 incluyen 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

El marcado Organization de nuestro sitio 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 aparecen en nuestra licencia comercial: razón social, fecha de fundación, fundador y domicilio social. Dejamos el número de teléfono fuera a propósito.

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

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

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 llegaba a una página que le vendía un creador.

Solución. Cada una de las tres ahora tiene 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 arregló 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 esa categoría no tenía ningún enlace interno. Lo sustituimos por un anillo ordenado por subcategoría: ahora cada página de plantilla recibe exactamente cuatro enlaces de entrada y cuatro de salida. Además, el HTML prerenderizado ya imprime esos enlaces; antes solo existían después de ejecutarse JavaScript, algo que un rastreador quizá nunca haga.

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 constructor de apps con IA que los asistentes de IA no encuentran es un tipo de fallo particular.

El enfoque obvio, enviar el mapa del sitio completo en cada despliegue, es la manera de que te limiten la clave, y la mayoría de los despliegues no cambian nada que a un buscador le importe. Así que un script compara el mapa del sitio que está sirviendo ahora mismo con el que acaba de compilarse y envía solo la diferencia.

Dos detalles hicieron que funcionara:

• Haz una instantánea antes de desplegar. La referencia debe capturarse antes de que la nueva compilación esté en línea. Después, el mapa «en vivo» ya es el nuevo y todas las diferencias salen vacías.
• Solo páginas nuevas, de momento. Nuestro mapa del sitio no tiene fechas lastmod, así que el script anuncia las páginas nuevas, pero no las reescrituras. Poner la fecha de compilación en cada URL marcaría todo el sitio como modificado en cada despliegue, justo el spam que queríamos evitar.

Se ejecuta solo en 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»

Cuando lanzamos las páginas /ai (más sobre ellas en una página de inicio para cada tipo de negocio), el staging mostraba «Not found» en todas, mientras el hosting estático las servía bien.

El servicio que hay delante de nuestros hosts de marketing solo reenvía una lista de rutas permitidas; 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 confirma que pasan. Un error pequeño, pero exactamente del tipo que hace invisible una sección nueva para los rastreadores sin que nadie se dé cuenta.

Lo que sacamos de todo esto

• Lee el HTML que lee un rastreador. La mayoría de estos problemas eran invisibles en el navegador y evidentes 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, lo adivinarán.
• Search Console te dice qué pregunta hacía la gente. Impresiones sin clics suelen significar que la página respondía a otra cosa.
• Envía las diferencias, no todo. Avisar solo de lo que cambió te mantiene dentro de los límites de uso.

Si quieres hacer lo mismo con un sitio que hayas creado, nuestras guías sobre SEO para webs creadas con IA y cómo configurar Google Search Console cubren lo básico.