Checklist de SEO Pré-Publicação

A garantia de qualidade (QA) pré-publicação é o portão de lançamento final no Processo de SEO . É onde três contratos se encontram: conformidade com o tipo de postagem, uso correto de elementos e conclusão do trabalho anterior de pesquisa, evidência, implementação e revisão. Uma página que falha em qualquer item aplicável retorna para correção.

Portão: QA pré-publicação final. Timebox: 60–90 minutos para uma página padrão; adicione tempo de especialista para alegações reguladas, de segurança, financeiras, médicas ou tecnicamente consequentes. Responsável: um editor, líder de conteúdo ou líder de SEO que não fez a implementação final e tem autoridade para bloquear o lançamento.

Uma checklist flexível não é uma checklist porque “quase pronto” não tem significado estável. Sob pressão de prazo, palavras opcionais se tornam um auxílio de memória e verificações difíceis desaparecem. Nomeie a autoridade de lançamento antes do início do QA. O responsável pelo QA pode aprovar ou reprovar; apenas o chefe de conteúdo, líder de SEO ou equivalente nomeado pode aprovar uma exceção por escrito ou declarar um item inaplicável. Eles não podem abrir mão de uma alegação falsa, elemento obrigatório ausente, ativo placeholder, canônica quebrada ou indexabilidade bloqueada para cumprir um prazo.

Por que este portão existe e por que funciona aqui

Este portão consome a especificação de tipo de postagem aprovada, contratos de elementos, registro de fontes, texto final, candidato implementado e aprovações de especialistas. Ele é executado depois que essas entradas são congeladas porque o QA não pode verificar um alvo em movimento, e antes da publicação porque um defeito pode ser copiado assim que a URL estiver ativa.

O QA anterior certifica um rascunho que pode mudar. Pulá-lo deixa auditores posteriores incapazes de distinguir entre desvio de página, especificação alterada e página nunca verificada. O QA pós-publicação transforma correções baratas em defeitos públicos.

Entradas e saídas

A saída é um contrato, não uma mensagem de chat. O publicador deve ser capaz de agir com base nele sem reconstruir a revisão.

A checklist

Cada item abaixo inclui a ação, motivo, método, ferramenta e condição observável de conclusão. “Verificado para SEO” ou “parece bom” nunca é evidência aceitável.

1. Conformidade com o tipo de postagem

Confirmar o tipo de postagem e escopo selecionados. O quê: corresponder o candidato a uma entrada na biblioteca de tipos de postagem e remover material pertencente a um tipo irmão. Por quê: o tipo de página determina intenção, estrutura, evidência e comportamento de conversão. Como: rotular cada seção com a decisão do leitor que ela suporta e compará-la com o propósito e exclusões do tipo. Ferramenta: briefing aprovado, mapa tópico e páginas de tipos de postagem. Concluído quando: exatamente um tipo primário está registrado, a abertura, o corpo e o CTA o servem, e zero seções existem apenas para a função de outro tipo.

Rastrear estrutura obrigatória e faixas de palavras. O quê: mapear cada seção obrigatória para o candidato renderizado e contar suas palavras em relação à faixa especificada. Por quê: seções ausentes criam perguntas sem resposta, enquanto comprimento descontrolado esconde lacunas atrás de volume. Como: usar uma matriz de requisito-para-cabeçalho e contagens automatizadas, depois inspecionar casos limite manualmente. Ferramenta: especificação do tipo de postagem, fonte e página renderizada. Concluído quando: zero seções obrigatórias estão ausentes e cada seção está dentro de seu mínimo e máximo declarados.

2. Conformidade de elementos

Verificar elementos, posições e parâmetros. O quê: comparar o mapa de elementos com a fonte e a renderização. Por quê: posição e campos fazem parte da função; uma resposta direta enterrada não responde mais primeiro, e parâmetros malformados podem quebrar a saída. Como: inspecionar de cima para baixo e validar campos, valores, aninhamento e sintaxe permitidos. Ferramenta: especificações de elementos, validador e navegador. Concluído quando: todo elemento obrigatório está em sua posição exigida, todo parâmetro é válido e nenhum duplicado inexplicado permanece.

Aplicar precedência de elementos tipados. O quê: aplicar as regras de redação de elementos sempre que uma passagem tiver um propósito registrado. Por quê: o texto livre pode parecer similar, mas não pode carregar a identidade do componente, campos, comportamento de acessibilidade ou saída estruturada. Como: declarar a função de cada bloco como um verbo — definir, alertar, comparar, instruir, resumir — e verificar se há um elemento correspondente. Ferramenta: biblioteca de elementos e inspetor de fonte. Concluído quando: zero passagens usam texto livre onde um elemento tipado é obrigatório.

3. Qualidade do conteúdo

Testar a resposta isoladamente. O quê: ler o bloco de resposta direta sem seu cabeçalho ou parágrafos ao redor. Por quê: sistemas de busca e recuperação de IA podem extrair apenas essa passagem. Como: verificar se nomeia o assunto, responde à pergunta, inclui qualificação necessária e não depende de “isto”, “ele” ou “como acima”. Ferramenta: visualização de texto isolado e revisor humano. Concluído quando: a resposta é autossuficiente, precisa e está dentro da faixa especificada de 40–60 palavras quando esse elemento é obrigatório.

Verificar alegações, linguagem e exclusividade. O quê: rastrear alegações materiais até a evidência, explicar jargões no primeiro uso e comparar o candidato com páginas que servem à mesma intenção. Por quê: alegações não suportadas prejudicam a confiança, enquanto quase-duplicatas competem e divergem. Como: sinalizar nomes, datas, números, alegações causais, comportamento de produtos e candidatos a similaridade; apoiar, qualificar, consolidar ou removê-los. Ferramenta: registro de evidências, fontes primárias, busca no site e relatório de similaridade. Concluído quando: zero alegações materiais carecem de suporte, zero termos de especialista permanecem inexplicados e nenhuma página existente responde à mesma intenção e escopo sem um plano de consolidação.

4. Frontmatter

Validar campos de identidade e prévia. O quê: aplicar a especificação de frontmatter ao título, descrição, palavras-chave, entity e junções de tipo de postagem. Por quê: esses campos direcionam roteamento, prévias, schemas e relacionamentos sem ler o corpo. Como: executar validação de campo e tamanho, depois comparar o significado com a página visível. Ferramenta: linter de frontmatter e prévia humana. Concluído quando: o título é único e preciso, a descrição tem 150–160 caracteres, as palavras-chave contêm 6–8 entradas relevantes e entity corresponde ao contrato do tipo de postagem.

Verificar campos de governança e FAQ. O quê: verificar datas, autor, revisor, propriedade e estrutura de FAQ visível em relação ao frontmatter. Por quê: registros anônimos impedem responsabilização, enquanto desvio de FAQ faz respostas visíveis e estruturadas discordarem. Como: comparar campos com o rastro de lançamento e texto visível normalizado. Ferramenta: analisador de fonte, rastreador e página renderizada. Concluído quando: datas e responsáveis obrigatórios são válidos, o revisor humano é nomeado quando exigido, a contagem de FAQ atende ao mínimo do tipo, cada par corresponde e zero entradas ocultas ou vazias permanecem.

5. Dados estruturados

Exigir o schema correto. O quê: confirmar que a marcação schema aplicável existe para a página e seus elementos visíveis. Por quê: marcação ausente ou genérica descarta significado legível por máquina que o modelo de conteúdo já fornece. Como: comparar tipos e propriedades emitidos com os contratos de tipo de postagem e elementos. Ferramenta: HTML renderizado e validador de schema. Concluído quando: todo tipo de schema obrigatório está presente uma vez, as propriedades obrigatórias estão preenchidas e nenhum tipo inaplicável é emitido.

Validar paridade, não apenas sintaxe. O quê: comparar nomes, datas, autor, entidade, FAQ, etapas e alegações do schema com o conteúdo visível. Por quê: sintaxe válida ainda pode descrever informações invisíveis ou contraditórias. Como: validar JSON-LD, depois comparar valores com a página. Ferramenta: teste de dados estruturados e revisão humana. Concluído quando: há zero erros e zero fatos no schema que contradizem ou excedem o conteúdo visível.

6. Links internos

Linkar para cima e para fora. O quê: fornecer uma rota para o pilar relevante e rotas contextuais para nós relacionados. Por quê: a hierarquia ajuda leitores e rastreadores a entender onde a página se encaixa, enquanto links laterais continuam a tarefa do leitor. Como: mapear cada link interno para uma próxima pergunta genuína, em vez de preencher uma cota. Ferramenta: grafo de links e página renderizada. Concluído quando: a página tem pelo menos um link para seu pilar, pelo menos um link lateral relevante onde um nó relacionado existe, e pelo menos uma página existente linka para ela antes ou no momento da publicação, para que não fique órfã.

Inspecionar destinos e âncoras. O quê: abrir cada destino e revisar seu texto âncora . Por quê: uma URL plausível pode estar ausente, redirecionada ou não relacionada, e rótulos genéricos escondem o propósito do destino. Como: executar um verificador de links internos, depois inspecionar manualmente as âncoras no contexto da frase. Ferramenta: rastreador e navegador. Concluído quando: zero links internos retornam erro, cada destino suporta a alegação ao redor e nenhum “clique aqui” isolado, URL crua ou âncora de correspondência exata enganosa permanece.

7. Mídia

Verificar ativos, alternativas e atualidade. O quê: confirmar que cada imagem existe, tem texto alternativo significativo ou uma alternativa vazia justificada, e reflete a interface atual. Por quê: mídia quebrada, vaga, placeholder ou desatualizada remove informações e pode tornar instruções inutilizáveis. Como: desabilitar imagens, inspecionar caminhos, reproduzir etapas do produto e comparar rótulos, valores, recortes e edição. Ferramenta: verificador de ativos, auditoria de acessibilidade, produto ativo e navegador. Concluído quando: zero ativos estão ausentes ou são placeholders, as alternativas são precisas e cada captura de tela representa a etapa atual.

8. Lançamento técnico

Verificar roteamento, indexabilidade e substituição. O quê: verificar slug, uma URL canônica autorreferente, status, comportamento robots, indexabilidade e redirecionamentos. Por quê: o conteúdo não pode ter desempenho na rota errada, atrás de noindex, ou depois que URLs antigas ficam abandonadas. Como: inspecionar o head renderizado e a resposta, comparar o registro e seguir cada rota substituída. Ferramenta: verificador de cabeçalho, mapa de redirecionamento, inspetor de fonte e inspeção de URL. Concluído quando: a URL aprovada retorna 200 com uma canônica pretendida e sem bloqueio; cada URL substituída dá um salto permanente para a substituição válida mais próxima.

Testar estabilidade móvel. O quê: inspecionar leitura em largura estreita, interação, estouro e Cumulative Layout Shift . Por quê: componentes que funcionam em desktop podem esconder controles, cortar tabelas ou mover conteúdo conforme a mídia carrega. Como: testar larguras móveis representativas e carregar a página com limitação de banda. Ferramenta: modo de dispositivo do navegador e relatório de desempenho. Concluído quando: todo conteúdo e controles permanecem utilizáveis sem estouro horizontal da página e o CLS medido é 0,1 ou inferior.

9. Prontidão para IA

Testar extração e HTML inicial. O quê: inspecionar respostas, definições, fatos-chave, comparações e conclusões como passagens independentes no HTML fornecido pelo servidor. Por quê: sistemas de recuperação podem selecionar uma passagem e podem não executar código do lado do cliente. Como: buscar o HTML inicial, remover contexto ao redor e verificar nomes de entidades, qualificadores, unidades e pronomes. Ferramenta: busca de HTML, extrator de passagens, navegador e auditoria AmICited. Concluído quando: todo fato prioritário está presente sem JavaScript e mantém seu sujeito, significado e limitações por conta própria.

Expor estrutura procedural. O quê: verificar se pares de FAQ e etapas ordenadas estão codificados como campos reconhecíveis e permanecem visíveis. Por quê: cabeçalhos e caixas estilizadas podem parecer corretos enquanto as máquinas recebem prosa não estruturada. Como: comparar saída de elementos, estrutura acessível e schema com a sequência visível. Ferramenta: árvore de acessibilidade e validador de dados estruturados. Concluído quando: todo FAQ obrigatório é legível por máquina como um par pergunta-resposta e todo procedimento obrigatório preserva etapas ordenadas na saída visível e estruturada.

Ferramentas no AmICited

Use o produto para inspecionar o candidato e estabelecer evidência de transferência; ele não substitui o julgamento humano.

1. Abra a auditoria de prontidão para agentes junto com Acessibilidade de IA e Prontidão para Agentes para inspecionar acessibilidade, alcançabilidade por rastreadores, cobertura de sitemap e conteúdo legível por agentes.
2. Inspecione a URL candidata com Inspeção de URL para verificar status de indexação, usabilidade móvel e veredito de resultados aprimorados. Atribua inspeção ativa na transferência para uma nova URL.
3. Abra a auditoria de atualização com Atualização de Conteúdo para dar a páginas sensíveis ao tempo um sinal de manutenção e próxima data de revisão. O histórico começa quando o rastreamento começa; nenhum histórico não significa nenhuma alteração.
4. Use SEO MCP através da conexão do workspace para verificações repetíveis e somente leitura de URL, atualização, Web Vitals e acessibilidade. Armazene a saída ou identificador de execução.

Automação: script das verificações determinísticas, preserve decisões humanas

Uma verificação que pode ser automatizada mas permanece manual será ignorada sob pressão. Automatize resultados estáveis e observáveis por máquina; exija um humano para propósito, verdade e contexto.

Automação escreve evidência, não aprovação. Falha bloqueia o portão; um script aprovado não aprova as colunas humanas.

Regras de decisão

“Ruim” deve ser observável. Use estes limites a menos que o tipo de postagem ou elemento selecionado defina um mais rigoroso; o contrato mais específico vence.

N/A não é uma aprovação mais branda. É válido apenas quando o item genuinamente não se aplica — por exemplo, nenhum redirecionamento é necessário porque nenhuma URL está sendo substituída — e o registro explica o motivo. Uma exceção deve nomear a regra alterada, razão de negócio, risco, aprovador, responsável pela correção e expiração. A autoridade de lançamento a assina; o revisor de QA não a autoaprova.

Entregável: o registro de aprovação

Anexe um registro imutável ao candidato exato. Uma auditoria posterior deve ser capaz de distinguir “nunca verificado” de “verificado e aprovado sob a versão 1 da especificação”. Armazene campos estruturados em vez de uma captura de tela de marcas verdes.

Caminho da página / canônica:
ID do candidato de lançamento ou hash de conteúdo:
Tipo de postagem e entidade:
Versão da especificação:
Responsável pelo QA:
Autoridade de lançamento:
Iniciado / concluído (carimbo de data/hora):

Verificações:
- Grupo / item:
- Resultado: APROVADO | REPROVADO | N/A
- Evidência: saída do validador, localização na fonte, destino ou observação
- Verificado por / em:

Exceções:
- Regra e escopo:
- Razão e risco:
- Aprovador:
- Responsável pela correção / expiração:

Decisão: APROVADO — PUBLICAR | REPROVADO — RETER
Responsável pela verificação ativa e prazo:
Próxima data de revisão de manutenção:

Um registro de aprovação é somente para anexação. Uma especificação ou candidato alterado recebe uma nova auditoria, não um histórico reescrito.

O que acontece em caso de falha

A falha inicia um ciclo de correção, não uma negociação no tópico de revisão.

1. O responsável pelo QA marca o candidato como REPROVADO — RETER, registra evidências e para no ponto em que continuar testaria uma versão que certamente mudará.
2. O responsável pelo conteúdo corrige falhas de tipo de postagem, elemento, texto, metadados e evidência. O responsável pela implementação corrige falhas de schema, links, mídia, roteamento, renderização e automação. Um especialista reexamina alegações em seu domínio.
3. O corretor identifica cada superfície alterada. O responsável pelo QA executa novamente o item reprovado, seus itens dependentes e qualquer grupo afetado pela mudança. Uma resposta reescrita, por exemplo, reabre alegações, conformidade de elementos, paridade de schema e extração de IA.
4. O responsável pelo QA cria um novo resultado com carimbo de data/hora. A publicação permanece bloqueada até que cada item aplicável seja aprovado e cada N/A ou exceção tenha autoridade válida.

O autor não certifica sua própria correção. O QA é dono do registro, a produção é dona das correções, os especialistas são donos da aprovação de domínio e a autoridade de lançamento é dona das exceções.

O que dá errado

• Tratar o portão como revisão de texto. A gramática pode estar impecável enquanto a página usa o tipo de postagem errado, contradiz seu schema ou não pode ser indexada.
• Testar a fonte em vez do candidato de lançamento. Markdown válido não prova que os templates emitiram a canônica pretendida, estrutura acessível ou layout responsivo.
• Tornar cada item manual. Revisores clicam verificações determinísticas repetidamente até que um prazo os ensine a pular a lista.
• Tornar cada item automatizado. Um validador verde não pode decidir se a evidência suporta uma alegação causal ou se uma comparação responde à decisão do leitor.
• Aceitar “vou corrigir depois do lançamento.” Isso converte um portão de pré-publicação em um backlog não documentado e apaga o significado de APROVADO.
• Permitir que a mesma pessoa implemente e aprove. A auto-revisão perde suposições porque o revisor lembra do comportamento pretendido em vez de observar a saída real.

Transferência

O próximo estado é a publicação e verificação ativa. O QA entrega o candidato aprovado, registro APROVADO, rota canônica, mapa de redirecionamento, janela de lançamento e exceções aprovadas. O publicador retorna a URL ativa e o horário de implantação; o responsável pela verificação ativa repete as verificações de status, canônica, indexabilidade, redirecionamentos, schema, links, mídia, mobile e CTA.

Se a produção for diferente, as verificações afetadas são reabertas. Se corresponder, adicione a URL ativa e evidência sem sobrescrever o resultado do candidato. Auditorias posteriores usam a versão da especificação armazenada para distinguir desvio de um padrão alterado.

FAQ

Perguntas frequentes

Aprovado significa que o candidato está em conformidade com o contrato atual com evidência inspecionável. Qualquer outra coisa é uma retenção. O CTA de encerramento do layout da academia segue este FAQ.