Figueirego Blog – Bastidores do blog

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

Mon, 19 Oct 2026 04:15:50 -0300

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:

Evidência	O que permite concluir
Pedido aceito	A solicitação foi recebida.
Página já indexada	Existe uma versão da página no índice.
Novo rastreamento	O Google voltou a consultar a página.
Resultado exibido na busca	É possível observar como ela apareceu naquela consulta.

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.

A página pública de RSS em português apresenta o endereço correspondente ao idioma. O leitor assina essa URL em seu aplicativo de feeds.

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.

Construindo meu blog, parte 4: imagens no S3 pelo Finder

Mon, 19 Oct 2026 04:15:50 -0300

Selecionar uma imagem, usar o botão direito e receber uma URL pronta para o artigo. Era esse o tipo de facilidade que eu queria trazer para a rotina do blog. A automação da AWS foi a parte mais trabalhosa depois do design.

O caminho começou com um auxiliar de upload e chegou a uma Ação Rápida no Finder. O caso feliz era simples de descrever. O trabalho apareceu nas perguntas seguintes: o que acontece quando a sessão expira, quando eu desisto do login ou quando o envio falha?

Páginas na Hostinger, imagens no S3

O S3 armazena objetos: neste caso, os arquivos das imagens. As páginas continuam na Hostinger. O Markdown guarda a URL pública do arquivo e o navegador busca a imagem nesse endereço.

Isso separa o envio da imagem do build do site. Colocar um arquivo no repositório não executa um upload para a AWS. Também existem assets locais que acompanham o build; o fluxo das novas imagens editoriais usa o S3.

Uma URL de imagem publicada precisa continuar funcionando quando minha sessão termina. Por isso, o endereço usado no artigo não é um link assinado temporário. O prefixo das imagens tem leitura pública configurada, enquanto a escrita exige autenticação. O script de envio não transforma qualquer bucket privado em público.

O que chamo de versões das imagens

Cada envio recebe um nome novo, com ano, mês, nome normalizado e um identificador. Um caminho ilustrativo seria:

images/2026/10/minha-capa-identificador-unico.webp

Se corrigir uma capa, envio outro arquivo e atualizo a referência no artigo. A imagem anterior continua disponível até ser removida. Isso ajuda a evitar que uma URL com cache longo passe a representar outro arquivo sem controle.

Esse mecanismo é diferente do S3 Versioning, que mantém versões de um mesmo objeto dentro do bucket. Aqui estou descrevendo novas chaves e novas URLs. Não basta ter dois arquivos para afirmar que o recurso nativo de versionamento está ativado.

O histórico do Git registra as alterações na referência do artigo. Ele não é, por si só, um backup dos arquivos externos. Preservar e recuperar as imagens exige cuidar também do armazenamento delas.

Um usuário dedicado ao envio

O atalho usa um perfil da AWS CLI com credenciais temporárias de um usuário dedicado. Não depende da sessão root e não guarda uma chave permanente dentro do projeto.

A conta e as permissões são preparadas antes. O auxiliar usa esse destino existente; não provisiona um ambiente AWS inteiro. O login local pelo navegador da AWS CLI permite renovar a autenticação sem colocar senha ou código no artigo, no script ou em uma conversa.

No projeto configurado, a instalação da Ação Rápida parte da raiz:

python3 blog/scripts/install-finder-upload.py

Esse comando pertence ao repositório privado e requer o ambiente descrito acima. Ele não é um instalador público universal para qualquer conta AWS. Para reproduzir a ideia, é preciso adaptar destino, perfil e permissões ao próprio ambiente.

A rotina no Finder

Com a ação instalada, seleciono a imagem e uso Ações Rápidas → Enviar imagem ao S3 — Figueirego. Após o envio, a ação copia a URL e apresenta a notificação de conclusão. Não preciso abrir o Terminal para a rotina normal.

Se a sessão expirou, o atalho abre a autenticação no navegador e aguarda a conclusão. Depois do login autorizado, continua o envio. Foi importante testar o caminho completo pelo Finder: executar o auxiliar no Terminal não demonstraria, sozinho, que o aviso aparecia pela ação do macOS.

Também conferimos a URL pública e a imagem recebida. Uma mensagem de conclusão ajuda, mas não substitui verificar se o arquivo certo está acessível fora da sessão AWS.

A ação instalada no Finder, acessível pelo botão direito sobre a imagem. O menu foi aberto para esta captura, sem executar outro upload.

Ver captura em tamanho original

Cancelar também faz parte da interface

Esperar cinco minutos para descobrir que um login foi abandonado era ruim. A espera ganhou uma janela com Cancelar envio, para encerrar aquela tentativa de forma explícita.

Situação	Comportamento esperado
Sessão válida	Enviar, copiar a URL e avisar a conclusão.
Sessão expirada	Abrir o login e continuar depois de autenticar.
Cancelamento enquanto aguarda login	Avisar, não enviar a imagem e preservar o conteúdo copiado.
Nova tentativa após cancelar	Permitir iniciar o fluxo novamente.

Fechar apenas a aba do navegador não equivale a apertar o botão de cancelamento. E esse botão cancela a espera pela autenticação; ele não promete interromper um upload que já começou.

Testamos a espera primeiro com uma AWS simulada e depois com login real. As duas verificações respondem a perguntas diferentes: a simulação ajuda a controlar o cenário; o teste real confirma a integração que será usada.

Da imagem no Finder à URL copiada. O cancelamento durante o login encerra o fluxo antes do envio.

Abrir diagrama em tamanho original

O que ainda precisa de cuidado

Não removo automaticamente uma imagem antiga só porque enviei outra. Ela pode continuar referenciada por um rascunho, por outro texto ou por um feed já recebido. A limpeza precisa considerar essas referências.

Se o upload concluir, mas a cópia para a área de transferência falhar, isso também não desfaz o objeto enviado. É preciso distinguir falha de envio de falha na última etapa da conveniência, para não repetir uploads sem necessidade.

A automação tornou a rotina mais curta. O aprendizado foi dedicar atenção também aos caminhos de desistência e recuperação: uma ferramenta simples de usar precisa explicar quando terminou, quando falhou e o que aconteceu com o arquivo.

Construindo meu blog, parte 3: do Markdown à publicação

Mon, 19 Oct 2026 04:15:50 -0300

Salvar um artigo no editor não significa que ele está publicado. O texto ainda precisa ser revisado, gerar uma página, passar pelas verificações e chegar à hospedagem. Depois disso, preciso abrir o endereço público e conferir o que o leitor recebeu.

Essa distinção ficou importante ao integrar blog e portfólio. Na primeira versão, o blog tinha um fluxo separado. Hoje, as duas partes saem do mesmo repositório e são entregues pela aplicação Next.js na Hostinger. O subdomínio antigo deixou de ser o destino.

O artigo começa com texto e metadados

Escrevo em Markdown. Antes do corpo, um bloco de dados chamado front matter informa como o artigo deve ser apresentado. Este é um exemplo reduzido, não um arquivo pronto para publicar:

---
title: "Como organizei meu blog"
date: 2026-10-19T09:00:00-03:00
draft: true
author: "Matheus Figueirêdo"
translationKey: how-i-organized-my-blog
description: "As decisões para organizar conteúdo, navegação e publicação."
tags: ["Hugo", "publicação"]
---

A data precisa corresponder à publicação real. draft: true mantém o texto fora do build público. Na tradução, o título, a descrição, os temas e o corpo mudam; a translationKey continua igual.

Uma capa pode ser acrescentada depois. Quando existe, precisa de URL, descrição alternativa e dimensões correspondentes ao arquivo. O artigo deve continuar legível sem depender da imagem para informar seu assunto.

Duas prévias para perguntas diferentes

Para revisar apenas os textos, posso usar o servidor do Hugo. Estes comandos partem da raiz do repositório e pressupõem Hugo extended na versão fixada pelo projeto:

cd blog
hugo server --buildDrafts --bind 127.0.0.1

A opção inclui rascunhos na prévia local. É útil para conferir texto, sumário e tradução. Para avaliar a integração com o portfólio, uso o projeto completo, em outro terminal:

cd client
npm ci
npm run dev

Esse caminho pressupõe Node.js 24.12.0 ou superior e Hugo extended 0.167.0 no ambiente. O script de desenvolvimento monta o blog no início. Depois de editar Markdown, preciso reconstruir essa parte com node scripts/build-blog.mjs --preview e recarregar a página. Ele não substitui o acompanhamento de arquivos do servidor Hugo dedicado, e o build integrado normal continua excluindo rascunhos.

Os comandos dependem dos auxiliares deste repositório privado. Para outro projeto, a ideia reproduzível é manter uma prévia rápida do conteúdo e outra que exercite a integração completa.

A versão que passa pelos testes é a que segue adiante

O fluxo atual é:

arquivos revisados → dev → main
 ↓
 testes e build integrado
 ↓
 SHA aprovado → production
 ↓
 Hostinger
 ↓
 conferência do site público

SHA é o identificador de um commit. Usá-lo na promoção permite relacionar a versão testada à versão enviada para publicação. A CI não deve aprovar um commit e promover silenciosamente outro que chegou depois.

O comando central de verificação, executado em client/, é:

node scripts/verify-release.mjs --production

Ele reúne checagem de tipos, lint, formatação, testes, build Next.js com Hugo e verificação dos arquivos gerados. Para conhecer as etapas sem executá-las, uso --dry-run. Nenhuma dessas opções, sozinha, envia código ao GitHub.

Depois dos checks da main, a automação promove o commit aprovado para production. A Hostinger acompanha essa branch. Se a main avançou durante a execução, a versão nova precisa passar por sua própria verificação. A promoção não deve atropelar o histórico com um envio forçado.

Revisar, testar, publicar e conferir: as quatro etapas do fluxo de entrega deste site.

Abrir diagrama em tamanho original

Conferir três resultados separados

Um check verde mostra o resultado da verificação. O deployment na Hostinger informa se a hospedagem conseguiu construir e iniciar a versão correspondente. Abrir as páginas públicas mostra o que está sendo entregue.

Por isso, a conferência inclui os dois idiomas, os links do artigo, as imagens, o RSS e o caminho de volta ao restante do site. Também preciso olhar o SHA da implantação. Um código de resposta HTTP 200 não demonstra que todos os componentes da página funcionaram.

Para conteúdo, há uma verificação adicional: confirmar que um rascunho não entrou na busca, no sitemap ou no feed. Uma prévia que inclui rascunhos não pode ser copiada para produção como se fosse o build público.

Recorte real do deploy concluído em 19/10/2026, referente à publicação inicial desta série com as capas. A hospedagem identifica o commit que recebeu.

Ver captura em tamanho original

Os mais lidos também passam por publicação

O GoatCounter fornece estatísticas de visitas. Uma rotina no GitHub consulta esses dados e grava um snapshot em blog/data/popular.json. O build incorpora esse resultado e entrega um arquivo público em /blog/popular.json.

O navegador pode atualizar as listas a partir desse arquivo, sem receber o token de consulta ao GoatCounter. A rotina de coleta tem execução diária e tentativas de recuperação. Horários agendados dependem dos provedores; não são uma garantia de atualização no segundo marcado.

Semana e mês representam os sete e trinta dias completos anteriores, em UTC. As versões de um mesmo artigo são agregadas pela identidade editorial. Isso conta visitas registradas, não pessoas únicas entre idiomas nem prova de leitura completa.

Quando a coleta falha, o fluxo conserva o snapshot anterior em vez de publicar números inventados. Uma atualização válida ainda precisa passar pela verificação e chegar à hospedagem. Monitorar o JSON público ajuda a detectar a diferença entre ter coletado dados e ter publicado esses dados.

Essa rotina faz parte do custo de manter o site. Automatizar ajuda, mas o resultado importante continua sendo o conteúdo correto no endereço que a pessoa abre.

Construindo meu blog, parte 2: design para entender e explorar

Mon, 19 Oct 2026 04:15:50 -0300

O terminal antigo fazia sentido para mim, mas podia exigir demais de quem visitava. Uma pessoa procurando conhecer meu trabalho não deveria precisar descobrir um comando para encontrar uma informação. Ao adaptar essa área para um desktop, quis aproveitar uma linguagem mais familiar: abrir, explorar e fechar janelas.

Isso não resolveu o design inteiro. Um desktop também pode confundir se tudo depender dele. O site tem páginas próprias para apresentação, projetos, textos e contato; a área interativa é uma possibilidade de exploração. O caminho convencional continua disponível.

Acertar essa combinação foi a parte mais trabalhosa da construção. Eu queria que o site transmitisse minha imagem e que a pessoa entendesse o que estava vendo. A aparência precisava ajudar nessa leitura.

Uma referência para apresentar, outra para construir

No Zeno Rocha, me chamou a atenção a maneira de se apresentar e dar visibilidade ao próprio trabalho mantendo a navegação intuitiva. No Akita, a referência foi principalmente a construção do blog e suas ideias. Não eram duas interfaces que eu pretendia juntar literalmente.

Ao experimentar com Claude, Antigravity e depois Codex com skills, fui refinando uma proposta que precisava combinar com o restante do meu site. Um resultado visual interessante ainda podia ter espaçamento ruim, informação demais no mesmo lugar ou uma interação pouco clara.

Isso apareceu especialmente nas capas dos artigos. Eu queria conservar título, resumo, autor, data, tempo de leitura e temas. Quando essas informações ficaram muito juntas, a imagem grande não compensou a falta de hierarquia. O degradê também precisou de revisão: uma transição que parecia aceitável no tema escuro podia formar uma faixa pesada no claro.

Dar uma função a cada área

Os destaques apresentam uma seleção de até três textos. Os recentes mostram o que foi publicado por último e podem repetir um destaque. O Arquivo oferece um caminho para explorar mais conteúdo e filtrar o que interessa.

Os temas aparecem como pequenos rótulos, sem o símbolo de hashtag. O rótulo comunica uma categoria; a aparência precisa continuar reconhecível como algo em que se pode clicar. Da mesma forma, um link de retorno deve dizer para onde leva. Um texto que promete voltar ao Arquivo precisa realmente levar ao Arquivo.

Esse tipo de detalhe parece pequeno quando avaliado sozinho. Junto, ele determina se a pessoa consegue prever o próximo passo. Meu critério passou a ser observar a função de cada elemento, além da sua posição na captura de tela.

Prévia local do Arquivo em 19/10/2026: busca, filtros e temas têm funções distintas na navegação.

Ver captura em tamanho original

Movimento precisa acompanhar a ação

As imagens dos destaques ficam em preto e branco nos dispositivos com mouse e ganham cor ao passar o ponteiro. A primeira troca parecia direta demais. Ajustamos a transição para dar tempo de perceber a mudança, com uma ampliação discreta da imagem.

O mesmo cuidado apareceu no sumário. Ao clicar do primeiro para o último tópico, o indicador não deveria disputar atenção com cada seção intermediária durante a rolagem. A navegação passou a tratar esse deslocamento como uma ação com um destino escolhido.

Esses efeitos precisam ter alternativas. No celular, não existe um hover confiável como no mouse. Pelo teclado, o foco precisa aparecer sem depender de uma animação lenta. Para quem pede movimento reduzido no sistema, deslocamentos e transições devem ser reduzidos ou removidos. A preferência é lida com a media query prefers-reduced-motion.

O objetivo não é fazer o visitante esperar por um efeito para conseguir usar o site. O movimento deve explicar o que está mudando e permitir continuar a navegação.

Captura real da leitura em português. O sumário mantém a seção selecionada visível ao lado do texto.

Ver captura em tamanho original

Ler em português ou inglês

A versão em português do blog fica em /pt/blog/; a inglesa, em /blog/. Cada artigo tem um arquivo por idioma. A ligação entre eles usa a mesma translationKey:

# Nos dois arquivos; o título e o texto são traduzidos.
translationKey: building-blog-reading

O seletor leva à versão correspondente quando ela existe. Ele não traduz automaticamente o texto. Isso exige revisar também resumos, rótulos, texto alternativo das imagens e links entre as partes da série.

A busca usa um índice local com texto, títulos e outros campos editoriais. Ela ajuda a localizar uma palavra dentro de um artigo; filtros do Arquivo ajudam a reduzir uma coleção por critérios. São tarefas próximas, mas não idênticas.

Comentários reais e limites do teste

Mantive o Disqus existente. Botões de reação que guardavam apenas uma escolha no navegador não entregavam uma interação real comigo, então essa proposta ficou de fora.

O carregamento dos comentários mostrou por que uma captura bonita não comprova funcionamento. Foi preciso revisar o domínio autorizado no Disqus e testar a abertura automática. Também houve interferência de ferramentas e mudanças de aba durante verificações. O diagnóstico precisava separar falha do serviço, configuração do site e problema no próprio teste.

Em produção, os comentários tentam carregar automaticamente. O botão de tentar novamente é uma recuperação para falhas. Nas prévias, a integração de produção fica desativada para não misturar ensaios com conversas reais.

Hoje eu revisaria uma tela percorrendo suas tarefas: encontrar um texto, trocar idioma, usar o sumário, voltar à listagem e localizar outro assunto. Repetiria isso com teclado, tema claro e escuro e uma largura de celular. Emulação ajuda a encontrar problemas de layout, mas não equivale a testar um aparelho físico. É esse uso que mostra se o design está cumprindo sua função.

Construindo meu blog, parte 1: da landing page ao site

Mon, 19 Oct 2026 04:15:50 -0300

Eu já tinha um projeto de site. Era uma landing page, com uma ideia que eu ainda queria manter, mas que precisava de mais espaço. Resolvi reaproveitar essa base, subdividir o conteúdo e melhorar a forma de apresentar meu trabalho e as coisas sobre as quais queria escrever.

Uma das mudanças mais visíveis foi transformar uma experiência de terminal em um desktop. O terminal tinha uma linguagem muito voltada para quem programa. Eu queria que uma pessoa pudesse explorar o site sem precisar conhecer comandos. Janelas e ícones me pareceram um ponto de partida mais familiar, embora isso ainda precisasse funcionar bem na prática e no celular.

O blog entrou nessa mesma construção. Meu receio ao juntar os dois era confundir a navegação e não conseguir ser claro sobre o que cada área oferecia. Por isso, esta série começa pela organização do projeto. O código veio acompanhado de decisões sobre comunicação.

O desktop real do portfólio: janelas e pastas como alternativa de exploração, mantendo a navegação convencional disponível.

Ver captura em tamanho original

Referências com papéis diferentes

O blog do Akita me ajudou com a construção do blog e com ideias para a rotina de publicação. Já o site do Zeno Rocha foi uma referência de apresentação: como mostrar o próprio trabalho e deixar a exploração intuitiva.

Usei essas referências para estudar o que poderia melhorar, reaproveitar ou descartar. Eu tinha uma ideia própria para preservar e precisava entender quais soluções ajudavam a expressá-la. A parte mais trabalhosa acabou sendo acertar o design para transmitir essa identidade.

As IAs participaram desse estudo. Concentrei mais no Codex a busca de informação e a investigação do projeto; usei Claude e Antigravity principalmente no design. Depois voltei ao Codex com skills para separar e aprofundar cada conceito. Essa divisão descreve meu processo, não uma regra sobre qual ferramenta qualquer pessoa deveria usar.

Onde termina o site e começa o blog

Hoje, o portfólio usa Next.js, React e TypeScript. Os artigos ficam em Markdown e são gerados pelo Hugo. O Hextra serve como base do tema, com personalizações em arquivos do projeto.

O Hugo é um gerador: lê o texto e seus metadados e produz HTML, CSS, JavaScript e índices. O Next.js reúne esse resultado com as páginas do portfólio. A Hostinger executa a aplicação Next.js e entrega o conjunto no mesmo domínio.

blog/content/ → Hugo → páginas, busca e feeds do blog
 ↓
 client/public/blog/
 client/public/pt/blog/
 ↓
 Next.js + páginas do portfólio → Hostinger

Isso corrige uma descrição da primeira versão do projeto, quando o blog estava separado. O conjunto atual tem um servidor Next.js em produção; o Hugo só roda na geração dos arquivos. Os artigos não precisam de uma API própria de edição ou de um banco de dados para montar seu conteúdo a cada visita.

Markdown passa pelo Hugo; arquivos gerados são integrados ao Next.js e entregues pela Hostinger.

Abrir diagrama em tamanho original

Cada tecnologia precisa ter um trabalho claro

Componente	Responsabilidade neste projeto
Markdown	Texto, resumo, data, idioma e demais dados editoriais.
Hugo e Hextra	Geração do blog e base dos layouts.
Next.js	Páginas do portfólio e entrega integrada do site.
GitHub e Actions	Histórico do código e conteúdo, testes e preparação da publicação.
Hostinger	Build e execução da versão publicada.
Amazon S3	Armazenamento das imagens enviadas separadamente.
Disqus	Conversas e moderação dos comentários.
GoatCounter	Estatísticas de visitas que alimentam os mais lidos.

Não acrescentei um banco de dados só para guardar os artigos. Também não coloquei o armazenamento das imagens dentro da responsabilidade do Hugo. Essa separação ajuda a encontrar problemas: uma imagem indisponível, um artigo ausente e um comentário que não carrega podem ter causas diferentes.

Organização que dá para enxergar nos arquivos

A estrutura principal ficou assim:

client/ aplicação Next.js
blog/content/pt/ conteúdo em português
blog/content/en/ conteúdo em inglês
blog/layouts/ personalizações de layout
blog/assets/ estilos e interações
blog/themes/hextra/ tema de base
blog/scripts/ auxiliares de publicação e imagens
.github/workflows/ verificações e automações do conjunto

As personalizações ficam fora da pasta do tema. Isso facilita revisar uma atualização sem misturar cada ajuste local ao código original do Hextra. Continua sendo necessário testar a atualização; a estrutura de pastas não garante compatibilidade.

O repositório ativo é privado. O resultado publicado, incluindo artigos, imagens e scripts enviados ao navegador, é público. O leitor não precisa acessar o repositório para usar o site, mas os comandos desta série são exemplos do meu projeto, não um pacote público pronto para clonar.

O que eu organizaria antes de começar

Se começasse hoje, olharia melhor para o design e a arquitetura antes de implementar. Separaria cada responsabilidade, o propósito de cada área e o papel das tecnologias. Fui descobrindo parte dessa organização enquanto construía.

Para um projeto parecido, eu começaria escrevendo o caminho do visitante: onde ele entende quem sou, onde encontra meus projetos e onde lê os textos. Depois desenharia o percurso de um artigo até a publicação. Esses dois mapas ajudam a perceber quais partes precisam conversar e quais podem continuar independentes.

Na próxima parte, entro no ponto que mais exigiu tentativas: fazer essa organização aparecer na interface, sem obrigar quem chega a entender a arquitetura do projeto.