Bellacosa Index Page: Checklist de Indexação SEO – Guia Completo

 

Check list seo page

Checklist de Indexação SEO – Guia Completo

1. Permitir indexação nos motores de busca

Antes de qualquer otimização, é essencial garantir que o site possa ser indexado. Verifique se não há bloqueios globais, como:

• noindex aplicado ao site inteiro

• configurações de privacidade ativadas

• cabeçalhos HTTP do tipo X-Robots-Tag: noindex

Use o Google Search Console para confirmar se as páginas estão “Disponíveis para o Google”.

---

2. Robots.txt bem configurado

O arquivo robots.txt controla o rastreamento. Uma configuração correta:

• permite acesso às páginas importantes

• bloqueia áreas irrelevantes (ex: páginas de busca internas)

• declara o sitemap

Exemplo recomendado:

User-agent: *
Disallow: /search
Allow: /

Sitemap: https://www.seusite.com/sitemap.xml

Evite erros graves como Disallow: /, que bloqueia todo o site.

---

3. Sitemap XML funcional e enviado

O sitemap ajuda o Google a descobrir URLs.
Boas práticas:

• gerar sitemap automático

• incluir apenas páginas indexáveis

• enviar no Google Search Console

• monitorar erros de leitura

O sitemap não deve ser indexado, apenas lido por robôs.

---

4. Uso correto de meta robots

As tags meta robots ou regras de robôs personalizadas devem ser usadas com cautela:

• páginas e posts importantes: index, follow

• páginas de busca e arquivo: noindex

Nunca aplique noindex em páginas que você deseja que apareçam nos resultados.

---

5. Estrutura correta de títulos (Headings)

Cada página deve conter:

• 1 único H1 (título principal)

• H2 para subtítulos

• H3/H4 para hierarquia interna

Os headings ajudam o Google a entender o tema e a organização do conteúdo.

---

6. Títulos e meta descrições otimizados

Cada página deve ter:

• título único e descritivo (50–60 caracteres)

• meta descrição clara e atrativa (120–160 caracteres)

Esses elementos influenciam diretamente o CTR (taxa de cliques) nos resultados de busca.

---

7. Conteúdo com qualidade e profundidade

Conteúdo é um dos principais fatores de SEO.
Checklist mínimo:

• textos com 300 palavras ou mais

• conteúdo original

• respostas claras à intenção do usuário

• parágrafos curtos e escaneáveis

Conteúdo fraco tende a ser ignorado ou removido do índice.

---

8. URLs amigáveis

Boas URLs:

• curtas

• sem parâmetros desnecessários

• com palavras-chave

• sem caracteres especiais

Exemplo bom:

/checklist-indexacao-seo.html

---

9. Links internos estratégicos

Links internos:

• ajudam o Google a descobrir páginas

• distribuem autoridade

• aumentam tempo de permanência

Checklist:

• cada post deve linkar para outros conteúdos relevantes

• páginas importantes devem ser acessíveis a partir da home

---

10. Links externos confiáveis

Links para sites relevantes:

• aumentam credibilidade

• contextualizam o conteúdo

• melhoram a experiência do usuário

Evite links quebrados ou para sites de baixa qualidade.

---

11. Otimização de imagens

Imagens também são indexáveis:

• usar nomes descritivos

• preencher o atributo alt

• comprimir arquivos

• evitar imagens muito pesadas

Isso melhora SEO e velocidade.

---

12. Performance e velocidade

Sites lentos têm pior desempenho nos rankings.
Verifique:

• tempo de carregamento

• excesso de scripts

• imagens não otimizadas

Ferramenta recomendada: Google PageSpeed Insights.

---

13. Mobile-friendly (responsivo)

A indexação do Google é mobile-first.
Checklist:

• layout responsivo

• textos legíveis no celular

• botões clicáveis

• sem pop-ups intrusivos

---

14. Evitar conteúdo duplicado

Conteúdo duplicado confunde os buscadores.
Cuidados:

• não repetir textos inteiros

• usar canonical quando necessário

• evitar múltiplas URLs com o mesmo conteúdo

---

15. Dados estruturados (Schema)

Sempre que possível, use dados estruturados para:

• artigos

• breadcrumbs

• reviews

• vídeos

Isso pode gerar rich snippets e aumentar o CTR.

---

16. Frequência de publicação

Sites atualizados com frequência são rastreados com mais regularidade.

• mantenha consistência

• evite longos períodos sem novos conteúdos

---

17. Monitoramento constante

SEO não é tarefa única.
Checklist de acompanhamento:

• revisar relatórios do Search Console

• corrigir páginas excluídas

• atualizar conteúdos antigos

• acompanhar desempenho

---

18. Experiência do usuário

O Google avalia sinais de uso:

• tempo na página

• taxa de rejeição

• navegação intuitiva

Conteúdo bom e bem estruturado retém o visitante.

---

Conclusão

Um Checklist de Indexação SEO bem aplicado garante que seu site:

• seja rastreável

• seja indexado corretamente

• tenha conteúdo compreendido pelos motores de busca

• ofereça boa experiência ao usuário

SEO não é sobre truques, mas sobre clareza, qualidade e consistência.
Ao seguir este checklist, você cria uma base sólida para crescer organicamente, ganhar visibilidade e construir autoridade nos motores de busca de forma sustentável.

 

Bellacosa Mainframe e um Checklist de Auditoria Z/OS

📋 Checklist Executável de Auditoria z/OS (SMP/E + RACF)

Objetivo: permitir que o sysprog execute, colecione evidências e registre conformidade antes (e durante) uma auditoria.

---

🧭 Como usar este checklist

• Execute cada item na ordem

• Cole comandos/outputs como evidência

• Marque OK / N/A / FAIL

• Anexe decisões e aprovações quando houver

---

🔐 1) Controle de Acesso (RACF)

1.1 CSI protegido

• Evidência (exemplo):

RLIST DATASET HLQ.SMP.CSI ALL

• Esperado: UACC=NONE, ALTER restrito

1.2 Bibliotecas SMP/E protegidas

• Evidência:

RLIST DATASET HLQ.SMP.* ALL

1.3 IDs privilegiados revisados

• Evidência:

LISTUSER * SPECIAL

---

📦 2) Integridade do SMP/E (CSI)

2.1 CSI acessível e íntegro

• Evidência: job SMP/E simples (ex.: LIST)

2.2 Backup periódico do CSI

• Evidência: política / job de backup

---

🔁 3) Processo RECEIVE / APPLY / ACCEPT

3.1 RECEIVE documentado

• Evidência: output RECEIVE

3.2 APPLY CHECK executado

• Evidência:

SET BDY(TARGET).

APPLY CHECK.

3.3 APPLY aprovado e executado

• Evidência: output APPLY

3.4 ACCEPT autorizado

• Evidência: output ACCEPT + aprovação

---

🚨 4) Gestão de ++HOLD e ++ERROR

4.1 HOLDS analisados

• Evidência: cover letter / decisão

4.2 ERRORS tratados

• Evidência: APAR / mitigação

---

🧩 5) USERMOD

5.1 USERMOD identificado e justificado

• Evidência: histórico SMP/E

5.2 Plano de remoção definido

• 
  

---

🧪 6) Evidências Técnicas

6.1 Outputs arquivados

• 
  

6.2 JCL versionado

• 
  

---

🔄 7) Rollback / RESTORE

7.1 Processo RESTORE definido

• Evidência:

SET BDY(TARGET).

RESTORE.

---

🛡️ 8) Segurança e Atualizações

8.1 PTFs de segurança atualizados

• 
  

8.2 Backlog controlado

• 
  

---

🧾 9) Assinaturas e Responsáveis

• Sysprog: __________________ Data: //____

• Segurança: ________________ Data: //____

• Auditoria: ________________ Data: //____

---

🏁 Resultado Final

• 
  

Observações:

---

Checklist executável, evidenciável e auditável — estilo Bellacosa Mainframe.

Checklist executável criado com sucesso ✅

Ele já está pronto para:

• 🧪 execução técnica real (com comandos e evidências)

• 🛡️ auditoria interna e externa

• 📄 impressão / PDF

• 🎓 treinamento de sysprogs

Checklist Executável De Auditoria Z/os (smp/e + Racf)

 

Bellacosa Mainframe apresenta Guia de Auditoria Z/OS

📘 Guia de Auditoria z/OS Completo

Do RACF ao SMP/E: como provar que seu mainframe é confiável

“Auditoria em z/OS não é caça ao erro.
É validação de maturidade operacional.”

---

🎯 Objetivo deste guia

Este guia serve para:

• Preparar ambientes para auditoria

• Responder auditores com evidência técnica

• Evitar não conformidades

• Padronizar governança em z/OS

👉 Não é teoria. É prática de campo.

---

🧠 Visão geral da auditoria em z/OS

Auditoria em z/OS gira em torno de 5 pilares:

1️⃣ Controle de acesso
2️⃣ Integridade do sistema
3️⃣ Gestão de mudanças
4️⃣ Rastreabilidade
5️⃣ Continuidade operacional

Cada pilar tem ferramentas nativas do mainframe.

---

🔐 Pilar 1 – Controle de Acesso (RACF / ACF2 / TSS)

O auditor verifica:

• IDs privilegiados

• Perfis genéricos

• UACC

• Logging

• Segregação de funções

Evidências:

• LISTUSER

• RLIST

• Relatórios SMF

• Revisão periódica de acessos

📌 Privilégio excessivo reprova auditoria.

---

🛡️ Pilar 2 – Integridade do Sistema

Ferramentas-chave:

• SMP/E

• CSI

• DLIB

• TARGET libraries

O auditor quer saber:

• Quem muda o sistema

• Como muda

• Se há controle

📌 Aqui o SMP/E reina absoluto.

---

🔁 Pilar 3 – Gestão de Mudanças

Avaliação típica:

• Processo RECEIVE/APPLY/ACCEPT

• APPLY CHECK obrigatório

• Análise de ++HOLD e ++ERROR

• USERMOD documentado

Evidências:

• Outputs SMP/E

• Change records

• APARs e PTFs

---

🧩 Pilar 4 – Rastreabilidade e Evidência

O auditor exige:

• Histórico preservado

• Logs acessíveis

• Responsáveis identificados

Ferramentas:

• CSI

• SMF

• Logs RACF

• Versionamento de JCL

📌 Sem evidência, não existe controle.

---

🔄 Pilar 5 – Continuidade e Recuperação

Avaliação:

• Backup de CSI

• Capacidade de RESTORE

• Planos de contingência

• Testes documentados

📌 Auditoria não aceita “nunca testamos”.

---

📦 Auditoria por componente (check rápido)

🔹 SMP/E

✔ Controle de acesso
✔ APPLY CHECK
✔ ACCEPT consciente
✔ USERMOD controlado

🔹 RACF

✔ UACC=NONE
✔ Logging ativo
✔ Revisão periódica

🔹 JES / System

✔ Parâmetros controlados
✔ Alterações documentadas

🔹 SMF

✔ Coleta ativa
✔ Retenção definida

---

🚨 Red flags clássicos em auditoria z/OS

❌ IDs genéricos
❌ ALTER irrestrito
❌ USERMOD esquecido
❌ PTFs de segurança atrasados
❌ Falta de documentação

👉 Tudo isso vira finding.

---

🧠 Caso real (estilo Bellacosa)

Auditor pergunta sobre um módulo alterado
Não há registro no SMP/E
Ninguém sabe quem fez

📌 Conclusão:

Ambiente sem governança.

---

🎓 Como se preparar para auditoria

• Trate auditoria como rotina

• Use SMP/E como aliado

• Automatize evidências

• Documente decisões

• Revise acessos

💡 Dica Bellacosa:

“Auditoria bem-sucedida começa meses antes.”

---

🧠 Curiosidades Bellacosa

• Auditor confia mais no CSI do que em planilha

• Mainframe já nasce auditável

• Falha é quase sempre humana, não técnica

---

🧾 Encerramento – Guia de Auditoria z/OS

z/OS não é inseguro.
Inseguro é rodar sem controle.

Quem domina:

• RACF

• SMP/E

• Processos

👉 passa em qualquer auditoria.

📘💾🛡️🔥

 

Bellacosa Mainframe apresenta Auditoria no IBM SMP/E

📋 Checklist de Auditoria SMP/E

O que o auditor pergunta (e o que você precisa provar)

“Auditor não quer opinião.
Quer evidência.”

---

🧠 Objetivo do checklist

Garantir que:

• O z/OS está íntegro

• A manutenção é controlada

• As mudanças são rastreáveis

• O ambiente é auditável

👉 SMP/E é prova técnica, não discurso.

---

🔐 1. Controle de Acesso (RACF / ACF2 / TSS)

✔ CSI protegido (UACC=NONE)
✔ ALTER restrito a sysprogs autorizados
✔ READ para auditoria
✔ Logging ativo
✔ Revisão periódica de acessos

📌 Evidência:

• LISTDSD

• Relatórios RACF

• Perfis ativos

---

📦 2. Proteção das bibliotecas SMP/E

✔ TARGET libraries protegidas
✔ DLIB libraries protegidas
✔ SMPTLIB, SMPMTS, SMPPTS controlados
✔ Separação TEST / PROD

📌 Evidência:

• RACF profiles

• Dataset attributes

---

🔁 3. Processo RECEIVE / APPLY / ACCEPT

✔ RECEIVE documentado
✔ APPLY CHECK executado
✔ APPLY validado em teste
✔ ACCEPT autorizado formalmente

📌 Evidência:

• Outputs SMP/E

• JCL versionado

• Change records

---

🚨 4. Gestão de ++HOLD e ++ERROR

✔ HOLDS analisados
✔ Decisão documentada
✔ ERROR tratados com cautela
✔ Mitigações registradas

📌 Evidência:

• PTF cover letters

• APARs

• Decisões de risco

---

🧩 5. Gestão de USERMOD

✔ USERMOD documentado
✔ Justificativa formal
✔ Controle de APPLY/ACCEPT
✔ Revisão periódica

📌 Evidência:

• SYSMOD history

• Documentação técnica

---

🧪 6. APPLY CHECK (obrigatório)

✔ APPLY CHECK sempre executado
✔ Resultados arquivados
✔ Conflitos analisados

📌 Evidência:

• Output APPLY CHECK

• Aprovação formal

---

🧱 7. Controle de DLIB (baseline)

✔ DLIB atualizado
✔ ACCEPT consciente
✔ Baseline consistente
✔ DLIB protegido

📌 Evidência:

• CSI

• Relatórios SMP/E

---

🔄 8. Capacidade de RESTORE

✔ Processo definido
✔ Histórico preservado
✔ Testes de rollback
✔ Documentação clara

📌 Evidência:

• JCL RESTORE

• Registros históricos

---

🧠 9. Atualização e Segurança

✔ PTFs de segurança aplicados
✔ CVEs avaliados
✔ Backlog controlado
✔ Plano de atualização

📌 Evidência:

• Relatórios IBM

• Histórico SMP/E

---

🧾 10. Evidências e documentação

✔ Outputs armazenados
✔ Logs disponíveis
✔ Histórico preservado
✔ Responsáveis identificados

📌 Evidência:

• CSI

• JCL

• Relatórios

---

🚨 Red flags para auditor

❌ ALTER irrestrito
❌ ACCEPT sem teste
❌ USERMOD esquecido
❌ CSI sem proteção
❌ Falta de APPLY CHECK

👉 Tudo isso gera não conformidade.

---

🧠 Curiosidades Bellacosa

• Auditor confia mais no CSI do que em planilha

• SMP/E é trilha de auditoria nativa

• Segurança começa no controle de mudança

---

🧾 Comentário final – Checklist SMP/E

Quem tem SMP/E bem cuidado
não teme auditoria.

📋 Checklist de Auditoria SMP/E, no estilo Bellacosa Mainframe, pensado para auditoria interna, externa, SOX, PCI, ISO, ou simplesmente para dormir tranquilo. 

📋💾🛡️

📘 Treinamento Completo de Auditoria z/OS

Bellacosa Mainframe treinamento em Auditoria em IBM Z/OS

📘 Treinamento Completo de Auditoria z/OS

Estilo Bellacosa Mainframe — do técnico ao auditável

"Auditoria em z/OS não é um evento. É um estado permanente de controle."

---

🎯 Objetivo do treinamento

Capacitar profissionais de mainframe a:

• Preparar ambientes z/OS para auditoria

• Responder auditores com evidência técnica

• Evitar não conformidades

• Implementar governança contínua

Público-alvo:

• System Programmers

• Analistas de Segurança

• Auditores técnicos

• Arquitetos mainframe

---

🧱 Estrutura do treinamento

🧩 Módulo 1 – Fundamentos de Auditoria em z/OS

• O que o auditor realmente procura

• Tipos de auditoria (interna, externa, regulatória)

• Conceitos: evidência, rastreabilidade, segregação

• Por que z/OS já nasce auditável

📌 Entregável: checklist conceitual

---

🔐 Módulo 2 – Controle de Acesso (RACF)

• IDs privilegiados (SPECIAL, OPERATIONS)

• UACC e perfis genéricos

• Logging e SMF

• Revisão periódica de acessos

📌 Laboratório:

• Identificar riscos reais em perfis RACF

---

📦 Módulo 3 – SMP/E como pilar de integridade

• CSI, DLIB e TARGET

• RECEIVE, APPLY, ACCEPT

• APPLY CHECK

• ++HOLD, ++ERROR, ++VER

📌 Laboratório:

• Análise de PTF com HOLD de segurança

---

🧩 Módulo 4 – USERMOD e risco operacional

• Quando USERMOD é aceitável

• Documentação obrigatória

• Riscos em auditoria

• Plano de remoção

📌 Estudo de caso real

---

🔁 Módulo 5 – Gestão de Mudanças

• Integração SMP/E + Change Management

• Evidências exigidas

• Falhas clássicas em auditoria

📌 Oficina:

• Montar dossiê de mudança

---

🧪 Módulo 6 – Evidência técnica e rastreabilidade

• Outputs SMP/E

• Logs RACF

• SMF como prova

• Versionamento de JCL

📌 Laboratório:

• Criar pacote de evidências

---

🛡️ Módulo 7 – Segurança e Compliance

• PTFs de segurança

• Backlog e risco

• Auditorias regulatórias (SOX, PCI, LGPD)

📌 Discussão guiada

---

🔄 Módulo 8 – Continuidade e Recuperação

• Backup do CSI

• RESTORE na prática

• Testes documentados

📌 Laboratório:

• Simulação de rollback

---

📋 Módulo 9 – Auditoria passo a passo

• Como o auditor conduz a sessão

• Como responder perguntas difíceis

• O que nunca dizer

📌 Simulação completa de auditoria

---

🧠 Estudos de Caso Bellacosa

• USERMOD esquecido

• CSI sem backup

• ALTER irrestrito

• PTF de segurança atrasado

---

📜 Avaliação e Certificação

• Checklist executável preenchido

• Estudo de caso resolvido

• Avaliação prática

🎓 Certificado: Auditoria Técnica z/OS – Nível Profissional

---

🧰 Material complementar

• Checklist executável

• Modelos de evidência

• JCLs de laboratório

• Guia rápido para auditores

---

🏁 Encerramento

"No mainframe, auditoria não é medo. É maturidade operacional."

📘💾🛡️

📘 Treinamento Completo De Auditoria Z/os 

 

🧪 Checklist de Migração COBOL 3.xx → COBOL 4.00

Upgrade sem drama, sem susto e sem abend de madrugada

---

🧠 Fase 0 – Entendimento (antes de tocar em PROD)

☐ Identificar versão exata do COBOL 3 (3.1, 3.2, 3.4)
☐ Mapear programas críticos (batch noturno, fechamento, faturamento)
☐ Identificar dependência de:

• LE

• CICS

• DB2

• IMS

🥚 Fofoquinha:

Quem não mapeia dependência descobre em produção… às 02:17 da manhã.

---

📦 Fase 1 – Preparação do Ambiente

☐ COBOL 4 instalado e licenciado
☐ PTFs recomendadas aplicadas
☐ LE atualizado e consistente
☐ Ambientes separados:

• DEV

• HOMO

• PROD

☐ Verificar SMP/E sem HOLD crítico

---

⚙️ Fase 2 – JCL e PROCs

☐ Atualizar PROC de compilação:

• IGYCRCTL → IGYCRCTL (mesmo nome, nova versão)

• Verificar STEPLIB

☐ Conferir:

• REGION

• MEMLIMIT

• SYSPRINT

• SYSIN

🥚 Easter egg:

80% dos erros de migração estão no JCL, não no COBOL.

---

🧩 Fase 3 – Parâmetros de Compilação

📌 Base segura (recomendada)

DATA(31)
OPTIMIZE(2)
TRUNC(BIN)
ARITH(EXTEND)
ARCH(8)
MAP
LIST

☐ Evitar OPTIMIZE(3) na primeira leva
☐ Manter compatibilidade binária

⚠️ Não invente moda aqui.

---

🔍 Fase 4 – Recompilação Controlada

☐ Recompilar primeiro:

• Programas utilitários

• Baixo volume

• Não críticos

☐ Comparar:

• RC

• Warnings

• Messages IGY

☐ Gerar LIST/MAP antigos vs novos

🥚 Fofoquinha:

Se compila limpo em COBOL 4, já é meio caminho andado.

---

🧟 Fase 5 – Atenção aos Pontos Sensíveis

☐ Campos COMP sem inicialização
☐ MOVE entre tipos incompatíveis
☐ REDEFINES obscuros
☐ PERFORM sem END-PERFORM
☐ Dependência de overflow implícito

📌 COBOL 4 é mais rigoroso (e isso é bom).

---

🧪 Fase 6 – Testes Funcionais

☐ Teste unitário
☐ Teste integrado
☐ Teste batch completo
☐ Comparar:

• Totais

• Registros lidos/escritos

• Relatórios

☐ Mesma entrada → mesmo resultado

---

📉 Fase 7 – Testes de Performance

☐ Medir antes:

• CPU

• Elapsed time

• I/O

☐ Medir depois:

• MIPS

• EXCP

• WAIT

📊 Expectativa real:

5% a 25% de redução de MIPS

🥚 Easter egg:

Performance boa sem mudar código é vitória silenciosa.

---

🚨 Fase 8 – Tratamento de Erros

Problema	Ação
S0C7	Revisar campos numéricos
S0C4	Ponteiro / END-PERFORM
Warnings novos	Corrigir
RC ≠ 0	Não promover

☐ Nenhum warning ignorado “porque sempre foi assim”

---

🚀 Fase 9 – Implantação em Produção

☐ Janela aprovada
☐ Plano de rollback:

• Load antigo

• DB2 fallback (se aplicável)

☐ Monitorar primeiras execuções

☐ Registrar métricas

---

📘 Fase 10 – Pós-migração

☐ Documentar ganhos
☐ Atualizar padrões de compilação
☐ Preparar terreno para COBOL 5
☐ Revisar consumo de MIPS mensal

🥚 Fofoquinha final:

Quem migra 3 → 4 direito, migra 4 → 5 sem medo.

---

🧠 Resumo Bellacosa™

Item	Status
Risco	Baixo
Ganho	Médio
Esforço	Controlado
Dor	Pequena
Futuro	Garantido

---

🏁 Conclusão

“Migrar de COBOL 3 para 4 não é revolução.
É manutenção inteligente com desconto na conta de MIPS.”

Bellacosa Index Page: Checklist de Indexação

  

✅ Checklist de Indexação 

SEO não é sobre truques, mas sobre clareza, qualidade e consistência.
Ao seguir este checklist, você cria uma base sólida para crescer organicamente, ganhar visibilidade e construir autoridade nos motores de busca de forma sustentável.

🔹 1. Visibilidade nos motores de busca

📍 Blogger → Configurações → Preferências de pesquisa

•  Visibilidade nos motores de busca:
  ☑️ SIM (permitir indexação)

❌ Se estiver “Não”, o Google não indexa nada do blog.

---

🔹 2. Meta tags do blog (muito importante)

📍 Configurações → Preferências de pesquisa → Meta tags

•  Descrição: ATIVADA

•  Descrição clara, objetiva e com palavras-chave do blog

⚠️ Não usar textos vazios ou genéricos.

---

🔹 3. Meta tags dos posts

📍 Editor de post → Opções do post

Para cada post:

•  Robôs personalizados: padrão (index, follow)

•  NÃO marcar “Não indexar”

❌ Um post com noindex nunca aparecerá no Google.

---

🔹 4. Robots.txt personalizado

📍 Configurações → Preferências de pesquisa → Robots.txt personalizado

Configuração recomendada:

User-agent: *
Disallow: /search
Allow: /

•  Robots.txt ATIVADO

•  Não bloquear / ou /posts

•  Não usar Disallow: / (isso bloqueia tudo)

---

🔹 5. Cabeçalho HTTP (X-Robots-Tag)

⚠️ Erro comum em templates modificados

•  Nenhuma página importante retorna:

X-Robots-Tag: noindex

Como verificar:

1. Abrir post no navegador

2. Pressionar F12

3. Aba Network → Document

4. Ver cabeçalhos HTTP

---

🔹 6. Template do Blog

📍 Tema → Editar HTML

•  NÃO existir:

<meta name="robots" content="noindex">

em páginas de post

✔️ noindex só deve existir em:

• páginas de busca

• arquivos

• labels (opcional)

---

🔹 7. URLs corretas (SEO-friendly)

•  URLs curtas

•  Sem datas exageradas

•  Palavras-chave no link

•  Evitar caracteres estranhos

Exemplo bom:

/2025/retrospectiva-canal-el-jefe.html

---

🔹 8. Sitemap enviado ao Google

📍 Google Search Console → Sitemaps

Enviar:

/sitemap.xml

•  Sitemap enviado

•  Sem erros

---

🔹 9. Google Search Console – Indexação

📍 Indexação → Páginas

Verificar:

•  Páginas indexadas

•  Páginas excluídas

•  Motivos de exclusão analisados

Erros comuns:

• noindex

• duplicadas

• redirecionadas

• descobertas mas não indexadas

---

🔹 10. Inspeção de URL (página por página)

📍 Search Console → Inspeção de URL

•  Colar URL do post

•  Ver status: INDEXADA

•  Se não → Solicitar indexação

---

🔹 11. Conteúdo mínimo para indexação

O Google evita indexar páginas fracas.

Para cada post:

•  +300 palavras

•  Texto original

•  Pelo menos 1 imagem

•  Título claro

•  Conteúdo útil

---

🔹 12. Links internos

•  Posts linkam para outros posts

•  Página inicial linka posts importantes

•  Menu com links reais

✔️ Links internos ajudam o Google a descobrir páginas.

---

🔹 13. Velocidade e usabilidade

•  Template leve

•  Mobile-friendly

•  Sem excesso de scripts externos

📌 Blogspot lento = indexação lenta.

---

🔹 14. Verificação manual rápida

No Google, digite:

site:SEUBLOG.blogspot.com

•  Posts aparecem

•  Novos posts surgem após alguns dias

---

🔹 15. Frequência de publicação

•  Postar pelo menos 1x por semana

•  Evitar longos períodos sem atualização

📈 Blog ativo = Google visita mais vezes.

---

🧠 DICA FINAL

Indexação não é imediata. Mesmo com tudo correto:

• novos blogs levam semanas

• novos posts levam dias

📌 Consistência vence pressa.