O que é SEO técnico e como o Google lê o site

Por que o site não aparece

Um site no ar não é automaticamente um site no Google. A página pode carregar no navegador e ainda assim estar bloqueada ao Googlebot, devolver erro HTTP, não ter conteúdo indexável ou existir em tantas URLs equivalentes que o buscador não sabe qual versionar. Nesses casos, reescrever o texto da home não resolve: o bloqueio é técnico.

A dor clássica é a busca site:seudominio.com.br voltar vazio, ou voltar só a home enquanto dezenas de páginas de serviço ficam de fora. Outra variante: a URL aparece, mas sem descrição, porque o rastreio foi bloqueado e o Google só viu o endereço pelo link de terceiros. O mapa maior do tema está em o que é SEO; este guia aprofunda a frente que decide se a página entra no índice.

Empresas pequenas caem com frequência no mesmo ciclo: publicam páginas, pedem ranking e descobrem meses depois que o Search Console mostra "Descoberta, atualmente não indexada", bloqueio por robots ou soft 404. O custo não é só atraso: é tempo gasto em conteúdo que o Google nunca processou de verdade.

Há também o caso inverso, igualmente caro: o site está indexado, o relatório de cobertura parece "verde", e mesmo assim as páginas money não aparecem para as buscas que importam. Aí o técnico já cumpriu a parte de elegibilidade, e o diagnóstico migra para intenção, conteúdo e concorrência. Separar os dois mundos evita gastar orçamento no lugar errado.

• Sinal de bloqueio técnico: site: vazio, Inspeção com robots/noindex/erro, sitemap cheio de 404.
• Sinal de problema misto: páginas no índice com impressão zero nas queries comerciais.
• Sinal de outro pilar: impressão existe, clique não; ou clique existe, conversão não.

Se a empresa está montando presença digital do zero, a ordem importa ainda mais. Publicar dez artigos sem garantir HTTPS, canonical e descoberta é construir telhado sem fundação. O contrário também falha: site tecnicamente limpo com páginas vazias não gera demanda. Este guia existe para a fundação; o restante do cluster cobre o que vai em cima dela.

O que é SEO técnico

SEO técnico

É o conjunto de ajustes na infraestrutura e na entrega do site que permitem ao Google encontrar, rastrear, entender, indexar e exibir as páginas na Busca.

SEO técnico não é "deixar o site bonito no PageSpeed" nem "encher de schema". É a camada que decide se o conteúdo existe para o buscador. O Google descreve três requisitos mínimos para uma página ser elegível à indexação: o Googlebot não pode estar bloqueado, a página precisa responder HTTP 200, e o conteúdo precisa ser indexável. A documentação está em Google Search technical requirements.

Na prática, o trabalho técnico cobre descoberta de URLs, regras de rastreio, sinais de indexação, consolidação de duplicatas, paridade mobile, HTTPS, performance medida em usuários reais e markup que ajuda a classificar o conteúdo. Ninguém garante posição: o algoritmo é do Google. Técnico bem feito aumenta elegibilidade e clareza, não inventa ranking.

No vocabulário de mercado, "SEO técnico" às vezes vira sinônimo de qualquer ticket de desenvolvimento: troca de tema, plugin novo, CDN. A definição útil é mais estreita. Se a mudança não altera a capacidade do Google de descobrir, processar ou exibir a URL com fidelidade, ela pode ser importante para o negócio e ainda assim não ser SEO técnico. Essa linha evita transformar a auditoria num backlog infinito de TI.

Outro equívoco frequente: tratar PageSpeed como o único termômetro. Velocidade entra, e os Core Web Vitals têm limiares públicos. Mas um site rápido com noindex na template de serviço continua invisível. A hierarquia correta é elegibilidade primeiro, experiência depois, e só então disputa de relevância.

Técnico vs on-page vs off-page

Os três pilares do SEO resolvem bloqueios diferentes e nenhum substitui o outro. Técnico cuida de acesso e processamento. On-page cuida do significado dentro da página. Off-page cuida de sinais externos, especialmente links e menções.

Ordem de diagnóstico

A ordem certa começa pelo índice. Se a URL não está no Google, ajustar title e H1 é prematuro. Se está indexada e não gera impressão, aí entram intenção, conteúdo e concorrência. Se gera impressão sem clique, o recorte vira snippet e proposta. Title, meta e headings ficam no território on-page; este guia só os menciona para marcar a fronteira.

• Passo 1: a URL é descoberta e rastreável?
• Passo 2: a URL está indexada e elegível?
• Passo 3: a página comunica o assunto (on-page)?
• Passo 4: a página compete em autoridade (off-page)?

Em operação, as três frentes conversam o tempo todo. Um redirect mal feito (técnico) pode apagar equity de links (off-page). Um title duplicado em massa (on-page) piora a leitura de canônicas. Um cluster de páginas finas indexáveis (técnico permitindo demais) agrava spam policies. Por isso auditoria madura não entrega três PDFs isolados: ela prioriza a causa raiz na ordem em que o Google processa a URL.

Como o Google encontra a página

O Google encontra páginas explorando a web com rastreadores automáticos, sem um cadastro central de todos os sites. A maior parte das URLs entra no índice porque foi descoberta por links ou por sitemap, não porque alguém "submeteu" manualmente cada uma. O guia oficial está em How Google Search works.

Três estágios da Busca

A Busca opera em três estágios, e nem toda página completa os três: rastreamento (crawl), indexação e exibição dos resultados (serving). Google não garante crawl, índice ou serving mesmo quando a página segue as Search Essentials. Também não aceita pagamento para rastrear mais ou ranquear melhor.

Durante o crawl, o Googlebot baixa a página e pode executar JavaScript com uma versão recente do Chrome. Se o conteúdo principal só aparece depois de um clique ou de um login, o rastreador pode não vê-lo. Problemas comuns de acesso incluem servidor instável, rede, e regras de robots.txt que barram o bot.

O orçamento de rastreio não é um número que o Google publica por domínio para o dono do site ajustar num painel. Na prática, o que você controla é a qualidade do que o bot encontra: menos erros 5xx, menos labirintos de parâmetros, menos cópias da mesma página, mais links internos claros para o que importa. Site que responde lento ou com erro em cadeia ensina o rastreador a desacelerar.

JavaScript merece menção honestamente limitada neste pilar. O Googlebot renderiza páginas com Chrome recente, mas renderização custa recurso e nem todo conteúdo disparado só após interação chega a ser visto. Se o HTML inicial da página money está vazio e o texto só nasce no cliente depois de eventos, o risco técnico sobe. A correção profunda (SSR, hydration, when to lazy-load) é trabalho de stack; o diagnóstico inicial é comparar "ver código-fonte" com "ver página renderizada" e com o HTML retornado na Inspeção de URL.

Indexação e Search Console

Indexação é a etapa em que o Google analisa o que foi rastreado e decide o que guardar no índice. Sem índice, não há resultado orgânico para aquela URL. O Search Console é a ferramenta gratuita para ver o que o Google enxerga no seu domínio: cobertura, inspeção de URL, estatísticas de rastreio e problemas de experiência.

Requisitos técnicos mínimos

Três condições mínimas tornam a página elegível à indexação, segundo o Google Search Central:

1. Googlebot sem bloqueio A página precisa ser pública. Login obrigatório, paywall rígido sem exceção e mecanismos de bloqueio de indexação impedem o processo.
2. Página em HTTP 200 Só páginas com status de sucesso entram. Erros de cliente e de servidor não são indexados. A Inspeção de URL mostra o código retornado ao Google.
3. Conteúdo indexável O texto precisa estar em tipo de arquivo suportado e não violar as políticas de spam.

Para checar uma URL específica, use a Inspeção de URL no Search Console. Para ver o panorama, combine o relatório de indexação de páginas com as estatísticas de rastreio: cada um mostra ângulos diferentes. O Starter Guide do Google reforça o mesmo princípio de base em SEO Starter Guide.

"Rastreada, atualmente não indexada" e "Descoberta, atualmente não indexada" são estados diferentes. No primeiro, o Google já baixou a página e optou por não guardá-la (qualidade, duplicata, sinais fracos). No segundo, ainda não houve crawl útil. Tratar os dois com o mesmo remédio (pedir indexação de novo) raramente funciona. Duplicata pede canonical e consolidação; qualidade baixa pede conteúdo; bloqueio pede liberação de acesso. O passo a passo de cada estado, da primeira conferência no site novo até o que fazer quando a URL sai do índice, está no guia de como indexar o site no Google.

O Search Console também mostra estatísticas de rastreio: quantos bytes, quantas respostas por código, tempo de resposta do host. Picos de 5xx, quedas bruscas de páginas rastreadas ou tempo de resposta alto são pistas de infraestrutura. Não transforme o gráfico em superstição: use-o para correlacionar com deploys, plugins novos e campanhas que geram parâmetros.

robots.txt e meta robots

O arquivo robots.txt diz aos rastreadores quais URLs podem acessar no site. Serve sobretudo para gerenciar tráfego de crawl e evitar sobrecarga. Não é o mecanismo confiável para manter uma página fora do Google. A introdução oficial está em Introduction to robots.txt.

robots.txt

Arquivo na raiz do domínio que orienta rastreadores sobre quais caminhos podem ser acessados. Controla crawl, não indexação.

Quando usar noindex

Use noindex quando a página pode ser vista por humanos, mas não deve entrar na Busca: filtros de catálogo, thank-you pages, ambientes de staging expostos por engano, ou páginas internas sem valor de busca. Use senha quando a informação for privada de verdade. O Google deixa claro: URL desallowada no robots.txt ainda pode ser indexada se receber links, em geral sem o conteúdo completo.

• Erro comum: bloquear CSS e JS essenciais no robots e atrapalhar a renderização.
• Erro comum: Disallow em páginas que deveriam ranquear, "para economizar crawl".
• Erro comum: achar que robots.txt esconde conteúdo sensível. Não esconde.

Em CMS populares, o robots.txt às vezes é gerado por plugin e muda sem o marketing perceber. Depois de atualizar tema, segurança ou "otimizador", abra /robots.txt de novo. Uma linha Disallow: / esquecida em staging que vaza para produção é clássico de site "sumido". O inverso também existe: staging aberto sem noindex e sem senha, gerando cópias indexadas do site oficial.

User-agent: *
Allow: /

Sitemap: https://www.exemplo.com.br/sitemap.xml

O exemplo acima é o mínimo saudável de muitos sites pequenos: permitir o rastreio geral e apontar o sitemap. Bloqueios finos (carrinho, busca interna, filtros) só entram quando há motivo claro e teste no Search Console. Meta robots por página complementa: noindex, follow em thank-you pages, por exemplo, evita indexar confirmações sem cortar o fluxo de PageRank interno dos links.

Sitemap XML

Um sitemap é o arquivo em que você lista páginas, vídeos e outros arquivos importantes do site e a relação entre eles. O Google usa essa lista para rastrear com mais eficiência. A visão geral está em Learn about sitemaps.

Sitemap XML

Lista estruturada das URLs que você considera importantes para a Busca, com sinais opcionais como data de atualização e versões em outros idiomas.

Você pode precisar de sitemap se o site for grande, novo, com poucos links externos, ou rico em mídia e notícias. Você pode não precisar se tiver cerca de 500 páginas ou menos que importam para a Busca, navegação interna completa a partir da home, e pouco conteúdo de vídeo, imagem ou news. Mesmo no segundo caso, manter um sitemap limpo ajuda a auditar o que você declara como publicável.

• Só URL canônica. Não liste parâmetros, prints e versões duplicadas.
• Só o que existe. URL no sitemap e 404 no ar é sinal contraditório.
• Envie no Search Console. Acompanhe erros de leitura do arquivo.
• Atualize quando publicar. Sitemap velho atrasa descoberta de páginas novas.

Sitemap não é pedido de ranking. É sugestão de descoberta. O Google pode ignorar URLs da lista e pode indexar URLs que nunca estiveram nela, se as encontrar por links. Por isso o arquivo precisa estar alinhado à verdade do site: listar só o que você quer ver na Busca, no protocolo certo, sem noindex, sem login.

Em sites com blog ativo, o erro operacional mais comum é o CMS gerar sitemap automático com rascunhos, tags vazias e arquivos de autor. Audite uma amostra. Se a lista tiver centenas de URLs finas, o problema não é "falta de sitemap": é excesso de URLs sem valor pedindo atenção do rastreador. Aí a correção mistura noindex, consolidação e arquitetura.

Canonical e conteúdo duplicado

Conteúdo duplicado é o mesmo texto (ou quase o mesmo) acessível em mais de uma URL. Parâmetros de campanha, versões com e sem www, HTTP e HTTPS, filtros de loja e páginas de print geram esse cenário com facilidade. A canonicalização é o jeito de indicar qual URL deve concentrar os sinais. O Google documenta os métodos em Consolidate duplicate URLs.

URL canônica

É a versão preferida de um conjunto de páginas iguais ou muito parecidas, a que você quer ver na Busca e onde os sinais devem se concentrar.

Sinais de canonicalização

Os sinais se empilham. Redirects e anotações rel="canonical" são fortes. Inclusão no sitemap é fraca, mas ajuda. Combinar métodos aumenta a chance de a preferência ser respeitada. Se você não declarar nada, o Google escolhe a versão que considera objetivamente melhor para o usuário.

Em sites pequenos, a maior parte do ganho vem de unificar protocolo e host, evitar parâmetros indexáveis e garantir que cada página importante tenha um link rel="canonical" apontando para si mesma. Em catálogos grandes, o tema cresce: aí a consolidação vira projeto contínuo, não checklist de uma tarde.

Self-canonical (a página apontando para si) é o padrão saudável das URLs money. Canonical cruzada errada, apontando serviço A para serviço B, é um dos jeitos mais silenciosos de "sumir" com uma página boa. Depois de editar templates, confira no código-fonte se o href da canônica ainda é absoluto, HTTPS e específico daquela URL.

Mobile-first indexing

Mobile-first indexing significa que o Google usa a versão mobile do conteúdo, rastreada com o agente de smartphone, para indexar e ranquear. Não é obrigatório ter um site mobile separado para aparecer na Busca, mas é fortemente recomendado ter uma experiência mobile adequada. As práticas estão em Mobile site and mobile-first indexing.

O Google recomenda design responsivo: o mesmo HTML e a mesma URL para desktop e mobile, com layout que se adapta. Servir conteúdo diferente por user-agent ou em URLs separadas (m.) exige paridade cuidadosa de texto, metadados, imagens e dados estruturados. Se a versão mobile omitir blocos que existem no desktop, o índice pode ficar incompleto.

• Mesmos robots meta no mobile e no desktop. noindex só no mobile pode tirar a página do índice.
• Não esconda o conteúdo principal atrás de gesto do usuário. O Google não carrega o que depende de swipe ou clique para existir.
• Libere recursos de CSS, JS e imagem necessários à renderização. Bloquear no robots atrapalha a análise.
• Imagens e vídeos precisam ser rastreáveis e com qualidade adequada na versão mobile.

Interstitials agressivos, menus que cobrem o conteúdo e pop-ups que travam a primeira tela atrapalham a pessoa e podem degradar a percepção de qualidade da página. No nível deste guia, a regra prática é: o visitante mobile precisa chegar ao assunto principal sem caça ao X. Anúncio e conversão existem; o que não pode é o conteúdo money existir só na versão desktop.

Se o site ainda usa URL separada m., a lista de falhas possíveis cresce: redirect do desktop para a home mobile, noindex só no m., schema faltando, imagens bloqueadas. Responsivo elimina boa parte dessa classe de erro. Por isso a recomendação do Google não é estética: é operacional.

HTTPS e segurança básica

HTTPS é o protocolo com criptografia que protege a troca entre navegador e servidor. No SEO técnico de guia, o ponto central é: o Google prefere HTTPS na escolha da URL canônica, e misturar HTTP e HTTPS sem redirect claro cria duplicata. Certificado válido, redirect 301 de HTTP para HTTPS e links internos já em HTTPS formam o pacote mínimo.

• Certificado ativo e renovado automaticamente quando possível.
• Redirect de todas as variantes HTTP para a HTTPS canônica.
• Sem conteúdo misto crítico: recursos HTTP dentro de página HTTPS geram aviso e podem quebrar partes da página.
• Canonical e sitemap só com URLs HTTPS.

Segurança básica no nível deste guia não inclui pentest nem WAF avançado. Inclui não expor staging na web pública indexável, não deixar painéis de admin sem autenticação forte, e não tratar robots.txt como cofre. Página sensível pede login; página que não deve ranquear pede noindex; página que deve ranquear pede HTTPS limpo.

HSTS e headers avançados de segurança são desejáveis em stacks maduros, mas fogem do piso deste guia. O que não foge: certificado expirado derruba confiança do usuário e pode interromper visitas; redirect em cadeia (HTTP → www HTTP → HTTPS → www HTTPS) desperdiça crawl e atrasa LCP. Prefira um salto direto para a canônica final.

Core Web Vitals

Core Web Vitals são o subconjunto de métricas de experiência que o Google recomenda a todo site medir. Representam carregamento, interatividade e estabilidade visual, com dados de usuários reais. A referência está em Web Vitals, no web.dev. Este capítulo fica no nível pilar: o suficiente para entender e medir. O desdobramento com limiares, ferramentas de campo e ordem de correção está no guia de velocidade do site no SEO, que continua este capítulo sem repetir o que já está aqui.

LCP INP e CLS

Três métricas estáveis formam o conjunto atual:

• LCP (Largest Contentful Paint): tempo até o maior conteúdo visível. Bom até 2,5 segundos.
• INP (Interaction to Next Paint): responsividade às interações. Bom até 200 milissegundos.
• CLS (Cumulative Layout Shift): estabilidade visual. Bom até 0,1.

A meta prática é atingir os limiares no 75º percentil das visitas, separados por mobile e desktop. Ferramentas de campo incluem Chrome UX Report, PageSpeed Insights e o relatório de Core Web Vitals no Search Console. Medição de laboratório ajuda no desenvolvimento; decisão de "passou ou não" para o site real olha o campo.

CWV bom não salva página bloqueada por robots. CWV ruim também não é o único motivo de um site não ranquear. Trate velocidade como parte da qualidade técnica e da experiência, não como atalho de ranking prometido.

Na leitura do Search Console, priorize URLs com tráfego real e conversão. Corrigir CLS numa página interna sem visitas enquanto a landing principal carrega hero de 3 MB é inversão de prioridade. PageSpeed Insights ajuda no diagnóstico laboratorial; a decisão de "passou" olha o campo no 75º percentil. Se o relatório de campo ainda não tem dados suficientes (site novo ou pouco tráfego), use laboratório com parcimônia e acompanhe de novo depois de volume.

• LCP alto: imagem hero pesada, servidor lento, CSS bloqueante.
• INP alto: JavaScript pesado no clique, main thread ocupada.
• CLS alto: anúncio sem reserva de espaço, fonte que desloca texto, imagem sem width/height.

Dados estruturados

Dados estruturados são um formato padronizado para descrever o significado da página ao Google. Em uma receita, por exemplo, dão ingredientes e tempo de preparo; em um artigo, headline e data. Podem habilitar resultados mais ricos (rich results). A introdução oficial está em Introduction to structured data. Este capítulo fica no nível pilar. O desdobramento com o que o Google ainda aceita, o que saiu da galeria e o que não se inventa está no guia de dados estruturados no SEO, que continua este capítulo sem repetir o que já está aqui.

Dados estruturados

Marcações (em geral JSON-LD com vocabulário schema.org) que explicitam entidades e propriedades da página para mecanismos de busca.

O Google recomenda JSON-LD, valida com o teste de resultados rich e monitora com relatórios no Search Console depois do deploy. Regras duras: o markup deve descrever o que está visível na página; não invente Review ou AggregateRating sem depoimento real autorizado; não crie página vazia só para hospedar schema. Tipos que saíram da galeria de rich results, como HowTo, não merecem schema morto.

• Comece pelo que a página é: Organization, Article/BlogPosting, FAQPage, LocalBusiness quando couber.
• Sincronize com o HTML. Mudou a FAQ visível, atualize o FAQPage na mesma edição.
• Valide antes de publicar e monitore quebras após mudanças de template.
• Não prometa rich result. Elegibilidade não é garantia de exibição.

Case studies citados pelo Google em documentação de structured data mostram ganhos de CTR e engajamento em sites que implementaram markup válido em escala. Isso não autoriza copiar números como meta do seu projeto: são resultados daqueles publishers, em contextos específicos. O aprendizado transferível é outro: markup alinhado ao conteúdo visível pode habilitar apresentação mais rica; markup mentiroso não é atalho.

No dia a dia de uma PME, o retorno costuma vir de tipos modestos e corretos: Organization com dados reais, FAQPage sincronizado com a FAQ visível, BlogPosting no artigo, BreadcrumbList coerente. Preferir poucos tipos certos a dezenas de propriedades opcionais copiadas de gerador automático.

Checklist de SEO técnico

Este checklist cobre o que dá para conferir sozinho, com Search Console e o navegador, sem transformar o guia em manual de migração. Cada item diz o que olhar e como saber que passou.

• Busca site:. As URLs money aparecem? Se não, abra a Inspeção de URL.
• Status 200. Home, serviços e contato respondem sucesso, não soft 404.
• robots.txt. Abra /robots.txt. Nada essencial de conteúdo ou de CSS/JS bloqueado por engano.
• Meta robots. Páginas que devem ranquear não carregam noindex.
• Sitemap. Arquivo acessível, enviado no Console, só com URLs canônicas 200.
• Canonical. Cada página importante aponta para a URL preferida em HTTPS.
• HTTPS. HTTP redireciona; cadeado válido; links internos já em HTTPS.
• Mobile. Conteúdo principal visível no viewport estreito, sem depender de gesto.
• CWV no Console. Veja se há URLs "Ruim" ou "Precisa melhorar" em volume.
• Links internos. Toda URL importante alcançável a partir da home em poucos cliques.

1. Reserve 30 minutos Escolha cinco URLs críticas e rode Inspeção de URL em cada uma.
2. Anote a causa Separe bloqueio de crawl, erro de servidor, noindex e "rastreada, não indexada".
3. Corrija o óbvio robots errado, HTTP sem redirect e sitemap com 404 são ganhos rápidos.
4. Peça reprocessamento com parcimônia Só depois da correção. Pedir índice em cima de erro repetido não ajuda.

Depois da rodada inicial, crie um hábito mensal leve: abrir cobertura, olhar CWV das URLs com impressão, conferir se o sitemap ainda reflete o que está no ar, e checar se algum plugin alterou robots. Trinta minutos por mês evitam a surpresa de trimestre. Quando a lista de erros passar de uma página ou envolver código de template, o checklist cede lugar a um plano de correção com dono técnico.

Quando contratar uma agência

Contratar ajuda faz sentido quando o volume de URLs, a complexidade do stack ou a mistura de erros passam do que uma tarde de checklist resolve. Conferir robots e HTTPS de um site institucional pequeno cabe no time interno. Auditar um e-commerce com facetas, JavaScript pesado e histórico de migrações é outro tipo de trabalho.

A Voh! tem a busca orgânica como especialidade e, quando o projeto pede, também faz tráfego no Meta e no TikTok e gestão de redes. O canal único vale para site institucional, loja virtual, catálogo ou página local, e inclui a criação de site com SEO quando ele ainda não existe. São três formas de começar: auditoria gratuita, Pacote Implementação + 6 Meses e SEO Mensal. O diagnóstico vem antes da proposta. Ninguém garante posição: o algoritmo é do Google. Para a história e o método, leia sobre a Voh!.

Uma auditoria técnica séria cruza cobertura no Search Console, amostragem de status HTTP, regras de robots e noindex, qualidade do sitemap, canônicas, paridade mobile, HTTPS, CWV de campo e schema das templates principais. Isso se amarra ao on-page das URLs money e ao contexto de concorrência, porque relatório técnico isolado de intenção de busca vira lista de tickets sem prioridade comercial. O detalhe do serviço está em serviços de SEO.

• Inventário: URLs money, status e estado no índice.
• Bloqueios: robots, noindex, soft 404 e canônicas cruzadas.
• Experiência: mobile, HTTPS e CWV das landings que convertem.

Para quem gerencia loja virtual, o recorte técnico costuma doer em facetas, parâmetros e páginas de filtro. Indexar tudo parece "mais cobertura"; na prática, dilui crawl e multiplica quase-duplicatas. O trabalho aqui é decidir o que merece índice, o que fica noindex e o que consolidar. Não é desenvolver a plataforma da loja: é fazer a busca orgânica enxergar o catálogo certo. A Voh! aplica as mesmas três ofertas a esse cenário.

Sinais de que o faça-você-mesmo já não basta: soft 404 em escala, site em JavaScript com conteúdo invisível no HTML inicial, migração de domínio, loja com milhares de parâmetros indexáveis, ou CWV ruim concentrado nas landings que mais convertem. Nesses casos, os cases publicados mostram o tipo de acompanhamento contínuo. Quem for avaliar proposta encontra critérios honestos em como contratar uma agência de SEO.

Se a dúvida é o que trava o rastreio e o índice do seu domínio, Fale com a Voh!: a análise volta por escrito, antes de qualquer pacote. Atendimento nacional de uma agência de SEO.

Na conversa comercial, desconfie de pacote que começa pela posição prometida e pula o Search Console. Técnico sério mostra URLs, status, bloqueios e prioridade. Proposta sem inventário é slide. A home da Voh! deixa explícito o canal único: busca orgânica, aplicada ao tipo de site que a empresa já tem ou precisa criar.

Os limites do SEO técnico

SEO técnico não resolve tudo, e insistir nele quando o bloqueio é outro só atrasa o diagnóstico certo.

• Demanda inexistente. Site perfeito tecnicamente não cria busca onde ninguém pesquisa o serviço.
• Oferta confusa. Indexar uma proposta que o próprio time não explica só amplia o problema.
• Conteúdo fino em escala. Rastrear e indexar páginas vazias não gera valor; pode esbarrar em políticas de spam.
• Autoridade consolidada do concorrente. Técnico nivela o chão; não apaga dez anos de links e marca do outro lado.
• Urgência de cliente esta semana. Orgânico é cumulativo. Urgência imediata pede outro canal enquanto a base é construída.
• Produto ilegal ou enganoso. Nenhuma otimização técnica contorna política do Google.

Outro limite honesto: corrigir CWV em página sem intenção de busca clara gera satisfação no relatório e silêncio na conta. Do outro lado, conteúdo excelente preso atrás de noindex é potencial desperdiçado. O trabalho maduro equilibra as frentes; não troca uma obsessão pela outra.

Por fim, técnico não é projeto com data de "concluído para sempre". CMS atualiza, tema muda, plugin novo injeta noindex, CDN altera cabeçalhos. Revisar cobertura e templates críticos no Search Console é manutenção, não fracasso da auditoria anterior.

Se a empresa precisa de leads nesta semana para pagar folha, SEO técnico (e SEO em geral) não é o instrumento certo sozinho. Dá para construir a base em paralelo a outro canal, com expectativa honesta de prazo. Confundir urgência comercial com ticket de indexação gera frustração nos dois lados.

Também não espere que técnico "conserte" um mercado em que a SERP é dominada por marketplaces e diretórios gigantes sem uma estratégia de conteúdo e autoridade ao lado. A infraestrutura precisa estar correta para competir; sozinha, ela não desloca players com anos de sinais acumulados. O guia-pai o que é SEO situa essa frente no mapa completo.

Resumo em 12 pontos

• SEO técnico faz o Google encontrar, rastrear, indexar e exibir o site.
• Três mínimos: Googlebot sem bloqueio, HTTP 200, conteúdo indexável.
• Crawl → índice → serving são estágios distintos; falha em um corta o restante.
• robots.txt controla rastreio; noindex controla indexação.
• Sitemap ajuda descoberta, especialmente em site grande ou novo.
• Canonical concentra sinais de URLs duplicadas; HTTPS é preferido.
• Mobile-first usa a versão mobile como base do índice.
• Core Web Vitals medem LCP, INP e CLS no 75º percentil.
• Dados estruturados descrevem o que já está visível; sem Review inventado.
• Checklist manual acha bloqueios óbvios; escala pede operação.
• Técnico não substitui on-page nem off-page.
• Ninguém garante posição; o algoritmo é do Google.

Se quiser saber o que especificamente trava o rastreio e o índice do seu site, Fale com a Voh!: a análise volta por escrito. Para o mapa maior do tema, volte ao guia de SEO linkado na abertura.

Leve deste guia três hábitos: confirmar o índice antes de reescrever copy, tratar robots e noindex como ferramentas diferentes, e medir experiência com dados de campo além do laboratório. O restante é consistência, com Search Console aberto e sem promessa de ranking.

Se sobrar tempo depois do checklist, abra duas URLs do concorrente direto na Inspeção de URL (quando a ferramenta permitir comparação de campo) e no modo dispositivo. Não para copiar layout: para ver se o buraco do seu site é acesso, velocidade ou simplesmente ausência de página equivalente. Muitas vezes o "problema de SEO" era falta de URL dedicada ao serviço que a pessoa busca, não um mistério de algoritmo.