 |
| Bellacosa Mainframe e o blog analytics parte v |
☕ Um Café no Bellacosa Mainframe
Blog Analytics : Parte V – Construindo o Bellacosa Blog Doctor
Desenvolvendo um Scanner Automático de HTML, SEO e Qualidade para Blogger
Quando o Feed Atom Deixa de Ser Apenas um Arquivo XML e se Transforma no SYSUDUMP de um Acervo Digital
☕ Um Café no Bellacosa Mainframe
Nas quatro primeiras partes desta série percorremos um caminho que começou com uma suspeita aparentemente pequena e terminou em uma descoberta muito maior.
Primeiro percebemos que o Blogger podia armazenar HTML invisível.
Depois identificamos os resíduos deixados por inteligência artificial, Microsoft Word, Google Docs e outros editores.
Em seguida aprendemos que limpar milhares de posts sem planejamento poderia causar mais problemas do que benefícios.
Por fim, construímos um checklist de auditoria para blogs antigos, tratando um acervo editorial como um sistema crítico que precisa de manutenção preventiva.
Agora chegamos ao ponto em que a teoria precisa virar ferramenta.
Não basta saber que existem resíduos.
Não basta abrir manualmente cada artigo.
Não basta analisar visualmente milhares de páginas.
Precisamos de um scanner.
Um programa capaz de receber o Feed Atom de um blog, percorrer milhares de publicações, interpretar o HTML, aplicar regras de qualidade, calcular indicadores, classificar riscos e produzir um relatório compreensível.
Em outras palavras:
Precisamos construir o Bellacosa Blog Doctor.
O Que é o Bellacosa Blog Doctor?
O Bellacosa Blog Doctor é uma ferramenta de auditoria técnica para Blogger.
Seu objetivo não é editar automaticamente todos os artigos.
Seu objetivo é muito mais importante:
diagnosticar antes de corrigir.
Em ambientes IBM Mainframe, ninguém altera um sistema crítico sem antes reunir evidências.
Primeiro olhamos:
logs;
dumps;
traces;
métricas;
códigos de retorno;
históricos de execução;
impactos;
dependências.
Somente depois decidimos o que fazer.
O Blog Doctor segue exatamente essa filosofia.
Ele não deve agir como um aspirador de pó cego que remove tudo que parece estranho.
Ele deve funcionar como um laboratório forense digital.
Receber dados.
Analisar.
Classificar.
Explicar.
Priorizar.
Gerar um laudo.
A Filosofia Mainframe Aplicada ao Blogger
Um mainframe não é confiável apenas porque possui hardware robusto.
Ele é confiável porque toda sua operação é baseada em controle, observabilidade e diagnóstico.
Quando um job falha, existem pistas:
RC;ABEND;SYSOUT;JESMSGLG;JESYSMSG;CEEDUMP;SYSUDUMP;mensagens do subsistema;
registros SMF.
O Blog Doctor deve produzir o equivalente editorial dessas evidências.
Por exemplo:
POST: ABEND sem Mistérios para Programadores COBOL
STATUS GERAL..............ATENÇÃO
HTML......................82
SEO TÉCNICO...............91
ACESSIBILIDADE............76
QUALIDADE EDITORIAL.......94
OCORRÊNCIAS:
- 3 imagens sem ALT
- 1 tabela dentro de parágrafo
- 2 links HTTP
- 4 atributos data-message-id
- heading H3 sem H2 anterior
PRIORIDADE.................MÉDIA
AÇÃO RECOMENDADA...........REVISÃO MANUAL
Esse relatório funciona como um pequeno dump do artigo.
Não diz apenas que existe um problema.
Mostra:
onde;
qual;
quantas vezes;
qual gravidade;
qual ação recomendada.
A Arquitetura da Ferramenta
Antes de escrever código, precisamos desenhar a arquitetura.
Uma ferramenta de auditoria bem organizada pode ser dividida em cinco camadas.
CAMADA 1 – AQUISIÇÃO
Feed Atom ou Blogger API
CAMADA 2 – NORMALIZAÇÃO
Conversão dos posts para objetos internos
CAMADA 3 – ANÁLISE
HTML, SEO, acessibilidade, conteúdo e metadados
CAMADA 4 – CLASSIFICAÇÃO
Score, gravidade, prioridade e recomendações
CAMADA 5 – RELATÓRIOS
Dashboard, CSV, JSON, tabelas e laudos
Essa separação é fundamental.
Sem ela, o programa rapidamente se transforma em um bloco gigantesco de JavaScript difícil de manter.
No universo mainframe, seria como colocar leitura de arquivo, regra de negócio, banco de dados, impressão e tratamento de erro dentro de uma única SECTION COBOL.
Pode até funcionar.
Mas ninguém gostaria de manter.
Camada 1 – Aquisição dos Dados
O primeiro módulo precisa localizar e carregar os artigos.
Existem duas fontes principais.
Feed Atom
O Feed Atom é excelente para análise porque fornece o conteúdo publicado em formato estruturado.
Ele pode conter:
título;
data de publicação;
data de atualização;
categorias;
links;
HTML completo do artigo.
Exemplo simplificado:
<entry>
<title>ABEND sem Mistérios</title>
<published>2026-07-25T20:00:00-03:00</published>
<category term="COBOL"/>
<category term="Mainframe"/>
<content type="html">
<![CDATA[
<h2>Introdução</h2>
<p>Conteúdo...</p>
]]>
</content>
</entry>
O Feed Atom funciona quase como uma unload de banco de dados.
Ele não representa apenas aquilo que aparece visualmente.
Ele revela aquilo que foi armazenado.
Blogger API
A Blogger API fornece dados em JSON.
Isso facilita o processamento porque JavaScript trabalha naturalmente com objetos JSON.
Exemplo:
{
"title": "ABEND sem Mistérios",
"published": "2026-07-25T20:00:00-03:00",
"labels": ["COBOL", "Mainframe"],
"content": "<h2>Introdução</h2><p>Conteúdo...</p>"
}
Em um projeto mais maduro, o Blog Doctor pode oferecer as duas opções:
leitura direta do Feed Atom;
leitura da Blogger API.
O Problema da Paginação
Blogs pequenos podem ser lidos em uma única requisição.
Blogs com milhares de posts não.
Tentar carregar quatro mil artigos de uma vez pode gerar:
timeout;
resposta truncada;
consumo elevado de memória;
travamento do navegador;
falhas de rede;
bloqueio temporário.
A solução é processar em lotes.
async function carregarPosts() {
const lote = 100;
let inicio = 1;
const posts = [];
while (true) {
const dados = await carregarLote(inicio, lote);
if (!dados.length) {
break;
}
posts.push(...dados);
inicio += dados.length;
if (dados.length < lote) {
break;
}
}
return posts;
}
Essa lógica lembra um programa batch lendo um arquivo em blocos.
Não importa se existem cem ou dez mil registros.
O processo continua até encontrar o fim.
Camada 2 – Normalização
Os dados recebidos do Feed Atom não devem ser usados diretamente em todas as funções.
Primeiro precisam ser normalizados.
Isso significa converter cada post para um formato interno consistente.
{
titulo: "ABEND sem Mistérios",
url: "https://...",
publicadoEm: Date,
atualizadoEm: Date,
html: "<h2>...</h2>",
texto: "ABEND sem Mistérios...",
palavras: 1842,
caracteres: 10920,
marcadores: ["COBOL", "Mainframe"],
imagens: [],
links: [],
headings: []
}
Esse objeto se transforma no registro mestre da auditoria.
Em COBOL, seria como montar um layout padronizado na WORKING-STORAGE antes de aplicar as regras de negócio.
Convertendo HTML em Texto
Um dos primeiros algoritmos necessários é remover o HTML para obter apenas o conteúdo textual.
function htmlParaTexto(html) {
const documento = new DOMParser()
.parseFromString(html, "text/html");
documento
.querySelectorAll("script, style, noscript")
.forEach(elemento => elemento.remove());
return (documento.body.textContent || "")
.replace(/\s+/g, " ")
.trim();
}
Essa função permite calcular:
palavras;
caracteres;
densidade textual;
repetições;
legibilidade;
termos mais usados.
Contando Palavras
A contagem não deve usar apenas:
texto.split(" ")
Esse método falha com:
múltiplos espaços;
quebras de linha;
pontuação;
hífens;
apóstrofos.
Uma abordagem melhor é usar expressão regular Unicode.
function contarPalavras(texto) {
const palavras = texto.match(
/[\p{L}\p{N}][\p{L}\p{N}'’-]*/gu
);
return palavras ? palavras.length : 0;
}
O uso de \p{L} ajuda a reconhecer letras acentuadas e outros alfabetos.
Isso é importante em um blog que mistura português, inglês, japonês romanizado, termos técnicos e nomes próprios.
Camada 3 – O Motor de Análise
Aqui está o verdadeiro coração do Bellacosa Blog Doctor.
Cada módulo analisa um aspecto diferente.
MÓDULO HTML
MÓDULO SEO
MÓDULO ACESSIBILIDADE
MÓDULO EDITORIAL
MÓDULO LINKS
MÓDULO IMAGENS
MÓDULO RESÍDUOS
MÓDULO PERFORMANCE
Cada módulo deve produzir ocorrências independentes.
Exemplo:
{
codigo: "HTML-TABLE-IN-P",
categoria: "HTML",
gravidade: "media",
mensagem: "Tabela encontrada dentro de parágrafo",
quantidade: 1
}
Scanner de HTML
O scanner de HTML deve procurar estruturas inválidas ou suspeitas.
Tabela dentro de parágrafo
const tabelaEmParagrafo =
/<p\b[^>]*>\s*<table\b/i.test(html);
Tabela dentro de heading
const tabelaEmHeading =
/<h[1-6]\b[^>]*>\s*<table\b/i.test(html);
Headings vazios
const headingsVazios = [
...documento.querySelectorAll("h1,h2,h3,h4,h5,h6")
].filter(elemento => !elemento.textContent.trim());
Mais de um H1
const quantidadeH1 =
documento.querySelectorAll("h1").length;
Essas regras parecem simples, mas quando aplicadas a milhares de posts revelam padrões históricos inteiros.
Scanner de Resíduos de IA
Os resíduos deixados por interfaces modernas podem ser identificados por padrões conhecidos.
const residuosIA = [
/data-message-id\s*=/i,
/data-message-author-role\s*=/i,
/data-message-model-slug\s*=/i
];
O algoritmo pode contar cada ocorrência.
function contarPadrao(html, regex) {
const global = new RegExp(regex.source, regex.flags + "g");
return (html.match(global) || []).length;
}
Resultado:
data-message-id...............12
data-message-author-role.......4
data-message-model-slug........4
Isso permite identificar não apenas se existe resíduo, mas sua intensidade.
Scanner de Microsoft Word
O Word possui uma assinatura bastante reconhecível.
const possuiWord =
/\bclass=["'][^"']*\bMso/i.test(html) ||
/<o:p\b/i.test(html) ||
/mso-[a-z-]+\s*:/i.test(html);
Também é possível detectar comentários condicionais:
<!--[if gte mso 9]>
Esses resíduos normalmente não quebram a página.
Mas aumentam o tamanho do HTML e tornam a manutenção mais difícil.
Scanner de Google Docs
O Google Docs costuma deixar estruturas mais limpas que o Word, porém pode inserir grande quantidade de spans e estilos inline.
Uma regra simples pode medir densidade de spans.
const spans =
documento.querySelectorAll("span").length;
const palavras =
contarPalavras(texto);
const densidadeSpan =
palavras > 0 ? spans / palavras : 0;
Exemplo:
Palavras..............1.000
Spans...................480
Densidade..............0,48
Uma densidade muito alta pode indicar excesso de formatação.
Análise de Headings
A hierarquia de títulos é essencial para organização semântica.
Um scanner deve verificar:
H1 duplicado;
H2 ausente;
H3 sem H2 anterior;
saltos de H2 para H4;
headings vazios;
headings excessivamente longos.
Algoritmo simplificado:
function analisarHierarquiaHeadings(documento) {
const headings = [
...documento.querySelectorAll("h1,h2,h3,h4,h5,h6")
];
const problemas = [];
let nivelAnterior = 0;
headings.forEach(heading => {
const nivel = Number(heading.tagName.substring(1));
if (nivelAnterior && nivel > nivelAnterior + 1) {
problemas.push({
tipo: "salto-heading",
de: nivelAnterior,
para: nivel,
texto: heading.textContent.trim()
});
}
nivelAnterior = nivel;
});
return problemas;
}
Isso funciona como um verificador de estrutura de programa.
É quase um compiler warning editorial.
Scanner de Imagens
Cada imagem deve ser analisada.
const imagens = [
...documento.querySelectorAll("img")
];
Para cada uma:
{
src: imagem.src,
alt: imagem.getAttribute("alt"),
title: imagem.getAttribute("title"),
width: imagem.getAttribute("width"),
height: imagem.getAttribute("height")
}
Problemas possíveis:
ausência de ALT;
ALT vazio;
URL HTTP;
imagem sem dimensões;
imagem externa;
possível arquivo pesado;
imagem duplicada;
nome de arquivo genérico.
Exemplo de diagnóstico:
IMG-ALT-MISSING
Gravidade: média
Ocorrências: 3
Scanner de Links
Links quebrados são uma das maiores dívidas técnicas de blogs antigos.
O scanner local pode verificar inicialmente:
HTTP;
links vazios;
href="#";JavaScript no href;
links internos;
links externos;
links duplicados.
const linksHTTP = links.filter(link =>
/^http:\/\//i.test(link.getAttribute("href") || "")
);
Verificar se uma URL externa realmente responde exige chamadas de rede e pode sofrer limitações de CORS.
Por isso, o Blog Doctor pode classificar a análise em dois níveis:
Nível local
estrutura do link;
protocolo;
domínio;
duplicação;
consistência.
Nível remoto
código HTTP;
redirect;
página removida;
timeout.
Scanner de Conteúdo
O conteúdo também pode ser avaliado.
Indicadores possíveis:
quantidade de palavras;
tamanho do título;
presença de introdução;
presença de conclusão;
repetição excessiva;
parágrafos muito longos;
densidade de palavras-chave;
excesso de caixa alta;
excesso de negrito;
excesso de emojis.
Exemplo:
const tituloCurto = titulo.length < 20;
const tituloLongo = titulo.length > 70;
const conteudoCurto = palavras < 300;
Essas regras não devem ser tratadas como leis universais.
Um post curto pode ser perfeitamente válido.
O scanner apenas sinaliza.
A decisão continua sendo humana.
O Índice Técnico de SEO
O Blog Doctor pode calcular uma pontuação de zero a cem.
Exemplo inicial:
Título.........................10
Conteúdo.......................15
Headings.......................10
Imagens........................10
Links internos.................10
Marcadores.....................10
HTML limpo.....................15
Acessibilidade.................10
Estrutura......................10
O algoritmo pode começar com 100 pontos e aplicar penalidades.
function calcularSEO(post) {
let score = 100;
if (post.titulo.length < 20) {
score -= 7;
}
if (post.palavras < 300) {
score -= 15;
}
if (post.imagensSemAlt > 0) {
score -= Math.min(12, post.imagensSemAlt * 3);
}
if (post.semLinksInternos) {
score -= 8;
}
if (post.residuoIA) {
score -= 6;
}
return Math.max(0, score);
}
Esse índice não mede posição no Google.
Ele mede qualidade técnica estimada.
É semelhante a uma métrica de saúde.
Um servidor pode estar funcionando e ainda apresentar alertas.
Um artigo pode estar indexado e ainda possuir problemas técnicos.
Gravidade e Prioridade
Nem todo problema merece a mesma atenção.
O Blog Doctor deve separar gravidade de prioridade.
Gravidade
Refere-se ao impacto técnico.
BAIXA
MÉDIA
ALTA
CRÍTICA
Prioridade
Refere-se à ordem de correção.
Um problema tecnicamente médio pode ter prioridade alta se aparecer em centenas de posts.
Exemplo:
Problema........Imagem sem ALT
Gravidade.......Média
Ocorrências.....1.240
Prioridade......Alta
Outro exemplo:
Problema........Resíduo data-message-id
Gravidade.......Baixa
Ocorrências.....3
Prioridade......Baixa
Essa distinção evita pânico.
A Matriz de Risco
Podemos criar uma matriz simples.
POUCOS POSTS MUITOS POSTS
BAIXO IMPACTO BAIXA MÉDIA
MÉDIO IMPACTO MÉDIA ALTA
ALTO IMPACTO ALTA CRÍTICA
Em JavaScript:
function calcularPrioridade(gravidade, ocorrencias) {
const peso = {
baixa: 1,
media: 2,
alta: 3,
critica: 4
};
const volume =
ocorrencias > 500 ? 3 :
ocorrencias > 50 ? 2 : 1;
const resultado = peso[gravidade] + volume;
if (resultado >= 6) return "crítica";
if (resultado >= 5) return "alta";
if (resultado >= 3) return "média";
return "baixa";
}
Geração de Relatórios
Uma ferramenta sem relatório é apenas um conjunto de funções.
O Blog Doctor precisa transformar dados técnicos em informação útil.
Ele pode produzir quatro tipos de saída.
Dashboard
Indicadores visuais:
Posts analisados.............4.018
HTML saudável................3.912
Posts com alerta................89
Posts críticos..................17
SEO técnico médio..............92
Imagens sem ALT................243
Links HTTP......................81
Resíduos de IA..................14
Relatório por artigo
TÍTULO: Data Division sem Mistérios
URL: https://...
PALAVRAS..................1.846
IMAGENS.......................4
LINKS INTERNOS................3
MARCADORES....................8
SEO TÉCNICO..................94
ALERTAS:
- 1 imagem sem ALT
- 1 link HTTP
CSV
O CSV permite abrir os resultados no Excel ou LibreOffice.
Colunas possíveis:
Título
URL
Data
Palavras
Caracteres
Marcadores
Imagens
Imagens sem ALT
Links internos
Resíduos IA
Resíduos Word
SEO Score
Prioridade
JSON
O JSON é ideal para integração futura.
{
"blog": "Bellacosa Mainframe",
"dataAuditoria": "2026-07-26",
"posts": [
{
"titulo": "ABEND sem Mistérios",
"score": 92,
"prioridade": "media",
"ocorrencias": []
}
]
}
A Tela de Progresso
Em um blog com milhares de posts, o usuário precisa saber que o sistema continua funcionando.
Carregando lote 12...
Posts recebidos........1.200
Posts analisados.......1.175
Palavras processadas...1.832.411
[██████████░░░░░░░░░░] 29%
Essa barra não é apenas estética.
Ela reduz a ansiedade e ajuda a identificar travamentos.
Em sistemas batch, o equivalente seria acompanhar o job no SDSF.
Cache e IndexedDB
Reanalisar quatro mil posts em toda visita é desperdício.
O navegador pode guardar os resultados localmente usando IndexedDB.
Arquitetura:
Primeira execução
Feed → análise → IndexedDB
Próxima execução
IndexedDB → dashboard
Atualização
Buscar apenas posts recentes
Isso transforma o painel em uma aplicação muito mais rápida.
Processamento Incremental
Em vez de reler o blog inteiro, podemos guardar a data da última análise.
{
ultimaAtualizacao: "2026-07-26T23:10:00-03:00"
}
Na próxima execução, o sistema procura apenas artigos publicados ou atualizados depois dessa data.
É o equivalente editorial de um processamento incremental.
Muito semelhante a um batch que lê apenas os registros alterados.
Web Workers
Analisar milhões de palavras pode travar a interface.
Uma solução futura é usar Web Workers.
O Worker executa o processamento em uma thread separada.
const worker = new Worker("blog-doctor-worker.js");
worker.postMessage(posts);
worker.onmessage = evento => {
atualizarDashboard(evento.data);
};
Assim, a interface continua respondendo enquanto a análise ocorre.
A Implementação Mínima
Uma primeira versão funcional do Blog Doctor precisa apenas de cinco componentes.
1. Leitor do Feed
2. Normalizador
3. Scanner de HTML
4. Calculador de Score
5. Gerador de tabela
Fluxo:
async function executarAuditoria() {
const entradas = await carregarTodosOsPosts();
const posts = entradas.map(normalizarPost);
const auditados = posts.map(post => {
const ocorrencias = analisarPost(post);
const score = calcularScore(post, ocorrencias);
return {
...post,
ocorrencias,
score
};
});
gerarRelatorio(auditados);
}
Essa função representa o coração do sistema.
Estrutura de uma Ocorrência
Todas as regras devem produzir o mesmo formato.
{
codigo: "IMG-ALT-MISSING",
categoria: "Acessibilidade",
gravidade: "media",
quantidade: 2,
mensagem: "Duas imagens não possuem texto alternativo",
recomendacao: "Adicionar ALT descritivo"
}
Essa padronização torna possível:
ordenar;
filtrar;
exportar;
calcular score;
gerar relatórios;
criar gráficos.
Criando um Catálogo de Regras
As regras podem ficar em uma lista.
const regras = [
{
codigo: "HTML-AI-RESIDUE",
categoria: "HTML",
gravidade: "baixa",
testar(post) {
return /data-message-id/i.test(post.html);
},
mensagem: "Resíduo de interface de IA encontrado"
},
{
codigo: "IMG-ALT-MISSING",
categoria: "Acessibilidade",
gravidade: "media",
testar(post) {
return post.imagensSemAlt > 0;
},
mensagem: "Imagem sem ALT"
}
];
Depois, o motor executa todas.
function executarRegras(post) {
return regras
.filter(regra => regra.testar(post))
.map(regra => ({
codigo: regra.codigo,
categoria: regra.categoria,
gravidade: regra.gravidade,
mensagem: regra.mensagem
}));
}
Essa arquitetura facilita adicionar novas verificações sem alterar o restante do programa.
O Equivalente ao Return Code
No mainframe, um job pode terminar com:
RC=0000
RC=0004
RC=0008
RC=0012
RC=0016
O Blog Doctor pode adotar uma lógica semelhante.
BDC0000 – Post saudável
BDC0004 – Alerta leve
BDC0008 – Revisão recomendada
BDC0012 – Problema grave
BDC0016 – Conteúdo crítico
Exemplo:
BDC0008
Imagem sem ALT e heading inconsistente
Isso adiciona identidade à ferramenta e facilita a leitura dos relatórios.
Mensagens no Estilo Mainframe
A ferramenta pode gerar mensagens padronizadas.
BBDHTML001W TABLE FOUND INSIDE PARAGRAPH
BBDSEO004W INTERNAL LINK NOT FOUND
BBDACC002E IMAGE WITHOUT ALT ATTRIBUTE
BBDIA001I AI INTERFACE METADATA DETECTED
BBDDOC003W MICROSOFT WORD RESIDUE FOUND
Legenda:
I – Information
W – Warning
E – Error
S – Severe
Além de divertido, isso cria consistência.
O Dashboard Final
Imagine a tela principal.
┌─────────────────────────────────────────┐
│ BELLA COSA BLOG DOCTOR │
│ BLOG HEALTH MONITOR │
├─────────────────────────────────────────┤
│ Posts.........................4.018 │
│ Score médio.....................94 │
│ Alertas.........................126 │
│ Críticos.........................12 │
├─────────────────────────────────────────┤
│ HTML ████████████████ 96 │
│ SEO ███████████████ 92 │
│ A11Y ██████████████ 88 │
│ LINKS ███████████████ 91 │
└─────────────────────────────────────────┘
Abas:
visão geral;
HTML;
SEO;
acessibilidade;
imagens;
links;
resíduos;
posts;
exportação.
O Que Não Deve Ser Automatizado
Uma ferramenta madura também precisa saber seus limites.
O Blog Doctor não deve:
reescrever automaticamente milhares de posts;
remover tags sem confirmação;
alterar URLs;
trocar títulos;
apagar marcadores;
corrigir links externos de forma cega;
publicar alterações sem backup.
Ele deve diagnosticar.
A correção pode ser manual ou assistida.
Mas sempre controlada.
Auditoria Não é Limpeza
Essa distinção é fundamental.
AUDITORIA
Descobre e classifica
LIMPEZA
Altera o conteúdo
Misturar as duas etapas é perigoso.
No mainframe, primeiro analisamos o dump.
Depois corrigimos o programa.
Não alteramos a memória do dump esperando que o sistema volte a funcionar.
O Bellacosa Blog Doctor como Projeto Real
O projeto pode evoluir em versões.
Versão 0.1
leitura de 100 posts;
contagem de palavras;
posts por ano.
Versão 0.5
paginação completa;
imagens;
links;
headings.
Versão 1.0
scanner HTML;
scanner SEO;
dashboard;
CSV.
Versão 2.0
IndexedDB;
processamento incremental;
mapa de calor;
evolução dos marcadores.
Versão 3.0
Web Workers;
auditoria remota de links;
relatórios JSON;
comparação entre auditorias.
Versão 4.0
sugestões de correção;
diff de HTML;
histórico de qualidade;
integração com Search Console.
Comparando Auditorias
Uma das funções mais poderosas será comparar dois momentos.
AUDITORIA 1 – JULHO/2026
Score geral.................88
HTML inválido...............49
Imagens sem ALT............312
AUDITORIA 2 – OUTUBRO/2026
Score geral.................94
HTML inválido...............11
Imagens sem ALT.............87
Isso permite medir evolução real.
Não apenas sensação.
O Histórico de Saúde
Cada auditoria pode ser salva.
{
data: "2026-07-26",
posts: 4018,
score: 92,
problemas: {
html: 49,
imagens: 312,
links: 87
}
}
Depois criamos um gráfico.
Julho...........88
Agosto..........90
Setembro........92
Outubro.........94
Esse é o verdadeiro conceito de evolução técnica.
O RMF Editorial
No z/OS, o RMF ajuda a observar recursos do sistema.
O Bellacosa Blog Doctor pode ser visto como um RMF editorial.
Em vez de medir:
CPU;
memória;
I/O;
canais;
dispositivos.
Ele mede:
HTML;
palavras;
imagens;
links;
headings;
marcadores;
qualidade;
acessibilidade.
O objetivo é o mesmo.
Transformar um sistema invisível em algo observável.
Um Scanner para Décadas de História
Um blog antigo não é apenas um conjunto de páginas.
É um sistema que atravessou:
mudanças de layout;
troca de editores;
novas tecnologias;
alterações de SEO;
migrações;
modismos;
ferramentas;
plataformas;
estilos de escrita.
O Blog Doctor permite enxergar essas camadas.
Um artigo de 2012 pode ter HTML completamente diferente de um artigo de 2026.
E isso não é necessariamente ruim.
É história.
O scanner não serve apenas para encontrar defeitos.
Ele também ajuda a compreender a evolução do acervo.
Conclusão
Construir o Bellacosa Blog Doctor significa aplicar ao universo editorial os mesmos princípios que tornaram o IBM Mainframe uma das plataformas mais confiáveis da história da computação.
Observabilidade.
Padronização.
Diagnóstico.
Controle.
Mensuração.
Rastreabilidade.
A ferramenta começa lendo um simples Feed Atom.
Depois converte cada post em uma estrutura organizada.
Em seguida executa algoritmos de análise.
Detecta resíduos.
Avalia HTML.
Examina imagens.
Verifica headings.
Conta palavras.
Classifica problemas.
Calcula scores.
Gera relatórios.
E transforma milhares de páginas dispersas em um sistema mensurável.
Essa talvez seja a maior evolução de toda a série.
No início queríamos apenas descobrir algumas tags invisíveis.
Agora estamos projetando uma plataforma de auditoria capaz de examinar décadas de produção digital.
O Feed Atom deixou de ser apenas um arquivo XML.
Virou dump.
Virou log.
Virou histórico.
Virou matéria-prima para inteligência editorial.
E o Bellacosa Blog Doctor deixa de ser apenas uma ideia curiosa.
Ele se transforma em uma ferramenta de engenharia.
Uma ferramenta que não promete milagres.
Não apaga tudo automaticamente.
Não substitui o julgamento humano.
Mas faz aquilo que as melhores ferramentas de diagnóstico sempre fizeram:
mostra a verdade antes que alguém toque em produção.
Porque, seja em um Data Center IBM ou em um blog com milhares de artigos, a regra continua sendo a mesma:
Primeiro diagnostique. Depois corrija. E nunca altere aquilo que você ainda não compreendeu.
Blog Analytics: A Investigação Completa
Seis capítulos sobre auditoria de HTML, resíduos invisíveis, limpeza segura, checklist técnico e construção do Bellacosa Blog Doctor.
Blog Analytics — Parte I
Como descobrir evidências invisíveis no HTML de um blog antigo.
Blog Analytics — Parte II
Os resíduos invisíveis deixados por editores, Word, IA e cópias antigas.
Blog Analytics — Parte III
Como limpar milhares de posts sem destruir o acervo editorial.
Blog Analytics — Parte IV
Checklist de auditoria para blogs antigos e acervos com anos de história.
Blog Analytics — Parte V
Construindo o Bellacosa Blog Doctor e seu scanner automático.
Blog Analytics — Parte VI
Criando o motor de regras, scores, prioridades e códigos de retorno.
Índice textual da série Blog Analytics
Esta série investiga a saúde técnica de blogs antigos no Blogger, cobrindo auditoria de HTML, resíduos de editores, SEO técnico, acessibilidade, limpeza segura, diagnóstico automatizado e motores de regras.
- Blog Analytics Parte I — Como descobrir evidências invisíveis
- Blog Analytics Parte II — Os resíduos invisíveis do HTML
- Blog Analytics Parte III — Como limpar com segurança
- Blog Analytics Parte IV — Checklist de auditoria
- Blog Analytics Parte V — Construindo o Bellacosa Blog Doctor
- Blog Analytics Parte VI — Criando o motor de regras
