Construindo meu blog, parte 5: SEO, idiomas e RSS

Um artigo pode abrir normalmente no navegador e ainda se apresentar de forma errada em outros lugares. O título da busca pode ser genérico, a página em português pode anunciar o feed inglês ou um feed de um tema pode trazer todos os textos do blog.

Ao revisar o site, passei a olhar também para essas saídas. O conteúdo publicado precisa continuar identificável quando aparece fora do layout que desenhei para ele.

Identidade visível e metadados têm funções próprias

Na tela, o título e a descrição ajudam a pessoa a entender onde chegou. Nos metadados, o site informa título, descrição, URL e outros dados usados por serviços externos. Esses campos precisam concordar sobre o conteúdo da página, mas não precisam repetir a marca em cada frase visível.

No projeto, os artigos usam dados editoriais para gerar metadados sociais e informações estruturadas. A revisão começa no texto: um título específico, uma descrição que explique o assunto e seções que desenvolvam o que foi prometido. Não faz sentido acrescentar termos de busca que o artigo não explica.

Cada parte desta série tem um foco: arquitetura, leitura, publicação, imagens ou descoberta. Os links entre elas ajudam o leitor a seguir a história sem transformar cinco textos em cinco variações da mesma introdução.

Dois idiomas precisam de endereços claros

O artigo em inglês fica sob /blog/; o português, sob /pt/blog/. A translationKey relaciona os arquivos, enquanto os metadados de idioma apontam para as páginas equivalentes.

Uma URL canônica informa qual endereço representa aquela página. hreflang indica alternativas de idioma. A versão portuguesa não deve tratar a inglesa como se fosse a única página principal e descartar sua própria identidade. As duas versões precisam de links coerentes e correspondentes.

A documentação de versões localizadas do Google explica a relação entre essas alternativas. No meu fluxo, a validação dos arquivos gerados ajuda a encontrar links de tradução incorretos antes da publicação.

O sitemap também deve refletir o que está disponível ao público. Rascunhos ficam fora da publicação normal, e uma prévia não deve ser usada como se fosse o endereço definitivo.

Solicitar indexação não comprova o resultado

No Search Console, há etapas diferentes que podem parecer uma só quando se olha apenas uma mensagem de sucesso:

Um rastreamento depois de uma alteração não demonstra, sozinho, que a descrição nova foi adotada no resultado. Também não garante posição para uma palavra-chave. O próprio Google informa que solicitar novo rastreamento não garante inclusão imediata nem inclusão no índice.

O projeto tem uma rotina de leitura do estado de indexação das páginas principais. Essa consulta serve para acompanhar mudanças e falhas; ela não equivale a enviar um novo pedido nem acompanha automaticamente todo artigo que eu venha a publicar. O conjunto monitorado precisa ser revisto conforme o site cresce.

RSS é outra apresentação do mesmo conteúdo

RSS permite acompanhar publicações em um leitor de feeds. A pessoa assina um endereço e recebe os itens sem precisar visitar a home para descobrir se apareceu algo novo.

Aqui, o feed geral em português fica em /pt/blog/index.xml; o inglês, em /blog/index.xml. Páginas de temas e seções também podem ter feeds próprios. O escopo precisa corresponder à página: se o leitor assina um tema, espera receber publicações daquele tema.

A identificação aparece em duas camadas. O HTML anuncia o feed pelo link de descoberta, e o próprio XML informa título, idioma, link e sua URL self. Uma página em português anunciando o feed inglês seria uma falha mesmo que os dois arquivos fossem XML válido.

Ver captura em tamanho original

O que a revisão do feed precisou conferir

O template parte das publicações elegíveis e aplica o recorte da seção ou do tema antes do limite de cinquenta itens. Assim, um tema menos frequente não desaparece simplesmente porque os cinquenta textos gerais mais recentes são de outros assuntos.

Rascunhos, demonstrações e conteúdo não listado ficam fora; datas futuras também são excluídas. Em produção, o filtro respeita ainda a exclusão de conteúdo marcado como noindex. Isso precisa ser verificado no XML gerado, além de revisar o template.

Dentro do item, imagens e links relativos precisam continuar funcionando fora do site. Um endereço que depende da página atual pode resolver incorretamente no leitor de RSS. O conteúdo do feed resolve essas referências contra a URL do artigo e inclui a capa quando ela existe.

As datas também têm significados separados. pubDate registra a publicação e preserva o deslocamento real, como -0300. Ao revisar um texto publicado, informo lastmod com a data da alteração:

# Exemplo de uma revisão posterior à publicação.
date: 2026-10-19T09:00:00-03:00
lastmod: 2026-10-20T10:30:00-03:00

O lastBuildDate do canal considera a maior data de modificação dos itens incluídos. Neste projeto, editar o arquivo sem preencher lastmod não transforma automaticamente a data do commit em data editorial.

Manter uma rotina que eu consiga repetir

Antes de publicar, reviso título e descrição, tradução, links entre as partes e dados da capa. Depois do build, confiro URLs, feeds e o conjunto de páginas que entrou na publicação. Quando a versão chega à hospedagem, verifico os arquivos servidos.

Se eu começasse novamente, organizaria design e arquitetura mais cedo, separando cada tecnologia e seu propósito. A revisão de SEO e RSS reforçou esse aprendizado: cada saída tem um trabalho próprio, mas todas precisam contar a mesma história sobre o conteúdo.

O site continuará mudando. Quero que essas decisões fiquem registradas para poder voltar a elas quando uma ferramenta, uma integração ou a minha própria ideia de blog mudar.