El contenido importante no debe depender de un clic, un desplazamiento en particular o una conexión a descubrir. Compruebe lo que contiene la respuesta inicial y lo que aparece después de renderizar. La elección técnica debe servir tanto a los visitantes, al mantenimiento como al acceso al motor.
Distinguir HTML inicial y página renderizada
El código recibido por el navegador puede contener solo un esqueleto, luego completado por JavaScript. Google describe un tratamiento que incluye exploración, renderizado e indexación. El hecho de que un motor pueda ejecutar JavaScript no garantiza que cada dependencia o interacción funcione. Por lo tanto, compare la respuesta inicial con el contenido renderizado en las páginas que llevan sus ofertas y sus respuestas editoriales.
Prueba las condiciones ordinarias
Abra una página en una sesión pública, con una red lenta, luego controle lo que permanece disponible si falla un recurso. ¿Están presentes el título, el texto decisivo y los enlaces a páginas útiles? Los errores de API no deben convertir un archivo existente en una página vacía. Compruebe también que los estados de carga no permanezcan visualizados indefinidamente.
Una prueba de aceptación en tres estados en la misma página
Pruebe la página desde su URL directa, luego después de la navegación interna, luego con una dependencia no disponible en su entorno de prueba de aceptación. Usted está buscando saber qué puede leer y hacer el visitante en cada estado. La capacidad de hacer JavaScript no prescinde de errores de servicio, enlaces y contenido consistente. Los siguientes puntos de control se aplican a una guía, así como a una hoja de producto.
| Elemento | pregunta en el html inicial | Pregunta después de renderizar |
|---|---|---|
| Título y texto decisivo | ¿Están presentes el sujeto y la respuesta? | ¿El texto es completo y siempre consistente? |
| Enlaces entre páginas | ¿Se pueden extraer destinos reales? | ¿La navegación produce buenas URL? |
| Datos del producto | ¿Los valores coinciden con el producto solicitado? | ¿Una interacción cambia la variante correctamente? |
| error o falta de recurso | ¿Son apropiados el estado y el mensaje? | ¿Se puede entender un error de carga? |
| metadatos | ¿La página lleva su propia identidad? | ¿Una actualización del lado del cliente crea una contradicción? |
Los Principios de SEO de JavaScript documentados por Google Distinguir entre exploración, renderizado e indexación. Su prueba de aceptación debe mantener estos pasos separados. Un texto visible en su navegador es un hallazgo de renderizado en estas condiciones, no prueba de que todas las experiencias de búsqueda pueden explotarlo o lo explotarán.
Make navigation explicit
Use enlaces HTML con un destino real para rutas de páginas cruzadas. Un botón que solo cambia el estado de una aplicación no siempre reemplaza una URL compartible. Para un catálogo, cada producto importante debe poder abrirse directamente. Verifique las redirecciones y los estados devueltos durante el acceso directo, no solo cuando se navega desde casa.
Ejemplo ficticio: características en una pestaña
Una hoja carga sus dimensiones solo después de abrir una pestaña. El equipo coloca la información decisiva en la página disponible públicamente y luego usa la pestaña para organizar la lectura. Controla el resultado en la inspección móvil y en la página. El objetivo no es prohibir JavaScript, sino evitar que la acción frágil acondicione el acceso a las características necesarias para la decisión.
Decidir qué poner a disposición sin interacción
Para un artículo, la respuesta principal y los enlaces útiles generalmente pueden venir con la página. Para un catálogo, la interfaz puede permanecer interactiva al tiempo que proporciona una URL directa que identifique el producto y su información esencial. Las funciones secundarias, como una herramienta de personalización, requieren un análisis limpio: hacerlas interactivas no significa que el resto de la tarjeta deba estar vacía al principio.
- Elija una plantilla representativa y elija su contenido público. Haga una comparación legible entre el código recibido y el contenido final, con la fecha y las condiciones de prueba.
- Inspeccione los enlaces importantes. Un enlace HTML con HREF y un destino real se puede utilizar más directamente que una acción que solo cambia un estado interno sin URL.
- En el entorno de prueba, haga que falle un recurso necesario. Verifique el mensaje, la capacidad de volver a intentarlo y lo que sigue siendo accesible. No cause voluntariamente una avería en la producción para esta demostración.
- Primero corrija el defecto observado en esta plantilla, luego revise las otras páginas que la usan. Mida también el efecto sobre la velocidad y el mantenimiento antes de generalizar una nueva arquitectura.
El documento de Google en Enlaces explorables Proporciona ejemplos de enlaces interpretables. Para un proyecto de recuperación, esta prueba de aceptación se puede integrar en las especificaciones: esperamos una respuesta verificable, navegación y estado de error, no solo una captura de pantalla exitosa. El diagnóstico de Cerraduras de CDN Sigue siendo adicional si el contenido no llega al navegador o al robot.
Elija una corrección proporcionada
Puede ser relevante una representación o generación de páginas del lado del servidor, pero no siempre se requiere una migración completa. Comience con una plantilla representativa, mida el acceso, el rendimiento y la actualización fácil. Luego verifique metadatos y enlaces en ambas versiones. Los Reducción de javascript innecesario puede completar este trabajo sin confundir la velocidad y la indexabilidad.