Nuestros cinco flujos de producto eran completamente invisibles para el primer
rastreo. No mal posicionados: ausentes. Cada nombre de producto, cada título de
beneficio y cada descripción se obtenía de un endpoint interno después de cargar
la página y se escribía en el DOM con innerHTML, de modo que el HTML que
recibía un rastreador contenía una sola cadena relevante:
Loading Platform Architecture....
Reconstruimos el sitio para que el contenido se renderice en el servidor. Esto es lo que encontramos.
El fallo era medible, y era cero
La comprobación cabe en un comando:
curl -s https://archmir.com/platform/expertarch | grep -c "Expert Level Reasoning Layer"
Antes de la reconstrucción devolvía 0. La página tenía título, descripción y
etiquetas Open Graph, todas inyectadas en el servidor mediante sustitución de
texto en una plantilla, pero no tenía cuerpo. Los metadatos describían una página
cuyo contenido no existía hasta que se ejecutaba JavaScript.
Esto importa más que antes. Googlebot indexa en dos pasadas: la primera lee el HTML en bruto y todo lo que requiere JavaScript entra en la cola del Web Rendering Service, donde puede esperar horas o semanas. Los rastreadores que nunca ejecutan JavaScript, incluidos los que generan las vistas previas en redes sociales y un número creciente de agentes de recuperación de IA, no llegan a ver el contenido en ningún momento.
Qué cambiamos
El contenido pasó de una petición del lado del cliente a Server Components. El comportamiento interactivo se mantuvo, pero ahora se engancha a un marcado que ya está en el HTML en lugar de crearlo.
| Antes | Después |
|---|---|
Catálogo obtenido de /api/content/platform e inyectado con innerHTML | Renderizado por el servidor; presente en el HTML inicial |
Páginas de producto construidas en tiempo de ejecución por una función _renderIsolationMode() | Generadas estáticamente en tiempo de compilación, un archivo por producto y por idioma |
Idioma cambiado con un parámetro de consulta ?lang= | Rutas separadas e indexables, con hreflang entre ellas |
| Una única imagen de Open Graph para todas las URL | Una tarjeta generada por ruta |
La jerarquía de encabezados empezaba en h3 sin ningún h2 por encima | Un h1 y después una jerarquía real de h2/h3 |
Las partes interactivas —cambio de pestañas, animaciones de scroll, reproducción de vídeo y el formulario de contacto— son componentes de cliente montados sobre marcado renderizado en el servidor. El usuario no pierde nada.
Tres cosas que no eran obvias
Esconder contenido tras opacity: 0 es un riesgo real. Nuestras animaciones
de scroll empiezan con cada sección invisible y la revelan con JavaScript.
Googlebot renderiza JavaScript y acabaría viéndola, pero un cliente sin
JavaScript vería una página en blanco. Un bloque <noscript> que neutralice la
animación no cuesta nada y elimina por completo ese modo de fallo.
Bloquear una URL en robots.txt no la saca del índice. Habíamos previsto
bloquear las antiguas URL con ?lang=. Habría sido justo al revés: una URL que
un rastreador no puede solicitar es una URL cuya redirección nunca podrá
descubrir, así que la dirección antigua habría permanecido indexada
indefinidamente. Para que una redirección funcione tiene que ser rastreable.
Los rastreadores de IA necesitan una invitación explícita. Google-Extended
y Applebot-Extended son tokens de exclusión para el uso en IA. No decir nada
deja la decisión en manos de un valor por defecto. Si quiere que su documentación
sea accesible para los motores generativos, inclúyalos bajo Allow.
La parte que no se puede automatizar
La estrategia de renderizado, los datos estructurados y las Core Web Vitals son problemas de ingeniería, y los problemas de ingeniería tienen soluciones determinables. Lo que ninguno de ellos sustituye es tener algo concreto y verificable que decir, y por eso las cifras de este artículo son las que medimos en nuestro propio sitio y no comparativas citadas de otros.