Redacción: 4SYSTEMPublicado el Actualizado el
9 lectura mínima
SEO JavaScript consiste en verificar que el contenido útil y los enlaces de una página permanezcan accesibles para Google, no solo visibles en su navegador. Para comprobar esto, compare la respuesta HTML del servidor, el DOM después de la ejecución y el HTML representado en la inspección de URL. Esta comparación le permite localizar un defecto de acceso, una dependencia de clic o un error de renderizado antes de modificar la arquitectura.
Google sabe cómo ejecutar JavaScript, pero esto no garantiza la presencia de cada contenido en el renderizado ni su indexación. Controle las características, los destinos de los enlaces y las pautas de indexación en una única URL.
Lea tres documentos, sin confundir sus funciones.
La respuesta HTML es el documento enviado por el servidor. Lo ve con “Mostrar código fuente” o en la respuesta de la consulta principal. El DOM es la estructura actual de la página, observable en la pestaña Elementos de las herramientas de desarrollo. JavaScript puede agregar, eliminar o reemplazar contenido.
Google distingue entre exploración, renderizado e indexación. Puede ejecutar JavaScript con Chromium cuando sus recursos lo permitan; Por tanto, el resultado no es necesariamente inmediato.[28] Una página que contiene solo una estructura vacía en su respuesta inicial depende más de esta ejecución que una página cuyo texto ya se entregó.
Su navegador no constituye prueba de representación Google: puede beneficiarse de una sesión, almacenamiento local o interacción. El documento decisivo para este control sigue siendo el HTML representado en la herramienta Google. El contenido que falta en el HTML renderizado utilizado para la indexación no se puede indexar como contenido de la página.[28] Sin embargo, su ausencia durante una prueba en vivo no prueba su ausencia en la versión indexada, porque los dos estados pueden diferir.[23]
Finalmente, distinga entre legibilidad e indexación. Ver el texto en esta representación confirma su presencia en el momento de la prueba, no su inclusión en el índice.
Prepare una verificación SEO JavaScript reproducible
Antes de abrir Search Console, defina exactamente lo que desea leer. “La ficha se muestra” es demasiado vago: recordar el nombre del producto, una característica distintiva y el enlace a otra ficha.
Registre en su declaración:
- la URL completa, la plantilla en cuestión y la versión implementada;
- el texto esperado, su ubicación y su origen: HTML o API;
- las URL de los scripts y la solicitud que proporciona las características;
- las interacciones necesarias, la existencia de una sesión y las reglas de acceso;
- estado HTTP, directivas
robotsy la canonicidad declarada.
El orden de control propuesto aquí es: acceso URL, respuesta inicial, directivas de indexación, recursos, inserción de contenido, enlaces y luego inspección Google.
Primero abra la URL directamente en una nueva sesión, sin hacer clic ni desplazarse. Luego observe por separado las interacciones que cambian el contenido. Mantener cada estado con su fecha y contexto; de lo contrario compararás diferentes situaciones sin saberlo.
Comparar un formulario: la tabla de diagnóstico completa
Tomemos un catálogo completamente ficticio, sin referencia a un cliente de 4SYSTEM. la hoja /catalogue/lampe-atelier proporciona su título como HTML. Las características provienen de un API llamado al abrir la pestaña “Características”. Los mapas de navegación utilizan botones con onclick.
La tabla es una plantilla completa para este escenario. La columna de inspección establece la inspección a realizar; no informa ninguna prueba real. El DOM descrito corresponde al estado después de abrir la pestaña.
| Artículo marcado | HTML fuente | DOM del navegador | Informe de inspección a verificar | Decisión |
|---|---|---|---|---|
| Título “Lámpara de taller” | Título proporcionado por el servidor | Título retenido | Comprobar la presencia del mismo título | Validar su presencia después de leer el renderizado |
| Característica “Material: acero” | Texto no proporcionado | Texto agregado después de hacer clic y responder API | Busque este texto sin abrir la pestaña | Si está ausente, elimine la dependencia de clic |
| Destino “Lámpara ajustable” | Botón con onclick, sin href | Mismo botón | Comprobar la presencia de un enlace real | Proporcionar un ancla hacia el formulario |
El título se puede leer sin que se pueda leer todo el archivo. Reutilice los mismos elementos en las tres vistas. Después de la corrección, archiva un nuevo cheque de una nueva sesión, sin borrar la observación inicial.
Reemplazar destinos ocultos detrás de onclick
Una tarjeta que abre un archivo con un evento JavaScript no es automáticamente un vínculo explotable. Google indica que no puede extraer URL de anclaje de manera confiable sin href ni otros elementos que simulen enlaces mediante eventos de script.[17]
En el catálogo ficticio, reemplace la navegación con un elemento real: <a href="/catalogue/lampe-orientable">Lampe orientable</a>. El script aún puede mejorar la transición, pero el destino existe independientemente del controlador de clic. Un botón conserva su lugar para una acción, como abrir un panel, en lugar de apuntar a otra página.
Verifique tres puntos: la presencia del ancla en el HTML renderizado, un destino real y una etiqueta comprensible. Luego abra el destino directamente: el servidor debe proporcionar la forma esperada, no solo un sobre de solicitud que funciona después de la navegación interna.
Los enlaces agregados por JavaScript también se pueden utilizar si respetan este marcado.[17] Corrija el componente de navegación y luego verifique sus variaciones en categorías y recomendaciones.
Aislar la dependencia de API y su activación
Comience con la consulta que proporciona el texto que falta. En la pestaña Red, observe su desencadenante, su estado y el contenido de la respuesta. Una respuesta JSON correcta no es suficiente: identifica también el paso que transforma estos datos en texto en el DOM.
Si la consulta espera un clic, sugerimos cargar las características esenciales tan pronto como se abra el formulario. Si sale automáticamente pero falla, revise el acceso API, las comprobaciones de origen, las cookies requeridas y los errores de script. No haga público un API privado para resolver un problema SEO: proporcione únicamente datos destinados al registro público.
Google no representa JavaScript de archivos o páginas bloqueados.[28] Verifique las restricciones de exploración para recursos útiles. La inspección en vivo también requiere una página accesible en Internet sin conexión.[23]
No establezca una supuesta fecha límite de renderizado universal. Para aislar una dependencia, pruebe una variación que entregue directamente el texto esencial y luego compare la representación. Este método distingue un problema de adquisición de datos de un problema de inserción.
Consulta Search Console sin sobreinterpretar la prueba
La inspección de URL primero presenta la información de la versión conocida de Google, no un estado actual de su implementación.[23] Tenga en cuenta la fecha de rastreo que se muestra antes de interpretar una diferencia. Luego ejecute la prueba en vivo exactamente en la misma URL.
Ver detalles de la página probada, su HTML renderizada y los recursos reportados. Encuentre el texto distintivo retenido, luego href esperado. La captura visual ayuda a comprender el estado de la página, pero no reemplaza esta investigación: un botón visible puede permanecer sin enlace.
Consulte también la respuesta original. si contiene noindex Si bien el formulario debe ser indexable, no cuente con JavaScript para eliminar esta directiva: Google puede interrumpir la representación cuando la encuentre.[28] Corregir la directiva en su origen, sin eliminar exclusiones legítimas de otras páginas.
Una prueba directa válida no garantiza la indexación. Tampoco predice la canonicidad que conservará Google.[23] Si el contenido se representa correctamente pero la página sigue faltando, continúe con la diagnóstico de una página no indexada en lugar de tratar JavaScript como la causa única.
Elija el parche y defina su validación
Decidir en función de la brecha observada. Contenido ausente en la respuesta inicial pero presente en la representación Google: la dependencia de JavaScript existe, sin ningún defecto de legibilidad demostrado. Contenido presente solo después del clic: modifique el disparador. Contenido perdido después de la ejecución: examine el componente que reemplaza a HTML. Enlaces sin destino: arreglar el marcado.
La renderización o prerenderización del servidor puede proporcionar el texto tan pronto como la respuesta HTML y reducir la dependencia de la renderización JavaScript; No todos los robots saben cómo realizar esto último.[28] Esta es una opción arquitectónica, no una obligación ni una promesa de indexación. En particular, evalúe la disponibilidad de datos en el lado del servidor y el riesgo de discrepancia entre versiones.
Para cerrar el ticket, registre el cambio, la versión probada y los documentos de control: respuesta inicial, DOM sin interacción, prueba directa HTML y enlace verificado. El criterio propuesto es concreto: el contenido esperado y su destino están presentes sin acción previa, con directivas coherentes.
Finalmente verifique otra hoja usando el mismo componente. Mantenga un registro separado del estado de indexación; la validación técnica del parche no es su prueba.
Preguntas frecuentes
¿Es invisible el contenido de un componente con DOM oculto?
No necesariamente. Google admite componentes web y reúne contenido DOM en la sombra y DOM claro al renderizar.[28] Para un formulario cuyas características están encapsuladas, busque su texto en la representación de inspección HTML. La mera presencia del componente en el código fuente no valida la presencia de sus datos.
¿Por qué una URL redirigida parece pasar la prueba?
La prueba en vivo rastrea las redirecciones, pero su informe no indica que se siguió una redirección ni que se probó la URL final.[23] Verifique la cadena de redireccionamiento en las herramientas de red e inspeccione el destino esperado por separado. En caso contrario, podrías validar el contenido de una página diferente al registro que estás intentando corregir.
¿Cómo comprobar si Google está usando un script antiguo?
Google especifica que su servicio de renderizado puede utilizar recursos antiguos JavaScript o CSS debido a su caché.[28] Compare los archivos a los que hace referencia la página con los de la implementación y luego verifique su versión en los elementos de prueba disponibles. Una estrategia de nombre de archivo versionado ayuda con el diagnóstico, sin necesidad de actualizar por sí sola.
Conclusión: abra un ticket verificable
Comience con un perfil representativo y contenido distintivo. Complete la comparación, corrija la primera discrepancia establecida y luego repita la prueba sin interacción. Proporcione al desarrollador observaciones y pruebas, no solo una captura de pantalla. Para enmarcar el diagnóstico y las correcciones, consulte el servicios web y SEO de 4SYSTEM y presente su URL con esta declaración.
Fuentes
- SEO Link Best Practices for Google | Google Search Central | Documentation | Google for Developers (consultado 2026-10-08)
- URL Inspection tool - Search Console Help (consultado 2026-10-08)
- Understand JavaScript SEO Basics | Google Search Central | Documentation | Google for Developers (consultado 2026-10-08)
