Plantilla de auditoría SEO para JavaScript

Comprobación de renderizado: HTML sin formato frente a DOM renderizado

Cuándo usarla: Confirma lo que ve el robot de Google después de ejecutar JavaScript, no solo la respuesta inicial del servidor.

Compare el código fuente con el DOM renderizado

Google recupera primero el HTML sin procesar y luego renderiza la página con un navegador sin interfaz antes de indexarla. Debido a que el renderizado es diferido y consume muchos recursos, puede retrasarse con respecto al rastreo, por lo que el resultado renderizado es lo que en última instancia importa para la indexación.

Empiece por ver la respuesta HTML sin procesar (la fuente que devuelve el servidor) y observe qué contenido, enlaces y metadatos están presentes antes de que se ejecute cualquier JavaScript. Luego, inspeccione el DOM renderizado después de que se ejecuten los scripts y compare ambos.

• [Page URL] auditada
• ¿Contenido clave del cuerpo presente en el HTML sin procesar?
• ¿Encabezados, texto y datos de producto presentes en el DOM renderizado?
• ¿Navegación y enlaces internos presentes después del renderizado?
• ¿Título, metadescripción y canonical presentes después del renderizado?

Señale cualquier cosa que aparezca solo después de ejecutar JavaScript. Ese contenido depende por completo de que el renderizado se realice correctamente, por lo que conlleva el mayor riesgo. Documente cada brecha entre el HTML sin procesar y el DOM renderizado como un hallazgo para corregir.

Contenido y enlaces rastreables

Cuándo usarla: Asegúrese de que el contenido principal y la navegación utilicen enlaces reales y rastreables presentes en el DOM.

Utilice enlaces reales y contenido presente en el DOM

Los motores de búsqueda siguen los enlaces a través de elementos <a> estándar con un atributo href que se resuelve en una URL real. Los enlaces activados únicamente por un controlador onclick, un botón o un span no se descubren de manera confiable, por lo que las páginas importantes pueden quedar sin rastrear.

Recorra sus plantillas clave y confirme que cada enlace de navegación y contextual sea un ancla real con un href rastreable.

• La navegación principal utiliza enlaces [a href]
• La paginación y los filtros exponen URL rastreables
• Los enlaces relacionados e internos son anclas reales, no onclick
• El contenido principal se renderiza en el DOM, no queda oculto detrás de interacciones

Evite depender de eventos de clic, desplazamiento infinito sin URL paginadas o contenido que solo se carga después de acciones del usuario que Googlebot no realizará. Si el contenido necesita un toque o desplazamiento para aparecer, trátelo como en riesgo y proporcione una ruta rastreable hasta él. Registre qué enlaces y secciones pasan la revisión y cuáles necesitan un href real o presencia en el DOM.

Indexabilidad: metadatos después de la renderización

Cuándo usarla: Capture sorpresas noindex, canonical o robots inyectadas con JS que bloquean o desvían la indexación.

Compruebe los metadatos renderizados, no solo la fuente

Las directivas de indexación se leen desde el HTML renderizado, por lo que JavaScript que las inyecta o cambia puede afectar silenciosamente la forma en que se indexa una página. Una fuente limpia aún puede enviar un noindex o un canonical incorrecto una vez que se ejecutan los scripts.

Para cada plantilla, inspeccione el DOM renderizado y confirme que las señales de indexación coinciden con su intención.

• Meta robots en el DOM renderizado: [index/noindex]
• Etiqueta canonical presente una sola vez y apuntando a la URL prevista
• No hay JavaScript que cambie el canonical a una URL diferente
• El título y la metadescripción se resuelven con los valores correctos después del renderizado
• Hreflang y datos estructurados presentes donde se esperaba

Los cambios de noindex o canonical inyectados con JS son arriesgados porque Google puede actuar sobre el valor renderizado. Tenga especial cuidado con frameworks o administradores de etiquetas que reescriben elementos del head. Si una directiva puede cambiar entre los estados sin procesar y renderizado, trátela como un defecto y configúrela del lado del servidor. Registre las directivas renderizadas de cada página y cualquier discrepancia.

Estrategia de renderizado: CSR vs SSR vs SSG

Cuándo usarla: Elija un enfoque de renderizado que haga que el contenido esté disponible de manera confiable para los rastreadores.

Elija una estrategia de renderizado que favorezca la rastreabilidad

La forma en que renderiza determina qué tan confiablemente llega el contenido a los motores de búsqueda. Debido a que el renderizado de Google es diferido, las estrategias que entregan contenido en el HTML inicial reducen el riesgo.

• Renderizado del lado del cliente (CSR): el navegador crea la página a partir de JavaScript. El contenido depende totalmente de que el renderizado se realice correctamente, por lo que conlleva el mayor riesgo de indexación.
• Renderizado del lado del servidor (SSR): el servidor devuelve HTML completamente formado en cada solicitud. El contenido, los enlaces y los metadatos están presentes de inmediato.
• Generación de sitio estático (SSG) o prerenderizado: el HTML se crea con anticipación o se sirve desde una capa de prerenderizado, lo que hace que el contenido esté disponible de manera confiable y con un rendimiento sólido.

Para páginas críticas para SEO, prefiera SSR, SSG o prerenderizado para que el contenido esté en el HTML inicial. Reserve el uso intensivo de CSR para áreas detrás de autenticación o de bajo valor SEO.

Documente su enfoque actual por plantilla, las brechas que crea y la estrategia objetivo.

• Plantilla: [name]
• Método de renderizado actual frente al objetivo

Impacto en el rendimiento de JavaScript

Cuándo usarla: Reduzca el peso de JS y el costo de ejecución para que las páginas se muestren rápidamente para los usuarios y rastreadores.

Reducir el costo de JavaScript

El uso intensivo de JavaScript ralentiza la representación para los usuarios y aumenta el trabajo que los motores de búsqueda deben realizar para representar sus páginas. Debido a que el procesamiento consume muchos recursos, las páginas más eficientes se procesan de manera más confiable y se cargan más rápido, lo que respalda tanto la experiencia como la indexación.

Audite la cantidad de script que incluye cada plantilla clave y qué bloquea.

• Se identifican paquetes de JavaScript grandes o no utilizados
• Scripts de bloqueo de procesamiento diferidos o divididos cuando sea posible
• Contenido crítico no bloqueado detrás de una ejecución lenta de script
• Scripts de terceros revisados para determinar su peso y necesidad
• Core Web Vitals revisado en plantillas clave

Favorezca la división del código, la eliminación del código no utilizado y la carga de scripts no críticos más adelante para que el contenido principal aparezca rápidamente. Nunca bloquees archivos JavaScript o CSS en robots.txt, ya que eso impide que Google muestre la página tal como la ven los usuarios. Registre los tamaños de los paquetes, los recursos de bloqueo y las correcciones que planea para cada plantilla auditada.

Pruebe y supervise

Cuándo usarla: Valide la representación con herramientas reales y supervise a través de Search Console a lo largo del tiempo.

Pruebe la página renderizada y supervísela

Verifique sus correcciones con respecto a lo que Google realmente renderiza. La herramienta de inspección de URL en Search Console muestra el HTML renderizado y una captura de pantalla de la página rastreada, lo que le permite confirmar que el contenido, los enlaces y los metadatos están presentes después del renderizado.

Ejecute cada plantilla clave mediante la inspección y capture los resultados.

• El HTML renderizado de la inspección de URL contiene el contenido principal
• La captura de pantalla renderizada muestra el diseño esperado
• Navegación y enlaces internos presentes en el HTML renderizado
• Directivas de indexación correctas en el resultado renderizado
• No se reportaron errores durante el renderizado

Luego, pase de comprobaciones puntuales a monitoreo continuo.

• Haga seguimiento de los informes de cobertura e indexación en Search Console
• Vuelva a inspeccionar después de cambios importantes en el framework o la plantilla
• Esté atento a las páginas que salen del índice

Registre cada URL probada [URL], su estado renderizado y cualquier seguimiento necesario para que los problemas se detecten temprano, no después de una caída en el posicionamiento.