A confusão que este post desfaz
A versão antiga deste artigo trocava as duas definições — e vale corrigir isso de forma explícita, porque o erro é comum e muda a decisão de quem contrata. Ela dizia que o site responsivo é aquele que "fica cada vez menor para que o zoom possa ser realizado". Não é: uma página que encolhe inteira e obriga o visitante a dar zoom e arrastar para ler é exatamente um site NÃO responsivo, um layout de computador que o celular está apenas espremendo. E dizia que o site mobile é o que "se adapta a quaisquer tipos de telas" — isso, sim, é a definição de responsivo. Tanto que, três parágrafos depois, o texto antigo listava "design responsivo" como funcionalidade do site mobile e se contradizia sozinho.
A distinção correta é estrutural, não estética: o site responsivo é um site só; o site mobile são dois sites. Um tem uma URL e um código-fonte que se reorganizam conforme a largura da tela. O outro tem endereço próprio — o clássico m.seusite.com.br —, código próprio e, quase sempre, conteúdo reduzido.
As três formas de servir o celular
Aqui está o ponto que a comparação binária esconde: não existem duas opções, existem três. A documentação do Google para desenvolvedores descreve as mesmas três configurações há anos — design responsivo, dynamic serving e URLs separadas — e a diferença entre elas está em duas perguntas apenas: quantas URLs o mesmo conteúdo tem, e quantos códigos precisam ser mantidos.
- Design responsivo — 1 URL, 1 código. O mesmo HTML chega a todo mundo e o CSS decide como organizar;
- Dynamic serving — 1 URL, 2 códigos. O servidor identifica o aparelho e devolve um HTML diferente no mesmo endereço;
- URLs separadas (m.site) — 2 URLs, 2 códigos. Cada versão vive em um endereço, com redirecionamento por dispositivo.
Este post é sobre decidir, não sobre definir. Se o que você procura é a explicação da técnica em si — os três ingredientes, o mobile-first como filosofia de projeto —, ela está em o que é um site responsivo. E o critério de "estar adequado ao celular", que é outra coisa, está em o que é mobile friendly.
Comparativo: URL, código, manutenção e situação hoje
| Critério | Design responsivo | Dynamic serving | Site mobile (m.site) |
|---|---|---|---|
| URLs | Uma | Uma | Duas |
| Código-fonte | Um | Dois no servidor | Dois projetos |
| Como decide o formato | CSS, pela largura da tela | Servidor, pelo user-agent | Redirecionamento por dispositivo |
| Publicar um conteúdo novo | Uma vez | Duas vezes ou template duplo | Duas vezes, em dois sites |
| Exigência técnica extra | Nenhuma | Vary: User-Agent | rel="alternate" + rel="canonical" |
| Risco típico | Implementação preguiçosa | Aparelho novo não reconhecido | Conteúdo divergente entre versões |
| Compartilhar link | Sempre funciona | Sempre funciona | Link m. aberto no desktop |
| Situação hoje | Padrão recomendado | Legado aceitável | Em desuso; migrar |
Responsivo: uma URL, um código
No design responsivo o servidor entrega o mesmo HTML para o celular, o tablet e o computador. Quem muda o resultado é o CSS: grades que se recalculam, imagens que acompanham a largura disponível e pontos de quebra que reempilham os blocos verticalmente quando a tela estreita. O menu horizontal vira menu de toque, as três colunas viram uma, a tabela ganha rolagem própria.
A consequência prática que interessa a quem paga a conta é simples: você publica uma vez e vale em todos os aparelhos. Não existe "esqueci de atualizar a versão mobile", que é o defeito mais comum dos sites divididos. É por isso que essa é a configuração que o Google recomenda como padrão — e a razão declarada não é preferência estética, é que uma URL única facilita rastreamento, indexação e compartilhamento.
Dynamic serving: uma URL, dois códigos
No dynamic serving o endereço é o mesmo, mas o servidor lê o user-agent — a identificação que o navegador envia — e devolve um HTML diferente para celular e para computador. Do lado de fora parece responsivo, já que a URL não muda. Por dentro, são duas saídas mantidas em paralelo.
Funciona, e ainda existe em sistemas grandes que dependem de renderização no servidor. Mas carrega dois problemas herdados. O primeiro é técnico: como o mesmo endereço devolve conteúdos diferentes, o servidor precisa enviar o cabeçalho Vary: User-Agent, sem o qual caches e buscadores podem guardar a versão errada. O segundo é de manutenção: a detecção depende de uma lista de dispositivos que envelhece — aparelho novo, navegador novo ou user-agent atípico caem na versão errada, e o defeito só aparece quando alguém reclama.
Site mobile (m.site): duas URLs, dois códigos
É o modelo que a pergunta "responsivo ou mobile?" tem em mente. Nele existem literalmente dois sites: seusite.com.br e m.seusite.com.br. Quando um celular chega ao endereço principal, um redirecionamento o manda para o equivalente na versão móvel. Para o buscador não tratar as duas como conteúdo duplicado, cada página de desktop aponta para a móvel com rel="alternate", e cada página móvel aponta de volta com rel="canonical" — página por página, não uma vez só.
Esse desenho fazia sentido quando o celular tinha pouca banda e pouco processamento: era mais fácil construir uma versão enxuta separada do que fazer um layout único servir bem aos dois. A fama de "site mobile é mais rápido" nasceu aí — e é importante entender que a velocidade vinha do enxugamento, não da separação. Um site responsivo que serve a imagem no tamanho certo e carrega primeiro o que aparece na primeira tela chega ao mesmo resultado sem duplicar nada.
Por que o site mobile perdeu
Não foi moda. Foram cinco mudanças concretas, e cada uma pesa sozinha:
- Indexação mobile-first — o Google passou a usar a versão de celular como a versão principal para indexar e avaliar o site. Se o m.site tem menos conteúdo, menos links internos e menos dados estruturados que a versão de desktop, é a versão pobre que vira a referência;
- Força dividida entre dois endereços — links externos apontam ora para uma versão, ora para outra, e o pareamento precisa estar impecável para consolidar os sinais. Basta uma página sem
canonicalcorreto para dividir a autoridade; - Manutenção dobrada — toda alteração precisa ser feita duas vezes. Na prática, uma das versões atrasa, e é sempre a móvel — justamente a que o buscador enxerga primeiro;
- Cadeias de redirecionamento — cada acesso pelo celular passa por um salto extra antes de a página abrir, e quando os redirects apontam para lugares errados o visitante cai na home em vez da página que pediu;
- Link fora de contexto — alguém compartilha no WhatsApp uma URL
m.que outra pessoa abre no computador, e o resultado é uma versão espremida e sem os recursos completos.
Somados, esses cinco pontos explicam a recomendação atual: para um projeto novo, responsivo; para um m.site existente, plano de migração.
"Manter duas versões do site não é ter o dobro de cuidado com o celular — é ter o dobro de chances de esquecer dele."
Três testes de 1 minuto para saber qual você tem
- Olhe a URL no celular. Abra o site pelo telefone e confira o endereço na barra do navegador. Se ele passou a começar com
m.ou ganhou/mobile, você tem duas URLs — logo, um site mobile separado; - Arraste a janela no computador. Com o site aberto, puxe a borda da janela reduzindo a largura devagar. Se o layout se reorganiza sozinho — colunas viram uma, o menu vira ícone, o texto continua legível —, é responsivo. Se tudo apenas encolhe até virar miniatura, não é;
- Compare o conteúdo das duas telas. Abra a mesma página no celular e no computador e confira se o texto, as seções e os links são os mesmos. Conteúdo faltando no celular é o sintoma clássico de versões separadas — e o problema mais caro delas.
Migrar de m.site para responsivo em 7 passos
Migração mal feita derruba tráfego. Feita na ordem, é rotina:
- Mapeie os pares de URL — planilha com cada endereço
m.e sua correspondente no site principal. Sem esse mapa, não há migração segura; - Reconcilie o conteúdo — se a versão móvel tem textos, campos ou páginas que a de desktop não tem, decida o que entra na versão única antes de publicar;
- Publique a versão responsiva no domínio principal e valide em telas de vários tamanhos, com atenção ao que só existia no m.site;
- Aplique redirecionamentos 301 um a um, de cada URL móvel para a página equivalente — nunca redirecione tudo para a home. Redirecionamento em massa para a home descarta o histórico de cada página;
- Remova o pareamento antigo — as tags
rel="alternate"das páginas de desktop e oscanonicalapontando para o m.site, além da regra de redirecionamento por dispositivo; - Atualize sitemap, links internos e destinos de campanha, incluindo materiais, anúncios e perfis que apontem para endereços
m.; - Acompanhe por oito semanas no Search Console: cobertura, páginas com erro, cliques e impressões por página. Oscilação nas primeiras semanas é esperada; queda que não se recupera indica redirect faltando.
Um detalhe que costuma ser esquecido: os 301 ficam no ar indefinidamente. Links antigos apontando para o m.site continuarão existindo por anos em outros sites, mensagens e materiais impressos.
Responsivo mal feito não é responsivo
Trocar o m.site por um responsivo malfeito não resolve nada — apenas muda o lugar do problema. Seis sintomas denunciam a implementação incompleta:
- Conteúdo escondido no celular — blocos ocultados por CSS para "caber". Como a versão móvel é a que o buscador avalia, o que some do celular some da avaliação;
- Tabela que estoura a largura — força rolagem horizontal na página inteira em vez de rolar dentro do próprio quadro;
- Fonte pequena demais — texto que só é legível com zoom, o que devolve o visitante ao problema que a técnica deveria eliminar;
- Botões pequenos e colados — alvos de toque menores do que um dedo, ou tão próximos que o clique erra o destino;
- Imagem de desktop servida ao celular — o arquivo de 2.000 pixels desce inteiro e é exibido em 360, gastando dados e tempo de carregamento;
- Menu que só abre no hover — comportamento de mouse em uma tela onde não existe passar o cursor: no toque, o submenu não abre.
Nenhum desses defeitos aparece em uma captura de tela bonita. Todos aparecem no primeiro visitante real — e é por isso que a escolha do layout precisa ser tratada como decisão de projeto, não de decoração, assunto de o que é layout e de o que é web design.
Quando um aplicativo entra na conversa
Há um terceiro personagem que costuma ser jogado na comparação sem critério: o aplicativo nativo. Ele resolve um problema diferente. Site serve para ser encontrado; aplicativo serve para ser reaberto. Um app precisa ser instalado, e ninguém instala um app para conhecer uma empresa, comparar um preço ou pedir um orçamento pela primeira vez.
Aplicativo compensa quando o uso é recorrente e depende de recursos do aparelho — notificações, câmera, funcionamento offline, programa de fidelidade, área logada de uso diário. Fora disso, ele soma custo de desenvolvimento, publicação nas lojas e manutenção em duas plataformas, sem substituir o site: o app não aparece na busca no lugar dele.
A decisão, por cenário
| Sua situação | O que fazer |
|---|---|
| Site novo, de qualquer porte | Responsivo, sem exceção |
| Site atual não responsivo, mas com bom conteúdo | Refazer o layout em responsivo, preservando URLs |
| m.site em funcionamento | Planejar a migração com 301 um a um |
| Dynamic serving já em produção e estável | Manter com Vary: User-Agent e migrar quando o site for reformulado |
| Responsivo com sintomas da seção anterior | Corrigir os seis pontos antes de investir em tráfego |
| Uso recorrente e com recursos do aparelho | Site responsivo mais aplicativo — nunca no lugar dele |
5 erros comuns nessa escolha
- Achar que responsivo é o que dá zoom — é o contrário, e essa troca leva empresas a contratar a solução errada;
- Criar um m.site novo em 2026 — ainda acontece em orçamentos que reaproveitam projetos antigos;
- Redirecionar todo o m.site para a home — o jeito mais rápido de perder o histórico de cada página;
- Cortar conteúdo do celular para "ficar leve" — reduz exatamente a versão que o buscador usa como principal;
- Testar só no próprio aparelho — um único modelo não representa as larguras, os navegadores e as conexões dos visitantes reais.
Perguntas frequentes
Qual é a diferença entre site responsivo e site mobile?
O site responsivo é um só site: uma URL e um código que reorganizam o layout conforme a largura da tela. O site mobile, no sentido clássico do termo, é uma segunda versão do site, publicada em endereço separado — normalmente m.seusite.com.br — com código e conteúdo próprios. A diferença não é visual, é estrutural: um site ou dois.
Site responsivo é aquele que fica menor para dar zoom?
Não — isso é exatamente o oposto. Quando a página inteira encolhe e você precisa dar zoom e arrastar para ler, o site não é responsivo: o celular está apenas espremendo um layout feito para desktop. Em um site responsivo o texto continua legível sem zoom e os blocos se reorganizam um embaixo do outro.
O que é dynamic serving?
É a terceira configuração possível: a URL é a mesma para todo mundo, mas o servidor identifica o dispositivo pelo user-agent e devolve um HTML diferente para celular e para computador. Funciona, porém depende de uma lista de dispositivos que envelhece, exige o cabeçalho Vary: User-Agent e quebra quando um aparelho novo não é reconhecido.
Ainda vale a pena criar um site m.site em 2026?
Para um site novo, não. O Google recomenda o design responsivo como configuração padrão, e a indexação mobile-first tornou a versão de celular a versão principal do site — o que transforma a divisão em duas URLs em risco desnecessário, além de dobrar manutenção e dividir sinais de autoridade entre dois endereços.
Como saber se o meu site é responsivo ou tem versão mobile separada?
Três testes de um minuto: abra o site no celular e olhe se a URL passa a começar com m. ou /mobile; no computador, arraste a borda da janela e veja se o layout se reorganiza sozinho; e compare o conteúdo das duas versões — se o celular mostra menos páginas ou menos texto, muito provavelmente existem dois sites.
Como migrar de site mobile para responsivo sem perder ranqueamento?
Mapeie cada URL m. até sua correspondente no site principal, publique a versão responsiva, aplique redirecionamentos 301 um a um — nunca todos para a home —, mantenha os redirects no ar indefinidamente, atualize sitemap e links internos, remova as tags rel="alternate" e rel="canonical" do pareamento antigo e acompanhe cobertura e cliques no Search Console por pelo menos oito semanas.
Site responsivo mal feito continua sendo responsivo?
Na prática, não resolve. Existem seis sintomas típicos: conteúdo escondido no celular, tabela que estoura a largura, fonte pequena demais, botões pequenos e colados, imagem de desktop servida ao celular e menu que só abre no hover. O código até se adapta, mas a experiência e a indexação sofrem como se não houvesse adaptação.
Site responsivo é mais lento que um site mobile?
Não por natureza. O site mobile ficou com fama de rápido porque era enxuto, não porque era separado. Um site responsivo bem construído serve imagens no tamanho certo para cada tela, carrega primeiro o que aparece na primeira tela e adia o resto — e chega ao mesmo resultado sem manter dois sites.
Preciso de um aplicativo em vez de um site responsivo?
Só quando o uso é recorrente e depende de recursos do aparelho, como notificações, câmera, uso offline ou fidelidade. Para descoberta, conteúdo, institucional e primeira compra, o site responsivo continua sendo o canal: aplicativo exige instalação, e ninguém instala um app para conhecer uma empresa.