Mobile first é a prática de começar qualquer projeto web pelo celular: você define o que é essencial, desenha e programa essa versão enxuta e só depois acrescenta recursos para tablets e desktops. Parece detalhe de processo, mas muda o resultado final do site, o desempenho no Google e a taxa de conversão de quem acessa pelo smartphone.
Se alguém já te disse que “o site é responsivo, então está tudo certo”, este guia é para você. Responsivo e mobile first não são a mesma coisa, e a diferença aparece onde dói: lentidão na rede móvel, botão pequeno demais, menu que some, conteúdo que existe no desktop e não existe no celular (e que o Google, por consequência, nem considera).
Aqui você vai entender o conceito de ponta a ponta, ver como o Google trata a versão mobile do seu site, aprender a aplicar mobile-first no design, no CSS e em desenvolvimento WordPress, conectar tudo aos Core Web Vitals e sair com um checklist para auditar o seu próprio projeto.
min-width nas media queries para telas maiores.O termo foi popularizado por Luke Wroblewski, designer que defendeu a ideia em palestras e depois em livro. O argumento central continua valendo: a tela pequena impõe limites (espaço, atenção, rede, energia), e esses limites obrigam o time a separar o que é indispensável do que é decoração. Quem resolve o problema difícil primeiro tem uma base sólida para expandir, em vez de espremer um layout grande dentro de uma tela pequena no final.
Hoje, “mobile first” aparece em três contextos diferentes. Misturar os três é a causa mais comum de erro de planejamento.
| Onde o termo aparece | O que significa na prática |
|---|---|
| Design e UX | Definir conteúdo, hierarquia e ações a partir da tela do celular antes de projetar o desktop |
| Código (HTML e CSS) | Escrever o estilo base para telas pequenas e somar regras conforme a largura cresce |
| Indexação do Google | O Google usa a versão mobile do site para rastrear, indexar e ranquear o conteúdo |
O terceiro item não é uma escolha sua, é uma regra do buscador. Os dois primeiros dependem da sua equipe, e é neles que você ganha vantagem competitiva.
Foto de Hal Gatewood no Unsplash. Em mobile first, o wireframe da tela pequena nasce antes de qualquer layout de desktop.
As duas formas circulam em português. “Mobile first” (sem hífen) é a mais comum em títulos e conversas. “Mobile-first” (com hífen) costuma aparecer quando funciona como adjetivo composto, como em “abordagem mobile-first” ou “CSS mobile-first”. Use a que soar mais natural na frase e mantenha consistência dentro do mesmo texto.
Esses termos são vendidos como sinônimos, mas descrevem decisões diferentes. Entender cada um evita contratar uma coisa e receber outra.
| Termo | Em uma frase |
|---|---|
| Mobile first | Ordem de trabalho: começa pelo celular e cresce |
| Desktop first | Ordem inversa: começa pelo desktop e reduz para o celular |
| Design responsivo | Resultado: o layout se ajusta a qualquer largura de tela |
| Design adaptativo | Layouts fixos pré-definidos que trocam em larguras específicas |
| Mobile friendly | Qualidade mínima: o site é usável no celular, sem zoom nem rolagem lateral |
Todo projeto mobile first termina responsivo, mas existe muito site responsivo que foi desenhado para desktop e depois espremido para caber no celular. A diferença aparece no peso do CSS, na hierarquia do conteúdo e na velocidade. Para um verbete rápido sobre o conceito base, veja o glossário de responsividade.
Na indexação mobile first, o Google usa a versão mobile do conteúdo, rastreada com o agente de smartphone, para indexar e ranquear. A documentação oficial avisa que ter menos conteúdo no celular do que no desktop pode reduzir o tráfego, porque só o conteúdo mobile é indexado. Isso afeta diretamente a indexação e o tráfego orgânico do site.
Segundo a PNAD Contínua TIC, do IBGE, o celular está presente em 97,4% dos domicílios brasileiros, enquanto o computador está em 38,7%. Para muitos negócios, o acesso por desktop virou exceção, concentrada em horário comercial. Projetar primeiro para o notebook é otimizar para a minoria dos seus visitantes.
Quem acessa pelo celular está em pé na fila, no ônibus, sob sol forte, com uma mão ocupada, dividindo atenção com outra tarefa e, muitas vezes, com sinal oscilando. Mobile first não é só “caber na tela pequena”. É projetar para esse contexto: carregamento leve, botões fáceis de tocar, formulários curtos e informação direta.
Os Core Web Vitals são avaliados separadamente para mobile e desktop, e um site pode passar em um e reprovar no outro. Páginas lentas no celular aumentam a taxa de rejeição e derrubam a conversão. Se o seu site parece rápido no teste e lento na mão do cliente, leia também a diferença entre site rápido no teste e site rápido de verdade.
Existe um benefício menos citado: projetar para a tela pequena força decisões de produto. Quando tudo precisa caber em uma coluna, sobram apenas as informações que realmente sustentam a ação principal. O resultado costuma ser um site mais claro também no desktop.
Este é o ponto em que mobile first deixa de ser opinião de design e vira requisito técnico. Vale entender o que a documentação oficial do Google recomenda.
O Google aceita três formas de entregar o site para celulares, mas recomenda uma delas.
| Configuração | Como funciona |
|---|---|
| Design responsivo (recomendada) | Mesma URL e mesmo HTML para todos os aparelhos, com o layout mudando por CSS |
| Serviço dinâmico | Mesma URL, mas o servidor devolve HTML diferente conforme o aparelho |
| URLs separadas | Endereços diferentes para mobile e desktop, com redirecionamentos entre eles |
A configuração responsiva é a mais simples de manter, porque o conteúdo e os metadados são idênticos por definição. As outras duas exigem cuidado extra com cabeçalhos, canonical, redirecionamentos e consistência entre versões, e por isso são fontes frequentes de erro.
noindex pode tirar a página do índice.O Google não toca, não desliza e não digita. Conteúdo principal carregado apenas após uma interação (clique para “ver mais”, rolagem infinita sem alternativa, abas que só buscam o texto depois do toque) corre o risco de não ser visto. A regra prática: se o texto importa para o ranqueamento, ele precisa estar disponível no carregamento da página.
Pop-ups que cobrem a tela inteira logo na chegada e blocos de anúncio que ocupam o topo da página no celular prejudicam a experiência. A orientação do Google trata esse tipo de elemento como ponto de atenção na avaliação da experiência de página, e a documentação de indexação mobile first menciona que anúncios de topo que consomem espaço demais podem afetar o ranqueamento.
Antes de abrir qualquer ferramenta de design, escreva uma lista em coluna única com tudo o que a página precisa ter, na ordem de importância. Essa lista é o esqueleto da versão mobile. Se um item não sobrevive à disputa por espaço nessa lista, provavelmente é decoração.
Uma pergunta ajuda a filtrar: o que a pessoa veio fazer aqui e qual é o caminho mais curto até isso? Em um site de serviços, pode ser pedir orçamento. Em uma loja, finalizar a compra. Em um blog, ler sem tropeçar.
A maioria das pessoas usa o celular com uma mão. As áreas mais confortáveis para tocar ficam na metade inferior da tela, e o topo é a região mais difícil de alcançar. Ações frequentes (menu, busca, botão principal) funcionam melhor ao alcance do polegar, e ações destrutivas (excluir, cancelar pedido) não devem ficar coladas em botões de uso comum.
Botão pequeno gera clique errado, e clique errado gera frustração. O WCAG 2.2 define 24 por 24 pixels CSS como tamanho mínimo para alvos de toque (nível AA) e 44 por 44 pixels como referência do nível AAA. Na prática, projetos mobile first adotam cerca de 48 pixels de altura nos botões principais e deixam espaço entre elementos clicáveis para evitar toque acidental.
No celular não existe “passar o mouse”. Menus que só abrem em hover, tooltips que escondem informação importante e botões que só revelam o rótulo ao passar o cursor falham para metade do público. Projete o estado padrão para toque e use o hover apenas como reforço em dispositivos que o suportam.
Cada campo a mais é uma desculpa para desistir. Peça só o que você vai usar, use o tipo de campo correto para abrir o teclado certo, ative o preenchimento automático e mostre erros ao lado do campo, em linguagem humana. Esse cuidado aparece em qualquer landing page que converte bem.
Menu hambúrguer não é pecado, mas esconder tudo atrás dele também não resolve. Deixe a ação principal à vista e mantenha poucos níveis de navegação. Quanto menos toques até a informação, melhor a experiência do usuário. Para ir mais fundo nesse tema, leia o que é UX e UI.
Texto de corpo em torno de 16 pixels ou mais, linhas com comprimento confortável, contraste suficiente e espaçamento entre parágrafos. Se a pessoa precisa dar zoom para ler, o projeto falhou na primeira etapa.
Na tela pequena, parágrafos longos viram paredes de texto. Use títulos descritivos, parágrafos curtos, listas e destaques pontuais. Isso ajuda o leitor humano e também facilita a extração de trechos pelos buscadores.
Foto de Hal Gatewood no Unsplash. Pensar em telas e fluxos antes do visual evita retrabalho.
Este é o roteiro que uso em projetos novos e em reformulações. Ele funciona tanto para uma landing page quanto para um site institucional ou uma loja virtual.
Abra o Google Analytics e o Google Search Console e responda: qual a proporção de sessões mobile, quais páginas concentram leads e vendas, em que dispositivos a conversão cai mais e qual o desempenho de campo por tipo de página. Sem esses números, a priorização vira opinião.
Escolha as duas ou três ações que mais importam (pedir orçamento, comprar, agendar, ligar, chamar no WhatsApp) e desenhe o caminho mais curto até elas. O mapeamento da jornada do cliente ajuda a encontrar onde a pessoa trava.
Desenhe a página inteira em uma coluna: título, proposta de valor, prova social, ação principal, detalhes, contato. Só depois pergunte: “o que eu ganho ao expandir isso para duas ou três colunas no desktop?”. Muitas vezes a resposta é “pouca coisa”, e está tudo certo.
O CSS padrão, sem media query, atende o celular. A partir daí, você adiciona regras em larguras maiores com min-width. Veja um exemplo que reúne os recursos mais úteis:
/* Base: celular */
.cartoes {
display: grid;
gap: 1rem;
padding: 1rem;
}
.titulo {
/* tipografia fluida: cresce com a tela, com piso e teto */
font-size: clamp(1.5rem, 1.2rem + 1.5vw, 2.25rem);
}
.botao {
min-block-size: 48px;
padding-inline: 1.25rem;
font-size: 1rem;
}
/* Hover só em aparelhos que realmente têm ponteiro */
@media (hover: hover) {
.botao:hover {
filter: brightness(1.1);
}
}
/* Respeita quem prefere menos movimento */
@media (prefers-reduced-motion: reduce) {
* {
animation-duration: 0.01ms !important;
transition-duration: 0.01ms !important;
}
}
/* Tablet em diante */
@media (min-width: 48em) {
.cartoes {
grid-template-columns: repeat(2, 1fr);
gap: 1.5rem;
}
}
/* Notebook em diante */
@media (min-width: 64em) {
.cartoes {
grid-template-columns: repeat(3, 1fr);
padding: 2rem;
}
}A vantagem é dupla: o navegador do celular processa menos regras e o código fica mais fácil de manter, porque cada breakpoint só acrescenta o que muda. O caminho inverso (partir de max-width) obriga o celular a baixar regras de desktop e depois sobrescrevê-las.
Três cuidados que fazem diferença:
rem, %, fr, ch) em vez de larguras fixas em pixels.Imagem costuma ser o maior peso da página e o elemento que define o LCP. A regra é entregar o arquivo certo para cada tela:
<img
src="produto-640.webp"
srcset="produto-640.webp 640w, produto-960.webp 960w, produto-1280.webp 1280w"
sizes="(min-width: 64em) 480px, 100vw"
width="1280"
height="960"
alt="Tênis de corrida azul visto de lado"
loading="lazy"
decoding="async"
>E para a imagem principal, a que aparece logo na primeira tela e costuma ser o elemento do LCP, o ajuste é o oposto:
<img
src="hero-960.webp"
srcset="hero-640.webp 640w, hero-960.webp 960w, hero-1280.webp 1280w"
sizes="100vw"
width="1280"
height="720"
alt="Equipe revisando um projeto de site em um notebook"
fetchpriority="high"
decoding="async"
>Observações importantes:
width e height para reservar o espaço e evitar saltos de layout (CLS).fetchpriority="high" em uma ou duas imagens no máximo. Se tudo é prioridade, nada é.Cada script extra compete com a thread principal do celular, que é bem menos potente que a de um notebook. Remova bibliotecas que ninguém usa, carregue scripts de terceiros (chat, pixels, mapas) depois do carregamento principal e evite carregar em todas as páginas o que só serve em uma. Limite o número de famílias e pesos de fonte e use font-display: swap para o texto aparecer sem esperar o arquivo. Esse é um dos pontos em que plugins gratuitos acabam saindo caro.
Servir os arquivos de um ponto próximo ao visitante e reaproveitar o que já foi baixado reduz o tempo de resposta em redes móveis. Entenda o papel do cache e de uma CDN na entrega.
Combine com a equipe limites objetivos para a página: peso total, quantidade de requisições, tamanho máximo de JavaScript e metas de LCP, INP e CLS. Quando um novo plugin, banner ou script estoura o orçamento, a conversa deixa de ser “eu acho que ficou pesado” e vira “isso custa 400 KB de JavaScript, vale a pena?”.
O emulador do navegador ajuda, mas não substitui o celular de verdade, com rede de verdade e dedo de verdade. Teste o fluxo principal em pelo menos um Android de entrada e um iPhone. Se o formulário é difícil de preencher com o polegar, o problema aparece em dez segundos.
Foto de Charles Lamb no Unsplash. Testar em aparelho real revela o que o emulador esconde.
Em loja virtual, o celular é onde muita decisão de compra começa e termina. Cada atrito se converte em carrinho abandonado, e por isso o mobile first tem retorno direto na receita. O que muda no projeto:
Se a sua loja roda em WooCommerce, tudo isso passa por tema, plugins e hospedagem, assunto da próxima parte.
Foto de CardMapr.nl no Unsplash. No e-commerce, o checkout no celular é o momento em que a venda se decide.
Boa parte dos sites de pequenas e médias empresas no Brasil roda em WordPress, e é nele que o mobile first mais costuma falhar, não por limitação da plataforma, mas por decisões de tema, plugins e hospedagem. Em desenvolvimento WordPress bem feito, a abordagem mobile first aparece em quatro camadas.
Quase todo tema comercial hoje se declara responsivo. Isso não significa que ele tenha sido construído do celular para o desktop. Temas multiuso e construtores visuais como o Elementor precisam suportar centenas de combinações de layout e costumam carregar folhas de estilo e scripts em praticamente todas as páginas, usados ou não.
O custo-benefício é legítimo: um tema pronto acelera a publicação para quem precisa de autonomia, e um tema sob medida entrega leveza e previsibilidade. O erro é escolher o primeiro e cobrar a performance do segundo. Antes de decidir, audite o tema atual:
| O que verificar | Por que importa |
|---|---|
Media queries com min-width ou max-width | Indica se a base foi escrita para celular ou para desktop |
| Percentual de CSS e JavaScript realmente usado na página | Código não usado pesa no celular sem entregar nada |
| Tamanho dos elementos de toque nos menus e botões | Evita toque errado e falhas de acessibilidade |
| Plugins que injetam arquivos em todas as páginas | Principal fonte de peso desnecessário |
Plugins de slider, pop-up, formulário e galeria costumam carregar CSS e JavaScript no site inteiro. Quando o desempenho no celular cai, a investigação deve começar por eles. Uma boa prática é carregar o recurso apenas nas páginas em que ele é usado:
// functions.php (ou plugin de personalização)
add_action( 'wp_enqueue_scripts', function () {
// Folha base do tema: sempre.
wp_enqueue_style( 'tema-base', get_stylesheet_uri(), [], wp_get_theme()->get( 'Version' ) );
// Estilo da home: só na home.
if ( is_front_page() ) {
wp_enqueue_style(
'tema-home',
get_theme_file_uri( 'assets/css/home.css' ),
[ 'tema-base' ],
wp_get_theme()->get( 'Version' )
);
}
} );
add_action( 'wp_enqueue_scripts', function () {
// "plugin-galeria" é um handle ilustrativo: troque pelo handle real do seu plugin.
if ( ! is_singular( 'product' ) ) {
wp_dequeue_style( 'plugin-galeria' );
wp_dequeue_script( 'plugin-galeria' );
}
}, 100 );Se você mantém um tema filho, essas regras ficam seguras em atualizações do tema pai.
Em um tema clássico, o WordPress escolhe qual arquivo monta cada página seguindo a hierarquia de templates: página, post, arquivo, busca, 404 e assim por diante. Quando nenhum template específico existe, o index.php entra como template de fallback, e por isso ele é obrigatório em qualquer tema clássico, junto do style.css.
Para o mobile first, isso importa por três motivos práticos:
index.php nasce com marcação inchada, esse peso se repete em todas as telas que dependem dele.Um exemplo enxuto de index.php que aplica essas ideias:
<?php get_header(); ?>
<main id="conteudo">
<?php if ( have_posts() ) : ?>
<?php $primeiro = true; ?>
<?php while ( have_posts() ) : the_post(); ?>
<article <?php post_class(); ?>>
<?php
if ( has_post_thumbnail() ) {
the_post_thumbnail( 'large', [
'sizes' => '(min-width: 64em) 720px, 100vw',
'loading' => $primeiro ? 'eager' : 'lazy',
'fetchpriority' => $primeiro ? 'high' : 'auto',
] );
}
?>
<h2><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></h2>
<?php the_excerpt(); ?>
</article>
<?php $primeiro = false; ?>
<?php endwhile; ?>
<?php endif; ?>
</main>
<?php get_footer(); ?>Só o primeiro item da lista recebe carregamento imediato e prioridade alta, porque é o candidato natural ao LCP. Os demais carregam sob demanda. Em temas de blocos (block themes), o conceito é o mesmo, mas os templates são arquivos HTML e o fallback continua existindo na hierarquia.
Foto de Pankaj Patel no Unsplash. A estrutura base do tema define o que o resto do site herda.
Um alerta relacionado: se o index.php aparece dentro das URLs públicas (por exemplo, seusite.com.br/index.php/contato/), a mesma página fica acessível por dois endereços, o que dilui sinais de SEO. A correção passa por configurar links permanentes sem index.php, definir a URL preferida com a tag canonical e aplicar redirecionamento 301 das URLs antigas, sempre testando antes em staging. Se o problema surgiu depois de uma migração, o guia sobre migrar um site WordPress sem perder SEO cobre o cuidado necessário, e o .htaccess é o arquivo onde essas regras costumam morar em servidores Apache.
Um tema leve em um servidor lento continua lento. O tempo de resposta do servidor (TTFB), o cache de página, a versão do PHP e o uso de CDN influenciam diretamente o LCP no celular. O próprio guia de otimização de LCP do web.dev coloca o TTFB como uma das quatro partes do tempo total. Se o diagnóstico aponta para o servidor, vale ler WordPress lento: causas e diagnóstico e entender o que é hospedagem de verdade.
Quando tema, plugins e infraestrutura formam um nó difícil de desatar, existe o ponto de virada em que compensa sair do tema pronto. Esse raciocínio está em o momento certo de sair do WordPress para uma stack sob medida e, para quem quer ir além do CMS tradicional, no conceito de headless CMS.
A indexação mobile first cria a base. A partir dela, a estratégia de SEO precisa pensar a página para a tela pequena.
Pesquisas feitas no celular costumam ser mais diretas e muitas vezes têm urgência: encontrar um telefone, um endereço, um preço, uma resposta rápida. Na primeira tela, a página precisa confirmar que o visitante chegou ao lugar certo: título claro, resposta ou proposta de valor logo no início e uma ação evidente. Isso reduz o retorno imediato à busca.
Use um único H1, subtítulos que descrevem o conteúdo da seção e parágrafos curtos. Responder a pergunta principal já no começo do texto, como neste artigo, ajuda o leitor e facilita a seleção de trechos pelos buscadores.
Mantenha na versão mobile os mesmos links internos importantes do desktop. Menus enxutos não podem eliminar o acesso às páginas que sustentam o seu SEO. Use âncoras descritivas e conecte conteúdos relacionados, como este guia faz com o glossário e com artigos de apoio.
Imagens leves, com alt text descritivo, nomes de arquivo coerentes e URLs estáveis. Vídeos em marcação padrão e posicionados de forma que o usuário os encontre sem rolagem excessiva.
Marque o que a página realmente contém, nas duas versões, e mantenha título e descrição equivalentes. Para conferir como o resultado aparece na busca, a ferramenta de preview de SEO ajuda a visualizar título e descrição, e o gerador de head organiza o cabeçalho da página.
Para quem atende uma região, o celular é o canal natural de contato. Botões de ligação e WhatsApp visíveis, endereço com link para o mapa e horário de funcionamento fácil de achar encurtam o caminho entre a busca e o orçamento.
Para um mapa completo de problemas técnicos desse tipo, o caminho é uma auditoria de SEO e, depois, o trabalho contínuo de SEO técnico. E, com a busca mudando por causa da IA, vale entender por que o SEO técnico ainda importa.
Os Core Web Vitals medem experiência real de uso, avaliada no percentil 75 das visitas e separada por dispositivo. A documentação do Google informa que eles são usados pelos sistemas de ranqueamento, e também ressalta que bons números não garantem posição no topo, porque o ranqueamento considera muitos outros sinais. Em mobile, o desafio é maior, porque o aparelho é menos potente e a rede é menos estável.
| Métrica | Meta para ficar na faixa “bom” |
|---|---|
| LCP (carregamento do maior elemento visível) | Até 2,5 segundos |
| INP (resposta às interações) | Até 200 milissegundos |
| CLS (estabilidade visual) | Até 0,1 |
Para ver como isso se encaixa no desempenho geral do site, consulte o verbete sobre performance web e o guia de desenvolvimento de sites de alta performance.
Medir é o que separa discurso de resultado. Use estas ferramentas em conjunto:
Uma rotina simples: faça essa checagem a cada mudança grande (novo plugin, novo bloco de página, nova campanha) e, no mínimo, uma vez por mês. Para acompanhar o impacto no negócio, vincule os resultados à medição de conversões por canal e ao seu Google Analytics 4.
O último ponto merece destaque. Mobile first quebra quando vira projeto de uma área só. Marketing define prioridade de conteúdo e conversão, design organiza a hierarquia, desenvolvimento entrega código e carregamento na ordem certa e infraestrutura sustenta a velocidade. Quando as áreas trabalham em filas separadas, a campanha vai ao ar antes de alguém medir o LCP da página de destino.
A pergunta aparece em quase toda conversa de orçamento. A resposta depende de dados, não de gosto.
| Situação | Caminho mais provável |
|---|---|
| Site recente, estrutura saudável, problemas pontuais no celular | Adaptar os templates de maior impacto |
| Tema pesado, plugins em conflito, correções que viram remendo | Reconstruir com base mobile first |
| Site com muito conteúdo e tráfego orgânico consolidado | Adaptar por etapas, protegendo URLs e SEO |
| Operação que depende de recursos específicos (reservas, assinaturas, painéis) | Avaliar desenvolvimento sob medida |
Um caminho que costuma dar bom retorno é duplo: corrigir agora as páginas que mais geram receita (ganho rápido) e, em paralelo, planejar a versão nova já com arquitetura mobile first. Os artigos criar site novo ou otimizar o site atual e por que seu site fica lento mesmo depois de otimizado ajudam a decidir com mais segurança.
Foto de Julio Lopez no Unsplash. O cliente alterna entre telas, e a experiência precisa acompanhar essa troca.
Em alguns casos, um site mobile first bem feito resolve tudo. Em outros, o produto pede recursos que o navegador comum não entrega bem: funcionamento offline, notificações, instalação na tela inicial, acesso profundo a recursos do aparelho. Nesses casos entram o PWA e o aplicativo.
Para escolher com critério, leia app nativo, PWA ou aplicação web e o guia o que é PWA. Se o projeto exigir app, consulte também os custos em quanto custa desenvolver um aplicativo para empresa e a visão geral de desenvolvimento de software multiplataforma.
min-width nas media queries.srcset, sizes, WebP ou AVIF e têm largura e altura declaradas.index.php e demais) entrega marcação enxuta, e as URLs públicas não exibem index.php.Se você leu até aqui, provavelmente já identificou pelo menos dois itens do checklist que o seu site não cumpre. A boa notícia é que quase tudo isso tem solução objetiva. Estes são os serviços que faço para tirar o seu projeto do papel ou corrigir o que está travando resultado:
Quer saber em que pé o seu site está? Me conte qual é o seu cenário (site institucional, blog, loja virtual ou sistema) e qual resultado você espera. Eu analiso o que está travando o desempenho no celular e proponho o caminho mais direto. Fale comigo pela página de contato.
Se o seu foco é entender melhor o investimento antes de conversar, leia o que está incluso e o que não está em um orçamento de site e o checklist técnico que toda empresa deveria exigir do próprio site.
É uma abordagem de projeto em que o site é pensado, desenhado e programado primeiro para o celular e depois expandido para telas maiores. O foco é priorizar o conteúdo essencial, a facilidade de uso e a velocidade, que são as maiores exigências do contexto móvel.
Não. O design responsivo é o resultado: um layout que se ajusta a qualquer largura. O mobile first é a ordem do trabalho: começar pela menor tela. Um site pode ser responsivo e ter sido desenhado primeiro para desktop, o que costuma gerar CSS inchado e uma experiência pior no celular.
É a política do Google de usar a versão mobile das páginas, rastreada com o agente de smartphone, para indexar e ranquear o conteúdo. Se a versão mobile tiver menos conteúdo que a desktop, o site pode perder tráfego, porque só o conteúdo mobile é indexado.
Não, e o Google recomenda o design responsivo, com a mesma URL e o mesmo HTML para todos os aparelhos. Versões separadas funcionam, mas exigem redirecionamentos, canonical e cabeçalhos corretos e aumentam o risco de divergência entre as versões.
Escreva os estilos base para o celular, sem media query, e use @media (min-width: ...) para acrescentar regras em telas maiores. Escolha breakpoints pelos pontos em que o conteúdo realmente quebra, use unidades relativas e teste em aparelhos reais.
Escolha um tema leve (ou desenvolva um sob medida), carregue CSS e JavaScript apenas onde forem necessários, otimize imagens com srcset e formatos modernos, use cache e CDN e acompanhe os Core Web Vitals no Search Console. O trabalho passa por tema, plugins, templates e hospedagem.
É o template de fallback de um tema clássico. Quando não existe um template mais específico para o tipo de página solicitado, o WordPress usa o index.php. Junto com o style.css, é um dos arquivos obrigatórios do tema.
Configure a estrutura de links permanentes sem index.php, defina a URL preferida com a tag canonical e crie um redirecionamento 301 das URLs antigas para as novas. Em servidores Apache, a regra de redirecionamento deve vir antes do bloco padrão do WordPress no .htaccess. Teste primeiro em staging.
Não, quando bem feito. A base mobile define prioridades e organização, e o desktop recebe seus próprios estilos por min-width. O resultado costuma ser um desktop mais limpo e um celular muito melhor.
Os Core Web Vitals: LCP até 2,5 segundos, INP até 200 milissegundos e CLS até 0,1. Também vale acompanhar taxa de conversão por dispositivo, taxa de rejeição e abandono do checkout.
Indiretamente. Ele não é um “bônus” de posição, mas garante que o Google enxergue todo o seu conteúdo e que a experiência no celular seja boa o bastante para manter o visitante na página. Os Core Web Vitals são usados pelos sistemas de ranqueamento, mas nenhum número isolado garante o topo da busca.
Nem sempre. Se a base é saudável, adaptar os templates de maior impacto costuma entregar resultado mais rápido. A reconstrução faz sentido quando o tema, os plugins ou a arquitetura impedem a correção. A decisão deve sair de dados de sessão, conversão e desempenho por tipo de página.
Vale quando a equipe usa o sistema no celular, como em vendas externas, atendimento e operação em campo. Para esses casos, conheça a visão de aplicação web para empresas.
Mobile first deixou de ser tendência e virou o padrão de como as pessoas navegam e de como o Google lê a web. Tratar o assunto como um detalhe de layout é o caminho mais curto para um site bonito no computador do dono e fraco na mão do cliente.
O caminho é direto: priorize o conteúdo essencial, escreva o CSS a partir do celular, mantenha paridade entre as versões, cuide de imagens, scripts e infraestrutura, estruture bem o tema e meça tudo com dados reais. Quem faz isso ganha em três frentes ao mesmo tempo: desempenho no Google, experiência do visitante e conversão.
Se você quer um site (ou uma loja virtual) construído com essa mentalidade desde o primeiro wireframe, ou precisa corrigir um projeto que já está no ar, fale comigo. Eu cuido do diagnóstico, do desenvolvimento e do acompanhamento, do código ao resultado.
index.php como fallback.
A stack certa ajuda, mas não substitui experiência. Entenda por que um site de alta performance depende mais de quem desenvolve do que da tecnologia escolhida.
O teste de velocidade vs performance real revela por que seu site pode ter nota alta no PageSpeed e ainda parecer lento para o usuário de verdade.
Veja o que costuma mudar no SEO técnico antes e depois de uma auditoria em sites que já tinham otimização básica, mas ainda perdiam posição.