Que una página se visualice correctamente en un ordenador, pero en un móvil la tabla de especificaciones del producto se desborde y el botón de consulta quede oculto, no suele ser un problema de «si existe una versión móvil», sino de que la plantilla, el contenido y las interacciones no se han adaptado conjuntamente. Para evaluar el comportamiento adaptable de un sistema SaaS global de creación de sitios web, no basta con revisar las vistas previas del panel de administración. La aceptación debe realizarse con páginas reales del negocio y combinar cambios graduales de tamaño, pruebas en dispositivos reales, cambio de idioma y el recorrido completo de conversión.
El criterio fundamental es comprobar si, en distintos tamaños de ventana, el contenido se puede leer íntegramente, las acciones clave funcionan y los usuarios pueden completar sus tareas. Al elegir un sistema, solicite al proveedor un entorno de prueba editable y publicable, en lugar de aceptar una página de inicio de demostración seleccionada para la ocasión.
Las páginas de prueba deben incluir, como mínimo, la página de inicio, el listado de productos, la página de detalles del producto y la página de consulta o de pago. En cada tipo de página, introduzca contenido similar al que se publicará: nombres de productos largos, tablas de especificaciones reales, varias imágenes y formularios con campos obligatorios. Que una plantilla vacía se adapte automáticamente no significa que siga funcionando correctamente cuando se introduce contenido real del negocio.
Al crear la matriz de pruebas, puede tomar como referencia anchos de ventana de 320, 375, 768, 1024 y 1440 píxeles CSS, y añadir otras medidas según los dispositivos que utilicen los clientes objetivo. Estos son solo valores de prueba, no puntos de ruptura obligatorios para el diseño. Registre también el nivel de zoom del navegador, el tamaño de fuente del sistema y la orientación de la pantalla para que los problemas puedan reproducirse.
Abra las herramientas para desarrolladores del navegador y cambie lentamente el ancho de la ventana para observar cómo pasa el diseño de varias columnas a una sola. Lo importante no es cuántos puntos de ruptura hay, sino si entre ellos se comprime el texto, se superponen las tarjetas, la navegación salta a otra línea o los botones desaparecen de repente. Cuando detecte una anomalía, anote el ancho en el que se produce y ajústelo repetidamente en valores cercanos.
Por ejemplo, antes de que el listado de productos pase de cuatro columnas a dos, puede que las tarjetas ya sean demasiado estrechas para mostrar los botones completos. En ese caso, ajuste el ancho de las columnas o las condiciones de cambio, en lugar de limitarse a reducir el tamaño de fuente. Limitar la altura de las tarjetas con un valor fijo también puede truncar títulos largos o textos traducidos.

Compruebe también que la página utilice la configuración correcta de viewport y que no se intente ocultar un defecto de adaptación desactivando el zoom. Al ampliar el texto, el contenido debe reorganizarse; no debe perderse por culpa de la altura fija de un contenedor.
Uno de los aspectos que más se pasan por alto en las pruebas móviles es el estado de la página cuando aparece el teclado en pantalla. Abra el formulario de consulta, introduzca los datos campo por campo, active la validación, corrija los errores y envíelo. Compruebe que el campo activo y los mensajes de error sigan visibles y que el botón fijo de la parte inferior no oculte ningún campo. Realice las pruebas con el método de recepción acordado y confirme que el mensaje de envío correcto coincide con la recepción real.
La navegación no debe depender exclusivamente de pasar el ratón por encima; los menús desplegables, el cambio de idioma y los filtros también deben admitir el uso táctil. Deje suficiente espacio entre botones contiguos y compruebe en dispositivos reales que no sea fácil pulsar el botón equivocado. En ordenadores, compruebe también con el teclado el orden del foco y que, al cerrar una ventana emergente, el foco vuelva a una posición lógica.
En una tienda transfronteriza, complete también el proceso de selección de variantes, modificación del carrito y pago. En un sitio B2B, compruebe especialmente la carga de archivos adjuntos, el envío de consultas y las vías de contacto. Pruebe con las funciones de atención al cliente de terceros, los avisos de cookies y las ventanas promocionales activados a la vez: que funcionen por separado no significa que sigan funcionando al combinarse.
En un sitio global no basta con validar el idioma predeterminado. Elija traducciones largas que realmente tenga previsto publicar y compruebe si los menús, los botones y los títulos de los productos desbordan sus contenedores. Para idiomas escritos de derecha a izquierda, como el árabe, revise también la dirección de lectura, la posición de los iconos y la combinación de números y texto, en lugar de limitarse a alinear el texto a la derecha.
Las pruebas deben incluir páginas ya publicadas. La vista previa del panel de administración no suele reflejar por completo los efectos de la caché, el procesamiento de imágenes y los scripts de terceros. Tras limitar la velocidad de la red y volver a cargar la página, observe si el contenido se desplaza de forma notable cuando aparecen las imágenes, las fuentes y las ventanas emergentes, y si se mueve el botón que el usuario iba a pulsar.
Las imágenes deben adaptarse correctamente al tamaño del contenedor y cargarse en las dimensiones adecuadas cuando sea necesario. Puede consultar LCP, CLS e INP con herramientas de rendimiento, pero no considere la puntuación de una única prueba de laboratorio como conclusión definitiva. Si todavía no se dispone de datos de visitas reales, especifique las condiciones de la prueba y siga validando la experiencia real después del lanzamiento.
Cuando detecte un problema, pida al proveedor que indique si corresponde a la plantilla, a la configuración del contenido, al código personalizado o a un componente de terceros, y que demuestre cómo lo soluciona. Responder simplemente «es compatible con el diseño adaptable» no permite evaluar nada. Compruebe si el personal de edición habitual puede ajustar el diseño móvil, si los cambios afectan a otros idiomas y si las actualizaciones de la plantilla sobrescriben los ajustes existentes.
El registro de aceptación debe conservar la dirección de la página, la versión, el idioma, el dispositivo, el tamaño de la ventana, los pasos para reproducir el problema y las capturas de pantalla. La imposibilidad de enviar una consulta, la falta de visibilidad del contenido esencial y la imposibilidad de cerrar la navegación deben considerarse impedimentos para el lanzamiento. Los espacios en blanco localizados o los saltos de línea no esenciales pueden tratarse por separado, pero deben acordarse las personas responsables y el alcance de la nueva verificación.
Por último, cambie un título de producto o una tabla de especificaciones en el entorno de prueba y vuelva a publicar la página para repetir las pruebas. Si una actualización normal del contenido obliga a añadir estilos página por página, significa que las reglas de adaptación aún dependen del mantenimiento manual. Esto refleja mejor el coste de mantenimiento del sistema a largo plazo que el aspecto cuidado de una página de demostración.
Artículos relacionados
Productos relacionados


