Idiomas

Diseño web adaptable

Qué es el diseño adaptable, por qué Google lo recomienda sobre la entrega dinámica o las URL móviles separadas, cómo la etiqueta meta viewport lo hace funcionar y el mito del ranking.

Publicado por primera vez: 2 jul 2026 · Última actualización: 22 ago 2026 · Avanzado
Idiomas
AIEscrito porAI v2

El diseño web adaptable sirve el mismo HTML en la misma URL a cada dispositivo y utiliza consultas de medios CSS para adaptar el diseño al viewport. Es la configuración móvil recomendada por Google, no porque posicione mejor (no lo hace; Google lo ha dicho explícitamente) sino porque hay una sola URL y un solo conjunto de HTML para rastrear e indexar, lo que lo hace más fácil de implementar y mantener. Requiere una etiqueta meta viewport correcta para funcionar; sin ella, los teléfonos simulan un viewport de ancho de escritorio y tus consultas de medios nunca se activan. Contrasta con la entrega dinámica (misma URL, diferente HTML mediante un encabezado Vary) y las URL separadas (m-dot). El diseño adaptable no es automáticamente rápido: la adaptación del diseño no es rendimiento, por lo que los Core Web Vitals aún requieren atención por separado.

TL;DR — El diseño web responsive sirve el mismo HTML en la misma URL a todos los dispositivos y usa media queries CSS para adaptar el diseño al viewport. Google lo recomienda como “the easiest design pattern to implement and maintain” (traducción) «el patrón de diseño más fácil de implementar y mantener», pero afirma expresamente que no lo posiciona por encima del servicio dinámico ni de las URLs separadas. Su ventaja real es operativa: una URL y un único HTML hacen automática la paridad del contenido, y la propia lista de comprobación de Google para la indexación mobile-first “only applies to dynamic serving and separate URL configurations.” (traducción) «solo se aplica a configuraciones de servicio dinámico y URLs separadas». Requiere una metaetiqueta viewport correcta: sin ella, los teléfonos presuponen un viewport de escritorio — 980px en iOS y 800px en Android antiguo — y las media queries nunca se activan. En contraste, el servicio dinámico usa la misma URL con HTML distinto mediante Vary: User-Agent, y las URLs separadas usan una versión m-dot. Responsive controla el diseño, no la velocidad: un sitio responsive aún puede fallar en Core Web Vitals.

Evidence for this claim Responsive design differs from dynamic serving, which changes HTML by user agent at one URL, and separate mobile URLs, which use distinct URLs. Scope: mobile and desktop rendered web documents Confidence: high · Verified: Mobile-first indexing best practices Evidence for this claim Responsive design serves the same HTML at the same URL while CSS adapts display to screen size. Scope: Google definition of responsive web design. Confidence: high · Verified: Google Search Central: Responsive design Evidence for this claim Google recommends responsive design because it is the easiest mobile pattern to implement and maintain. Scope: Google configuration recommendation. Confidence: high · Verified: Google Search Central: Mobile configurations

La definición, precisamente

Las propias palabras de Google: el diseño responsive “sirve el mismo código HTML en la misma URL independientemente del dispositivo del usuario (por ejemplo, escritorio, tableta, móvil, navegador no visual), pero puede mostrar el contenido de manera diferente según el tamaño de la pantalla.” Esa frase contiene toda la idea:

  • Mismo HTML — un solo payload de marcado, no uno específico por dispositivo.
  • Misma URL — sin redirección a m.example.com, sin bifurcación por user-agent.
  • Se muestra de manera diferente según el tamaño de la pantalla — mediante media queries de CSS.

Esa es la línea que lo separa de las otras dos configuraciones que Google documenta. Dynamic serving “usa la misma URL independientemente del dispositivo… se basa en la detección de user-agent y en la cabecera de respuesta HTTP Vary: user-agent para servir una versión diferente del HTML a diferentes dispositivos.” URLs separadas “sirven HTML diferente a cada dispositivo, y en URLs separadas,” redirigiendo a los usuarios a la versión apropiada para el dispositivo. El diseño responsive es la única de las tres con una única fuente de HTML.

Evidence for this claim Responsive design differs from dynamic serving, which changes HTML by user agent at one URL, and separate mobile URLs, which use distinct URLs. Scope: mobile and desktop rendered web documents Confidence: high · Verified: Mobile-first indexing best practices

Por qué Google lo recomienda: simplicidad, no una ventaja de ranking

Google es directo: “recomienda el Diseño Web Responsive porque es el patrón de diseño más fácil de implementar y mantener.” Observa qué es y qué no es esa razón: es un argumento operativo (un solo código base, menos piezas móviles), no un argumento de ranking.

Evidence for this claim Google recommends responsive design because it is the easiest mobile pattern to implement and maintain. Scope: Google configuration recommendation. Confidence: high · Verified: Google Search Central: Mobile configurations

La frase más útil — y menos aprovechada — del documento de buenas prácticas de Google para mobile-first es esta nota de alcance: “The contents of this guide only apply to dynamic serving and separate URL configurations. In case of responsive design, the content and the metadata are the same on the mobile and desktop version of the pages.” (traducción) «El contenido de esta guía solo se aplica al servicio dinámico y a las configuraciones con URLs separadas. En el diseño responsive, el contenido y los metadatos son los mismos en las versiones móvil y de escritorio». Conviene releerla: Google indica que gran parte de su lista mobile-first — igualar datos estructurados, metaetiquetas robots y textos alternativos entre versiones, configurar cabeceras Vary y enlazar anotaciones rel=alternate/canonical — no se aplica a un sitio responsive, porque solo existe una versión que mantener. Ese es el argumento práctico más sólido a favor de RWD y casi nunca se formula así.

Los beneficios colaterales derivan todos de “una URL, un HTML”:

  • Sin riesgo de contenido duplicado o de paridad entre example.com/page y m.example.com/page — no hay nada que pueda divergir.
  • Sin fragilidad de Vary: User-Agent como la que conlleva el dynamic serving (una caché que ignore la cabecera puede servir el HTML equivocado al dispositivo equivocado — o a Googlebot).
  • Sin cadenas de redirección ni división de link equity entre URLs de escritorio y móviles.
  • Sin maquinaria de anotaciones (rel=alternate en escritorio, rel=canonical en móvil) que mantener y en la que equivocarse.

Esto es exactamente por lo que, en mi guía de Ahrefs sobre la indexación mobile-first, “usa diseño responsive” es el primer de los diez consejos para crear un sitio adaptado a móviles: elimina categorías enteras de problemas antes de que empiecen.

¿El diseño responsive mejora directamente el ranking? No.

Este es el mito que hay que desmentir pronto. Zineb Ait Bahajji, de Google, lo dijo claramente: Google no posiciona mejor los sitios con diseño responsive que los sitios que usan otras configuraciones (sitios móviles separados o dynamic serving). Google sigue prefiriendo el RWD — porque es más fácil de mantener, es más preparado para el futuro y ven menos errores de configuración con él — pero “menos errores” no es lo mismo que “una bonificación de ranking”. Un sitio con dynamic serving o m-dot bien implementado que mantenga la paridad puede posicionarse igual; el riesgo con esos es que deriven, y la deriva es lo que te perjudica.

Así que el planteamiento honesto: el diseño responsive no te hace ganar rankings. Te evita perderlos por un error de paridad, y te ahorra tiempo de mantenimiento. Ambas cosas valen mucho — ninguna es un impulso algorítmico.

Cómo funciona: la metaetiqueta viewport es un requisito previo, no un lujo

La mayoría de las guías enumeran la etiqueta meta viewport como una viñeta más entre muchos consejos de CSS. No es un consejo: es lo que hace que el diseño responsive funcione en absoluto. La publicación de 2012 de Google Search Central que explica por qué Google mismo se volvió responsive es contundente al respecto: “By default, smartphone browsers pretend to be high-resolution desktop browsers, and lay out a page as if you were viewing it on a desktop monitor… The default viewport width for the default Android browser is 800px, and 980px for iOS, regardless of the number of actual physical pixels on the screen.” (traducción) «Por defecto, los navegadores de teléfonos inteligentes fingen ser navegadores de escritorio de alta resolución y maquetan una página como si la estuvieras viendo en un monitor de escritorio… El ancho de viewport predeterminado para el navegador Android predeterminado es de 800px, y de 980px para iOS, independientemente del número de píxeles físicos reales en la pantalla.»

Ese es el fallo: sin una etiqueta viewport, el teléfono renderiza la página en un lienzo de 980px y después reduce todo para que quepa; aparecen texto diminuto, “modo de vista general” y una media query max-width: 479px que nunca se activa porque el navegador cree que el ancho es de 980px. La solución es una sola línea: “In order to trigger the browser to render your page at a more readable scale, you need to use the viewport meta element: <meta name="viewport" content="width=device-width, initial-scale=1">.” (traducción) «Para que el navegador renderice la página a una escala más legible, debes usar el elemento meta viewport: <meta name=“viewport” content=“width=device-width, initial-scale=1”>». Establecer width=device-width también actualiza el diseño cuando el usuario gira el dispositivo, lo que permite que las media queries respondan a la orientación. Los detalles — initial-scale y las trampas de accesibilidad de user-scalable/maximum-scale — se explican en el artículo dedicado a la metaetiqueta viewport.

Cómo funciona: consultas de medios CSS

Con el viewport configurado correctamente, el diseño se adapta con consultas de medios CSS — reglas que se aplican solo a ciertos anchos de viewport:

<style>
/* Base styles apply everywhere */
@media screen and (max-width: 479px) {
  /* Portrait smartphones: stack columns, hide the sidebar, grow tap targets */
}
@media screen and (min-width: 480px) and (max-width: 1024px) {
  /* Tablets */
}
</style>

Trata los valores de píxel anteriores como ilustrativos, no como una lista de verificación para copiar. La práctica duradera — reflejada en la referencia de consultas de medios de MDN y en el curso de diseño responsive de web.dev — es tratar los breakpoints como una decisión de diseño, no como una lista de dispositivos: establécelos donde tu propio contenido realmente se rompe (una navegación se envuelve mal, las columnas se vuelven demasiado estrechas, el texto se corta en líneas cortas) y prueba también los rangos entre breakpoints, no solo un puñado de tamaños de pantalla con nombre. Los anchos de viewport de los dispositivos cambian cada ciclo de producto; los breakpoints basados en contenido no necesitan actualizarse cuando eso ocurre.

La publicación de 2012 de Google también señaló la disciplina CSS que evita que un diseño responsive se rompa: “Instead of specifying width for container elements, we started using max-width instead. In place of height we used min-height, so larger fonts or multi-line text don’t break the container’s boundaries.” (traducción) «En lugar de especificar width para elementos contenedores, empezamos a usar max-width. En lugar de height usamos min-height, para que las fuentes más grandes o el texto multilínea no rompan los límites del contenedor.» Sus tres principios rectores eran igualmente simples: las páginas deberían renderizarse legiblemente en cualquier resolución, un conjunto de contenido debería ser visible en cualquier dispositivo, y deberías “never show a horizontal scrollbar, whatever the window size.” (traducción) «nunca mostrar una barra de desplazamiento horizontal, sea cual sea el tamaño de la ventana.» Los refinamientos modernos (clamp() para tipografía fluida, consultas de contenedor, srcset/<picture> para imágenes apropiadas al dispositivo) se asientan sobre esa base — no son necesarios para ser “verdaderamente” responsive. Para profundidad de implementación más allá del marco SEO, el propio curso de diseño responsive de web.dev de Google es el lugar al que acudir.

Responsive vs. servicio dinámico vs. URLs separadas

Las tres configuraciones que Google documenta, lado a lado:

Diseño responsiveServicio dinámicoURLs separadas (m-dot)
URLUna URLUna URLURLs diferentes (m.example.com)
HTMLMismo HTML para todosHTML diferente por dispositivoHTML diferente por dispositivo
Cómo se adaptaConsultas de medios CSSDetección de user-agent del servidorRedirección al sitio específico del dispositivo
Requisito adicionalEtiqueta meta viewportCabecera Vary: User-Agentrel=alternate + rel=canonical, hreflang entre versiones
Riesgo de paridadBajo — una versiónMedio — fácil de desviarAlto — dos sitios que sincronizar
Postura de GoogleRecomendadoCompatibleCompatible, menos recomendado

El servicio dinámico todavía tiene sentido ocasionalmente (p. ej., experiencias de dispositivo radicalmente diferentes que una sola plantilla no puede expresar razonablemente); las URLs separadas son en su mayoría legado hoy en día. Si estás en cualquiera de los dos, los análisis completos —incluidos los mecanismos del encabezado Vary para el servicio dinámico— están en el artículo sobre servicio dinámico. Pero para un proyecto desde cero, el diseño responsive es la respuesta por defecto, y la carga de la prueba recae en elegir cualquier otra cosa.

El enfoque de Bing: criterios, no arquitectura

Bing coincide con el resultado, pero lo presenta de otra manera. No recomienda “Responsive Web Design” por su nombre como Google; su prueba de compatibilidad móvil evalúa criterios comprobables: configuración del viewport y del zoom, ancho del contenido, legibilidad del texto, separación entre enlaces y otros objetivos táctiles, y uso de complementos incompatibles. Recomienda la misma etiqueta viewport que Google y establece que “the content width should not exceed the screen width” (traducción) «el ancho del contenido no debe superar el ancho de la pantalla»; el desbordamiento se marca como “Page content does not fit device width.” (traducción) «El contenido de la página no cabe en el ancho del dispositivo». Por tanto, Bing y Google favorecen un renderizado apto para móviles, pero la formulación explícita de configuración recomendada debe atribuirse específicamente a Google.

Diseño responsive e indexación mobile-first (después de julio de 2024)

La indexación mobile-first está completa: Google terminó el despliegue y ahora usa la versión rastreada para móviles de tu página para indexar y clasificar por defecto. Casi todas las guías todavía escriben sobre el diseño responsive como un movimiento en tiempo futuro de “prepárate para la indexación mobile-first”. Ese marco está desactualizado. El despliegue está completo y, para un sitio ya responsive, no cambia nada: tu contenido y metadatos ya son idénticos en móvil y escritorio porque hay una sola versión. Eso no es una coincidencia; es el punto principal. El artículo sobre indexación mobile-first del sitio cubre la cronología y las reglas de paridad en detalle.

Responsive ≠ automáticamente rápido

La trampa más grande. El diseño responsive controla el layout, no el rendimiento. Un sitio responsive puede seguir enviando una imagen hero de escritorio de 3 MB que los teléfonos solo reducen en CSS, o enviar JavaScript de peso de escritorio a un dispositivo móvil — y fallar LCP o CLS gravemente. “Responsive” no es un aprobado de Core Web Vitals. Optimizar de verdad significa servir activos de tamaño adecuado por breakpoint (para eso están srcset/<picture> y las imágenes responsive), no solo dejar que el CSS encoja los sobredimensionados. Arregla el rendimiento por separado: consulta el contenido de Core Web Vitals y el material de imágenes responsive para saber cómo.

El rendimiento no es la única suposición que no se cumple automáticamente. Un solo codebase no garantiza una renderización, accesibilidad o presentación en resultados de búsqueda idénticas tampoco: los navegadores y dispositivos todavía difieren lo suficiente en cómo manejan CSS, fuentes y layout dependiente de JavaScript que las pruebas entre dispositivos y navegadores siguen siendo parte del trabajo, igual que en cualquier otra configuración. “Responsive” describe una arquitectura, no un resultado verificado; pruébalo como probarías cualquier otra cosa.

Un poco de historia

Merece un párrafo porque cambia el marco de toda la “buena práctica”. Google no recomendó primero el diseño responsive y lo adoptó después: empezó por aplicarlo en sus propias propiedades por motivos de ingeniería, y luego llegó la recomendación. Su publicación de 2012 explica que Google “faced a stark choice between creating mobile specific websites, or adapting existing sites… Creating two sites would allow us to better target specific hardware, but maintaining a single shared site preserves a canonical URL, avoiding any complicated redirects, and simplifies the sharing of web addresses.” (traducción) «se enfrentó a la clara disyuntiva de crear sitios específicos para móviles o adaptar los existentes… Dos sitios permitirían dirigirse mejor a hardware concreto, pero mantener un único sitio compartido conserva una URL principal, evita redirecciones complicadas y simplifica compartir direcciones web». Conservar la URL principal, evitar la complejidad de redirecciones y facilitar el uso compartido fueron los motivos antes de que se llamara buena práctica SEO, y siguen siéndolo.

Dónde encaja esto en el panorama general: el diseño responsive es una pieza de la historia más amplia del SEO móvil, junto con la usabilidad móvil, los intersticiales intrusivos, la historia de AMP y la lista de verificación de SEO móvil que los une. Este artículo es la pieza de “¿cómo debería servir mi sitio en móvil?”; los demás cubren el resto.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.