Idiomas

Design responsivo

O que é design responsivo, por que o Google o recomenda em vez de servir dinamicamente ou usar URLs móveis separadas, como a meta tag viewport faz isso funcionar e o mito do ranqueamento.

Publicado pela primeira vez: 2 de jul. de 2026 · Última atualização: 22 de ago. de 2026 · Avançado
Idiomas
AIEscrito porAI v2

O design responsivo serve o mesmo HTML na mesma URL para todos os dispositivos e usa media queries CSS para adaptar o layout à viewport. É a configuração móvel recomendada pelo Google — não porque ranqueia melhor (não ranqueia; o Google já disse isso claramente), mas porque há uma única URL e um único conjunto de HTML para rastrear e indexar, o que o torna o mais fácil de implementar e manter. Requer uma meta tag viewport correta para funcionar — sem ela, os celulares simulam uma viewport de largura de desktop e suas media queries nunca são acionadas. Ele contrasta com a entrega dinâmica (mesma URL, HTML diferente via cabeçalho Vary) e URLs separadas (m-dot). Responsivo não é automaticamente rápido: a adaptação de layout não é desempenho, então os Core Web Vitals ainda precisam de atenção separada.

TL;DR — O web design responsivo serve o mesmo HTML na mesma URL para todos os dispositivos e usa media queries CSS para adaptar o layout ao viewport. O Google recomenda — “the easiest design pattern to implement and maintain” (tradução) «o padrão de design mais fácil de implementar e manter» — mas explicitamente não o ranqueia acima da entrega dinâmica ou URLs separadas. Sua vantagem real é operacional: uma URL, um conjunto de HTML, então a paridade de conteúdo é automática e a própria lista de verificação de indexação mobile-first do Google “only applies to dynamic serving and separate URL configurations.” (tradução) «aplica-se apenas às configurações de entrega dinâmica e URLs separadas». Requer uma meta tag viewport correta para funcionar — sem ela, os celulares assumem um viewport de largura de desktop (980px iOS / 800px Android antigo) e suas media queries nunca disparam. Contraste: entrega dinâmica (mesma URL, HTML diferente via Vary: User-Agent) e URLs separadas (m-dot). O responsivo controla o layout, não a velocidade — um site responsivo ainda pode falhar no 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

A definição, precisamente

As palavras do próprio Google: design responsivo “serve the same HTML code on the same URL regardless of the users’ device (for example, desktop, tablet, mobile, non-visual browser), but can display the content differently based on the screen size.” (tradução) «serve o mesmo código HTML no mesmo URL, independentemente do dispositivo dos usuários (por exemplo, desktop, tablet, celular, navegador não visual), mas pode exibir o conteúdo de forma diferente com base no tamanho da tela.» Essa frase contém a ideia completa:

  • Mesmo HTML — um único payload de marcação, não um específico por dispositivo.
  • Mesmo URL — sem redirecionamento para m.example.com, sem bifurcação por user-agent.
  • Exibido de forma diferente pelo tamanho da tela — via media queries de CSS.

Essa é a linha que o separa das outras duas configurações que o Google documenta. Dynamic serving “uses the same URL regardless of device… relies on user-agent sniffing and the Vary: user-agent HTTP response header to serve a different version of the HTML to different devices.” (tradução) «usa o mesmo URL independentemente do dispositivo… depende da detecção de user-agent e do cabeçalho de resposta HTTP Vary: user-agent para servir uma versão diferente do HTML para diferentes dispositivos.» URLs separados “serves different HTML to each device, and on separate URLs,” (tradução) «serve HTML diferente para cada dispositivo, e em URLs separados,» redirecionando os usuários para a versão apropriada ao dispositivo. O responsivo é o único dos três com uma única fonte 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 que o Google o recomenda — simplicidade, não uma vantagem de ranqueamento

O Google é direto: ele “recommends Responsive Web Design because it’s the easiest design pattern to implement and maintain.” (tradução) «recomenda o Responsive Web Design porque é o padrão de design mais fácil de implementar e manter.» Observe o que esse motivo é e não é — é um argumento operacional (um codebase, menos partes móveis), não um argumento de ranqueamento.

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

A linha mais útil — e mais subutilizada — no documento de práticas recomendadas de mobile-first do Google é a nota de escopo: “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.” (tradução) «O conteúdo deste guia se aplica apenas a configurações de dynamic serving e URLs separados. No caso de design responsivo, o conteúdo e os metadados são os mesmos nas versões mobile e desktop das páginas.» Leia isso novamente. O Google está dizendo que a maior parte de sua longa lista de verificação de mobile-first — correspondência de dados estruturados entre versões, correspondência de meta tags robots, correspondência de texto alternativo, configuração de cabeçalhos Vary, configuração de anotações rel=alternate/canonical — simplesmente não se aplica a você se você for responsivo, porque há apenas uma versão para acertar. Esse é o caso prático mais forte para RWD, e quase ninguém o enquadra dessa forma.

Os benefícios indiretos fluem todos de “um URL, um HTML”:

  • Sem risco de conteúdo duplicado ou de paridade entre example.com/page e m.example.com/page — não há nada para divergir.
  • Sem fragilidade de Vary: User-Agent como o dynamic serving carrega (um cache que ignora o cabeçalho pode servir o HTML errado para o dispositivo errado — ou para o Googlebot).
  • Sem cadeias de redirecionamento ou divisão de link equity entre URLs de desktop e mobile.
  • Sem maquinário de anotações (rel=alternate no desktop, rel=canonical no mobile) para manter e errar.

É exatamente por isso que, no meu guia da Ahrefs sobre indexação mobile-first, “use responsive design” é a primeira das dez dicas para construir um site mobile-friendly — ele remove categorias inteiras de problemas antes que eles comecem.

O design responsivo melhora diretamente o ranqueamento? Não.

Este é o mito a matar cedo. A Zineb Ait Bahajji, do Google, foi direta: O Google não ranqueia sites com design responsivo melhor do que sites que usam outras configurações (sites mobile separados ou dynamic serving). O Google ainda prefere RWD — porque é mais fácil de manter, amigável ao futuro, e eles veem menos erros de configuração com ele — mas “menos erros” não é o mesmo que “um bônus de ranqueamento.” Um site com dynamic serving ou m-dot bem implementado que mantém paridade pode ranquear identicamente; o risco com esses é que eles divergem, e a divergência é o que prejudica você.

Então, o enquadramento honesto: o design responsivo não ganha ranqueamento para você. Ele o salva de perdê-los para um erro de paridade, e o salva de tempo de manutenção. Ambos valem muito — nenhum é um impulso de algoritmo.

Como funciona: a meta tag viewport é um pré-requisito, não um luxo

A maioria dos guias lista a meta tag viewport como apenas mais um item entre muitas dicas de CSS. Ela não é uma dica — é o que faz o design responsivo funcionar de fato. O post de 2012 do Google Search Central explicando por que o próprio Google se tornou responsivo é direto sobre o motivo: “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.” (tradução) «Por padrão, os navegadores de smartphones fingem ser navegadores de desktop de alta resolução e organizam a página como se você a estivesse vendo em um monitor de desktop… A largura padrão da viewport para o navegador Android padrão é 800px, e 980px para iOS, independentemente do número de pixels físicos reais na tela.»

Esse é o modo de falha: sem a tag de viewport, o telefone monta a página em uma área de 980px de largura e depois reduz tudo para fazê-la caber. O resultado é texto minúsculo, uma visão geral afastada e uma media query max-width: 479px que nunca é acionada, pois o navegador acredita que a área disponível tem 980px. A correção cabe em uma linha: “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">.” (tradução) «Para que o navegador apresente a página em uma escala mais legível, é preciso usar o elemento meta de viewport indicado.» Definir width=device-width também atualiza o layout quando a pessoa gira o aparelho, permitindo que as media queries respondam à orientação. Os detalhes de initial-scale e as armadilhas de acessibilidade de user-scalable e maximum-scale ficam no artigo dedicado à meta tag viewport.

Como funciona: media queries de CSS

Com a viewport configurada corretamente, o layout se adapta com media queries de CSS — regras que se aplicam apenas em certas larguras 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>

Trate os valores de pixel acima como ilustrativos, não como uma lista de verificação para copiar. A prática duradoura — ecoada na referência de media queries da MDN e no curso de design responsivo do web.dev — é tratar os breakpoints como uma decisão de layout, não como uma lista de dispositivos: defina-os onde seu próprio conteúdo realmente quebra (uma navegação que envolve mal, colunas que ficam estreitas demais, texto com linhas curtas) e teste também os intervalos entre os breakpoints, não apenas um punhado de tamanhos de tela nomeados. As larguras de viewport dos dispositivos mudam a cada ciclo de produto; breakpoints baseados em conteúdo não precisam de atualização quando isso acontece.

O post de 2012 do Google também destacou a disciplina de CSS que impede que um layout responsivo quebre: “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.” (tradução) «Em vez de especificar width para elementos de contêiner, começamos a usar max-width. No lugar de height, usamos min-height, para que fontes maiores ou texto de várias linhas não quebrem os limites do contêiner.» Seus três princípios orientadores eram igualmente simples: as páginas devem ser legíveis em qualquer resolução, um único conjunto de conteúdo deve ser visível em qualquer dispositivo, e você deve “never show a horizontal scrollbar, whatever the window size.” (tradução) «nunca mostrar uma barra de rolagem horizontal, seja qual for o tamanho da janela.» Refinamentos modernos (clamp() para tipografia fluida, container queries, srcset/<picture> para imagens adequadas ao dispositivo) ficam acima dessa base — não são necessários para ser “verdadeiramente” responsivo. Para profundidade de implementação além do enquadramento de SEO, o próprio curso Learn Responsive Design do web.dev do Google é o lugar certo.

Responsivo vs. dynamic serving vs. URLs separadas

As três configurações que o Google documenta, lado a lado:

Design responsivoEntrega dinâmicaURLs separadas (m-dot)
URLUma URLUma URLURLs diferentes (m.example.com)
HTMLO mesmo HTML para todosHTML diferente por dispositivoHTML diferente por dispositivo
Como se adaptaMedia queries de CSSDetecção do agente do usuário no servidorRedirecionamento para um site específico do dispositivo
Requisito adicionalMeta tag viewportCabeçalho Vary: User-Agentrel=alternate + rel=canonical, com hreflang entre as versões
Risco de disparidadeBaixo — uma versãoMédio — as versões podem divergirAlto — dois sites para sincronizar
Posição do GoogleRecomendadoCompatívelCompatível, mas menos recomendado

A entrega dinâmica ainda faz sentido ocasionalmente (por exemplo, experiências de dispositivo radicalmente diferentes que um único template não consegue expressar de forma razoável); URLs separadas são, em sua maioria, legado hoje em dia. Se você estiver em uma dessas abordagens, os mergulhos profundos completos — incluindo a mecânica do cabeçalho Vary para entrega dinâmica — estão no artigo sobre entrega dinâmica. Mas para um projeto novo, o design responsivo é a resposta padrão, e o ônus da prova está em escolher qualquer outra coisa.

O ângulo do Bing: critérios, não arquitetura

O Bing concorda com o resultado, mas o descreve de outra maneira. Em vez de endossar o “design responsivo” pelo nome, como o Google, seu teste de compatibilidade com dispositivos móveis avalia critérios verificáveis: configuração da viewport e dos controles de zoom, largura do conteúdo, legibilidade do texto, espaçamento de links e outros alvos de toque, além do uso de plug-ins incompatíveis. O Bing recomenda a mesma tag de viewport e estabelece que “the content width should not exceed the screen width” (tradução) «a largura do conteúdo não deve ultrapassar a largura da tela». Quando há transbordamento, a ferramenta informa “Page content does not fit device width.” (tradução) «O conteúdo da página não cabe na largura do dispositivo.» Portanto, Bing e Google favorecem uma apresentação adequada a dispositivos móveis; a linguagem explícita de configuração recomendada deve ser atribuída especificamente ao Google.

Design responsivo e indexação mobile-first (pós-julho de 2024)

A indexação mobile-first está concluída — o Google finalizou a implementação, e agora ele usa a versão rastreada por dispositivos móveis da sua página para indexação e ranqueamento por padrão. Quase todos os guias ainda escrevem sobre design responsivo como uma ação no futuro, “prepare-se para a indexação mobile-first”. Esse enquadramento está desatualizado. A implementação está completa, e para um site já responsivo ela não muda nada — seu conteúdo e metadados já são idênticos entre mobile e desktop porque há apenas uma versão. Isso não é coincidência; é exatamente o objetivo. O artigo do site sobre indexação mobile-first cobre a linha do tempo e as regras de paridade em detalhes.

Responsivo ≠ automaticamente rápido

A maior armadilha. O design responsivo controla o layout, não o desempenho. Um site responsivo ainda pode enviar uma imagem de herói de desktop de 3 MB que os celulares apenas reduzem via CSS, ou enviar JavaScript pesado de desktop para um dispositivo móvel — e falhar feio no LCP ou no CLS. “Responsivo” não é um passe para os Core Web Vitals. Otimizar de verdade significa servir assets com tamanho adequado por breakpoint (é para isso que servem srcset/<picture> e imagens responsivas), não apenas deixar o CSS encolher imagens superdimensionadas. Corrija o desempenho separadamente — veja o conteúdo sobre Core Web Vitals e o material sobre imagens responsivas para saber como.

O desempenho não é a única suposição que não se sustenta automaticamente. Um único codebase também não garante renderização idêntica, acessibilidade ou apresentação nos resultados de busca — navegadores e dispositivos ainda diferem o suficiente em como lidam com CSS, fontes e layout dependente de JavaScript, então o teste entre dispositivos e navegadores continua fazendo parte do trabalho, assim como seria em qualquer outra configuração. “Responsivo” descreve uma arquitetura, não um resultado verificado; teste como você testaria qualquer outra coisa.

Um pouco de história

Vale reservar um parágrafo para isso, pois a história muda a leitura da “melhor prática”. O Google não recomendou primeiro o design responsivo para só depois adotá-lo: suas próprias propriedades se tornaram responsivas por razões de engenharia, e a recomendação veio em seguida. O post de 2012 explica que a empresa “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.” (tradução) «enfrentou uma escolha difícil entre criar sites específicos para dispositivos móveis ou adaptar os sites existentes… Criar dois sites permitiria direcionar melhor determinados equipamentos, mas manter um único site compartilhado preserva uma URL preferencial, evita redirecionamentos complicados e simplifica o compartilhamento de endereços da web.» Preservar a URL preferencial, eliminar a complexidade dos redirecionamentos e simplificar o compartilhamento já eram as razões antes que alguém chamasse a abordagem de melhor prática de SEO — e continuam sendo.

Onde isso se encaixa no panorama geral: o design responsivo é uma peça da história mais ampla de SEO para dispositivos móveis, ao lado da usabilidade móvel, dos intersticiais intrusivos, do histórico do AMP e do checklist de SEO para dispositivos móveis que amarra tudo isso. Este artigo é a peça “como devo servir conteúdo para dispositivos móveis?”; os outros cobrem o restante.

Add an expert note

Pin an expert quote

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