Expertise · SEO
SEO técnico e estrutural — indexabilidade, endereços canónicos, mapa do site gerado a partir de dados, redirecionamentos, títulos e descrições, conteúdo magro, velocidade medida em bytes. Sem promessas de posições.
Já construídoDuas implementações próprias, ambas abertas no disco. A primeira: a auditoria deste sítio — 249 endereços percorridos com pedidos diretos, 23 colunas por endereço, o resultado num ficheiro tabular versionado ao lado do código, mais as correções que daí saíram (o endereço canónico resolvido uma vez por todas as rotas, o endereço de partilha, o mapa do sítio gerado a partir de dados). A segunda: `mega-seo-analyzer`, um analisador próprio com 16 módulos de análise e uma pontuação ponderada escrita explicitamente no código. O que não podemos sustentar e não vamos escrever: posições obtidas ou percentagens de crescimento. Não temos medições publicáveis para isso.
SEO clássico é um trabalho de inventário, não de ideias. Um motor de busca tem de conseguir chegar a cada página, perceber qual é a sua versão oficial, receber um título e uma descrição que não se repitam e encontrar conteúdo suficiente para merecer um lugar numa lista. Quase tudo o que se estraga aqui pode ser contado, e o que pode ser contado pode ser corrigido.
Por isso começamos com uma percorrença completa, não com uma amostra. Neste site saíram 249 endereços, cada um com 23 colunas: código de resposta, endereço canónico, título, descrição, hreflang, número de blocos de dados estruturados, volume de texto visível e o restante. O resultado é um ficheiro tabular versionado ao lado do código, por isso cada afirmação abaixo pode ser reproduzida com os comandos do anexo do relatório.
O que saiu: 244 endereços respondem 200 e cinco redirecionam. 131 páginas não tinham endereço canónico. 219 de 244 declaravam a página inicial como endereço de partilha, por isso qualquer partilha mostrava a página errada. 100 títulos ultrapassavam 60 caracteres, sendo o mais longo de 106. 65 páginas partilhavam uma única descrição gerada a partir de modelo. 96 páginas tinham menos de 2.000 caracteres de texto visível. As duas primeiras foram corrigidas com uma linha cada no arranjo de base, que se aplica a cada rota; o resto está na lista de trabalho, com prioridade escrita.
Esta página é uma de três. SEO ocupa-se dos motores que devolvem uma lista de links. A visibilidade nas respostas geradas por modelos é outra coisa e tem a sua própria página, porque se controla de outra forma e — importante — não se pode prometer. As respostas diretas e os dados estruturados são a terceira. O que é comum às três: a página tem de ser acessível, renderizada no servidor e ter um único endereço oficial. Essa parte faz-se uma vez e serve para todas.
Qué incluye
Pedidos diretos a cada endereço conhecido, sem seguir redirecionamentos, com no máximo seis pedidos em simultâneo para não incomodar o servidor, e 23 colunas por endereço: código, endereço canónico, título, descrição, hreflang, número de blocos de dados estruturados, volume de texto visível. O resultado é um ficheiro tabular que entregamos. Neste site: 249 endereços, dos quais 244 respondem 200 e 5 redirecionam.
131 páginas não declaravam qualquer endereço canónico, e 219 de 244 declaravam a página inicial como endereço de partilha — por isso qualquer partilha nas redes mostrava outra página. Ambos foram corrigidos com uma declaração relativa no arranjo de base, que se resolve para cada rota em separado. É uma linha de código em vez de uma convenção que cada nova página teria de se lembrar sozinha.
O mapa é construído a partir das fontes de conteúdo e passa por uma deduplicação final — neste site, 147 endereços, a mesma cifra no código e no ficheiro servido em produção. Um script executado após a publicação falha se o mapa perder uma página ou se aparecerem variantes de endereço que não abrem. O que falta hoje, dito como falta: as entradas não têm data da última modificação, e 93 endereços indexáveis ainda não estão incluídos.
Numa reestruturação, cada endereço existente recebe um veredito: mantém-se, redireciona-se permanentemente ou desaparece. Neste site resultaram 43 redirecionamentos na configuração. Verificados em separado também os aspetos que ninguém testa: a passagem do domínio sem `www` para o com `www` é uma só; o endereço com barra final redireciona corretamente; o endereço escrito em maiúsculas devolve 404, portanto não existe duplicado de escrita.
100 títulos de 244 ultrapassam 60 caracteres, sendo o mais longo de 106 — o risco é o truncamento nos resultados. 33 descrições ultrapassam 160 caracteres, mas zero faltam. Mais grave: 65 páginas partilham uma única descrição gerada a partir de modelo, e 30 delas diferem entre si por 240 bytes no total. Mediana de texto visível: 2.328 caracteres, com 96 páginas abaixo de 2.000. São números, não impressões, e cada um tem uma lista de endereços por trás.
O nosso analisador tem 16 módulos — na página, desempenho, mapa do site, segurança, acessibilidade, infraestrutura de nomes, informações de registo do domínio, ligações externas, redes sociais, stack técnica, posições, pesquisa de palavras-chave, auditoria geral — além de módulos de comparação: encontrar concorrentes, diferença de palavras-chave, diferença de conteúdo, referências. A pontuação geral é ponderada explicitamente no código: desempenho 0,20, SEO 0,20, na página 0,15, segurança 0,15, respostas diretas 0,10, acessibilidade 0,10, social 0,10. Os módulos que falham não puxam a pontuação para baixo — saem da ponderação, para que um serviço externo em falha não produza um relatório falso.
Um redirecionamento feito de dentro da aplicação constrói a página e só depois envia a resposta de redirecionamento. Neste site há 11 casos deste tipo, cada um produzindo mais de 200 KB de HTML antes de dizer «vá para outro lado». Funciona, mas é desperdício; movê-los para a configuração é um pequeno trabalho com efeito direto no orçamento de crawl. Está na lista de reparações, escrita como ausência.
Pedimos cinco endereços com 18 identificadores de agente diferentes e comparamos o código, o tamanho e a impressão do conteúdo normalizado. Todos recebem 200 e exatamente o mesmo conteúdo que um browser; `robots.txt` é idêntico, 129 bytes, para todos; não existe bloqueio, desafio ou limitação para crawlers. A única diferença reprodutível — 237 bytes a menos numa página dinâmica, para três agentes — vem da própria framework, que lhes envia HTML completo não em stream, portanto mais conteúdo já renderizado, não menos.
Não prometemos posições, percentagens de crescimento ou um número de visitas. Não temos medições publicáveis para isso e não inventamos. O que entregamos é verificável de outra forma: a lista de endereços com o estado de cada um, as reparações feitas, a verificação executada após a publicação e a diferença mensurável entre o estado de antes e o de depois — em bytes, códigos e números de páginas, não em promessas.
Qué aspecto tiene
A primeira entrega é o ficheiro tabelar com cada endereço e o seu estado em 23 colunas, mais os comandos que o reproduzem. A partir daqui, qualquer discussão tem uma linha por trás. É também o momento em que se descobrem os endereços que ninguém sabia que existiam.
Primeiro, as coisas que se resolvem num só lugar e se aplicam em todo o lado: o endereço canónico, o endereço de partilha, o comportamento da página de erro, as regras para robôs. Depois, as que exigem trabalho por página: títulos, descrições, conteúdo fino. A ordem não é negociável — ao contrário, repara-se cem páginas manualmente por algo que se resolvia com uma linha.
O mapa liga-se às fontes de dados, para que uma nova página entre automaticamente. Os endereços antigos recebem redirecionamentos permanentes na configuração, não no interior da aplicação. Entregamos a lista completa das decisões, endereço por endereço.
Entregamos um script executado após cada publicação, que falha se um endereço canónico tiver desaparecido, se o mapa do site tiver perdido uma página ou se `robots.txt` tiver começado a bloquear recursos de renderização. Sem ele, as reparações erodem-se em poucos meses e ninguém nota até à próxima auditoria.
Se tiver consola de pesquisa e ferramenta de análise, montamos o reporting por cima delas e definimos o que seguimos. Se não tiver, o primeiro passo é tê-las — e dizemo-lo antes, não depois. O que não fazemos: não reportamos posições de uma ferramenta de terceiros como se fossem dados da origem.
Os dados
Las preguntas que hace cualquiera que tenga un delegado de protección de datos — hechas aquí antes de que las haga él.
Un caso
A situação
Um site recentemente reestruturado, com cerca de 250 endereços públicos. Todos respondiam 200 e nada parecia errado. A pergunta inicial não foi «como aumentamos o tráfego», mas «o que declara cada página sobre si própria».
Qué construimos
Percorremos cada endereço com pedidos diretos, sem seguir redirecionamentos, com no máximo seis pedidos em simultâneo, e escrevemos para cada um 23 colunas num ficheiro tabelar versionado junto ao código. Por cima dele, corremos verificações separadas: quem declara que endereço canónico, quem declara que endereço de partilha, que comprimentos têm os títulos e descrições, quantas páginas partilham a mesma descrição do modelo, quanto texto visível tem cada uma, o que responde o servidor a 18 identificadores de agente diferentes, o que oferece em compressão e protocolo. Cada valor foi lido da resposta real, não deduzido da configuração.
Qué salió
244 endereços respondem 200, cinco redirecionam. 131 páginas não declaravam endereço canónico; 219 de 244 declaravam a página inicial como endereço de partilha. Ambos foram corrigidos com uma declaração relativa no layout de base — duas linhas que se aplicam a cada rota, em vez de uma correção em cada página. As restantes constatações entraram num plano com onze passos, pela ordem do impacto: 100 títulos com mais de 60 caracteres, 65 páginas com descrição do modelo, 96 páginas com menos de 2.000 caracteres de texto, 93 endereços indexáveis em falta no mapa, 11 redirecionamentos feitos a partir do interior da aplicação.
Qué no dice el caso
A auditoria foi feita sem acesso à consola de pesquisa e sem dados de tráfego, deliberadamente, e a limitação está escrita no relatório: podemos dizer o que está tecnicamente errado, não o que está a acontecer nos resultados. Dos onze passos do plano, dois estão aplicados hoje; os restantes são trabalhos em aberto, não assinalados. Um relatório que declara todos os passos concluídos no dia em que foi escrito não é um relatório.
Perguntas
O público é diferente. SEO dirige-se a motores que devolvem uma lista de links — a sua página aparece, a pessoa clica. GEO dirige-se a modelos generativos que compõem uma resposta e podem citar uma fonte; aí não há posição e não há garantia, por isso trabalha-se no que pode ser controlado, não no resultado. AEO dirige-se a respostas diretas — o excerto extraído, o painel de informação, a resposta vocal — e apoia-se em dados estruturados corretos. A base é comum: página acessível, renderizada no servidor, com um único endereço oficial. Essa parte faz-se uma vez.
Um ficheiro tabelar com cada endereço do site e o seu estado em 23 colunas — código de resposta, endereço canónico, título, descrição, hreflang, blocos de dados estruturados, volume de texto — mais um relatório escrito com as constatações por ordem de impacto, cada uma com o local no código, o critério e a correção. E os comandos que reproduzem cada valor. No site deste caso saíram 249 linhas; está mesmo no repositório, junto ao código.
Não, e tampouco uma posição específica. Não temos medições publicáveis para resultados deste tipo e não inventamos. O que podemos mostrar é a diferença verificável: quantas páginas não tinham endereço canónico antes e quantas têm agora, quantas declaravam incorretamente o endereço de partilha, quantos endereços antigos ficaram sem redirecionamento. No site deste caso, os valores foram 131, respetivamente 219 de 244. Esses são factos; uma posição prometida não é.
Por um script executado após cada publicação, que verifica os endereços canónicos, as âncoras de conteúdo, o mapa do site e `robots.txt`, e falha se algo desaparecer. As correções de SEO erodem-se exatamente como qualquer outra convenção não escrita: alguém adiciona uma página nova, esquece uma declaração, e ninguém repara até à auditoria seguinte. Um script repara imediatamente.
Ambas têm o seu propósito, mas a análise técnica é feita com um analisador próprio: 16 módulos — on-page, desempenho, mapa do site, segurança, acessibilidade, infraestrutura de nomes, registo de domínio, ligações externas, redes sociais, stack técnica, posições, palavras-chave — mais módulos de comparação com concorrentes. A pontuação global tem ponderações escritas no código, não escondidas: desempenho e SEO 0,20 cada, on-page e segurança 0,15 cada, o resto 0,10 cada. Um módulo que falha sai da ponderação em vez de produzir uma pontuação falsa.
Sinalizamo-las como risco, não como oportunidade. Neste site, 100 dos 147 endereços no mapa são combinações serviço × domínio, e 65 páginas partilham uma única descrição de template — 30 delas diferem entre si por 240 bytes no total. Um motor de busca trata isto como conteúdo produzido em escala, e o risco é uma sanção, não um aumento de visibilidade. A solução é conteúdo real em cada página ou menos páginas. Não recomendamos a geração de páginas como estratégia.
Conta, mas não na forma como costuma ser vendida. Não lhe damos uma pontuação de laboratório, porque é fácil de mover e não diz o que um visitante vive. Damos-lhe bytes medidos: quanto pesa o HTML comprimido, o que é transmitido em cada navegação, o que contêm os pacotes de JavaScript, se o servidor oferece compressão moderna e um novo protocolo. Neste site: não oferece nem Brotli nem HTTP/2, o catálogo de traduções custa cerca de 70 KB comprimidos em cada navegação, e um pacote de 443 KB contém quatro catálogos de idioma dos quais apenas um é usado. Os três estão na lista de reparações.
É uma decisão do proprietário do site, não nossa, e exige separar três categorias que hoje são tratadas de forma idêntica na maioria dos sites: crawlers de pesquisa que enviam pessoas de volta, agentes desencadeados por um humano que pediu a página, e crawlers de treino. As regras para eles são independentes. Neste site existe neste momento uma única regra geral, portanto a posição é implícita — e dizemo-lo, em vez de fingir que é uma estratégia. Os detalhes pertencem à página de visibilidade em respostas geradas.
Não compramos ligações e não construímos redes de sites. Não geramos páginas em escala para cobrir combinações de palavras. Não reportamos posições retiradas de uma ferramenta de terceiros como se fossem dados da origem. E não declaramos uma auditoria concluída sem o ficheiro tabular e os comandos que a reproduzem — um relatório que não pode verificar sozinho não é uma auditoria, é uma opinião.
14 delas são código e ficheiros dos nossos repositórios. Não publicamos o nome nem a linha: juntos, numa única página, descreveriam com demasiada precisão como estão construídos sistemas que não são só nossos. Percorremo-los consigo, no repositório, a pedido — a verificação continua possível, só que se faz numa conversa.
Conte-nos o seu processo. Em conjunto decidimos o que vale a pena construir, o que podemos ligar e como verificamos o resultado.