Formato nuevo
Hacer que el sitio funcione en todos los tamaños de pantalla: por qué y cómo
La mayoría de las visitas llegan desde smartphones: la gente mira el catálogo en el teléfono y a menudo envía el lead desde ahí. Un sitio que «flota» o pide scroll horizontal pierde usuarios y señales de calidad para la búsqueda.
Abajo: qué significa encajar en el tamaño de pantalla, en qué se diferencia responsive de un m-site aparte, objetivos para negocio y SEO, el proceso y los checks. El layout como oficio es un artículo hermano; aquí el foco es la UX móvil.
Qué significa que el sitio funcione en móvil
Encajar en el tamaño de pantalla significa que layout y UI siguen legibles y usables en teléfono, tablet y desktop. Suele ser responsive: una URL, media queries CSS o una grid moderna, imágenes flexibles.
El objetivo no es «meterlo todo pequeñito» — es mantener el viaje: encontrar un servicio o producto → entender la oferta → llamar o enviar la solicitud sin pelear con el menú y el formulario.
Señales de un responsive sólido:
- sin scroll horizontal inútil
- texto legible sin zoom
- botones y enlaces fáciles de tocar
- menús y filtros que abren de forma predecible
- el mismo sentido de contenido que en desktop
Por qué importa para el negocio y el SEO
Comercio: parte del camino de compra empieza en móvil. Si la ficha de producto o el formulario son incómodos, el lead se va al competidor con UX decente.
La búsqueda lleva tiempo juzgando la experiencia móvil (mobile-first). Una página móvil lenta o rota duele más al crawl y al comportamiento que «una keyword más en el H1».
Objetivos del diseño responsive:
- no perder tráfico de teléfono
- mantener la conversión en pantalla pequeña
- simplificar el mantenimiento de una plantilla
- cumplir expectativas de indexación mobile-first
Responsive o una versión móvil aparte
Sitio responsive: una dirección; contenido y señales SEO no se multiplican. Una versión móvil aparte (a menudo `m.`) implica segunda plantilla y riesgo de deriva — copy distinto, noindex olvidado, cadenas de redirect.
Un m. aparte rara vez tiene sentido (legacy pesado, apps especiales). Para un proyecto nuevo y la mayoría de CMS, usa responsive más bloques más ligeros si hace falta — no un segundo sitio.
Responsive:
- una URL canónica
- analytics y goals más simples
- menos duplicados
- un solo ciclo de edición de contenido
m. aparte:
- hace falta unificar y redirects cuidadosos
- fácil deriva de contenido
- doble mantenimiento de plantillas
- más riesgo de errores SEO técnicos
Cómo construyen responsive los equipos en la práctica
Empieza por plantillas prioritarias: home, landings clave, catálogo, producto, carrito/formulario, blog. Fija breakpoints, rehace grid, tipografía, spacing, nav (un burger no es un vertedero de todo el menú desktop).
Imágenes — srcset/sizes, compresión, no cargues 4K de desktop en 360px. Tablas y bloques anchos — scroll del contenedor o una vista simplificada sin romper todo el layout.
Proceso típico:
- viewport y grid base
- menú móvil y header
- bloques de contenido y CTAs
- formularios y teléfono clicable
- media y fuentes
- regresión desktop tras los cambios
Beneficios de un responsive sólido
Un solo sitio es más fácil para marketing e ingeniería. Ads y SEO apuntan a las mismas URLs. Los usuarios no saltan entre una versión «completa» y una «lite» con precios distintos.
Para el equipo, menos sorpresas: editas la oferta una vez, revisas dos o tres anchos — no sincronizas dos instancias de CMS.
Qué ganas:
- conversión del tráfico móvil
- indexación predecible de un canónico
- menor coste de mantenimiento
- mejores Core Web Vitals cuando se optimiza el peso
Cómo probar en distintas pantallas
No te quedes en un iPhone del emulador. Revisa anchos de Android de gama media, landscape, redes reales (3G/LTE). Prueba toques, máscaras de input, CTAs sticky y si el chat tapa el botón de enviar.
Automatización: Lighthouse mobile, un crawler con user-agent móvil si hace falta, revisión de screenshots de URLs clave tras el release. Tras cambiar el theme del CMS — otra pasada completa de plantillas.
Checklist de aceptación:
- home / categoría / producto / formulario
- menú y búsqueda
- sin texto cortado ni solapamientos
- velocidad móvil aceptable
- enlaces legales y consentimientos tocables
- retargeting/chat no rompen la UX
FAQ
¿Diseño responsive y versión móvil son lo mismo?
No siempre. Responsive es una URL y un markup que se ajusta al ancho. Una «versión móvil» a menudo es un subdominio o plantilla aparte (m.) — hoy menos a menudo la estrategia por defecto.
¿Es obligatorio el meta viewport?
Sí para un escalado normal en el teléfono: meta viewport en `<head>`. Sin él la página suele renderizarse como una miniatura de desktop.
¿El diseño responsive afecta al SEO?
Sí — de forma indirecta y fuerte: usabilidad, velocidad, bounce, indexación mobile-first. Una vista móvil rota arriesga visibilidad y conversión.
¿Basta encoger el layout de desktop en CSS?
No. Hace falta prioridad de contenido, targets táctiles grandes, tipografía legible, formularios usables y a veces otro orden de bloques.
¿Necesito AMP?
No es obligatorio para la mayoría de sitios comerciales. Primero deja bien responsive y velocidad; AMP es una elección aparte para casos estrechos.
¿Cómo compruebo el responsive rápido?
Modo dispositivo de DevTools más teléfonos reales, PageSpeed/Lighthouse mobile y un pase por plantillas clave (home, categoría, producto, formulario).
¿Todavía se construye un m.site aparte?
A veces en setups legacy. Inconvenientes: URLs duplicadas, redirects, deriva de contenido. Prefiere responsive en un canónico.
¿Responsive significa un sitio rápido?
No automáticamente. Imágenes y scripts pesados matan la UX móvil aunque la grid esté limpia. Comprime media y corta el exceso.
¿Desktop se ve bien — y el formulario del teléfono pide scroll horizontal?
Arreglamos viewport, targets táctiles y plantillas clave — una URL responsive, no un segundo m.site.
Hablar del proyecto
