Landing page com SEO: lançar, estruturar, validar

Construindo Páginas de Aterrissagem Otimizadas para SEO

Use este skill para criar, melhorar, auditar, implantar ou validar páginas de aterrissagem.

Não use este skill para pequenas edições de texto, estilo ou componente, a menos que SEO, conversão, acessibilidade, desempenho, implantação ou prontidão para lançamento façam parte da solicitação.

Fluxo de Trabalho Principal

1. Inspecione o projeto existente antes de editar.
2. Identifique o negócio/entidade, público, localização, serviços, objetivo de conversão e destino de implantação.
3. Identifique a stack tecnológica e mantenha suas convenções.
4. Verifique metadados, headings, dados estruturados, sitemap, robots (incluindo acesso de crawlers de IA), llms.txt, favicon, manifest, pré-visualizações sociais e fatos visíveis do negócio.
5. Revise layout responsivo, acessibilidade, dimensionamento de imagens, carregamento de JavaScript e riscos de CLS.
6. Faça alterações concretas de arquivo usando o estilo existente do projeto.
7. Execute as ferramentas de validação disponíveis ou forneça comandos exatos se estiver bloqueado.
8. Resuma as alterações, verificação, riscos restantes e etapas pós-lançamento.

Prioridades Padrão

• Torne o primeiro viewport claro: entidade, oferta, localização ou público e CTA principal.
• Mantenha fatos importantes visíveis no HTML, não apenas em metadados ou JSON-LD.
• Prefira schema Service para serviços; use schema Product apenas com dados reais de oferta de produto.
• Para negócios locais, priorize consistência NAP (nome, endereço, telefone), áreas de serviço, horário de funcionamento, links para mapa/perfil, avaliações e fotos reais.
• Trate domínio personalizado, Google Business Profile, avaliações, citações, Search Console e fotos reais como trabalho de lançamento/off-site, não apenas ajustes de código.
• Após alterações de domínio ou implantação, atualize canonical, sitemap, URL do sitemap no robots, URLs de dados estruturados, URLs de imagens sociais e propriedade do Search Console.
• Não invente classificações, avaliações, garantias, rankings, indexação, Core Web Vitals, pontuações Lighthouse/PageSpeed, status de implantação, status de citação em AI Overview/AI ou resultados de API.
• Os schemas FAQ e HowTo não produzem mais resultados ricos do Google (FAQ removido em 7 de maio de 2026; HowTo removido em 2023); mantenha o schema FAQPage para entendimento de IA/mecanismos de resposta, não para um recurso prometido de SERP.
• Pergunte ao proprietário do site antes de alterar o acesso de bots de IA em robots.txt; isso altera a exposição real a citações de assistentes e treinamento de modelos. Observe que AI Overviews/AI Mode do Google são regidos pelo acesso normal do Googlebot e controles do Search Console, não por tokens de bot de IA.
• llms.txt é uma higiene opcional sem aumento comprovado de ranking ou citação, e o Google afirma que não é necessário para recursos de IA; ofereça, não venda como uma vantagem de visibilidade para IA.
• Adapte o design ao tipo de página e público; priorize clareza, confiança, usabilidade em dispositivos móveis e conversão sobre decoração.

Quando Ler as Referências

• Para fluxo de construção e estrutura de página, leia references/landing-page-workflow.md.
• Para detalhes de implementação específicos de framework, leia references/framework-implementation.md.
• Para texto de página de aterrissagem, CTAs e sinais de confiança, leia references/content-conversion.md.
• Para verificações de SEO, AEO, GEO e busca local, leia references/seo-aeo-geo-checklist.md.
• Para sites de negócios locais, leia references/local-business-seo.md.
• Para preocupações com JSON-LD e resultados ricos, leia references/structured-data.md.
• Para desempenho, acessibilidade e trabalho de CLS, leia references/performance-accessibility.md.
• Para scripts de validação, Lighthouse/PageSpeed, Search Console e relatórios, leia references/validation-workflow.md.
• Para implantação, domínios, Search Console e Google Business Profile, leia references/deployment-domain-search-console.md.
• Para llms.txt, acesso de crawlers de IA e relatórios de busca de IA, leia references/ai-crawlers-and-llms-txt.md.
• Para WebMCP, ferramentas chamáveis por agente e formulários prontos para agente, leia references/webmcp.md.

Templates

Use os templates apenas como pontos de partida. Adapte-os ao projeto antes de inserir:

• templates/metadata-head.html
• templates/site.webmanifest
• templates/robots.txt
• templates/sitemap.xml
• templates/local-business-jsonld.html
• templates/website-jsonld.html
• templates/website-with-search-jsonld.html - legado; seu SearchAction não produz mais um recurso do Google
• templates/organization-jsonld.html
• templates/person-jsonld.html
• templates/breadcrumb-jsonld.html
• templates/faq-jsonld.html
• templates/service-offer-catalog-jsonld.html
• templates/static-landing-page.html
• templates/launch-checklist.md
• templates/privacy-notice.md
• templates/llms.txt

Scripts

Os scripts são auxiliares opcionais. Execute-os a partir da raiz do projeto de destino quando o ambiente permitir:

• scripts/check-metadata.mjs [html-file] [--no-write] - verificação estática de metadados, headings, imagem, favicon, manifest e SEO básico.
• scripts/check-structured-data.mjs [html-file] [--no-write] - análise de JSON-LD e verificações de sanidade do schema.
• scripts/check-links.mjs [html-file] [--network] [--no-write] - links locais, fragmentos, assets e verificação opcional de URLs externas.
• scripts/check-site-files.mjs [site-root] [--no-write] - verificação de robots.txt, sitemap.xml, site.webmanifest, llms.txt e ícones comuns; passe public para pastas públicas de frameworks.
• scripts/check-placeholders.mjs [paths...] [--no-write] - verificação de {{PLACEHOLDER}} não substituídos após aplicação de templates.
• scripts/run-lighthouse.mjs <url> [mobile|desktop] - relatório Lighthouse em JSON.
• scripts/summarize-lighthouse.mjs [lighthouse-json-report] [--no-write] - resumo em Markdown a partir de um relatório Lighthouse.
• scripts/run-pagespeed.mjs <url> [mobile|desktop] - relatório PageSpeed Insights em JSON.
• scripts/summarize-pagespeed.mjs [pagespeed-json-report] [--no-write] - resumo em Markdown a partir de um relatório PageSpeed.
• scripts/list-search-console-sites.mjs [--no-write] - listar propriedades verificadas do Search Console.
• scripts/submit-sitemap.mjs <search-console-site-url> <sitemap-url> - enviar um sitemap através da API do Search Console.
• scripts/inspect-url.mjs <inspection-url> <search-console-site-url> [language-code] - inspecionar dados de indexação de URL através da API do Search Console.

Use PAGESPEED_API_KEY para chamadas da API PageSpeed quando disponível.

Use GOOGLE_SEARCH_CONSOLE_ACCESS_TOKEN apenas para ações suportadas pela API do Search Console.

Se uma ação solicitada com suporte de API precisar de credenciais e a variável de ambiente estiver ausente, peça ao usuário para exportá-la em seu próprio terminal. Não peça para ele colar o segredo na conversa, e nunca digite uma chave você mesmo em um comando: uma chave colada ou digitada inline fica registrada na transcrição e nos logs, enquanto uma variável exportada é herdada por esses scripts sem nunca entrar na conversa. references/validation-workflow.md tem os comandos por shell.

Não escreva segredos em .env, arquivos rastreados ou configuração de projeto, a menos que o usuário peça explicitamente.

Se credenciais, rede, dependências ou cota não estiverem disponíveis, não finja sucesso. Explique o bloqueio e forneça etapas manuais ou comandos alternativos.

Quando não tiver certeza sobre o uso, execute o script com argumentos ausentes para ver seu texto de uso ou leia references/validation-workflow.md.

Regras

• Prefira edições concretas de arquivo a conselhos genéricos.
• Preserve as convenções existentes do projeto.
• Peça credenciais apenas quando a ação solicitada precisar delas, e peça ao usuário para exportá-las em vez de colá-las.
• Não faça keyword stuffing.
• Não adicione classificações falsas, avaliações falsas ou alegações não suportadas.
• Não prometa resultados de ranking, indexação ou Core Web Vitals.
• Evite animações de entrada que movam o layout. Prefira revelações apenas com opacidade quando animação for necessária.
• Frameworks não são ruins por padrão. Use HTML estático para sites simples e use React, Next.js, Astro ou frameworks similares quando o projeto já os utiliza ou precisa de seus recursos.
• Para negócios locais, priorize nome exato do negócio, consistência NAP, área de serviço, horário de funcionamento, link do mapa, Google Business Profile ou equivalente local, avaliações e orientação sobre domínio personalizado.