¿Tu sitio web es realmente responsive? Cómo verificarlo en 10 minutos

Si tu sitio se ve bien en tu laptop pero el botón de “Comprar” se sale de la pantalla en el celular de tu cliente, no es responsive. Esto se prueba en 10 minutos con tres herramientas: DevTools del navegador, un celular real y una tablet. Acá te lo explicamos paso a paso.

Qué es responsive (y qué no es)

Un sitio responsive se adapta al ancho de la pantalla. El texto se relee bien, los botones siguen siendo tocables, las imágenes no se cortan y los menús funcionan tanto con dedo como con mouse.

Lo que NO es responsive:

• Sitio “mobile-friendly” que en realidad es una versión separada y vieja.
• Sitio que en celular muestra el desktop achicado y tenés que hacer zoom para leer.
• Sitio con texto que se ve, pero los formularios no se llenan porque los campos quedan fuera de pantalla.
• Sitio que carga rápido en tu fibra pero tarda 15 segundos en datos móviles.

Más del 60% del tráfico web en Costa Rica entra desde celular. Si tu sitio falla en mobile, le estás cerrando la puerta a la mayoría de tus clientes.

Los 5 anchos que sí importan

El internet tiene mil tamaños de pantalla, pero en la práctica importan cinco:

• 360-390px: celulares estándar (Samsung Galaxy A-series, iPhone SE, iPhone 12/13 mini). En Costa Rica los Samsung A dominan por precio.
• 414-430px: celulares grandes (iPhone Pro Max, Galaxy S Ultra).
• 768px: tablets en vertical (iPad estándar).
• 1024px: tablets en horizontal y laptops chicas.
• 1280-1440px: laptops y monitores normales.

¿Necesitás probar en 4K o pantallas ultrawide? No. Probá los cinco anchos de arriba y cubrís el 95% de tus usuarios reales.

Cómo probarlo en DevTools (5 minutos)

DevTools es el inspector que trae todo navegador. No necesitás saber código.

1. Abrí tu sitio en Chrome, Edge o Firefox.
2. Click derecho → “Inspeccionar”. O presioná F12.
3. Buscá el ícono de teléfono/tablet en la barra superior del panel que se abrió (en Chrome se llama “Toggle device toolbar”). O usá Ctrl+Shift+M.
4. Arriba del sitio vas a ver un menú con tamaños. Probá: iPhone SE, iPhone 12 Pro, iPad, iPad Pro.
5. Si tu sitio se ve mal en alguno, anotalo.

Mirá específicamente:

• ¿El menú funciona en celular (hamburguesa que se abre)?
• ¿Los botones se ven sin hacer zoom?
• ¿Las imágenes ocupan todo el ancho sin estirarse feo?
• ¿Hay scroll horizontal (señal mala)?
• ¿Los formularios se llenan sin que se descuadre el teclado?

DevTools simula bastante bien. No es perfecto, pero es el primer filtro.

Probarlo en celular real (3 minutos)

DevTools mente un poco. Probá en celular real, ojalá no en el tuyo. Pedile prestado el celular a alguien con un Samsung A o un iPhone normalito (no el Pro Max nuevo).

Abrí tu sitio. Mirá:

• ¿Cargó en menos de 3 segundos? Si tarda más, perdiste al 40% de los visitantes.
• ¿Pudiste hacer la acción principal (comprar, llenar formulario, llamar al WhatsApp) sin pelear?
• ¿Los textos se leen sin entrecerrar los ojos?
• ¿Los enlaces se tocan bien? Si tenés que hacer zoom para acertarle a un botón, está mal.

Esto es la prueba más honesta. Lo que se ve en tu Mac Studio no es lo que ve tu cliente en el bus de camino a Heredia.

Probarlo en tablet (2 minutos)

Mucha gente se olvida de la tablet. En CR no es el dispositivo principal, pero un 5-10% de tus visitas vienen de ahí. Probá en iPad o tablet Android:

• En vertical: ¿el layout se ve raro, con espacios vacíos enormes?
• En horizontal: ¿se ve como desktop o como mobile estirado?
• ¿Los videos se reproducen bien?

Si no tenés tablet, DevTools cubre el caso aceptablemente.

BrowserStack para probar en serio

Si tu sitio es comercial y serio (e-commerce, SaaS, app web), no podés probar solo en lo que tenés en la oficina. BrowserStack y LambdaTest te permiten probar en cientos de dispositivos reales remotamente. Tarifas desde $30/mes.

Para un sitio chico no hace falta. Para algo que mueve plata, sí.

Errores típicos que vamos a encontrar

Después de auditar cientos de sitios en CR, esto sale 9 de 10 veces:

• Texto muy chiquito en celular: el cuerpo debería ser mínimo 16px. Si está en 12 o 14, no se lee.
• Botones que no se tocan: el área tocable debería ser mínimo 44x44px (Apple) o 48x48px (Google).
• Imágenes que rompen el layout: ancho fijo en px en vez de porcentaje produce scroll horizontal.
• Menús que no se abren: la hamburguesa que no responde al tap. Pasa seguido.
• Forms con campos cortados cuando el teclado se abre.
• Popups imposibles de cerrar: la X está fuera de pantalla o tiene 8px.
• Velocidad pésima: sitios de 5MB de imágenes sin optimizar.

Cuándo es momento de rediseñar vs parchar

Si tu sitio falla en 2-3 puntos de la lista, son parches. Un developer competente lo arregla en pocas horas.

Si falla en 6+ puntos, o el código fue hecho con un template viejo (típicamente WordPress con un theme de 2017 sin actualizar), un rediseño suele costar menos que andar parchando cada bug.

¿Cómo saber cuál es tu caso? Pedí una auditoría. Si el dev te dice “se arregla en una tarde”, parche. Si te dice “habría que migrar el theme y reescribir half del HTML”, rediseño.

Para más contexto sobre cómo se construye un sitio bien desde el inicio, mirá nuestra entrada de qué caracteriza al desarrollo web moderno. Y para entender la base, qué es el desarrollo web.

Auditoría gratis

Si querés que te corramos la auditoría completa (responsive, velocidad, SEO técnico, accesibilidad) y te digamos exactamente qué arreglar antes que te cueste ventas, escribinos por el formulario. Te entregamos un PDF con los hallazgos en 5 días hábiles. Sin compromiso.