Bellacosa Mainframe e o SEO

☕ Um Café no Bellacosa Mainframe

👑 KAZUYA SOUMA E O REINO DOS 25 LIMITES DE SEO

Sitemaps, robots.txt, title tags, meta descriptions, Googlebot, conteúdo gerado por IA, AI Overviews, llms.txt, structured data, canonical URLs — e o dia em que um programador COBOL descobriu que metade das “leis do SEO” eram apenas costumes da corte.

🎬 PRÓLOGO — O REINO ESTAVA QUEBRADO, MAS TODOS DISCUTIAM O TAMANHO DO TITLE

Imagine a situação.

Você acaba de ser transportado para outro mundo.

Não recebeu uma espada lendária.

Não ganhou magia infinita.

Não possui um dragão.

Não consegue lançar uma bola de fogo.

Pior ainda: entregaram para você um reino quase falido, uma pilha de relatórios contraditórios e dezenas de ministros repetindo regras que ninguém sabe exatamente de onde vieram.

“Majestade! O title precisa ter exatamente 60 caracteres!”

Outro conselheiro aparece correndo:

“Não! A meta description precisa ter 160!”

Um terceiro entra desesperado:

“O artigo precisa ter 2.000 palavras ou o Google não gosta!”

Do fundo da sala surge outro:

“Precisamos instalar llms.txt imediatamente! É o novo segredo do SEO para inteligência artificial!”

Kazuya Souma olha para todos.

Silêncio.

Ele provavelmente faria aquilo que o tornou interessante em Genjitsu Shugi Yuusha no Oukoku Saikenki (How a Realist Hero Rebuilt the Kingdom): em vez de procurar uma solução espetacular, começaria separando fatos, recursos, limitações e processos.

É exatamente isso que faremos.

Porque administrar SEO em 2026 tem muito menos a ver com decorar números mágicos e muito mais com saber distinguir quatro coisas:

LIMITES TÉCNICOS
REQUISITOS
RECOMENDAÇÕES
BOAS PRÁTICAS

E essa diferença é gigantesca.

Para nosso jovem programador COBOL, podemos traduzir assim:

01 SEO-RULE.
   05 RULE-TYPE        PIC X(20).
   05 RULE-VALUE       PIC X(50).
   05 RULE-SOURCE      PIC X(100).

O problema começa quando alguém coloca tudo em:

IF REGRA = "GOOGLE MANDA"
    PERFORM OBEDECER
END-IF.

Sem verificar se o Google realmente mandou.

Bem-vindo ao Reino de Elfrieden do SEO.

Kazuya está esperando na sala do trono.

E trouxe uma planilha.

👑 CAPÍTULO 1 — A PRIMEIRA REFORMA: SEPARE LEI DE CONSELHO

Esta talvez seja a ideia mais importante de todo este artigo.

Considere:

Sitemap = máximo 50.000 URLs

Isso é um limite técnico.

Agora considere:

Meta description = 150 ou 160 caracteres

Isso não é um limite técnico do Google.

Há uma enorme diferença.

É semelhante a comparar:

05 WS-NOME PIC X(30).

com a recomendação:

“Procure não usar nomes excessivamente longos na interface.”

No primeiro caso existe uma restrição estrutural.

No segundo existe uma decisão de projeto.

Kazuya provavelmente começaria criando quatro ministérios.

Ministério dos Limites Técnicos

Coisas que possuem fronteiras documentadas.

Exemplo:

Sitemap:
até 50.000 URLs
ou
50 MB descompactado

Ministério dos Requisitos

Coisas necessárias para determinada funcionalidade ou formato.

Por exemplo:

Sitemap XML → UTF-8

Ministério das Recomendações

Coisas aconselhadas para melhorar funcionamento, experiência ou apresentação.

Exemplo:

Web Stories → aproximadamente 280 caracteres por página

Não significa que o Google tenha um guarda real executando:

IF STORY-LENGTH > 280
    MOVE "BANIDO DO REINO" TO SEO-STATUS
END-IF.

Ministério das Boas Práticas

Aqui entram decisões editoriais.

Por exemplo, no Bellacosa Mainframe podemos deliberadamente manter descrições SEO compactas, mesmo que não exista uma fronteira rígida de 150 ou 160 caracteres.

Essa disciplina continua útil.

Só não devemos confundir:

“É uma regra editorial que funciona bem para mim.”

com:

“Google tecnicamente proíbe passar desse número.”

Essa distinção é a primeira grande reforma administrativa de Souma.

🗺️ CAPÍTULO 2 — SITEMAP: O MAPA DO REINO

Imagine que Elfrieden possui 40.000 vilas.

Kazuya precisa mandar um funcionário visitar algumas delas.

Seria absurdo dizer:

“Boa sorte. Saia andando.”

Ele entrega um mapa.

O sitemap cumpre uma função semelhante para mecanismos de busca.

Simplificando bastante, ele informa:

Estas são URLs que considero importantes no meu site.

Um sitemap XML poderia conter algo parecido com:

<url>
    <loc>https://exemplo.com/cobol</loc>
</url>

<url>
    <loc>https://exemplo.com/cics</loc>
</url>

<url>
    <loc>https://exemplo.com/db2</loc>
</url>

O sitemap padrão possui dois limites importantes:

50.000 URLs por sitemap e 50 MB quando descompactado.

Perceba o detalhe da descompressão.

Você pode ter:

sitemap.xml.gz

pequeno no disco.

Mas o que interessa para o limite é o conteúdo descompactado.

Nosso COBOLeiro imediatamente reconhece a pegadinha:

tamanho armazenado e tamanho lógico não são necessariamente a mesma coisa.

Se o reino crescer demais, não precisamos jogar o mapa fora.

Criamos vários:

sitemap01.xml
sitemap02.xml
sitemap03.xml
sitemap04.xml

E então usamos um sitemap index.

Pense nele como um catálogo dos mapas:

SITEMAP INDEX
 |
 +-- sitemap-cobol.xml
 +-- sitemap-db2.xml
 +-- sitemap-cics.xml
 +-- sitemap-ims.xml
 +-- sitemap-racf.xml

Um sitemap index pode referenciar até 50.000 sitemaps.

Para um blog pessoal isso é monstruosamente grande.

Para sites de comércio eletrônico, grandes portais e marketplaces, porém, a arquitetura de sitemap passa a ser assunto sério.

🖼️ CAPÍTULO 3 — AS PROVÍNCIAS ESPECIAIS: IMAGENS, NOTÍCIAS E VÍDEOS

Nem todo sitemap trata apenas de páginas comuns.

Existem extensões especializadas.

Em sitemap de imagens, uma única entrada <url> pode conter até 1.000 elementos de imagem.

Algo conceitualmente parecido com:

<url>
   <loc>https://exemplo.com/mainframe</loc>

   <image:image>...</image:image>
   <image:image>...</image:image>
   <image:image>...</image:image>
</url>

Não significa simplesmente:

“Seu site só pode ter 1.000 imagens.”

Esse detalhe é importantíssimo.

A regra refere-se à estrutura daquele sitemap.

É o equivalente a alguém ler:

OCCURS 1000 TIMES

e concluir:

“O mainframe inteiro só suporta mil registros.”

Não!

Você precisa saber a que estrutura o limite pertence.

📰 News Sitemap

Para notícias existe outra administração provincial.

Um sitemap de notícias pode conter até 1.000 elementos de notícias, e o Google estabelece regras específicas para esse tipo de sitemap, inclusive relacionadas à atualidade das publicações.

Isso mostra uma coisa interessante:

SEO técnico é cheio de escopos.

Perguntar:

“Qual é o limite?”

sem perguntar:

“Limite de quê, dentro de qual especificação?”

é uma excelente maneira de produzir informação errada.

🎥 CAPÍTULO 4 — O MINISTÉRIO DO VÍDEO

O sitemap de vídeo possui suas próprias regras.

Uma descrição de vídeo nesse contexto pode chegar a 2.048 caracteres.

Temos também requisitos relacionados à thumbnail.

Um mínimo técnico documentado pode ser muito pequeno, como 60 × 30 pixels, mas seria um erro grotesco interpretar:

“mínimo aceito”

como:

“tamanho recomendado para produzir.”

É aqui que Souma interromperia a reunião.

— Ministros, existe diferença entre conseguir sobreviver com uma tigela de arroz e decidir que uma tigela de arroz é a dieta ideal do reino.

Perfeito.

SEO possui inúmeros números assim.

O fato de algo ser tecnicamente aceito não significa que seja a melhor escolha editorial.

⭐ CAPÍTULO 5 — O PEQUENO FAVICON E A GRANDE CONFUSÃO

O favicon parece insignificante.

Aquele pequeno símbolo exibido associado ao site pode ter enorme importância visual para reconhecimento de marca.

Existem requisitos mínimos e de proporção, incluindo formato quadrado 1:1, e o Google aceita dimensões muito pequenas, embora recomende trabalhar com resoluções maiores para melhor apresentação.

Aqui surge novamente nossa tabela administrativa:

MÍNIMO ACEITO ≠ TAMANHO IDEAL

Essa equação deveria ficar colada na parede de qualquer profissional de SEO.

Programadores já conhecem isso.

Uma aplicação pode tecnicamente funcionar com recursos mínimos.

Isso não significa que você queira colocar produção nessa configuração.

🤖 CAPÍTULO 6 — ROBOTS.TXT: OS GUARDAS DA FRONTEIRA

Agora chegamos a uma parte fascinante.

O arquivo:

robots.txt

fica normalmente na raiz do site.

Exemplo conceitual:

https://exemplo.com/robots.txt

Ele pode fornecer instruções de crawling para robôs compatíveis com o protocolo.

Por exemplo:

User-agent: *
Disallow: /area-interna/

Existe aqui um limite técnico importante: o Google estabelece 500 KiB para o robots.txt; conteúdo além da capacidade processada é ignorado.

Isso é bem diferente do conselho:

“Tente manter o robots.txt pequeno.”

Aqui existe efetivamente uma fronteira de processamento.

E cuidado com outro erro clássico:

robots.txt não deve ser imaginado como RACF.

Isso merece letras gigantes.

ROBOTS.TXT ≠ CONTROLE DE ACESSO

RACF pode efetivamente impedir um usuário não autorizado de acessar determinado recurso.

robots.txt é uma instrução de crawling para agentes que a respeitam.

Portanto jamais trate:

Disallow: /segredo/

como mecanismo de segurança.

É quase como colocar uma placa:

“Favor não entrar.”

e imaginar que instalou uma fechadura.

Souma demitiria o ministro da segurança na mesma tarde.

🕷️ CAPÍTULO 7 — O GOOGLEBOT E O MITO DOS 15 MB

A tabela original apresentava algo como:

Crawler file size = 15 MB default

Esse é um ótimo exemplo do perigo de transformar um número encontrado na internet em verdade eterna.

Documentação muda.

Infraestrutura muda.

Em 2026, o Google esclareceu limites atuais de sua infraestrutura de crawling: para o Googlebot principal, o valor documentado atualmente é 2 MB por URL individual, excluindo PDFs; PDFs possuem tratamento próprio, com limite documentado de 64 MB. O valor de 15 MB continua aparecendo como padrão para outros crawlers da infraestrutura quando não há limite específico.

E aqui está a lição mais importante:

SEO-2022 ≠ SEO-2026

Um artigo antigo pode ter sido perfeitamente correto quando publicado.

Isso não significa que permaneça correto quatro anos depois.

Nosso programador COBOL conhece esse problema.

Um manual de:

Enterprise COBOL 4

pode conter conceitos úteis.

Mas você não deve assumir que cada opção continua idêntica no COBOL moderno.

Versão importa.

Em SEO também.

🏷️ CAPÍTULO 8 — A LENDA DOS 60 CARACTERES

Chegamos a uma das maiores lendas da corte.

Durante anos repetiram:

“Title deve ter no máximo 60 caracteres.”

Só que não existe um limite rígido universal de 60 caracteres para o elemento <title>.

Você pode perfeitamente escrever:

<title>
Um Café no Bellacosa Mainframe — COBOL, CICS, Db2,
VSAM e os Segredos do Reino
</title>

O problema é outro.

O mecanismo de pesquisa precisa apresentar resultados dentro de uma interface.

Dependendo do dispositivo, espaço disponível e outras condições, o título mostrado pode ser truncado ou tratado de maneira diferente.

Portanto a pergunta correta não é:

“Tenho 59 ou 61 caracteres?”

É:

“Meu título comunica rapidamente o assunto e coloca informação importante cedo?”

Isso muda completamente a forma de escrever.

📝 CAPÍTULO 9 — META DESCRIPTION: OS 160 MANDAMENTOS QUE NÃO EXISTEM

Outra lenda:

META DESCRIPTION = MÁXIMO 160

Não existe esse limite rígido.

O snippet apresentado nos resultados pode ser truncado e o Google pode inclusive construir snippets a partir do próprio conteúdo da página.

Então por que continuar produzindo descrições Bellacosa perto de 150 caracteres/bytes como disciplina editorial?

Porque é útil!

Veja a diferença:

REGRA A:
"Não posso passar de 150 porque o Google proíbe."

REGRA B:
"Quero aproximadamente 150 porque desejo uma descrição curta,
reutilizável e informativa."

A primeira justificativa está errada.

A segunda é uma estratégia editorial perfeitamente razoável.

Souma adoraria isso.

Uma regra administrativa não precisa ter sido entregue pelos deuses para ser útil ao reino.

📚 CAPÍTULO 10 — QUANTAS PALAVRAS UM ARTIGO PRECISA?

E agora chegamos a uma deliciosa ironia.

Este próprio artigo foi solicitado com:

mais de 1.500 palavras.

Excelente.

Mas essas 1.500+ palavras têm uma finalidade editorial: queremos aprofundamento, exemplos, analogias e contexto.

Não estamos escrevendo 1.500 palavras porque existe algo no Google parecido com:

IF WORD-COUNT < 1500
    MOVE ZERO TO GOOGLE-RANKING
END-IF.

Isso simplesmente não existe.

Uma página explicando:

“O que significa RC=0000?”

pode resolver a dúvida rapidamente.

Já uma página explicando:

“Como funciona uma transação COBOL/CICS/Db2?”

pode legitimamente precisar de milhares de palavras.

O tamanho correto é consequência da profundidade necessária.

Não deveria ser objetivo independente.

🤖 CAPÍTULO 11 — O EXÉRCITO DE ESCRITORES ARTIFICIAIS CHEGA AO REINO

Então aparecem os escribas mágicos.

IA generativa.

De repente alguém pergunta:

“Qual porcentagem de IA o Google permite?”

10%?

30%?

50%?

Existe detector?

Há limite de palavras?

A pergunta começa pelo lugar errado.

Não existe uma cota universal do tipo:

HUMANO 70%
IA     30%

O problema relevante é qualidade e finalidade.

Imagine usar IA para produzir automaticamente:

10 páginas
100 páginas
10.000 páginas
1.000.000 páginas

apenas alterando palavras-chave e criando conteúdo sem valor real.

A questão deixa de ser:

“Foi IA?”

e passa a ser:

“Isso existe para ajudar pessoas ou para manipular sistemas de busca em escala?”

Esse ponto é fundamental.

IA pode ajudar a:

organizar conhecimento;
revisar texto;
gerar exemplos;
estruturar tópicos;
transformar documentação complexa em material didático;
comparar conceitos;
criar perguntas;
encontrar lacunas no raciocínio.

Mas:

IA + VOLUME

não produz automaticamente:

AUTORIDADE + QUALIDADE

🧠 CAPÍTULO 12 — AI OVERVIEWS E O NOVO CONSELHO REAL

Com AI Overviews e experiências generativas de pesquisa, muita gente anunciou:

“SEO morreu!”

Depois:

“SEO virou GEO!”

Depois:

“Agora precisamos escrever exclusivamente para LLMs!”

Souma provavelmente perguntaria:

— Temos evidência?

A documentação do próprio Google continua enfatizando fundamentos conhecidos: páginas rastreáveis, conteúdo útil, estrutura compreensível, qualidade, confiabilidade e boas práticas técnicas.

Ou seja, não apareceu uma magia chamada:

PERFORM RANK-IN-AI
   UNTIL POSITION = 1.

A busca está mudando profundamente.

Mas fundamentos continuam fundamentais.

É parecido com modernização de mainframe.

Adicionar:

REST
JSON
OpenAPI
z/OS Connect
Kafka
OpenTelemetry

não significa que:

COBOL
CICS
Db2
RACF

deixaram instantaneamente de importar.

A nova camada normalmente conversa com a antiga.

📜 CAPÍTULO 13 — LLMS.TXT: O PERGAMINHO MÁGICO

Poucas coisas representam melhor a ansiedade provocada pela IA que:

llms.txt

A ideia parece sedutora.

Temos:

robots.txt
sitemap.xml

Logo parece natural imaginar:

llms.txt

como:

“o sitemap das inteligências artificiais”.

Só que esse salto lógico é perigoso.

Para Google Search, o próprio Google esclareceu em 2026 que llms.txt não é necessário para melhorar ranking ou visibilidade.

Isso não significa que o formato jamais possa ter utilidade em outros ecossistemas.

Significa apenas:

llms.txt
   ≠
botão secreto para Google AI

E aqui escondemos nosso primeiro easter egg.

Imagine Kazuya recebendo um pergaminho:

“Majestade! Descobrimos o segredo definitivo do reino!”

Ele abre.

Está escrito:

LLMS.TXT

Kazuya consulta Hakuya.

Hakuya responde:

“Não consta no orçamento.”

Fim da reunião.

🧩 CAPÍTULO 14 — STRUCTURED DATA: NÃO É ENCHER JSON-LD ATÉ EXPLODIR

Structured data ajuda sistemas a compreender entidades e informações estruturadas.

Você pode encontrar JSON-LD parecido com:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Kazuya Souma e os Limites do SEO"
}

Mas a conclusão errada seria:

“Não existe limite geral de caracteres, então quanto mais structured data eu colocar, melhor.”

Não.

Os tipos possuem propriedades, requisitos e recomendações próprias.

E principalmente:

o dado estruturado deve representar o conteúdo real.

Structured data não deveria contar uma história diferente daquela que a página conta ao visitante.

🔗 CAPÍTULO 15 — CANONICAL: QUEM É O REI LEGÍTIMO?

Imagine cinco URLs mostrando praticamente o mesmo conteúdo:

/artigo
/artigo?ref=facebook
/artigo?utm_source=x
/artigo?versao=1
/artigo?origem=newsletter

Quem representa aquele conteúdo?

Entra:

<link rel="canonical"
      href="https://exemplo.com/artigo">

Conceitualmente estamos dizendo:

“Esta é a versão representativa que prefiro.”

Canonicalização é muito mais importante que ficar perguntando:

“Quantos caracteres uma canonical URL pode ter?”

É quase uma crise sucessória.

Temos cinco pretendentes ao trono.

Canonical ajuda a indicar:

👑 “Souma é o rei.”

🔤 CAPÍTULO 16 — UTF-8 ENTRA NO DATACENTER E O COBOLERO OLHA DESCONFIADO

Sitemaps XML devem utilizar UTF-8.

Nesse momento nosso veterano olha para a tela:

“EBCDIC mandou lembranças.”

😂

Esse é um ótimo exemplo para iniciantes entenderem modernização.

Seu COBOL pode trabalhar dentro de um ambiente historicamente ligado ao EBCDIC.

Mas quando atravessamos fronteiras:

Mainframe
    |
    +-- API
    +-- XML
    +-- JSON
    +-- Web
    +-- Linux
    +-- Browser

precisamos respeitar os padrões daquele ecossistema.

Modernização não significa necessariamente destruir o legado.

Muitas vezes significa traduzir corretamente nas fronteiras.

📱 CAPÍTULO 17 — OS 280 CARACTERES DAS WEB STORIES

Outro excelente exemplo de recomendação transformada em “lei”.

Aproximadamente 280 caracteres por página aparecem como orientação de experiência para Web Stories.

Por quê?

Porque uma Story não deveria parecer:

IDENTIFICATION DIVISION.
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.

espremida dentro da tela de um telefone.

😂

Web Story é formato visual.

Muito texto destrói a experiência.

Logo:

~280 caracteres

é uma orientação de design e legibilidade.

Não significa:

281 = ABEND S0C7

Easter egg número dois detectado.

🛠️ CAPÍTULO 18 — O PASSO A PASSO DE KAZUYA PARA UMA AUDITORIA

Agora vamos administrar o reino.

Quando encontrar uma lista de “novos limites SEO”, não saia imediatamente alterando seu site.

Faça o seguinte.

PASSO 1 — Identifique a afirmação

Exemplo:

Title máximo = 60 caracteres

PASSO 2 — Pergunte qual é a natureza dela

É:

limite técnico?
requisito?
recomendação?
boa prática?
opinião?

PASSO 3 — Procure a fonte primária

Prefira documentação oficial.

Não faça:

POST LINKEDIN
   ↓
BLOG QUE CITOU OUTRO BLOG
   ↓
THREAD
   ↓
VÍDEO
   ↓
"GOOGLE DISSE"

Procure chegar ao documento original.

PASSO 4 — Verifique a data

Uma informação de 2022 pode ter sido correta em 2022 e não representar 2026.

PASSO 5 — Descubra o escopo

“1.000 imagens” significa:

1.000 no site?
1.000 no sitemap?
1.000 por URL?
1.000 por domínio?

Uma palavra muda tudo.

PASSO 6 — Não confunda mínimo com recomendado

MINIMUM != OPTIMUM

PASSO 7 — Teste

Search Console, analytics, logs, indexação e comportamento real devem complementar documentação.

Souma não administraria o reino apenas lendo manuais.

Ele mediria os celeiros.

🔍 CAPÍTULO 19 — A AUDITORIA BELLACOSA MAINFRAME

Para um blog técnico, eu priorizaria uma auditoria aproximadamente nesta sequência lógica:

RASTREAMENTO
      ↓
INDEXAÇÃO
      ↓
CANONICALIZAÇÃO
      ↓
SITEMAP
      ↓
ARQUITETURA
      ↓
LINKS INTERNOS
      ↓
TÍTULOS
      ↓
DESCRIÇÕES
      ↓
CONTEÚDO
      ↓
IMAGENS
      ↓
DADOS ESTRUTURADOS
      ↓
PERFORMANCE
      ↓
ANALYTICS

Observe o que não aparece:

CONTAR PALAVRAS ATÉ 2.000

Também não aparece:

CORTAR TITLE NO CARACTERE 60

Muito menos:

INSTALAR LLMS.TXT E REZAR

A preocupação deveria ser:

O Google consegue descobrir a página?

Depois:

Consegue rastreá-la?

Depois:

Entende qual URL representa aquele conteúdo?

Depois:

A página responde realmente a alguma necessidade?

Depois:

Existe alguma razão para alguém preferir esse conteúdo a centenas de páginas semelhantes?

Essa última pergunta é cruel.

Mas é excelente.

💡 CAPÍTULO 20 — CURIOSIDADES QUE O APRENDIZ COBOL DEVE GUARDAR

SEO possui uma característica curiosamente parecida com mainframe.

Existe uma camada enorme de folclore criada em torno da tecnologia.

No mainframe ouvimos:

“COBOL está morto.”

“Mainframe não tem API.”

“Mainframe não usa TCP/IP.”

“Tudo é batch.”

“Não existe DevOps.”

Em SEO:

“60 caracteres.”

“160 caracteres.”

“2.000 palavras.”

“Keyword density.”

“IA será penalizada automaticamente.”

“llms.txt fará você aparecer nas respostas de IA.”

Quando repetidas milhares de vezes, afirmações ganham aparência de especificação.

Mas engenharia exige outra coisa:

AFIRMAÇÃO
   ↓
FONTE
   ↓
CONTEXTO
   ↓
VERSÃO/DATA
   ↓
TESTE
   ↓
EVIDÊNCIA

Esse fluxo serve tanto para SEO quanto para investigar um incidente no z/OS.

🥚 EASTER EGG — INCIDENTE ÀS 03:17

São 03:17 da madrugada.

O telefone toca.

O blog perdeu tráfego.

O jovem SEO entra desesperado na War Room:

“Majestade! Deve ser porque nosso title tem 63 caracteres!”

Kazuya pergunta:

— A página está indexada?

Silêncio.

— Verificaram canonical?

Silêncio.

— Sitemap?

Mais silêncio.

— robots.txt?

Ninguém responde.

— Houve alteração no template?

O programador COBOL levanta lentamente a mão.

“Majestade... ontem alguém alterou o template do Blogspot e colocou noindex.”

Kazuya fecha os olhos.

Hakuya abandona a sala.

Liscia pergunta por que contrataram 14 consultores para contar caracteres.

E o velho COBOLeiro toma outro café.

Easter egg desbloqueado: RC=0317.

🏰 EPÍLOGO — COMO O HERÓI REALISTA RECONSTRUIRIA O REINO DO SEO

A grande lição desses “25 novos limites” não está nos 25 números.

Está justamente em aprender quando não procurar um número.

Existem fronteiras técnicas reais:

50.000 URLs por sitemap
50 MB descompactado
50.000 sitemaps por sitemap index
1.000 imagens por URL no image sitemap
1.000 entradas em news sitemap
2.048 caracteres na descrição específica de video sitemap
500 KiB de robots.txt

Existem requisitos:

UTF-8 em sitemap
estruturas XML corretas
URLs apropriadas ao contexto

Existem recomendações:

favicon em tamanho adequado
Web Stories sem muralhas de texto
titles claros
descriptions concisas

E existem mitos:

TITLE TEM OBRIGATORIAMENTE 60
META DESCRIPTION TEM OBRIGATORIAMENTE 160
ARTIGO PRECISA TER 2.000 PALAVRAS
GOOGLE ACEITA X% DE IA
LLMS.TXT É O NOVO ROBOTS.TXT DO GOOGLE

É aí que Kazuya Souma deixa de ser apenas nossa referência de anime e se torna uma ótima metáfora para engenharia.

O protagonista realista não resolve todos os problemas usando uma espada.

Ele pergunta:

Quais recursos temos?

Qual é o problema verdadeiro?

Quais regras realmente existem?

Quem disse isso?

Os dados confirmam?

Como podemos melhorar o sistema sem desperdiçar recursos?

Esse pensamento serve perfeitamente para um programador COBOL iniciante.

Quando alguém disser:

“Mainframe funciona assim.”

Pergunte:

Em qual sistema?

Quando disser:

“COBOL não consegue fazer isso.”

Pergunte:

Qual versão?

Quando disser:

“Google exige isso.”

Pergunte:

Onde está documentado?

Quando disser:

“O limite é X.”

Pergunte:

Limite técnico ou recomendação?

Quando disser:

“Sempre fizemos assim.”

Aí, meu jovem padawan COBOL, você acaba de encontrar o equivalente tecnológico daquele ministro do reino que não sabe por que existe determinado imposto, mas continua cobrando porque seu antecessor também cobrava.

☕ E essa talvez seja a verdadeira lição de Kazuya Souma aplicada ao SEO:

não administre tecnologia por superstição. Administre por especificação, contexto, evidência e resultado.

Porque no fim das contas, seja reconstruindo Elfrieden, mantendo um programa COBOL de quarenta anos ou tentando fazer o Google entender um Blogspot em 2026, a regra continua a mesma:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. SEO-REALISTA.

       PROCEDURE DIVISION.

       INVESTIGAR.
           PERFORM LER-DOCUMENTACAO.
           PERFORM IDENTIFICAR-CONTEXTO.
           PERFORM VALIDAR-LIMITES.
           PERFORM TESTAR-RESULTADO.

           IF BOATO = TRUE
               MOVE "NAO ACREDITE AINDA"
                 TO DECISAO
           END-IF.

           IF EVIDENCIA = TRUE
               PERFORM TOMAR-DECISAO
           END-IF.

           STOP RUN.

E se alguém aparecer na próxima reunião dizendo que mudar uma meta description de 161 para 159 caracteres vai sozinho salvar o reino...

mande-o primeiro conferir se o castelo inteiro não está com noindex.

MAXCC=0000. Reino reconstruído. Café servido. ☕👑

Translate

quarta-feira, 16 de fevereiro de 2022