SEO Landing — PageSpeed 100 + schema no ship

Gerador de SEO Landing

Cria uma página HTML estática de página única otimizada para 100/100 no PageSpeed e máximo SEO: CSS crítico, imagens AVIF, dados estruturados JSON-LD completos, interatividade apenas nativa, zero requisições de terceiros no primeiro carregamento.

Quando Usar

• O usuário pedir uma landing page / one-pager com foco em velocidade e SEO → modo gerar.
• O usuário fornecer um brief (ТЗ) e quiser uma página estática pronta para produção → modo gerar.
• O usuário pedir uma auditoria de uma landing page existente com base na checklist, sem alterações → modo apenas-auditoria (§0b, somente leitura, sem arquivos de projeto).
• O usuário pedir para corrigir/melhorar uma landing page existente → modo corrigir-existente (§0c).

Procedimento

0. Primeiro, direcione a solicitação para um modo

A skill atende três modos — escolha um com base na solicitação (pergunte se ambíguo), pois cada modo coleta entradas diferentes e produz saídas diferentes:

• gerar — criar uma nova landing page a partir de um brief ("criar/construir/gerar uma landing…"). Executa o procedimento completo abaixo.
• apenas-auditoria — inspeção somente leitura de uma página existente ("auditar/verificar/revisar esta landing contra a checklist…", sem alterações solicitadas). Executa §0b. Nunca escreve arquivos de projeto.
• corrigir-existente — aplicar correções direcionadas a uma página existente ("corrigir/melhorar/otimizar esta página…"). Executa §0c.

Roteamento representativo:

• "Crie uma landing para uma clínica odontológica a partir deste brief" → gerar.
• "Audite https://exemplo.com/ contra a checklist de desempenho e relate o que está errado" → apenas-auditoria.
• "A imagem hero desta landing está mudando no carregamento — corrija isso" → corrigir-existente.

Campos do brief exclusivos da geração (palavras-chave alvo, tipo de negócio, CTA, fatos de mídia) são coletados APENAS para trabalhos de geração e reconstrução. Uma auditoria ou correção direcionada não deve ser bloqueada ou atrasada por entradas de geração ausentes, e o modo apenas-auditoria não deve criar ou modificar arquivos de projeto.

0a. Coletar o brief (modo gerar; pergunte se ausente)

Obrigatório antes de gerar qualquer coisa:

• Domínio / URL final — para canonical, og:url, caminhos absolutos, JSON-LD @id.
• Identidade do site (para marcação WebSite, apenas quando a página é a página inicial do domínio/subdomínio): nome preferido do site, nomes alternativos opcionais e a URL canônica da página inicial — coletados separadamente da URL da landing.
• Trilha de breadcrumbs (para marcação BreadcrumbList, apenas quando existe uma hierarquia real do site): a trilha visível de breadcrumbs e as URLs canônicas pai.
• Idioma da página, direção base e locale Open Graph — três entradas separadas, nunca um valor copiado entre formatos: uma tag de idioma BCP-47 para <html lang> (ex.: en-US, ar-SA), a direção base (ltr/rtl — documentos RTL recebem dir="rtl" em <html>, e lang sozinho não define direcionalidade) e o locale Open Graph no formato language_TERRITORY para og:locale (ex.: en_GB). Pergunte quando a direção for desconhecida para um idioma com capacidade RTL (especificação técnica §2).
• Tópico + 1–3 palavras-chave alvo — para H1, title, description.
• Tipo de negócio: Organization ou LocalBusiness. Para LocalBusiness colete o nome comercial público/legal verificado e o endereço postal estruturado completo (rua, localidade, região, código postal, país), além de telefone e coordenadas geográficas. Também colete o(s) subtipo(s) schema.org verificado(s) com base no negócio real (ex.: Restaurant, Dentist, HardwareStore) — nunca escolhido a partir de palavras-chave alvo. Nunca invente fatos de identidade ausentes: recorra à marcação Organization ou omita a marcação de entidade até que os fatos sejam fornecidos.
• CTA e contatos (telefone, formulário, mensageiros). Quando um formulário for solicitado, colete também seu destino e método de envio (um endpoint próprio ou um serviço de formulário documentado — nunca inventado), o texto de consentimento/privacidade necessário para os dados pessoais coletados e onde as submissões são armazenadas e quem as possui; sem destino, o formulário é omitido ou explicitamente esboçado (especificação técnica §10 contrato de envio de formulário).
• Um favicon aprovado pela marca ou permissão explícita para criar um — nunca invente uma marca silenciosamente.
• Material de origem aprovado e um proprietário de declaração para fatos objetivos de marketing (números, preços, qualificações, garantias, comparações, estudos de caso) — sem eles, tais declarações são omitidas, nunca inventadas.
• Se as imagens são fornecidas; se blocos de FAQ / avaliações / vídeo são necessários. Para um bloco de vídeo colete fatos apoiados por fontes: URL/ID do vídeo, título, descrição, data/hora precisa da primeira publicação com fuso horário e uma miniatura rastreável única (além de contentUrl quando aplicável). Nunca invente fatos de mídia ausentes. Também colete o modo de vídeo com sua compensação declarada: fachada somente com clique (padrão — privacidade/desempenho; a página não atenderá aos requisitos de descoberta de vídeo do Google e nenhum benefício de pesquisa de vídeo é reivindicado) ou detectável por SEO (<video> auto-hospedado ou um embed direto documentado — necessário quando o tráfego de pesquisa de vídeo for relevante) (especificação técnica §9).

Se domínio ou palavras-chave estiverem ausentes — pergunte primeiro, não os invente.

0b. Modo apenas-auditoria (somente leitura)

Auditar uma página existente sem gerar uma substituição. Nenhum arquivo de projeto é criado ou modificado neste modo — a entrega é um relatório.

1. Identifique o alvo: uma URL implantada (preferível — permite que cada verificação seja executada contra a realidade) ou arquivos HTML locais. Se nenhum for fornecido, pergunte; nunca adivinhe o alvo.
2. Execute as verificações aplicáveis da §5 contra o alvo como está: validade W3C, existência de ativos locais (para arquivos locais), JSON-LD por meio de um validador schema.org, Lighthouse contra a URL servida/implantada, contrato de rastreabilidade (robots.txt + sitemap.xml no host implantado) e as verificações manuais de acessibilidade na especificação técnica §8.
3. Relate evidências por verificação: aprovado/reprovado com o valor medido ou marcação observada, e o comando/ferramenta exato usado. Onde uma verificação não puder ser executada (sem URL implantada para Lighthouse, sem robots.txt no host), relate um bloqueador para essa verificação — não estime, extrapole ou omita silenciosamente.
4. Distingua validade de sintaxe de elegibilidade para recursos do Google (FAQPage, VideoObject, rich results): marcação válida é relatada como marcação válida, nunca como um recurso de pesquisa alcançado.
5. Opcionalmente, termine com uma lista de correções priorizada. Aplicar correções é uma solicitação separada de corrigir-existente — não comece a editar sem ela.

0c. Modo corrigir-existente

Aplicar correções direcionadas a uma página existente sem uma reconstrução completa.

1. Identifique a página/arquivos e os problemas específicos a corrigir; colete apenas as entradas que essas correções precisam (nunca o brief completo de geração).
2. Aplique cada correção de acordo com a seção relevante da especificação técnica, preservando marcação e conteúdo não relacionados.
3. PONTO DE PARADA (§4) se aplica: mostre a página alterada antes da validação. Se as correções alterarem o que o usuário aprovou anteriormente, obtenha nova aprovação antes de relatar.
4. Valide a página alterada (§5) e relate apenas evidências medidas.

Fluxo de trabalho de geração (modo gerar)

1. Criar a pasta do projeto

Cada projeto vive em sua própria pasta dentro do workspace — nunca escreva na raiz do workspace. A saída é um projeto com vários arquivos: todo recurso local referenciado pelo HTML deve existir como um arquivo real.

<workspace>/<slug-do-projeto>/
  index.html        # a página landing gerada
  styles.css        # apenas quando o CSS abaixo da dobra é adiado (§1); ausente quando todo CSS está inline
  script.js         # apenas quando a página usa JS (§10); arquivo único, defer
  images/           # todas as variantes de imagem referenciadas em src/srcset/preload/tags OG (AVIF/WebP/JPEG, todos os breakpoints)
  favicon.png       # ícone de marca estável quadrado, ≥48×48
  ASSETS.md         # registro de direitos e proveniência para cada ativo
  robots.txt
  sitemap.xml
  SERVER-SETUP.md   # instruções de hospedagem

Ramo de imagens:

• Imagens fornecidas no brief → produza todas as variantes necessárias (AVIF/WebP/JPEG em cada breakpoint nomeado em srcset) a partir delas.
• Nenhuma imagem disponível → solicite-as ao usuário ou omita a imagem/bloco. Nunca emita uma URL de ativo de aparência bem-sucedida sem produzir o arquivo ou pedir explicitamente por ele — um arquivo referenciado mas ausente é uma falha de geração, não um espaço reservado.

2. Gerar a página

Construa index.html seguindo estritamente references/tech-spec.md — 13 seções de requisitos (desempenho, estrutura HTML, SEO, segurança, CSS/fontes, lista proibida, testes, acessibilidade, vídeo incorporado, blocos típicos, widgets adiados, veracidade e proveniência do conteúdo, sanitização de entrada e codificação de saída).

Trate cada valor do brief como não confiável: codifique-o para seu contexto exato de saída (texto HTML, atributo, URL, JSON-LD), permita apenas esquemas de URL na lista de permissões (rejeite javascript:/data: inesperados), escape < em JSON-LD serializado e valide IDs estruturadas (ex.: YouTube ^[A-Za-z0-9_-]{11}$) antes que cheguem a qualquer URL (especificação técnica §13).

Para vídeo incorporado do YouTube, use o padrão de fachada por padrão; o modo detectável por SEO (<video> auto-hospedado ou um embed direto documentado) é uma escolha explícita do brief com uma compensação divulgada, nunca uma troca silenciosa — regras e os requisitos de descoberta do Google na especificação técnica §9, implementação de referência da fachada em references/video-facade.md. Mapas seguem apenas a regra da fachada (especificação técnica §10): uma captura de tela local no DOM inicial, o iframe inserido apenas na ativação explícita — nunca um iframe de mapa nativo com loading="lazy". Referência: references/map-facade.md.

3. Gerar arquivos complementares

• robots.txt na raiz do site com uma linha Sitemap: totalmente qualificada, nunca bloqueando a página canônica ou a mídia necessária.
• sitemap.xml com URLs canônicas <loc> absolutas com escape XML, correspondendo ao HTML canônico; lastmod apenas a partir de um timestamp verificável de alteração de conteúdo significativo (omita quando desconhecido — nunca use a hora da geração cegamente).
• Instruções de hospedagem de references/server-config.md: cache, Brotli/gzip, cabeçalhos de segurança.

4. PONTO DE PARADA — aprovação do usuário

Mostre a página gerada ao usuário e pergunte explicitamente se a versão HTML está OK. Não prossiga para a validação e o relatório final até que o usuário confirme. Se houver observações — corrija e pergunte novamente.

5. Validar

Execute o contrato de validação executável da especificação técnica §7 — comandos fixos contra a página servida, resultados medidos apenas, BLOQUEADOR explícito quando uma porta não puder ser executada:

• Validade HTML W3C (validador Nu, saída JSON; zero erros).
• Existência de ativo/link local: extraia toda URL local referenciada pela saída (img src/srcset, <source> srcset, preload href/imagesrcset, favicon, imagens OG/Twitter, CSS url(), script src) e verifique se cada arquivo existe na pasta do projeto. Qualquer recurso local referenciado ausente é uma falha grave — produza o arquivo ou remova a referência; nunca envie HTML apontando para arquivos que nunca foram criados.
• Sintaxe JSON-LD (analisar JSON) — separada da elegibilidade para rich results do Google, que é verificada com o Rich Results Test na página implantada.
• Capturas de tela responsivas em 320/768/1280/1920px, inspecionadas quanto a estouro e refluxo.
• Lighthouse: versão/perfil fixos, 3 execuções, mediana por categoria, limite ≥ 90, artefatos mantidos na pasta reports/ do projeto — apenas evidências de laboratório, nunca Core Web Vitals de campo e nunca certificação WCAG.
• Verificações manuais de acessibilidade (especificação técnica §8) — nenhuma ferramenta automatizada sozinha determina conformidade WCAG: navegação por teclado, ordem/foco visível, fluxo de foco em diálogos, zoom/refluxo, movimento reduzido, nome-papel-valor semântico, qualidade de texto alternativo e todos os estados visuais interativos. Registre evidências de aprovado/reprovado por critério WCAG 2.1 AA aplicável; relate itens não resolvidos em vez de certificá-los silenciosamente.
• Contrato de rastreabilidade: analise sitemap.xml, compare cada <loc> com o HTML canônico, verifique a URL Sitemap: em robots.txt e solicite ambos os arquivos implantados com sucesso (HTTP 200).

Corrija quaisquer violações encontradas antes de relatar. Divulgue evidências honestamente: cada número relatado vem com o comando exato e o caminho do artefato que o produziu; uma porta que não pôde ser executada é relatada como BLOQUEADOR: <motivo> em vez de um número. Nunca produza uma pontuação PageSpeed/LCP que não foi realmente medida.

6. Relatório final

Liste resumidamente:

• Parâmetros LCP
• Pontuação PageSpeed
• Tipos schema.org usados no código

Principais armadilhas

• Nunca use bibliotecas JS/CSS externas, fontes externas ou imagens SVG (especificação técnica §6).
• Nunca referencie um ativo local que nunca foi criado: cada src/srcset/URL de preload/OG deve resolver para um arquivo real na pasta do projeto; imagens de origem ausentes são solicitadas ao usuário, não inventadas (contrato de SAÍDA).
• Nunca emita um valor bruto do brief na marcação: codifique tudo por contexto, rejeite URLs javascript:/data: inesperadas e teste automaticamente a geração com valores hostis (aspas, </script>, cargas de manipulador de eventos) (especificação técnica §13).
• Nunca carregue iframes do YouTube, mapas, chats, pop-ups de inscrição ou banners de cookies no primeiro carregamento (especificação técnica §9, §10, §11) — a única exceção documentada é um modo de vídeo detectável por SEO escolhido no brief com um embed direto registrado como dependência de primeiro carregamento (especificação técnica §9 Modo S).
• Todo o conteúdo deve existir em HTML bruto — nada renderizado apenas por JS.
• URLs absolutas em JSON-LD, canonical e tags OG.
• Orçamento total de JS ≤ 15 KB, um arquivo, defer antes de </body>.