Opus Growth

Site

Prompts prontos para Claude, ChatGPT e outros assistentes conectados às suas contas de anúncios. Copie um, preencha os colchetes e envie.

Descreva seu problema e encontraremos os prompts certos

Escreva com suas próprias palavras o que está dando errado na sua conta de anúncios, no seu site ou no seu rastreamento. A IA escolhe os prompts da biblioteca que ajudam e explica por que cada um se encaixa.

Experimente:

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um site editorial de especialista com seção de guias e schema de autor

Peça ao seu assistente para criar o site de um especialista com página inicial em estilo capa de revista, guias longos e um perfil de autor. Tipografia serifada, schema Article e Person e artigos datados e com fontes resultam em uma publicação que as pessoas leem e que as respostas de IA podem citar.

Quando usarQuando você é consultor, especialista ou tem um negócio de conhecimento de uma pessoa só e quer que seu site pareça uma publicação que mostra sua expertise por meio da escrita, e não um folheto.

Use minha conexão com o Opus Growth para isso. Se você não encontrar a ferramenta de que precisa, procure entre as ferramentas do Opus Growth (com search_tools, se estiver na sua lista); se não conseguir acessar as ferramentas de forma alguma, não adivinhe, me avise.

Crie para mim um site de especialista em estilo editorial no meu servidor de hospedagem Opus Growth [nome do servidor]. Eu: [nome completo], [especialização, ex.: consultor de exportação], [região que atendo, ou "online"]. Serviços: [serviços]. Experiência: [experiência real e os setores em que trabalhei; não invente]. Telefone: [telefone], e-mail: [e-mail], domínio: [domínio]. Temas dos dois primeiros guias: [tema 1], [tema 2]. Se meu escritório recebe visitas, o endereço: [endereço ou "nenhum"].

O site deve parecer uma publicação que comprova expertise por meio da escrita, não um folheto. Os guias ficam no centro do site, porque são o que os leitores e as respostas de IA citam.

A direção de design é editorial:
1. Tipografia: uma serifa com personalidade da Fontshare para os títulos (ex.: Zodiak 700 e 400 itálico) e uma sans tranquila para a interface e os textos curtos (ex.: Author 400 e 600). Corpo do artigo na serifa a 19 pixels, entrelinha 1,7, no máximo 68 caracteres por linha.
2. Cor: fundo em papel creme, texto em tinta escura, um cinza quente secundário e um único destaque escuro (ex.: vinho). O destaque aparece apenas nos kickers, na letra capitular e nos filetes das citações em destaque.
3. Grade: 12 colunas; uma capa assimétrica 7 para 5 na página inicial, com filetes verticais finos entre as colunas. Sem sombras nem cantos arredondados.
4. Elemento de assinatura: um cabeçalho com filete duplo como o título de um jornal (com uma linha fina de data acima) e, nos artigos, uma grande letra capitular na cor de destaque mais uma citação em destaque na margem.
5. Movimento: nenhum.

Páginas e seus schemas:
1. index.html (capa): um título e um resumo cujo primeiro parágrafo responde "quem é você, quem você ajuda e com o quê", a imagem e o título do artigo principal, uma coluna lateral com o outro artigo, caixas de serviços e de autor, uma citação em destaque e uma faixa "como eu trabalho". WebPage e Person.
2. hizmetler.html: uma seção por serviço; o primeiro parágrafo diz para quem é e quando, seguido de etapas numeradas e da entrega escrita. Um Service por serviço, com o Person autor como provider.
3. hakkimda.html: experiência real, princípios de trabalho (sem resultados garantidos), como os artigos são produzidos e a política de fontes. ProfilePage com mainEntity Person (jobTitle, knowsAbout, worksFor #org).
4. rehber/index.html: artigos do mais recente ao mais antigo, com data e autor. CollectionPage e ItemList (numberOfItems).
5. rehber/[artigo].html: pelo menos 700 palavras, um primeiro parágrafo que responde diretamente à pergunta, uma hierarquia de H2, uma tabela com thead e th scope onde ajudar, pelo menos uma citação em destaque, de dois a quatro links internos e fontes no final. No topo, um link do autor e as datas de publicação e de última atualização em <time>. Article (headline, image, datePublished, dateModified, author via @id para o Person, publisher #org). Se usar valores de exemplo, diga que são fictícios.
6. iletisim.html: ContactPage. 7. kvkk.html (aviso de privacidade) e 404.html.

Se o escritório não recebe visitas, defina localBusiness: false em site.config.js; Organization mais Person bastam.

Regras técnicas. Siga-as à risca, porque os gates abaixo medem exatamente isto:

1. Configuração. Execute scaffold_site primeiro como prévia, mostre-me a lista de arquivos e instale com confirm=true depois que eu aprovar. Em seguida, leia site_design_guide e site_seo_guide por inteiro. Antes de escrever qualquer código, escreva a direção em _kaynak/ART.md (sensação, combinação de fontes, cores com taxas de contraste, grade, elemento de assinatura, decisão sobre movimento, lista de páginas) e mostre-me.
2. Elimine o JavaScript. Nenhuma página deste site carrega JavaScript. Remova de todas as páginas o script cdn.tailwindcss.com, a linha tailwind.config, as tags GSAP, ScrollTrigger, SplitText, Lenis e Swiper e as tags de script motion.js, chrome.js e site.config.js; apague assets/chrome.js e assets/motion.js. Mantenha assets/site.config.js, mas apenas como fonte de marca, contato e seo para o seo-stamp.mjs; ele nunca é carregado no navegador.
3. Menu e rodapé são HTML estático. Os componentes <site-nav> e <site-footer> são desenhados por JavaScript, então rastreadores de busca e de IA não conseguem ver o menu, os links internos nem os dados de contato. Escreva o cabeçalho em _kaynak/ust.inc e o rodapé (nome, endereço, telefone, e-mail, todos os links das páginas, aviso de privacidade, "Web: Opus Growth") em _kaynak/alt.inc. Use a extensão .inc para que seo-stamp e html-validate não tratem os fragmentos como páginas. Toda página leva os marcadores  e . Depois escreva um script Node sem dependências com site_write_file em _kaynak/parca-bas.mjs: ele carimba os dois fragmentos entre os marcadores em cada arquivo HTML, adiciona aria-current="page" ao link do menu da página atual e reescreve o sitemap.xml usando o dateModified do JSON-LD de cada página como lastmod (ignorando 404 e páginas noindex). Construa o menu mobile sem JavaScript usando <details><summary>Menu</summary>; os menus de desktop e mobile são dois elementos <nav> separados com aria-labels diferentes.
4. Hospede as fontes você mesmo. Este site usa duas famílias e no máximo cinco arquivos; as fontes do título, do resumo em itálico e do corpo aparecem todas na primeira tela, então faça preload das quatro. Na demonstração, o preload de apenas duas empurrou o CLS de um artigo longo para 0,24 e o Performance mobile para 86; o preload das quatro deu CLS 0 e Performance 99. Baixe o CSS da Fontshare (https://api.fontshare.com/v2/css?f[]=family@400,600&display=swap, código de peso 401 para itálico) com site_fetch para _kaynak/fontshare.css, leia-o com site_read_file e pegue apenas as URLs woff2 da família que você pediu; o serviço às vezes acrescenta uma família que você não solicitou. Baixe cada woff2 com site_fetch para assets/fonts/. Coloque as regras @font-face (font-display: swap) dentro de assets/app.css, porque o design-check.mjs só procura uma fonte personalizada nesse arquivo. Não use as padrão Inter, Roboto, Poppins ou Montserrat.
5. Compile o Tailwind. O assets/app.css vira a fonte do Tailwind: @tailwind base; @tailwind components; @tailwind utilities; no topo, depois @font-face, o anel de foco, o skip link, uma regra prefers-reduced-motion e suas próprias classes de componente dentro de @layer components. Nunca dê a uma classe de componente o nome de um utilitário do Tailwind (list-item, table, grid, container, hidden e assim por diante), porque o conflito quebra o layout silenciosamente após a compilação. Escreva tailwind.config.js na raiz (content: ["./*.html", "./**/*.html", "./_kaynak/*.inc"], cores e fontFamily). Execute "npx --yes tailwindcss@3 -i assets/app.css -o assets/site.css --minify" com site_run_command e background=true, e aguarde com site_command_status. O <head> de toda página contém, nesta ordem: um único <link rel="stylesheet" href="/assets/site.css">, depois uma linha de preload para cada arquivo de fonte usado na primeira tela (título, destaque e corpo; as="font" type="font/woff2" crossorigin). Linhas de preload colocadas antes da folha de estilo atrasam o CSS e aumentam o LCP; uma fonte da primeira tela sem preload troca tarde, desloca a página e aumenta o CLS, e <link rel="icon" href="/assets/img/favicon.svg" type="image/svg+xml">. A linha do favicon é obrigatória: sem ela o navegador pede /favicon.ico, recebe um 404, e o erro no console reduz o Best Practices.
6. Imagens. Baixe as fotos com site_fetch usando resize e image_format="webp" em várias larguras (480, 800, 1200 e 1600 para a imagem da primeira tela, 480, 800 e 1200 para as demais; qualidade entre 60 e 75, menor para fotos detalhadas). Toda <img> tem srcset, sizes compatíveis com o layout real, width e height (CLS zero) e um texto alt significativo e honesto. fetchpriority="high" vai apenas na imagem que o Lighthouse aponta como elemento LCP, e essa imagem não é lazy; todas as outras imagens usam loading="lazy". Se o elemento LCP for texto, nenhuma imagem recebe fetchpriority. Prepare também assets/img/logo.png, um assets/img/og.jpg de 1200x630 e assets/img/favicon.svg.
7. Regras de HTML (padrões do html-validate). <!DOCTYPE html> em maiúsculas; nenhum atributo style inline (incluindo o style="background:var(--brand)" do kit, use uma classe); &nbsp; em vez de espaços simples no texto dos links tel:; um type em todo <button>; sem espaços no fim das linhas; tabelas com <thead>, <tbody> e th scope. Links dentro de parágrafos são sublinhados; links de menu, rodapé, breadcrumb e botões têm área de toque de pelo menos 44x44 pixels (min-h-[44px] min-w-[44px]).
8. Dados estruturados. Preencha o bloco seo em site.config.js (siteUrl, description, logo, imagem og, tipo de negócio, campos de endereço) e execute "node seo-stamp.mjs" com site_run_command; ele carimba Organization, WebSite e, quando couber, um subtipo de LocalBusiness, além de tags canonical e OG. Adicione à mão o schema específico de cada página: em toda página um nó WebPage com @id (ou AboutPage, ContactPage, CollectionPage, ProfilePage), datePublished e dateModified, isPartOf #site, about #business ou #org, e breadcrumb apontando para um BreadcrumbList; mais um Service por serviço, Person e ProfilePage para o autor, ItemList no índice de guias e Article em cada guia. Escreva cada nó em seu PRÓPRIO bloco <script type="application/ld+json"> e não use um wrapper @graph, porque o seo-check.mjs só lê o @type de nível superior e não enxerga um BreadcrumbList dentro de @graph. Ligue os nós com @id. Nunca invente horário de funcionamento, coordenadas, avaliações, comentários, prêmios, número de clientes ou certificados; deixe de fora os campos desconhecidos.
9. Acesso para IA. Escreva o robots.txt: o site inteiro aberto, apenas /_kaynak/ fechado; Allow: / para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended e Bingbot; sua decisão sobre o CCBot com o motivo como comentário; a linha Sitemap por último. Adicione llms.txt na raiz: um resumo correto do negócio em duas frases, as páginas importantes com uma linha cada e os dados de contato. Escreva o 404.html (noindex, com os marcadores de cabeçalho e rodapé).
10. Redação. Cada página tem pelo menos 150 palavras de texto original dentro de <main>, e o primeiro parágrafo responde diretamente à pergunta principal da página. Os títulos têm de 48 a 60 caracteres, as descrições de 145 a 158, únicos em cada página. Sem travessões longos nem curtos, sem slogans batidos, sem promessas vazias. Se algo no site não for real, diga claramente que é fictício.

Gates. Após cada alteração, execute estes com site_run_command nesta ordem e só avance quando cada um estiver limpo:
1. node _kaynak/parca-bas.mjs, node seo-stamp.mjs, a compilação do Tailwind (de novo se você adicionou classes).
2. node seo-check.mjs: 0 erros e 0 avisos. Se avisar "gövde kısa" (corpo curto demais), acrescente texto real, não enrolação.
3. node design-check.mjs: 0 erros. O único aviso permitido é "Hiç hareket yok" (sem movimento); é uma escolha deliberada para a experiência de leitura, então explique o motivo no relatório.
4. npx --yes html-validate "**/*.html": 0 erros.
5. Veja todas as páginas com site_preview em view="mobile" e view="desktop", e confira também a página inicial em 360 e 768 pixels. Corrija qualquer overflow horizontal, título apertado ou alvo de toque menor que 44 pixels e confira de novo.
6. Meça todas as páginas com core_web_vitals em strategy="mobile" e strategy="desktop", depois audite a página inicial e a página mais longa com seo_audit. Meta: no mobile, Accessibility, Best Practices e SEO 100 e Performance de pelo menos 95; no desktop, as quatro de pelo menos 95. Nenhuma requisição pode sair do site. Se o LCP estiver alto, use resources=true para achar o arquivo que o está atrasando: geralmente linhas de preload colocadas antes da folha de estilo, ou fetchpriority dado a uma imagem que não é o elemento LCP. Se o CLS passar de 0,1, procure uma fonte da primeira tela sem preload.
Não dê o trabalho por concluído até que tudo isso passe.

Depois de publicar, envie https://[domínio]/sitemap.xml com gsc_submit_sitemap e verifique a página inicial com gsc_url_inspect. Se não houver uma propriedade do Search Console, avise-me; não tente conectar uma por conta própria.

Relatório de entrega: uma tabela com as quatro pontuações do Lighthouse e o LCP por página no mobile e no desktop, o resultado dos quatro gates, o motivo de qualquer aviso do design-check, uma lista das informações do site que são fictícias ou estão faltando e o que ainda preciso fazer (Business Profile, fotos reais, horário de funcionamento e assim por diante).

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um site de negócio familiar tradicional com visual clássico e padrões modernos

Peça ao seu assistente para criar um site no espírito de um rótulo antigo e de uma placa de loja para um produtor de terceira geração, com moldura e textura de papel. O visual é antigo, mas a construção é nova: mobile first, sem JavaScript, fontes hospedadas por você, WebP, schema Product e HowTo.

Quando usarQuando você vende um ofício passado de geração em geração, como lokum, azeite, queijo ou utensílios de cobre, e quer um visual clássico que carregue essa história sem abrir mão de velocidade e acessibilidade.

Crie um site com aparência tradicional para o nosso negócio de família no meu servidor de hospedagem Opus Growth [nome do servidor]. Negócio: [nome do negócio], [o que fazemos, ex.: azeite ou delícia turca], [cidade], [ano de fundação e geração, somente se for verdade]. Produtos: [para cada um, nome, tamanho da embalagem, descrição curta e o preço publicado, ou "sem preço"]. Etapas de produção: [lista curta]. Como as pessoas fazem pedidos: [telefone, loja, entrega]. Telefone: [telefone], e-mail: [e-mail], endereço da loja: [endereço], domínio: [domínio]. Fotos da família e do acervo: [onde estão, ou "nenhuma"].

O visual é antigo, a construção é nova. Deve parecer um rótulo antigo, uma placa de loja ou um livro-caixa de colheita, mas as páginas precisam abrir perfeitamente no celular, não carregar nenhum JavaScript e cada página deve ser medida. O visual antigo nunca é desculpa para má legibilidade ou contraste fraco.

A direção de design é tradicional:
1. Tipografia: uma família serifada clássica da Fontshare (ex.: Gambetta 400, 400 itálico, 600). Versaletes com font-variant-caps: all-small-caps e espaçamento largo entre letras no menu, nos botões e nos rótulos; títulos centralizados.
2. Cor: fundo cor de papel, texto marrom-tinta, um marrom secundário e uma cor principal (ex.: verde-oliva), com uma segunda cor quente apenas em rótulos pequenos. Tudo com contraste de no mínimo 4.5:1.
3. Textura: uma textura de papel para o fundo como SVG feTurbulence em data URI no CSS; sem arquivo de imagem extra e sem requisição extra.
4. Elemento marcante: uma moldura de rótulo antigo, uma caixa de filete duplo com ornamentos nos cantos (border, outline-offset e ::before, ::after), e um pequeno ornamento desenhado em SVG inline entre as seções (ex.: um ramo de oliveira), aria-hidden.
5. Layout: centralizado e estreito; produtos em cartões de rótulo emoldurados, uma coluna no celular.
6. Movimento: nenhum.
7. Fotos: use o acervo da família, se houver. Caso contrário, você pode usar fotos de acervo em domínio público ou com licença aberta, mas informe a fonte e a licença na legenda e nunca as apresente como da família.

Páginas e seus schemas:
1. index.html: uma primeira tela emoldurada cujo parágrafo de abertura responde "quem, faz o quê, onde, vende como", rótulos de produtos, uma seção da família, como fazer pedidos. WebPage. Defina o subtipo de negócio mais adequado em site.config.js (ex.: Store ou FoodEstablishment).
2. urunler.html: cada produto em seu próprio cartão de rótulo com nome, tamanho da embalagem, descrição e preço publicado. CollectionPage e um Product por item (brand, manufacturer #business, offers com price, priceCurrency, availability). Nunca escreva um preço que eu não tenha informado; sem preço, omita offers por completo.
3. hikayemiz.html: a história real, geração por geração. AboutPage.
4. uretim.html: as etapas da colheita ou da matéria-prima até a embalagem, a definição oficial de grau do produto e a regulamentação em que ela se baseia (ex.: o Código Alimentar Turco). WebPage e HowTo.
5. sss.html: seis perguntas reais sobre pedidos, entrega e armazenamento. FAQPage.
6. iletisim.html: telefone para pedidos, endereço da loja, um link de mapa; deixe de fora o horário de funcionamento se ele mudar conforme a estação. ContactPage.
7. kvkk.html (aviso de privacidade) e 404.html.

Regras técnicas. Siga-as exatamente, porque os portões abaixo medem exatamente isto:

1. Configuração. Execute scaffold_site primeiro como prévia, mostre-me a lista de arquivos e instale com confirm=true depois que eu aprovar. Em seguida, leia site_design_guide e site_seo_guide por completo. Antes de escrever qualquer código, escreva a direção em _kaynak/ART.md (sensação, combinação de fontes, cores com taxas de contraste, grade, elemento marcante, decisão sobre movimento, lista de páginas) e mostre-a para mim.
2. Elimine o JavaScript. Nenhuma página deste site carrega JavaScript. Remova de todas as páginas o script cdn.tailwindcss.com, a linha tailwind.config, as tags GSAP, ScrollTrigger, SplitText, Lenis e Swiper e as tags de script motion.js, chrome.js e site.config.js; exclua assets/chrome.js e assets/motion.js. Mantenha assets/site.config.js, mas somente como fonte de marca, contato e seo para o seo-stamp.mjs; ele nunca é carregado no navegador.
3. Menu e rodapé são HTML estático. Os componentes <site-nav> e <site-footer> são desenhados por JavaScript, então rastreadores de busca e de IA não conseguem ver o menu, os links internos nem os dados de contato. Escreva o cabeçalho em _kaynak/ust.inc e o rodapé (nome, endereço, telefone, e-mail, todos os links de páginas, aviso de privacidade, "Web: Opus Growth") em _kaynak/alt.inc. Use a extensão .inc para que seo-stamp e html-validate não tratem os fragmentos como páginas. Toda página leva os marcadores  e . Depois, escreva um script Node sem dependências com site_write_file em _kaynak/parca-bas.mjs: ele insere os dois fragmentos entre os marcadores em todos os arquivos HTML, adiciona aria-current="page" ao link do menu da página atual e reescreve o sitemap.xml usando o dateModified do JSON-LD de cada página como lastmod (ignorando 404 e páginas noindex). Construa o menu mobile sem JavaScript usando <details><summary>Menu</summary>; os menus desktop e mobile são dois elementos <nav> separados com aria-labels diferentes.
4. Hospede as fontes você mesmo. Este site usa uma família serifada clássica e no máximo três arquivos. Baixe o CSS da Fontshare (https://api.fontshare.com/v2/css?f[]=family@400,600&display=swap, código de peso 401 para itálico) com site_fetch para _kaynak/fontshare.css, leia-o com site_read_file e pegue somente as URLs woff2 da família que você pediu; o serviço às vezes acrescenta uma família que você não solicitou. Baixe cada woff2 com site_fetch para assets/fonts/. Coloque as regras @font-face (font-display: swap) dentro de assets/app.css, pois o design-check.mjs só procura uma fonte personalizada nesse arquivo. Não use as padrão Inter, Roboto, Poppins ou Montserrat.
5. Compile o Tailwind. assets/app.css passa a ser a fonte do Tailwind: @tailwind base; @tailwind components; @tailwind utilities; no topo, depois @font-face, o anel de foco, o skip link, uma regra prefers-reduced-motion e suas próprias classes de componente dentro de @layer components. Nunca dê a uma classe de componente o nome de um utilitário do Tailwind (list-item, table, grid, container, hidden e assim por diante), porque o conflito quebra o layout em silêncio após a compilação. Escreva tailwind.config.js na raiz (content: ["./*.html", "./**/*.html", "./_kaynak/*.inc"], cores e fontFamily). Execute "npx --yes tailwindcss@3 -i assets/app.css -o assets/site.css --minify" com site_run_command e background=true, e aguarde com site_command_status. O <head> de cada página contém, nesta ordem: um único <link rel="stylesheet" href="/assets/site.css">, depois uma linha de preload para cada arquivo de fonte usado na primeira tela (título, destaque e corpo; as="font" type="font/woff2" crossorigin). Linhas de preload colocadas antes da folha de estilo atrasam o CSS e aumentam o LCP; uma fonte da primeira tela sem preload troca tarde, desloca a página e eleva o CLS, e <link rel="icon" href="/assets/img/favicon.svg" type="image/svg+xml">. A linha do favicon é obrigatória: sem ela o navegador pede /favicon.ico, recebe um 404, e o erro no console reduz as Boas Práticas.
6. Imagens. Baixe as fotos com site_fetch usando resize e image_format="webp" em várias larguras (480, 800, 1200 e 1600 para a imagem da primeira tela, 480, 800 e 1200 para as demais; qualidade entre 60 e 75, menor para fotos detalhadas). Toda <img> tem srcset, sizes compatível com o layout real, width e height (CLS zero) e um texto alt significativo e honesto. fetchpriority="high" vai somente na imagem que o Lighthouse indica como elemento LCP, e essa imagem não é lazy; todas as outras usam loading="lazy". Se o elemento LCP for texto, nenhuma imagem recebe fetchpriority. Prepare também assets/img/logo.png, um assets/img/og.jpg de 1200x630 e assets/img/favicon.svg.
7. Regras de HTML (padrões do html-validate). <!DOCTYPE html> em maiúsculas; nenhum atributo style inline (incluindo o style="background:var(--brand)" do kit, use uma classe); &nbsp; em vez de espaços comuns no texto dos links tel:; um type em todo <button>; sem espaços no fim das linhas; tabelas com <thead>, <tbody> e th scope. Links dentro de parágrafos são sublinhados; links de menu, rodapé, breadcrumb e botões têm área de toque de no mínimo 44x44 pixels (min-h-[44px] min-w-[44px]).
8. Dados estruturados. Preencha o bloco seo em site.config.js (siteUrl, description, logo, imagem og, tipo de negócio, campos de endereço) e execute "node seo-stamp.mjs" com site_run_command; ele insere Organization, WebSite e, quando relevante, um subtipo de LocalBusiness, além das tags canonical e OG. Adicione à mão o schema específico de cada página: em todas as páginas um nó WebPage com @id (ou AboutPage, ContactPage, CollectionPage, ProfilePage), datePublished e dateModified, isPartOf #site, about #business ou #org, e breadcrumb apontando para um BreadcrumbList; mais um Product com Offer por item na página de produtos, HowTo na página de produção e FAQPage na página de perguntas frequentes. Escreva cada nó em seu PRÓPRIO bloco <script type="application/ld+json"> e não use um wrapper @graph, porque o seo-check.mjs só lê o @type de nível superior e não enxerga um BreadcrumbList dentro de @graph. Ligue os nós por @id. Nunca invente horário de funcionamento, coordenadas, avaliações, comentários, prêmios, número de clientes ou certificados; deixe de fora os campos desconhecidos.
9. Acesso para IA. Escreva o robots.txt: o site inteiro aberto, somente /_kaynak/ fechado; Allow: / para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended e Bingbot; sua decisão sobre o CCBot com o motivo em um comentário; a linha Sitemap por último. Adicione llms.txt na raiz: um resumo correto do negócio em duas frases, as páginas importantes com uma linha cada e os dados de contato. Escreva 404.html (noindex, com os marcadores de cabeçalho e rodapé).
10. Redação. Cada página tem no mínimo 150 palavras de texto original dentro de <main>, e o primeiro parágrafo responde diretamente à pergunta principal da página. Os títulos têm de 48 a 60 caracteres, as descrições de 145 a 158, únicos em todas as páginas. Sem travessões longos ou médios, sem slogans prontos, sem promessas vazias. Se algo no site não for real, diga claramente que é fictício.

Portões. Após cada alteração, execute-os com site_run_command nesta ordem e só avance quando cada um estiver limpo:
1. node _kaynak/parca-bas.mjs, node seo-stamp.mjs, a compilação do Tailwind (de novo se você adicionou classes).
2. node seo-check.mjs: 0 erros e 0 avisos. Se avisar "gövde kısa" (corpo curto), adicione texto real, não enchimento.
3. node design-check.mjs: 0 erros. O único aviso permitido é "Hiç hareket yok" (sem movimento); o estilo clássico pede isso, então explique o motivo no relatório.
4. npx --yes html-validate "**/*.html": 0 erros.
5. Veja cada página com site_preview em view="mobile" e view="desktop" e confira também a página inicial em 360 e 768 pixels. Corrija qualquer rolagem horizontal, título apertado ou alvo de toque menor que 44 pixels e olhe de novo.
6. Meça cada página com core_web_vitals em strategy="mobile" e strategy="desktop", depois audite a página inicial e a página mais longa com seo_audit. Meta: no mobile, Acessibilidade, Boas Práticas e SEO 100 e Desempenho de no mínimo 95; no desktop, as quatro notas de no mínimo 95. Nenhuma requisição pode sair do site. Se o LCP estiver alto, use resources=true para encontrar o arquivo que o está atrasando: geralmente linhas de preload colocadas antes da folha de estilo, ou fetchpriority dado a uma imagem que não é o elemento LCP. Se o CLS passar de 0.1, procure uma fonte da primeira tela sem preload.
Não dê o trabalho por concluído até que tudo isso passe.

Após a publicação, envie https://[domínio]/sitemap.xml com gsc_submit_sitemap e verifique a página inicial com gsc_url_inspect. Se não houver uma propriedade do Search Console, avise-me; não tente conectar uma por conta própria.

Relatório de entrega: uma tabela com as quatro notas do Lighthouse e o LCP por página no mobile e no desktop, o resultado dos quatro portões, o motivo de qualquer aviso do design-check, uma lista das informações do site que são fictícias ou estão faltando, e o que ainda preciso fazer (Business Profile, fotos reais, horário de funcionamento e assim por diante).

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie o site de um escritório de advocacia ou contabilidade em estilo minimalista suíço, com fortes sinais de confiança

Faz seu assistente criar um site estático para o escritório, em uma grade rigorosa, com a hierarquia sustentada por uma única família tipográfica. Coloca na página os sinais de confiança que um segmento YMYL exige: perfis dos profissionais, uma nota de orientação datada e com fontes, textos que respeitam as regras de publicidade profissional e schema Person.

Quando usarQuando um escritório de advocacia, de contabilidade ou outra prática profissional semelhante precisa de um site com aparência séria e sóbria, que respeite as regras de publicidade profissional e comprove sua expertise.

Crie um site estático multipágina, em estilo minimalista suíço, para o nosso escritório no meu servidor de hospedagem do Opus Growth [nome do servidor]. Escritório: [nome do escritório], [profissão, ex.: escritório de advocacia ou escritório de contabilidade], [cidade]. Áreas de atuação: [áreas]. Profissionais: [para cada um, nome, cargo, ordem ou conselho em que está registrado, número de registro, áreas]. Telefone: [telefone], e-mail: [e-mail], endereço: [endereço], domínio: [domínio]. Tema da nota informativa: [um assunto frequente, ex.: o limite legal para reajustes de aluguel].

Esta é uma área em que as pessoas tomam decisões sobre seu dinheiro e seus direitos, então a confiança deve vir de clareza, credenciais e fontes, não de decoração. Respeite as regras profissionais: para advogados na Turquia, o regulamento de proibição de publicidade da União das Ordens dos Advogados da Turquia; para contadores, as regras profissionais da TÜRMOB; ou o equivalente onde você atua. Não escreva taxas de sucesso, números de casos ganhos, nomes de clientes, afirmações de superioridade como "o melhor" ou "especialista líder", comparações de honorários, garantias ou promessas exageradas. Apresente as informações com um aviso de que são gerais e não substituem aconselhamento jurídico ou financeiro.

A direção de design é minimalista suíça:
1. Tipografia: uma única família grotesca da Fontshare (ex.: Switzer 400, 500, 600). A hierarquia vem apenas do tamanho e do peso: um título grande, compacto e alinhado à esquerda, texto de corpo sóbrio, rótulos de seção pequenos.
2. Cor: fundo branco, texto quase preto, um cinza escuro e um único destaque (ex.: vermelho suíço). O destaque aparece apenas na marca da seção, nos rótulos e no anel de foco. As fotos são em preto e branco (grayscale do Tailwind).
3. Grade: 12 colunas rigorosas. Em cada seção, o rótulo fica nas colunas 1 a 3 e o conteúdo nas colunas 4 a 12; as seções são separadas por uma linha preta de 1 pixel. Sem cantos arredondados nem sombras.
4. Elemento de assinatura: rótulos de seção numerados com o símbolo § na cor de destaque, e linhas-guia tênues das 12 colunas desenhadas apenas em CSS atrás da primeira tela.
5. Movimento: nenhum.

Páginas e seus schemas:
1. index.html: uma primeira tela cujo parágrafo de abertura responde "qual assunto, para quem, onde", as áreas de atuação, como você trabalha e como os honorários são definidos (sem valores, com a tabela oficial e um contrato de prestação de serviços por escrito), a nota informativa mais recente, um resumo da equipe. WebPage.
2. calisma-alanlari.html: uma seção por área; o primeiro parágrafo responde à pergunta mais comum dessa área, seguido dos principais temas e da base legal. Um Service por área.
3. ekip.html: um perfil para cada profissional (nome, cargo, ordem ou conselho, áreas, biografia curta). AboutPage e uma Person por profissional (jobTitle, knowsAbout, worksFor #business, memberOf da ordem ou do conselho).
4. bilgi-notlari/[tema].html: uma nota fundamentada na lei, que começa com uma resposta curta. No topo: autor, revisor, data de publicação e data da última revisão; no final, uma lista de fontes. Article (autor e publisher via @id, image, datePublished, dateModified, citation) e reviewedBy mais lastReviewed na WebPage. Nunca escreva um ponto jurídico ou financeiro que você não conheça; pergunte-me sobre cada frase de que não tiver certeza.
5. sss.html: seis perguntas reais, FAQPage. 6. iletisim.html: ContactPage. 7. kvkk.html (mencionando o sigilo profissional) e 404.html.

Regras técnicas. Siga-as exatamente, porque os gates abaixo medem exatamente isto:

1. Configuração. Execute scaffold_site primeiro como prévia, mostre-me a lista de arquivos e instale com confirm=true depois que eu aprovar. Em seguida, leia site_design_guide e site_seo_guide por completo. Antes de escrever qualquer código, escreva a direção em _kaynak/ART.md (sensação, combinação de fontes, cores com taxas de contraste, grade, elemento de assinatura, decisão sobre movimento, lista de páginas) e mostre-a para mim.
2. Elimine o JavaScript. Nenhuma página deste site carrega JavaScript. Remova de todas as páginas o script cdn.tailwindcss.com, a linha tailwind.config, as tags de GSAP, ScrollTrigger, SplitText, Lenis e Swiper e as tags de script motion.js, chrome.js e site.config.js; exclua assets/chrome.js e assets/motion.js. Mantenha assets/site.config.js, mas apenas como fonte de brand, contact e seo para o seo-stamp.mjs; ele nunca é carregado no navegador.
3. Menu e rodapé são HTML estático. Os componentes <site-nav> e <site-footer> são desenhados por JavaScript, então rastreadores de busca e de IA não enxergam o menu, os links internos nem os dados de contato. Escreva o cabeçalho em _kaynak/ust.inc e o rodapé (nome, endereço, telefone, e-mail, link de todas as páginas, aviso de privacidade, "Web: Opus Growth") em _kaynak/alt.inc. Use a extensão .inc para que o seo-stamp e o html-validate não tratem os fragmentos como páginas. Cada página leva os marcadores  e . Depois, escreva com site_write_file um script Node sem dependências em _kaynak/parca-bas.mjs: ele carimba os dois fragmentos entre os marcadores em todos os arquivos HTML, adiciona aria-current="page" ao link do menu da página atual e reescreve o sitemap.xml usando o dateModified do JSON-LD de cada página como lastmod (ignorando 404 e páginas noindex). Construa o menu mobile sem JavaScript usando <details><summary>Menu</summary>; os menus de desktop e mobile são dois elementos <nav> separados com aria-label diferentes.
4. Hospede as fontes você mesmo. Este site usa uma família de fontes e no máximo três arquivos. Baixe o CSS da Fontshare (https://api.fontshare.com/v2/css?f[]=family@400,600&display=swap, código de peso 401 para itálico) com site_fetch para _kaynak/fontshare.css, leia-o com site_read_file e use apenas as URLs woff2 da família solicitada; o serviço às vezes acrescenta uma família que você não pediu. Baixe cada woff2 com site_fetch para assets/fonts/. Coloque as regras @font-face (font-display: swap) dentro de assets/app.css, porque o design-check.mjs só procura uma fonte personalizada nesse arquivo. Não use as padrão Inter, Roboto, Poppins ou Montserrat.
5. Compile o Tailwind. assets/app.css passa a ser a fonte do Tailwind: @tailwind base; @tailwind components; @tailwind utilities; no topo, depois @font-face, o anel de foco, o skip link, uma regra prefers-reduced-motion e suas próprias classes de componente dentro de @layer components. Nunca dê a uma classe de componente o nome de uma utilitária do Tailwind (list-item, table, grid, container, hidden e assim por diante), porque o conflito quebra o layout silenciosamente após a compilação. Escreva tailwind.config.js na raiz (content: ["./*.html", "./**/*.html", "./_kaynak/*.inc"], cores e fontFamily). Execute "npx --yes tailwindcss@3 -i assets/app.css -o assets/site.css --minify" com site_run_command e background=true, e aguarde com site_command_status. O <head> de cada página contém, nesta ordem: um único <link rel="stylesheet" href="/assets/site.css">, depois uma linha de preload para cada arquivo de fonte usado na primeira tela (título, destaque e corpo; as="font" type="font/woff2" crossorigin). Linhas de preload colocadas antes da folha de estilo atrasam o CSS e aumentam o LCP; uma fonte da primeira tela sem preload é trocada tarde, desloca a página e aumenta o CLS, e <link rel="icon" href="/assets/img/favicon.svg" type="image/svg+xml">. A linha do favicon é obrigatória: sem ela o navegador pede /favicon.ico, recebe um 404, e o erro no console reduz as Best Practices.
6. Imagens. Baixe as fotos com site_fetch usando resize e image_format="webp" em várias larguras (480, 800, 1200 e 1600 para a imagem da primeira tela, 480, 800 e 1200 para as demais; qualidade entre 60 e 75, menor para fotos detalhadas). Toda <img> tem srcset, sizes compatível com o layout real, width e height (CLS zero) e um texto alt significativo e honesto. fetchpriority="high" vai apenas na imagem que o Lighthouse indica como elemento LCP, e essa imagem não é lazy; todas as outras imagens usam loading="lazy". Se o elemento LCP for texto, nenhuma imagem recebe fetchpriority. Prepare também assets/img/logo.png, um assets/img/og.jpg de 1200x630 e assets/img/favicon.svg.
7. Regras de HTML (padrões do html-validate). <!DOCTYPE html> em maiúsculas; nenhum atributo style inline (incluindo o style="background:var(--brand)" do kit, use uma classe); &nbsp; em vez de espaços comuns no texto dos links tel:; um type em todo <button>; sem espaços no fim das linhas; tabelas com <thead>, <tbody> e th scope. Links dentro de parágrafos são sublinhados; links de menu, rodapé, breadcrumb e botões têm área de toque de pelo menos 44x44 pixels (min-h-[44px] min-w-[44px]).
8. Dados estruturados. Preencha o bloco seo em site.config.js (siteUrl, description, logo, imagem og, tipo de negócio, campos de endereço) e execute "node seo-stamp.mjs" com site_run_command; ele carimba Organization, WebSite e, quando relevante, um subtipo de LocalBusiness, além de tags canonical e OG. Adicione à mão o schema específico de cada página: em todas as páginas um nó WebPage com @id (ou AboutPage, ContactPage, CollectionPage, ProfilePage), datePublished e dateModified, isPartOf #site, about #business ou #org, e breadcrumb apontando para uma BreadcrumbList; além de um Service por área de atuação, uma Person por profissional na página da equipe, Article e reviewedBy na nota informativa, e FAQPage na página de perguntas frequentes. Escreva cada nó em seu PRÓPRIO bloco <script type="application/ld+json"> e não use um wrapper @graph, porque o seo-check.mjs só lê o @type de nível superior e não enxerga uma BreadcrumbList dentro de @graph. Ligue os nós com @id. Nunca invente horários de funcionamento, coordenadas, avaliações, comentários, prêmios, número de clientes ou certificados; deixe de fora os campos desconhecidos.
9. Acesso para IA. Escreva o robots.txt: o site inteiro aberto, apenas /_kaynak/ fechado; Allow: / para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended e Bingbot; sua decisão sobre o CCBot com o motivo em um comentário; a linha Sitemap por último. Adicione llms.txt na raiz: um resumo correto do negócio em duas frases, as páginas importantes com uma linha cada e os dados de contato. Escreva 404.html (noindex, com os marcadores de cabeçalho e rodapé).
10. Redação. Cada página tem pelo menos 150 palavras de texto original dentro de <main>, e o primeiro parágrafo responde diretamente à pergunta principal da página. Os títulos têm de 48 a 60 caracteres, as descrições de 145 a 158, únicos em cada página. Sem travessões longos nem curtos, sem slogans prontos, sem promessas vazias. Se algo no site não for real, diga claramente que é fictício.

Gates. Após cada alteração, execute estes com site_run_command nesta ordem e só avance quando cada um estiver limpo:
1. node _kaynak/parca-bas.mjs, node seo-stamp.mjs, a compilação do Tailwind (de novo se você adicionou classes).
2. node seo-check.mjs: 0 erros e 0 avisos. Se avisar "gövde kısa" (corpo curto demais), adicione texto real, não enchimento.
3. node design-check.mjs: 0 erros. O único aviso permitido é "Hiç hareket yok" (sem movimento); o estilo exige isso, então explique o motivo no relatório.
4. npx --yes html-validate "**/*.html": 0 erros.
5. Veja cada página com site_preview em view="mobile" e view="desktop", e confira também a página inicial em 360 e 768 pixels. Corrija qualquer overflow horizontal, título espremido ou alvo de toque menor que 44 pixels e verifique de novo.
6. Meça cada página com core_web_vitals em strategy="mobile" e strategy="desktop", depois audite a página inicial e a página mais longa com seo_audit. Meta: no mobile, Accessibility, Best Practices e SEO 100 e Performance de pelo menos 95; no desktop, as quatro de pelo menos 95. Nenhuma requisição pode sair do site. Se o LCP estiver alto, use resources=true para encontrar o arquivo que o está atrasando: geralmente linhas de preload colocadas antes da folha de estilo, ou fetchpriority dado a uma imagem que não é o elemento LCP. Se o CLS passar de 0,1, procure uma fonte da primeira tela sem preload.
Não dê o trabalho por concluído até que tudo isso passe.

Relatório de entrega: uma tabela com as quatro notas do Lighthouse e o LCP de cada página no mobile e no desktop, o resultado dos quatro gates, o motivo de qualquer aviso do design-check, uma lista das informações do site que são fictícias ou estão faltando, e o que ainda preciso fazer (Business Profile, fotos reais, horário de funcionamento e assim por diante).

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um site institucional de várias páginas sem JavaScript e entregue com nota 100

Peça ao seu assistente para criar um site estático, rápido e acessível para trabalhos corporativos como arquitetura, engenharia ou consultoria. Menu e rodapé são HTML estático, fontes e CSS são hospedados por você e cada página é medida antes da entrega.

Quando usarQuando uma empresa corporativa precisa de um site com várias páginas em que velocidade e acessibilidade importam mais que decoração, sem animação e sem JavaScript.

Crie um site corporativo, com várias páginas e totalmente estático, para o meu negócio no meu servidor de hospedagem Opus Growth [nome do servidor]. Negócio: [nome da empresa], [setor, por exemplo escritório de engenharia e arquitetura], [cidade/área de atendimento]. Serviços: [serviços com uma breve descrição de cada um]. Telefone: [telefone], e-mail: [e-mail], endereço: [endereço], domínio: [domínio]. Preferência de cores: [preferência de cor/marca, ou "à sua escolha"]. Fotos: [onde estão as fotos reais, ou "use fotos de banco de imagens adequadas"].

Este site prioriza velocidade e acessibilidade. Nenhuma linha de JavaScript em nenhuma página; GSAP, Lenis e Swiper nunca são carregados. Tudo, incluindo o menu, o menu mobile e o FAQ, funciona com HTML e CSS.

A direção de design é "folha de desenho técnico":
1. Tipografia: uma fonte de títulos grotesca e compacta da Fontshare (por exemplo, Cabinet Grotesk 800) e uma fonte de corpo discreta (por exemplo, General Sans 400 e 600). No máximo três arquivos de fonte.
2. Cor: fundo claro em tom de papel, texto em tinta escura, um cinza secundário e uma única cor de destaque como sinal. O destaque aparece apenas em rótulos, filetes finos e no botão principal. Toda cor de texto atinge pelo menos 4,5:1 de contraste.
3. Grade: 12 colunas, seções separadas por filetes de 1 pixel; sem sombras, cantos arredondados ou gradientes.
4. Elemento de assinatura: abaixo da imagem da primeira tela, uma faixa de quatro células no estilo do carimbo de um desenho de arquitetura (por exemplo, tipo de projeto, norma seguida, escala, número da folha), e uma grade milimétrica muito discreta desenhada apenas em CSS atrás da primeira tela.
5. Movimento: nenhum. Nem durações de transição; apenas o sublinhado e a mudança de cor acontecem instantaneamente ao passar o mouse.

Páginas e seus schemas:
1. index.html: uma primeira tela cujo parágrafo de abertura responde diretamente a "o que vocês fazem, para quem, onde", três cartões de serviço (cada um com link para a sua seção), um processo de quatro etapas (numeradas como "Etapa 1" com um contador CSS, não 01/02), dois exemplos de projetos, uma faixa de telefone. WebPage.
2. hizmetler.html: uma seção por serviço; o primeiro parágrafo responde "quando é necessário, o que faz", depois uma lista de escopo, duração típica e entregáveis. WebPage mais um Service por serviço (provider #business, areaServed).
3. projeler.html: exemplos com tipo de edificação, método e resultado; nomes de clientes apenas com permissão. CollectionPage.
4. hakkimizda.html: quem somos, nossas regras de trabalho, onde atuamos. AboutPage.
5. sss.html: pelo menos seis perguntas reais dentro de <details>. WebPage e FAQPage.
6. iletisim.html: telefone, e-mail e endereço dentro de <address>, um link de mapa; deixe de fora o horário de funcionamento se você não o souber. ContactPage com mainEntity #business.
7. kvkk.html (aviso de privacidade) e 404.html.

Regras técnicas. Siga-as exatamente, porque os testes abaixo medem exatamente isto:

1. Configuração. Execute scaffold_site primeiro como prévia, mostre-me a lista de arquivos e instale com confirm=true depois que eu aprovar. Em seguida, leia site_design_guide e site_seo_guide por completo. Antes de escrever qualquer código, escreva a direção em _kaynak/ART.md (sensação, combinação de fontes, cores com taxas de contraste, grade, elemento de assinatura, decisão sobre movimento, lista de páginas) e mostre-a para mim.
2. Remova o JavaScript. Nenhuma página deste site carrega JavaScript. Remova de todas as páginas o script cdn.tailwindcss.com, a linha tailwind.config, as tags de GSAP, ScrollTrigger, SplitText, Lenis e Swiper e as tags de script motion.js, chrome.js e site.config.js; exclua assets/chrome.js e assets/motion.js. Mantenha assets/site.config.js, mas apenas como fonte de marca, contato e seo para o seo-stamp.mjs; ele nunca é carregado no navegador.
3. Menu e rodapé são HTML estático. Os componentes <site-nav> e <site-footer> são desenhados por JavaScript, então rastreadores de busca e de IA não conseguem ver o menu, os links internos nem os dados de contato. Escreva o cabeçalho em _kaynak/ust.inc e o rodapé (nome, endereço, telefone, e-mail, todos os links de páginas, aviso de privacidade, "Web: Opus Growth") em _kaynak/alt.inc. Use a extensão .inc para que seo-stamp e html-validate não tratem os fragmentos como páginas. Toda página leva os marcadores  e . Depois, escreva um script Node sem dependências com site_write_file em _kaynak/parca-bas.mjs: ele carimba os dois fragmentos entre os marcadores em todos os arquivos HTML, adiciona aria-current="page" ao link do menu da página atual e reescreve o sitemap.xml usando o dateModified do JSON-LD de cada página como lastmod (ignorando 404 e páginas noindex). Construa o menu mobile sem JavaScript usando <details><summary>Menu</summary>; os menus desktop e mobile são dois elementos <nav> separados com aria-labels diferentes.
4. Hospede as fontes você mesmo. Este site usa no máximo três arquivos de fonte. Baixe o CSS da Fontshare (https://api.fontshare.com/v2/css?f[]=family@400,600&display=swap, código de peso 401 para itálico) com site_fetch para _kaynak/fontshare.css, leia-o com site_read_file e pegue apenas as URLs woff2 da família que você pediu; o serviço às vezes acrescenta uma família que você não solicitou. Baixe cada woff2 com site_fetch para assets/fonts/. Coloque as regras @font-face (font-display: swap) dentro de assets/app.css, porque o design-check.mjs só procura uma fonte personalizada nesse arquivo. Não use as padrão Inter, Roboto, Poppins ou Montserrat.
5. Compile o Tailwind. assets/app.css passa a ser a fonte do Tailwind: @tailwind base; @tailwind components; @tailwind utilities; no topo, depois @font-face, o anel de foco, o skip link, uma regra prefers-reduced-motion e suas próprias classes de componente dentro de @layer components. Nunca dê a uma classe de componente o nome de um utilitário do Tailwind (list-item, table, grid, container, hidden e assim por diante), porque o conflito quebra o layout silenciosamente após a compilação. Escreva tailwind.config.js na raiz (content: ["./*.html", "./**/*.html", "./_kaynak/*.inc"], cores e fontFamily). Execute "npx --yes tailwindcss@3 -i assets/app.css -o assets/site.css --minify" com site_run_command e background=true, e aguarde com site_command_status. O <head> de toda página contém, nesta ordem: um único <link rel="stylesheet" href="/assets/site.css">, depois uma linha de preload para cada arquivo de fonte usado na primeira tela (título, destaque e corpo; as="font" type="font/woff2" crossorigin). Linhas de preload colocadas antes da folha de estilo atrasam o CSS e aumentam o LCP; uma fonte da primeira tela sem preload é trocada tarde, desloca a página e aumenta o CLS, e <link rel="icon" href="/assets/img/favicon.svg" type="image/svg+xml">. A linha do favicon é obrigatória: sem ela o navegador pede /favicon.ico, recebe um 404, e o erro no console reduz as Melhores Práticas.
6. Imagens. Baixe as fotos com site_fetch usando resize e image_format="webp" em várias larguras (480, 800, 1200 e 1600 para a imagem da primeira tela, 480, 800 e 1200 para as demais; qualidade entre 60 e 75, menor para fotos com muitos detalhes). Toda <img> tem srcset, sizes compatíveis com o layout real, width e height (CLS zero) e um texto alt significativo e honesto. fetchpriority="high" vai apenas na imagem que o Lighthouse indica como elemento LCP, e essa imagem não é lazy; todas as outras imagens usam loading="lazy". Se o elemento LCP for texto, nenhuma imagem recebe fetchpriority. Prepare também assets/img/logo.png, um assets/img/og.jpg de 1200x630 e assets/img/favicon.svg.
7. Regras de HTML (padrões do html-validate). <!DOCTYPE html> em maiúsculas; nenhum atributo style inline (incluindo o style="background:var(--brand)" do kit, use uma classe); &nbsp; em vez de espaços comuns no texto dos links tel:; um type em todo <button>; sem espaços no final das linhas; tabelas com <thead>, <tbody> e th scope. Links dentro de parágrafos são sublinhados; links de menu, rodapé, breadcrumb e botão têm área de toque de pelo menos 44x44 pixels (min-h-[44px] min-w-[44px]).
8. Dados estruturados. Preencha o bloco seo em site.config.js (siteUrl, description, logo, imagem og, tipo de negócio, campos de endereço) e execute "node seo-stamp.mjs" com site_run_command; ele carimba Organization, WebSite e, quando pertinente, um subtipo de LocalBusiness, além de tags canonical e OG. Adicione à mão o schema específico de cada página: em toda página um nó WebPage com @id (ou AboutPage, ContactPage, CollectionPage, ProfilePage), datePublished e dateModified, isPartOf #site, about #business ou #org, e breadcrumb apontando para um BreadcrumbList; mais um Service por serviço na página de serviços e FAQPage na página de FAQ. Escreva cada nó em seu PRÓPRIO bloco <script type="application/ld+json"> e não use um wrapper @graph, porque o seo-check.mjs só lê o @type de nível superior e não encontra um BreadcrumbList dentro de @graph. Conecte os nós com @id. Nunca invente horário de funcionamento, coordenadas, avaliações, comentários, prêmios, número de clientes ou certificados; deixe de fora os campos desconhecidos.
9. Acesso para IA. Escreva o robots.txt: o site inteiro aberto, apenas /_kaynak/ fechado; Allow: / para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended e Bingbot; sua decisão sobre o CCBot com o motivo em um comentário; a linha Sitemap por último. Adicione llms.txt na raiz: um resumo correto do negócio em duas frases, as páginas importantes com uma linha cada e os dados de contato. Escreva 404.html (noindex, com os marcadores de cabeçalho e rodapé).
10. Redação. Cada página tem pelo menos 150 palavras de texto original dentro de <main>, e o primeiro parágrafo responde diretamente à pergunta principal da página. Os títulos têm de 48 a 60 caracteres, as descrições de 145 a 158, únicos em cada página. Sem travessões longos ou médios, sem slogans prontos, sem promessas vazias. Se algo no site não for real, diga claramente que é fictício.

Testes. Após cada alteração, execute-os com site_run_command nesta ordem e não avance até que cada um esteja limpo:
1. node _kaynak/parca-bas.mjs, node seo-stamp.mjs, a compilação do Tailwind (de novo se você adicionou classes).
2. node seo-check.mjs: 0 erros e 0 avisos. Se ele avisar "gövde kısa" (corpo curto demais), adicione texto real, não enchimento.
3. node design-check.mjs: 0 erros. O único aviso permitido é "Hiç hareket yok" (sem movimento); essa é uma escolha deliberada deste site, então dê o motivo no relatório.
4. npx --yes html-validate "**/*.html": 0 erros.
5. Veja cada página com site_preview em view="mobile" e view="desktop", e confira também a página inicial em 360 e 768 pixels. Corrija qualquer overflow horizontal, título apertado ou alvo de toque menor que 44 pixels e verifique de novo.
6. Meça cada página com core_web_vitals em strategy="mobile" e strategy="desktop", depois audite a página inicial e a página mais longa com seo_audit. Meta: no mobile, Acessibilidade, Melhores Práticas e SEO 100 e Desempenho pelo menos 95; no desktop, as quatro pelo menos 95. Nenhuma requisição pode sair do site. Se o LCP estiver alto, use resources=true para encontrar o arquivo que o atrasa: geralmente linhas de preload colocadas antes da folha de estilo, ou fetchpriority dado a uma imagem que não é o elemento LCP. Se o CLS passar de 0,1, procure uma fonte da primeira tela sem preload.
Não considere o trabalho concluído até que tudo isso passe.

Depois de publicar, envie https://[domínio]/sitemap.xml com gsc_submit_sitemap e verifique a página inicial com gsc_url_inspect. Se não houver uma propriedade no Search Console, avise-me; não tente conectar uma por conta própria.

Relatório de entrega: uma tabela com as quatro pontuações do Lighthouse e o LCP de cada página no mobile e no desktop, o resultado dos quatro testes, o motivo de qualquer aviso do design-check, uma lista das informações do site que são fictícias ou estão faltando, e o que eu ainda preciso fazer (Business Profile, fotos reais, horário de funcionamento e assim por diante).

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie uma página de campanha sem formulário para o tráfego de anúncios que gere ligações e conversas no WhatsApp, com as conversões marcadas

Cria uma página única para o tráfego do Google Ads e do Meta que repete a promessa do anúncio e oferece botões de ligação, WhatsApp e agendamento. Marca os cliques como eventos do dataLayer, configura o modo de consentimento, adiciona acionadores e tags do Tag Manager após a sua aprovação e mede a velocidade da página com e sem as tags.

Quando usarQuando seus anúncios levam para a página inicial ou para uma página genérica de serviço, e seus clientes entram em contato por telefone e WhatsApp muito mais do que por formulários.

No meu servidor de hospedagem Opus Growth [nome do servidor], crie uma única página de campanha para o tráfego de anúncios do Google Ads e da Meta, além de uma página de privacidade. Não há formulário; os visitantes entram em contato por telefone, WhatsApp ou um link de agendamento. Detalhes: empresa [nome da empresa], serviço [serviço], área [bairros], telefone [telefone], WhatsApp [número], link de agendamento [link ou "nenhum"], endereço [endereço], horário [horário de funcionamento], títulos dos anúncios e oferta principal [títulos e oferta], contêiner do Tag Manager [GTM-XXXXXXX], conta do Google Ads [nome da conta], conta de anúncios da Meta [nome da conta].

Coerência de mensagem: o h1 repete a promessa do título do anúncio com as mesmas palavras (serviço, área, oferta principal). Não coloque na página uma promessa que não esteja no anúncio, nem no anúncio uma que não esteja na página. Se os títulos do Google e da Meta forem diferentes, use o título do anúncio que mais investe e sugira como alinhar o outro anúncio à página. Em saúde, direito ou finanças, não prometa certeza ("garantido", "100%").

Estrutura da página: a barra superior tem apenas o nome da marca e um botão de ligar, sem menu, para que os visitantes não se dispersem. Hero: h1, descrição de uma frase, três botões (Ligar agora, Chamar no WhatsApp, Escolher um horário), quatro pontos curtos de segurança logo abaixo e uma imagem. Depois, o processo em três etapas, o que define o preço (resposta primeiro, se você não publicar preços), FAQ, uma chamada final para ação e um rodapé com nome, endereço, telefone e o link de privacidade. No celular, fixe uma barra de dois botões (Ligar, WhatsApp) na parte inferior da tela e dê ao corpo da página um espaçamento inferior da mesma altura, para que nada fique escondido embaixo dela e nada se desloque. O link do WhatsApp usa wa.me com uma mensagem pré-preenchida. Mantenha o visual simples e confiável: uma única família de fonte (por exemplo General Sans, dois pesos), um destaque de cor e um botão de WhatsApp verde-escuro com contraste de pelo menos 4,5:1 com o texto branco.

Regras de movimento e mensuração:
1. Movimento leve, sem bibliotecas: não carregue GSAP, Lenis nem Swiper. Transições de hover e de clique nos botões; nos cartões das etapas, uma pequena subida guiada pela rolagem que use apenas transform, dentro de `@supports (animation-timeline: view())` e somente para visitantes que não pedem movimento reduzido. Não use opacity: na demonstração, cartões esmaecidos abaixo da tela falharam no contraste e derrubaram a Acessibilidade para 96. Nada na primeira tela começa com animação de entrada.
2. Carregue a camada de mensuração como `assets/tag.js` com defer:
   a. `window.dataLayer` e os padrões do Consent Mode v2: ad_storage, ad_user_data, ad_personalization e analytics_storage "denied", wait_for_update 500.
   b. Dê a cada link de ação data-conv="phone", "whatsapp" ou "booking" e um data-conv-place com o nome da seção. Um único listener de clique os envia ao dataLayer como `{event: "phone_click" | "whatsapp_click" | "booking_click", conv_place, page_path}`.
   c. Não coloque o snippet clássico do GTM no `<head>`; injete-o depois do evento load com requestIdleCallback, para que as tags nunca atrasem a primeira renderização.
   d. Adicione uma pequena barra de consentimento fixa: Rejeitar e Aceitar como botões de mesmo peso, com a escolha guardada no navegador e enviada como atualização de consentimento. No celular, ela fica acima da barra de ação e baixa o suficiente para não cobrir o botão principal do hero.
3. Tag Manager: primeiro mostre o estado atual com list_gtm_containers, list_gtm_triggers e gtm_workspace_status. Proponha três gatilhos de Evento Personalizado com create_gtm_trigger (phone_click, whatsapp_click, booking_click). Encontre a conversão de contato e o valor de send_to dela no Google Ads com list_conversion_actions e get_conversion_tags. Para que uma pessoa que liga e também envia mensagem não seja contada duas vezes, proponha vincular telefone e WhatsApp a uma única conversão "Clique de contato" contada uma vez; se não existir, diga o que você criaria e aguarde minha aprovação. Proponha uma tag de conversão do Google Ads com create_gtm_tag (tag_type "sp"). Para a Meta, encontre o pixel com list_meta_pixels; se o código base do pixel não estiver no contêiner, proponha-o como uma tag HTML Personalizado em todas as páginas e, separadamente, as tags que enviam `fbq('track','Contact')` nos cliques e `fbq('track','Schedule')` no agendamento. Execute cada ferramenta primeiro com confirm=false, mostre a lista de alterações e crie-as após minha aprovação. Mostre publish_gtm_container primeiro com confirm=false, publique após minha aprovação e informe a versão que pode ser restaurada.
4. Plano de testes: escreva passo a passo como posso ver, no modo de visualização do GTM, qual tag dispara em cada um dos três botões e que nenhum cookie de publicidade é gravado quando o consentimento é rejeitado.
5. Depois de adicionar o GTM e as tags, execute core_web_vitals novamente, porque as tags podem reduzir a pontuação, e mostre a diferença em uma tabela. Para que a tag do Google não seja bloqueada por bloqueadores de anúncios, mostre a prévia do caminho de mensuração próprio com site_tag_gateway e configure-o após minha aprovação.

Configuração e armadilhas conhecidas (cada uma reduziu uma pontuação nas medições da demonstração, não pule nenhuma):
1. Se já houver um site no ar no servidor, avise-me primeiro, porque a configuração sobrescreve o index.html e a pasta assets. Mostre a prévia de scaffold_site com confirm=false e chame-o com confirm=true após minha aprovação. Depois leia site_design_guide e site_seo_guide. Antes de escrever código, coloque a direção de design (tipografia, cor, grade, elemento marcante, linguagem de movimento e as bibliotecas que NÃO serão carregadas) em um ART.md curto fora de assets e mostre-o para mim.
2. Compile o Tailwind em vez de carregá-lo pelo CDN. Instale-o com site_run_command e background=true: `npm i -D tailwindcss@3`, e acompanhe com site_command_status. Os caminhos de content em `tailwind.config.js` devem cobrir todos os arquivos HTML, os templates e qualquer arquivo JS que escreva nomes de classe. `_src/tw.css` contém a linha `@import "../assets/app.css";` e as três linhas `@tailwind`; compile-o em um único arquivo com `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Remova o script cdn.tailwindcss.com e o tailwind.config inline de todas as páginas e vincule apenas `/assets/site.css`. Recompile após cada alteração no HTML.
3. Hospede as fontes você mesmo. Leia o CSS das famílias da Fontshare escolhidas, baixe o arquivo woff2 de cada peso para `assets/fonts/` com site_fetch e escreva as regras @font-face com `font-display: swap` em `assets/app.css`; o design-check procura uma fonte personalizada ali. Confira o nome da font-family no CSS que você baixou, porque a Fontshare pode devolver outra família quando um peso não existe. Faça o preload da fonte do título da primeira tela e da fonte do corpo em todas as páginas com `<link rel="preload" as="font" type="font/woff2" crossorigin>`; na demonstração isso eliminou o deslocamento de layout causado pela troca de fonte (CLS 0,024 para 0). A maioria das fontes da Fontshare não tem o glifo ₺, então escreva "TL" nos preços.
4. Faça o menu e o rodapé em HTML estático. Não carregue chrome.js nem site.config.js nas páginas. Escreva um pequeno `chrome-stamp.mjs` que leia a lista de navegação em site.config.js e carimbe `_src/header.tpl` e `_src/footer.tpl` entre os marcadores `` e `` de cada página, adicionando aria-current="page" ao link atual. Não dê aos templates a extensão .html e use marcadores como `[[NAV]]` em vez de `{{...}}`, caso contrário o design-check e o seo-check os leem como páginas inacabadas. Construa o menu mobile sem JS usando `<details>`. Mantenha o nome da empresa, o endereço e o telefone no rodapé como texto simples.
5. Converta as imagens ao baixá-las com site_fetch: grave a mesma foto em arquivos separados com resize="480x", "800x" e "1200x", image_format="webp", quality=65. Dê a cada `<img>` srcset, sizes, width e height. A imagem principal da primeira tela recebe fetchpriority="high" e nunca é lazy; as demais recebem loading="lazy" decoding="async". Se a imagem principal ocupar a tela do celular, sirva um recorte mais largo e menor no mobile com `<picture>` (na demonstração, o hero mobile passou de 89 KB para 43 KB).
6. Crie um favicon PNG de 48 px a partir do logotipo com site_fetch e adicione `<link rel="icon">` a todas as páginas. Sem ele, o navegador registra um 404 e Best Practices cai para 96.
7. Regras do validador de HTML: comece todo documento com `<!DOCTYPE html>` em maiúsculas (os arquivos iniciais do kit usam minúsculas), use `&nbsp;` nos espaços do texto visível dos links tel:, nunca use o atributo style="" e dê a todo botão type="button".

SEO, AEO e GEO:
1. Use URLs de diretório com barra final (/gizlilik/). Preencha o bloco seo de site.config.js e execute `node seo-stamp.mjs`. Escreva o schema específico de cada página (na página de campanha, WebPage, um Service vinculado a #business como provider com areaServed, e FAQPage; na página de privacidade, WebPage e BreadcrumbList. Em site.config.js, use o subtipo de LocalBusiness mais específico, por exemplo HousePainter, Plumber, Dentist. A página de privacidade explica os cookies, as tags de mensuração e como alterar a escolha de consentimento) em blocos `<script type="application/ld+json">` separados e vincule-o ao grafo base com @id. Não esconda o BreadcrumbList dentro de um @graph; dê a ele um bloco próprio, porque é a única forma de o seo-check enxergá-lo.
2. Títulos de 48 a 60 caracteres (o seo-check sinaliza como erro qualquer um acima de 65), descrições de 145 a 158 caracteres, um h1 por página. Toda página precisa de pelo menos 150 palavras de conteúdo principal; páginas de contato e privacidade costumam ficar abaixo disso.
3. O primeiro parágrafo de cada página responde diretamente à pergunta da página. Escreva um FAQ específico da página com `<details>` e marque-o como FAQPage. Mostre a organização que publica e uma data de "Última atualização" com `<time>`.
4. No robots.txt, escreva sua decisão com o motivo para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot e CCBot, e aponte para o sitemap. O sitemap.xml traz datas lastmod reais. O llms.txt contém um resumo preciso do site em duas frases e a lista das páginas principais.
5. Não invente nada: nenhuma avaliação, nota, prêmio, número de clientes, certificado, horário de funcionamento, coordenada ou preço, a menos que eu os forneça. Deixe os campos desconhecidos fora do schema.

Portões de verificação (em ordem; não diga que terminou até que todos passem):
1. Com site_run_command, execute `node chrome-stamp.mjs`, o build do Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 erros, 0 avisos), `node design-check.mjs` (0 erros; justifique qualquer aviso restante) e `npx html-validate "**/*.html"` (0 erros).
2. Veja cada página com site_preview, view="mobile" e view="desktop". O site_preview captura a página com o movimento desligado (reduced-motion), então, se faltar conteúdo nessa imagem, o estado sem movimento está quebrado. Em capturas de página inteira, imagens lazy mais abaixo podem aparecer vazias; isso não é um erro, mas confira os caminhos delas.
3. Execute core_web_vitals para cada página com strategy="mobile" e strategy="desktop". Aprovado: no mobile, Performance de pelo menos 95 e Acessibilidade, Best Practices e SEO 100; no desktop, as quatro de pelo menos 95. Em uma página que falhar, use resources=true para encontrar o arquivo que a atrasa, corrija e meça de novo. Depois execute seo_audit na página inicial com strategy="mobile" e runs=2. A lista de requisições de rede não deve conter nenhum host além do seu próprio domínio.
4. Sem rolagem horizontal nas larguras de 360, 390, 768 e 1440 px, alvos de toque de pelo menos 44 px, sem erros no console.

Como esta é uma página de destino de anúncios, meça-a também sem as tags: as pontuações dos portões são para a página sem tags, e a página com tags é medida separadamente na etapa 5.

Depois de publicar: mostre a prévia da regra `/assets/* Cache-Control: public, max-age=31536000, immutable` com site_headers e aplique-a após minha aprovação; a partir daí, renomeie os arquivos CSS ou JS quando mudarem (site-v2.css e assim por diante). Envie o sitemap.xml com gsc_submit_sitemap e verifique a página inicial com gsc_url_inspect. Termine com uma tabela de pontuação por página (página, quatro pontuações mobile, quatro pontuações desktop, LCP, CLS), os resultados dos portões e a lista das correções que você aplicou.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um site SaaS escuro e rápido, com uma história de produto fixada e guiada pela rolagem com GSAP

Cria um site de produto com várias páginas no seu servidor de hospedagem, com uma história de produto fixada com ScrollTrigger e sincronizada com a rolagem, uma entrada de títulos com SplitText e rolagem suave com Lenis. As bibliotecas de animação carregam apenas onde são necessárias e depois da primeira renderização, e o Lighthouse mobile é medido e mantido acima de 95.

Quando usarQuando você quer um site de produto com movimento marcante para o seu software ou produto digital, sem abrir mão de velocidade, acessibilidade ou visibilidade nas buscas.

No meu servidor de hospedagem Opus Growth [nome do servidor], crie um site de produto escuro e com várias páginas para [nome do produto], que conte a história do produto conforme o visitante rola a página. Produto: [o que faz, para quem é]. Os três passos que um usuário segue no produto: [três passos]. Principais recursos: [4 a 6 recursos]. Contato: [e-mail], [telefone], [número do WhatsApp], [endereço, se houver]. Domínio: [domínio]. Preferência de cor: [cor ou "você escolhe"]. Capturas de tela ou fotos reais do produto: [links ou "nenhuma"].

Páginas: início (/), produto (/urun/), sobre (/hakkimizda/), contato (/iletisim/), privacidade (/gizlilik/) e 404.html. Seções da página inicial, em ordem: hero (h1, descrição em duas frases, dois botões, imagem do produto), a história do produto como elemento de assinatura, recursos, para quem é, FAQ e uma chamada final para ação. Sem formulário na página de contato; use email, telefone e um link do WhatsApp com mensagem pré-preenchida, porque o servidor serve apenas arquivos estáticos.

Estilo: movimento escuro. Fundo escuro, uma única cor de destaque contida (não neon), uma fonte display grotesca compacta da Fontshare (por exemplo, Cabinet Grotesk) e uma fonte de texto calma (por exemplo, Switzer). Sem gradientes e sem WebGL; guarde a ousadia para a história do produto.

Regras de movimento (a parte mais difícil, siga-as à risca):
1. Bibliotecas: GSAP 3.13 core, ScrollTrigger, SplitText e Lenis. Baixe-as do jsdelivr para `assets/vendor/` com site_fetch e fixe a versão. Carregue-as apenas nas páginas inicial e de produto; as páginas sobre, contato e privacidade não levam nenhum script. Não carregue o Swiper.
2. Não anexe essas bibliotecas com `<script defer>`. Coloque um pequeno loader no final da página: depois do evento load, ele espera duas chamadas de requestAnimationFrame e então requestIdleCallback, adiciona os scripts em ordem com async=false e não baixa nada se `<html>` não tiver a classe `anim`. Na demonstração, as bibliotecas com defer levaram o LCP no mobile a 3,2 s e deixaram o Performance em 92; com esse loader chegou a 99.
3. Um script de uma linha no `<head>` adiciona a classe `js` ao `<html>`, e a classe `anim` a menos que prefers-reduced-motion seja "reduce". Defina os estados iniciais ocultos apenas sob `.anim`, para que o conteúdo fique visível desde o início com JS desativado ou para visitantes que preferem menos movimento, e as bibliotecas nunca sejam baixadas para eles. Como rede de segurança caso uma biblioteca falhe ao carregar, adicione uma animação CSS que torne visíveis todos os elementos ocultos após 2,5 s. Se o JS chegar depois disso, não oculte novamente o conteúdo visível; apenas monte a história fixada.
4. Entrada do título com SplitText: o h1 da primeira tela é o elemento LCP, nunca o comece oculto. O h1 começa visível em uma cor atenuada que ainda passa no contraste AA, e o SplitText leva suas linhas à cor total uma após a outra (opções mask e aria ativadas). Mantenha a entrada das linhas mascaradas, subindo, nos títulos h2 mais abaixo e execute-a na rolagem com ScrollTrigger.
5. Elemento de assinatura: na história do produto, use pin e scrub do ScrollTrigger por meio de gsap.matchMedia apenas a partir de 768 px de largura (scrub em torno de 0.6, end "+=180%"). À esquerda, os três passos ficam ativos um a um; à direita, a tela do produto se preenche passo a passo. Não esmaeça os passos inativos com opacity; mude apenas a cor do título e a linha da borda. Na demonstração, passos esmaecidos com opacity falharam no contraste no desktop e derrubaram a Acessibilidade para 95. No mobile não há pin; os passos aparecem no fluxo normal. Sem JS, a tela do produto mostra seu estado final.
6. Ative o Lenis apenas em dispositivos `(pointer: fine)` para que dispositivos de toque mantenham a rolagem nativa. Controle o Lenis pelo gsap.ticker e mova o foco para o destino depois de rolar até um link interno da página.
7. A tela do produto é uma figura decorativa com aria-hidden e uma figcaption que diz o que ela mostra. Toda interação funciona com o teclado e o anel de foco permanece visível.

Configuração e armadilhas conhecidas (cada uma reduziu uma pontuação nas medições da demonstração, não pule nenhuma):
1. Se já houver um site no ar no servidor, avise-me primeiro, porque a configuração sobrescreve index.html e a pasta assets. Mostre uma prévia de scaffold_site com confirm=false e chame-o com confirm=true após a minha aprovação. Depois leia site_design_guide e site_seo_guide. Antes de escrever código, coloque a direção de design (tipografia, cor, grid, elemento de assinatura, linguagem de movimento e as bibliotecas que NÃO serão carregadas) em um ART.md curto fora de assets e mostre para mim.
2. Compile o Tailwind em vez de carregá-lo pela CDN. Instale-o com site_run_command e background=true: `npm i -D tailwindcss@3`, e depois acompanhe com site_command_status. Os caminhos de content em `tailwind.config.js` devem cobrir todos os arquivos HTML, os templates e qualquer arquivo JS que escreva nomes de classes. `_src/tw.css` contém a linha `@import "../assets/app.css";` e as três linhas `@tailwind`; compile-o em um único arquivo com `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Remova o script cdn.tailwindcss.com e o tailwind.config inline de todas as páginas e vincule apenas `/assets/site.css`. Recompile após cada alteração de HTML.
3. Hospede as fontes você mesmo. Leia o CSS das famílias da Fontshare que escolheu, baixe o arquivo woff2 de cada peso para `assets/fonts/` com site_fetch e escreva as regras @font-face com `font-display: swap` em `assets/app.css`; o design-check procura uma fonte personalizada ali. Confira o nome do font-family no CSS que você baixou, porque a Fontshare pode devolver outra família quando um peso não existe. Faça preload da fonte do título da primeira tela e da fonte do texto em todas as páginas com `<link rel="preload" as="font" type="font/woff2" crossorigin>`; na demonstração isso eliminou o deslocamento de layout causado pela troca de fonte (CLS de 0,024 para 0). A maioria das fontes da Fontshare não tem o glifo ₺, então escreva "TL" nos preços.
4. Faça o menu e o rodapé em HTML estático. Não carregue chrome.js nem site.config.js nas páginas. Escreva um pequeno `chrome-stamp.mjs` que leia a lista de navegação em site.config.js e carimbe `_src/header.tpl` e `_src/footer.tpl` entre os marcadores `` e `` de cada página, adicionando aria-current="page" ao link atual. Não dê aos templates a extensão .html e use marcadores como `[[NAV]]` em vez de `{{...}}`, caso contrário o design-check e o seo-check os leem como páginas inacabadas. Construa o menu mobile sem JS usando `<details>`. Mantenha o nome da empresa, o endereço e o telefone no rodapé como texto simples.
5. Converta as imagens durante o download com site_fetch: grave a mesma foto em arquivos separados com resize="480x", "800x" e "1200x", image_format="webp", quality=65. Dê a cada `<img>` srcset, sizes, width e height. A imagem principal da primeira tela recebe fetchpriority="high" e nunca é lazy; as demais recebem loading="lazy" decoding="async". Se a imagem principal ocupa toda a tela do celular, sirva um recorte mais largo e menor no mobile com `<picture>` (na demonstração, o hero mobile caiu de 89 KB para 43 KB).
6. Crie um favicon PNG de 48 px a partir do logotipo com site_fetch e adicione `<link rel="icon">` a todas as páginas. Sem ele, o navegador registra um 404 e as Boas Práticas caem para 96.
7. Regras do validador de HTML: comece todo documento com `<!DOCTYPE html>` em maiúsculas (os arquivos iniciais do kit usam minúsculas), use `&nbsp;` nos espaços do texto visível dos links tel:, nunca use o atributo style="" e dê a todo botão type="button".

SEO, AEO e GEO:
1. Use URLs de diretório com barra final (/urun/, /hakkimizda/, /iletisim/, /gizlilik/). Preencha o bloco seo de site.config.js e execute `node seo-stamp.mjs`. Escreva o schema específico de cada página (início WebPage e FAQPage; produto SoftwareApplication e FAQPage; sobre AboutPage; contato ContactPage; BreadcrumbList nas páginas internas. Para uma empresa de software sem loja física, defina localBusiness:false em site.config.js) em blocos `<script type="application/ld+json">` separados e vincule-o ao grafo base com @id. Não esconda o BreadcrumbList dentro de um @graph; dê a ele seu próprio bloco, porque essa é a única forma de o seo-check o enxergar.
2. Títulos de 48 a 60 caracteres (o seo-check sinaliza como erro qualquer um acima de 65), descrições de 145 a 158 caracteres, um h1 por página. Toda página precisa de pelo menos 150 palavras de conteúdo principal; as páginas de contato e privacidade costumam ficar abaixo disso.
3. O primeiro parágrafo de cada página responde diretamente à pergunta da página. Escreva um FAQ específico da página com `<details>` e marque-o como FAQPage. Mostre a organização responsável pela publicação e uma data de "Última atualização" com `<time>`.
4. No robots.txt, escreva sua decisão com o motivo para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot e CCBot, e aponte para o sitemap. O sitemap.xml traz datas lastmod reais. O llms.txt contém um resumo preciso do site em duas frases e a lista das páginas principais.
5. Não invente nada: nenhuma avaliação, nota, prêmio, número de clientes, certificado, horário de funcionamento, coordenada ou preço, a menos que eu os informe. Deixe campos desconhecidos fora do schema.

Critérios de aprovação (em ordem; não diga que terminou até que todos passem):
1. Com site_run_command, execute `node chrome-stamp.mjs`, o build do Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 erros, 0 avisos), `node design-check.mjs` (0 erros; justifique qualquer aviso restante) e `npx html-validate "**/*.html"` (0 erros).
2. Veja todas as páginas com site_preview, view="mobile" e view="desktop". O site_preview captura a página com o movimento desativado (reduced-motion), então, se faltar conteúdo nessa imagem, o estado sem movimento está quebrado. Nas capturas de página inteira, imagens lazy mais abaixo podem aparecer vazias; isso não é erro, mas confira os caminhos delas.
3. Execute core_web_vitals em todas as páginas com strategy="mobile" e strategy="desktop". Aprovação: no mobile, Performance de pelo menos 95 e Acessibilidade, Boas Práticas e SEO 100; no desktop, as quatro de pelo menos 95. Em uma página que falhar, use resources=true para encontrar o arquivo que a atrasa, corrija e meça novamente. Depois execute seo_audit na página inicial com strategy="mobile" e runs=2. A lista de requisições de rede não pode conter nenhum host além do seu próprio domínio.
4. Sem rolagem horizontal nas larguras de 360, 390, 768 e 1440 px, alvos de toque de pelo menos 44 px, nenhum erro no console.

Verificação de movimento: o site_preview não consegue mostrar movimento, então descreva a seção fixada da página inicial e diga o que devo verificar no meu próprio navegador: no desktop, a história do produto deve ficar presa no topo enquanto os passos avançam com a rolagem; no celular, deve fluir sem ficar presa; e, com redução de movimento ativada no sistema operacional, nada deve se mover e tudo deve estar visível.

Depois de publicar: mostre a prévia da regra `/assets/* Cache-Control: public, max-age=31536000, immutable` com site_headers e aplique-a após a minha aprovação; a partir daí, renomeie os arquivos CSS ou JS quando mudarem (site-v2.css e assim por diante). Envie o sitemap.xml com gsc_submit_sitemap e verifique a página inicial com gsc_url_inspect. Termine com uma tabela de pontuação por página (página, quatro pontuações mobile, quatro pontuações desktop, LCP, CLS), os resultados dos critérios e a lista de correções aplicadas.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um site moderno sem JavaScript: animações CSS controladas por rolagem, View Transitions e container queries

Cria um site com várias páginas no seu servidor de hospedagem que não carrega nenhum script, com movimento via animation-timeline, transições de página via View Transitions e cards responsivos via container queries. Cada recurso é protegido por @supports e pela preferência de movimento reduzido, então os navegadores sem suporte ainda recebem a página completa.

Quando usarQuando você quer que seu site pareça moderno e fluido, mas abra na forma mais leve possível, sem carregar nenhum JavaScript.

No meu servidor de hospedagem Opus Growth [nome do servidor], crie um site de várias páginas para [nome da empresa] que não carregue nenhum JavaScript e faça suas animações e transições de página com os recursos de CSS do próprio navegador. Negócio: [o que faz, para quem], cidade: [cidade, bairro]. Serviços ou produtos: [lista]. Trabalhos: [para cada um: nome, material ou escopo, duração, problema resolvido, link da imagem]. Contato: [e-mail], [telefone], [número de WhatsApp], [endereço]. Domínio: [domínio].

Páginas: início (hero, trabalhos recentes, processo, FAQ), trabalhos (/isler/), sobre (/hakkimizda/), contato (/iletisim/, sem formulário), privacidade (/gizlilik/) e 404.html.

Estilo: editorial e natural. Uma fonte serifada de destaque (por exemplo Zodiak) com uma fonte de texto discreta (por exemplo Switzer), fundo em tom de linho, um único acento escuro, muito espaço. Guarde a ousadia para os cards de trabalho.

Regras de CSS moderno (aprimoramento progressivo; em um navegador sem suporte, a página deve ficar estática, mas completa):
1. Não carregue nenhum arquivo JavaScript; nada de GSAP, Lenis ou Swiper. O menu mobile funciona com `<details>`.
2. Transições de página (View Transitions entre páginas da mesma origem): escreva `@media (prefers-reduced-motion: no-preference) { @view-transition { navigation: auto; } }` e mantenha a duração em torno de 0,35 s. Dê à barra superior o view-transition-name: site-header. Dê à imagem de um card de trabalho na página inicial e à mesma imagem na página de trabalhos o mesmo view-transition-name único, para que a imagem cresça até o seu lugar na nova página. Use cada nome apenas uma vez por página.
3. Animações guiadas por rolagem: uma linha de progresso no topo que cresce com scaleX em `animation-timeline: scroll(root)` (display:none por padrão, visível apenas com suporte); em cards e títulos de seção, `animation-timeline: view()` com `animation-range: entry 0% entry 70%` usando apenas translateY; na imagem do hero, uma escala e um deslocamento suaves enquanto ela está em vista. Não use opacity: elementos esmaecidos abaixo da tela reprovam na checagem de contraste do Lighthouse. Coloque todas essas regras dentro de `@supports (animation-timeline: scroll())` e `prefers-reduced-motion: no-preference`.
4. Container queries: transforme o card de trabalho em um componente com `container-type: inline-size`. Com `@container (min-width: 34rem)`, a imagem fica em cima em um contêiner estreito e ao lado do texto em um contêiner largo. O mesmo card é estreito em uma grade de três colunas na página inicial e largo em uma única coluna na página de trabalhos. O núcleo do Tailwind 3 não tem classes de container query; escreva essas regras como CSS puro em app.css.
5. O nível de título do card deve se adequar à página em que ele está: na página de trabalhos, coloque um h2 entre o h1 e os títulos h3 dos cards. Quando isso faltou na demonstração, Acessibilidade caiu para 98 por causa de heading-order.
6. Na página de trabalhos, a primeira imagem de card que entra na primeira tela não usa lazy e recebe fetchpriority="high".

Configuração e armadilhas conhecidas (cada uma reduziu uma nota nas medições da demonstração, não pule nenhuma):
1. Se já houver um site no ar no servidor, avise-me primeiro, porque a configuração sobrescreve o index.html e a pasta assets. Mostre a prévia de scaffold_site com confirm=false e chame com confirm=true após a minha aprovação. Depois leia site_design_guide e site_seo_guide. Antes de escrever código, coloque a direção de design (tipografia, cor, grade, elemento marcante, linguagem de movimento e as bibliotecas que NÃO serão carregadas) em um ART.md curto fora de assets e mostre-o para mim.
2. Compile o Tailwind em vez de carregá-lo pelo CDN. Instale com site_run_command e background=true: `npm i -D tailwindcss@3`, e em seguida acompanhe com site_command_status. Os caminhos de content em `tailwind.config.js` devem cobrir todos os arquivos HTML, os templates e qualquer arquivo JS que escreva nomes de classes. `_src/tw.css` contém a linha `@import "../assets/app.css";` e as três linhas `@tailwind`; compile-o em um único arquivo com `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Remova o script cdn.tailwindcss.com e o tailwind.config inline de todas as páginas e vincule apenas `/assets/site.css`. Recompile após cada alteração no HTML.
3. Hospede as fontes você mesmo. Leia o CSS das famílias Fontshare escolhidas, baixe o arquivo woff2 de cada peso em `assets/fonts/` com site_fetch e escreva as regras @font-face com `font-display: swap` em `assets/app.css`; o design-check procura uma fonte personalizada ali. Confira o nome do font-family no CSS que você baixou, porque a Fontshare pode retornar outra família quando um peso não existe. Faça preload da fonte do título da primeira tela e da fonte do texto em todas as páginas com `<link rel="preload" as="font" type="font/woff2" crossorigin>`; na demonstração, isso eliminou o deslocamento de layout causado pela troca de fonte (CLS de 0,024 para 0). A maioria das fontes Fontshare não tem o glifo ₺, então escreva "TL" nos preços.
4. Faça o menu e o rodapé em HTML estático. Não carregue chrome.js nem site.config.js nas páginas. Escreva um pequeno `chrome-stamp.mjs` que leia a lista de navegação em site.config.js e carimbe `_src/header.tpl` e `_src/footer.tpl` entre os marcadores `` e `` de cada página, adicionando aria-current="page" ao link atual. Não dê aos templates a extensão .html e use marcadores como `[[NAV]]` em vez de `{{...}}`, caso contrário o design-check e o seo-check os leem como páginas inacabadas. Construa o menu mobile sem JS usando `<details>`. Mantenha o nome da empresa, o endereço e o telefone no rodapé como texto simples.
5. Converta as imagens ao baixá-las com site_fetch: grave a mesma foto em arquivos separados com resize="480x", "800x" e "1200x", image_format="webp", quality=65. Dê a cada `<img>` srcset, sizes, width e height. A imagem principal da primeira tela recebe fetchpriority="high" e nunca é lazy; as demais recebem loading="lazy" decoding="async". Se a imagem principal preencher a tela do celular, sirva um recorte mais largo e menor no mobile com `<picture>` (na demonstração, o hero mobile passou de 89 KB para 43 KB).
6. Crie um favicon PNG de 48 px a partir do logo com site_fetch e adicione `<link rel="icon">` a todas as páginas. Sem ele, o navegador registra um 404 e Boas Práticas cai para 96.
7. Regras do validador de HTML: comece cada documento com `<!DOCTYPE html>` em maiúsculas (os arquivos iniciais do kit usam minúsculas), use `&nbsp;` nos espaços do texto visível dos links tel:, nunca use o atributo style="" e dê a todo botão type="button".

SEO, AEO e GEO:
1. Use URLs de diretório com barra final (/isler/, /hakkimizda/, /iletisim/, /gizlilik/). Preencha o bloco seo de site.config.js e execute `node seo-stamp.mjs`. Escreva o schema específico de cada página (início: WebPage e FAQPage; trabalhos: CollectionPage com um CreativeWork por peça em hasPart (com material, se conhecido); sobre: AboutPage; contato: ContactPage; BreadcrumbList nas páginas internas. O subtipo de LocalBusiness mais específico em site.config.js) em blocos `<script type="application/ld+json">` separados e vincule-o ao grafo base com @id. Não esconda o BreadcrumbList dentro de um @graph; dê a ele um bloco próprio, pois é a única forma de o seo-check enxergá-lo.
2. Títulos de 48 a 60 caracteres (o seo-check marca como erro tudo acima de 65), descrições de 145 a 158 caracteres, um h1 por página. Cada página precisa de pelo menos 150 palavras de conteúdo principal; as páginas de contato e privacidade costumam ficar abaixo disso.
3. O primeiro parágrafo de cada página responde diretamente à pergunta da página. Escreva um FAQ específico da página com `<details>` e marque-o como FAQPage. Mostre a organização responsável pela publicação e uma data de "Última atualização" com `<time>`.
4. No robots.txt, escreva sua decisão com o motivo para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot e CCBot, e aponte para o sitemap. O sitemap.xml traz datas lastmod reais. O llms.txt contém um resumo preciso do site em duas frases e a lista das páginas principais.
5. Não invente nada: nada de avaliações, notas, prêmios, números de clientes, certificados, horários de funcionamento, coordenadas ou preços, a menos que eu os informe. Deixe os campos desconhecidos fora do schema.

Critérios de aprovação (em ordem; não diga que terminou até que todos passem):
1. Com site_run_command, execute `node chrome-stamp.mjs`, a compilação do Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 erros, 0 avisos), `node design-check.mjs` (0 erros; justifique qualquer aviso restante) e `npx html-validate "**/*.html"` (0 erros).
2. Veja todas as páginas com site_preview, view="mobile" e view="desktop". O site_preview captura a página com o movimento desativado (reduced-motion), então, se faltar conteúdo nessa imagem, o estado sem movimento está quebrado. Em capturas de página inteira, imagens lazy mais abaixo podem aparecer vazias; isso não é erro, mas confira os caminhos delas.
3. Execute core_web_vitals para cada página com strategy="mobile" e strategy="desktop". Para passar: no mobile, Desempenho de pelo menos 95 e Acessibilidade, Boas Práticas e SEO em 100; no desktop, as quatro notas de pelo menos 95. Em uma página que falhar, use resources=true para encontrar o arquivo que a atrasa, corrija e meça de novo. Depois execute seo_audit na página inicial com strategy="mobile" e runs=2. A lista de requisições de rede não deve conter nenhum host além do seu próprio domínio.
4. Sem rolagem horizontal nas larguras de 360, 390, 768 e 1440 px, alvos de toque de pelo menos 44 px, sem erros no console.

Verificação de suporte: o site_preview captura com o movimento desligado, então não consegue mostrar as transições. Explique como conferir no Chrome que a imagem cresce até o seu lugar quando clico em uma peça na página inicial, que a linha do topo se preenche conforme eu rolo, que o card muda de layout conforme estreito e alargo a janela, e que a página abre completa em um navegador sem esses recursos.

Depois de publicar: mostre a prévia da regra `/assets/* Cache-Control: public, max-age=31536000, immutable` com site_headers e aplique-a após a minha aprovação; a partir daí, renomeie os arquivos CSS ou JS quando mudarem (site-v2.css e assim por diante). Envie o sitemap.xml com gsc_submit_sitemap e verifique a página inicial com gsc_url_inspect. Termine com uma tabela de notas por página (página, quatro notas mobile, quatro notas desktop, LCP, CLS), os resultados dos critérios e a lista das correções aplicadas.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um site de portfólio de agência com prévias no cursor e galeria no estilo Webflow, sem Webflow

Cria um site de agência brutalista e moderno no seu servidor de hospedagem, com prévias de projetos que seguem o cursor, títulos de seção que se abrem ao rolar a página e uma galeria Swiper. As interações usam 3 KB de JS puro, com equivalentes para toque e teclado, a galeria carrega na primeira interação e todas as páginas são medidas.

Quando usarQuando você quer um portfólio interativo para o seu estúdio de design ou agência, como os feitos no Webflow, sem mensalidade de plataforma, scripts pesados nem carregamento lento no celular.

No meu servidor de hospedagem Opus Growth [nome do servidor], crie um site de portfólio estático e rápido para [nome do estúdio], com a sensação dos sites de agência interativos feitos no Webflow, sem usar Webflow. Estúdio: [o que faz, para quem], cidade e bairro: [cidade, bairro]. Serviços: [3 serviços]. Projetos: [para cada um: nome, tipo de trabalho, ano, uma frase sobre o problema, uma sobre a solução, link da imagem]. Contato: [e-mail], [telefone], [número do WhatsApp], [endereço]. Domínio: [domínio].

Páginas: home (hero, índice de trabalhos selecionados, o que fazemos, processo, FAQ, chamada para ação final), trabalhos (/isler/: galeria mais problema, trabalho realizado e nota de entrega de cada projeto), estúdio (/hakkimizda/), contato (/iletisim/, sem formulário; e-mail, WhatsApp com mensagem pré-preenchida e telefone), privacidade (/gizlilik/) e 404.html. Sem dados aprovados pelo cliente, não escreva porcentagens nem números de crescimento para os resultados dos projetos; descreva o resultado em palavras.

Estilo: brutalista moderno. Cantos retos, linhas de grade visíveis de 1 px, uma fonte display grotesca em caixa alta e em negrito (por exemplo Clash Grotesk) e uma fonte de texto calma (por exemplo Supreme), um único destaque fluorescente usado apenas como fundo com texto preto sobre ele. Os estados de hover mudam cor e fundo; o anel de foco é grosso e visível em qualquer fundo.

Regras de interação (a sensação do Webflow IX2, sem biblioteca):
1. NÃO carregue GSAP nem Lenis. Escreva as interações em um único arquivo JS puro e pequeno (IntersectionObserver e requestAnimationFrame) e carregue-o com defer apenas nas páginas home e trabalhos. Nenhum script nas outras páginas.
2. Elemento marcante, o índice "Trabalhos selecionados": cada linha é um link real para o projeto e traz o caminho da imagem de prévia em um atributo data-img. Por padrão (sem JS ou em dispositivo de toque), cada linha mostra uma imagem pequena no fluxo. Somente em dispositivos que correspondem a `(hover: hover) and (pointer: fine)` e que não pedem movimento reduzido, o JS adiciona uma classe cursor-fx ao `<html>`, oculta as imagens inline e mostra uma única caixa de prévia que segue o ponteiro. Mova a caixa com variáveis CSS e transform: translate3d em vez de left e top, e interrompa o loop de requestAnimationFrame quando o ponteiro parar. No foco do teclado, a mesma prévia abre fixa ao lado da linha e fecha quando o foco sai.
3. Adicione o anel de cursor personalizado somente sob a mesma condição; nunca oculte o cursor nativo, marque o anel com aria-hidden e faça-o crescer sobre os links.
4. Transições de seção: os títulos das seções se abrem da esquerda para a direita com clip-path ao rolar. O JS aplica o estado inicial oculto apenas aos títulos que estão abaixo da tela quando a página abre; o conteúdo da primeira tela nunca é ocultado. Dê ao atributo o nome data-reveal; o design-check reconhece movimento por esse nome e, caso contrário, avisa "no motion".
5. Galeria Swiper somente na página de trabalhos. Sem JS, o HTML da galeria é uma faixa horizontal de CSS scroll-snap, e os botões anterior e próximo ficam ocultos até o Swiper iniciar. Baixe o bundle js e css do Swiper 14 em `assets/vendor/` com site_fetch. Carregue-o quando o ponteiro entrar na galeria, ao toque, ao foco ou na primeira rolagem da página. Na demo, carregá-lo quando a galeria se aproximava da viewport levou o LCP mobile a 3 s por causa do bundle de 150 KB (Performance 94); carregar na primeira interação deu 99. Ative os módulos Navigation, Keyboard e A11y com mensagens em turco, e defina a velocidade de transição como 0 quando houver movimento reduzido.
6. Monte os slides com div em vez de ul e li. O Swiper dá role="group" aos slides; em li, esse role causou erros de aria-allowed-role e de lista e derrubou a Acessibilidade para 96.

Configuração e armadilhas conhecidas (cada uma baixou uma nota nas medições da demo, não pule nenhuma):
1. Se já houver um site no ar no servidor, avise-me primeiro, porque a configuração sobrescreve index.html e a pasta assets. Mostre a prévia de scaffold_site com confirm=false e chame com confirm=true depois da minha aprovação. Em seguida, leia site_design_guide e site_seo_guide. Antes de escrever código, coloque a direção de design (tipografia, cor, grade, elemento marcante, linguagem de movimento e as bibliotecas que NÃO serão carregadas) em um ART.md curto fora de assets e mostre-o para mim.
2. Compile o Tailwind em vez de carregá-lo pelo CDN. Instale com site_run_command e background=true: `npm i -D tailwindcss@3`, e acompanhe com site_command_status. Os caminhos de content em `tailwind.config.js` devem cobrir todos os arquivos HTML, os templates e qualquer arquivo JS que escreva nomes de classes. `_src/tw.css` contém a linha `@import "../assets/app.css";` e as três linhas `@tailwind`; compile-o em um único arquivo com `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Remova o script cdn.tailwindcss.com e o tailwind.config inline de todas as páginas e vincule apenas `/assets/site.css`. Recompile após cada alteração no HTML.
3. Hospede as fontes você mesmo. Leia o CSS das famílias do Fontshare que escolheu, baixe o arquivo woff2 de cada peso em `assets/fonts/` com site_fetch e escreva as regras @font-face com `font-display: swap` em `assets/app.css`; o design-check procura uma fonte personalizada ali. Confira o nome da font-family no CSS que você baixou, pois o Fontshare pode retornar outra família quando um peso não existe. Faça preload da fonte do título da primeira tela e da fonte do texto em todas as páginas com `<link rel="preload" as="font" type="font/woff2" crossorigin>`; na demo, isso eliminou o deslocamento de layout causado pela troca de fonte (CLS de 0,024 para 0). A maioria das fontes do Fontshare não tem o glifo ₺, então escreva "TL" nos preços.
4. Faça o menu e o rodapé em HTML estático. Não carregue chrome.js nem site.config.js nas páginas. Escreva um pequeno `chrome-stamp.mjs` que leia a lista de navegação em site.config.js e carimbe `_src/header.tpl` e `_src/footer.tpl` entre os marcadores `` e `` de cada página, adicionando aria-current="page" ao link atual. Não dê aos templates a extensão .html e use marcadores como `[[NAV]]` em vez de `{{...}}`, senão o design-check e o seo-check os leem como páginas inacabadas. Construa o menu mobile sem JS usando `<details>`. Mantenha o nome da empresa, o endereço e o telefone no rodapé como texto simples.
5. Converta as imagens ao baixá-las com site_fetch: grave a mesma foto em arquivos separados com resize="480x", "800x" e "1200x", image_format="webp", quality=65. Dê a cada `<img>` srcset, sizes, width e height. A imagem principal da primeira tela recebe fetchpriority="high" e nunca é lazy; as demais recebem loading="lazy" decoding="async". Se a imagem principal preencher a tela do celular, sirva um recorte mais largo e menor no mobile com `<picture>` (na demo, o hero mobile passou de 89 KB para 43 KB).
6. Crie um favicon PNG de 48 px a partir do logo com site_fetch e adicione `<link rel="icon">` em todas as páginas. Sem ele, o navegador registra um 404 e as Práticas recomendadas caem para 96.
7. Regras do validador HTML: comece todo documento com `<!DOCTYPE html>` em maiúsculas (os arquivos iniciais do kit usam minúsculas), use `&nbsp;` nos espaços do texto visível dos links tel:, nunca use o atributo style="" e dê type="button" a todo botão.

SEO, AEO e GEO:
1. Use URLs de diretório com barra final (/isler/, /hakkimizda/, /iletisim/, /gizlilik/). Preencha o bloco seo de site.config.js e execute `node seo-stamp.mjs`. Escreva o schema específico de cada página (home WebPage e FAQPage; trabalhos CollectionPage com um CreativeWork por projeto em hasPart; estúdio AboutPage; contato ContactPage; BreadcrumbList nas páginas internas. Para um estúdio com escritório físico, use businessType ProfessionalService) em blocos `<script type="application/ld+json">` separados e vincule-o ao grafo base com @id. Não esconda o BreadcrumbList dentro de um @graph; dê a ele seu próprio bloco, pois é a única forma de o seo-check enxergá-lo.
2. Títulos de 48 a 60 caracteres (o seo-check sinaliza como erro qualquer um acima de 65), descrições de 145 a 158 caracteres, um h1 por página. Toda página precisa de pelo menos 150 palavras de conteúdo principal; as páginas de contato e privacidade costumam ficar abaixo disso.
3. O primeiro parágrafo de cada página responde diretamente à pergunta da página. Escreva um FAQ específico da página com `<details>` e marque-o como FAQPage. Mostre a organização que publica e uma data de "Última atualização" com `<time>`.
4. No robots.txt, escreva sua decisão com o motivo para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot e CCBot, e aponte para o sitemap. O sitemap.xml traz datas lastmod reais. O llms.txt contém um resumo preciso do site em duas frases e a lista das páginas principais.
5. Não invente nada: nenhuma avaliação, nota, prêmio, número de clientes, certificado, horário de funcionamento, coordenada ou preço, a menos que eu informe. Deixe os campos desconhecidos fora do schema.

Portões de verificação (em ordem; não diga que terminou até todos passarem):
1. Com site_run_command, execute `node chrome-stamp.mjs`, o build do Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 erros, 0 avisos), `node design-check.mjs` (0 erros; justifique qualquer aviso restante) e `npx html-validate "**/*.html"` (0 erros).
2. Veja todas as páginas com site_preview, view="mobile" e view="desktop". O site_preview captura a página com o movimento desligado (reduced-motion); portanto, se faltar conteúdo nessa imagem, o estado sem movimento está quebrado. Nas capturas de página inteira, imagens lazy mais abaixo podem aparecer vazias; isso não é erro, mas confira os caminhos delas.
3. Execute core_web_vitals para todas as páginas com strategy="mobile" e strategy="desktop". Critério: no mobile, Performance de pelo menos 95 e Acessibilidade, Práticas recomendadas e SEO 100; no desktop, as quatro de pelo menos 95. Em uma página que falhar, use resources=true para achar o arquivo que a atrasa, corrija e meça de novo. Depois, execute seo_audit na home com strategy="mobile" e runs=2. A lista de requisições de rede não pode conter nenhum host além do seu próprio domínio.
4. Sem rolagem horizontal nas larguras de 360, 390, 768 e 1440 px, alvos de toque de pelo menos 44 px, sem erros no console.

Verificação das interações: o site_preview não consegue mostrar hover nem efeitos de cursor. Diga-me como conferir em um navegador desktop que a prévia segue o ponteiro sobre as linhas do índice, que ela abre ao lado da linha ao navegar com Tab, que o celular mostra as imagens inline e que a galeria desliza com o dedo.

Depois de publicar: mostre a prévia da regra `/assets/* Cache-Control: public, max-age=31536000, immutable` com site_headers e aplique-a depois da minha aprovação; a partir daí, renomeie os arquivos CSS ou JS quando mudarem (site-v2.css e assim por diante). Envie o sitemap.xml com gsc_submit_sitemap e verifique a home com gsc_url_inspect. Termine com uma tabela de notas por página (página, quatro notas mobile, quatro notas desktop, LCP, CLS), os resultados dos portões e a lista das correções que você aplicou.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um site de luxo bilíngue para um hotel boutique ou projeto imobiliário, com fotografias grandes, parallax suave e hreflang

Cria um site acolhedor e luxuoso em turco e inglês para um hotel boutique ou projeto residencial no seu servidor de hospedagem. Entrega fotos grandes com rapidez e um recorte separado para celular, adiciona parallax sem JavaScript que respeita a preferência por movimento reduzido e configura corretamente o schema Hotel ou RealEstateListing e o hreflang.

Quando usarVocê quer alcançar também hóspedes ou compradores estrangeiros, suas fotos vendem mas o seu site está pesado nos celulares, ou suas páginas em inglês se misturam com as em turco nos resultados de busca.

Crie um site em turco e inglês para o meu [hotel / projeto residencial] no meu servidor de hospedagem [nome do servidor]. Detalhes:
1. Nome: [nome do negócio ou projeto], localização: [localização], tipo: [hotel boutique / projeto residencial]
2. Para um hotel, os tipos de quarto (tamanho, cama, hóspedes, vista, comodidades), horários de check-in e check-out, temporada e regras da casa: [detalhes dos quartos]
3. Para um projeto, os tipos de unidade (quartos, metros quadrados, andar, data de entrega) e dados do estande de vendas: [detalhes das unidades]
4. Telefone: [telefone], WhatsApp: [WhatsApp], e-mail: [e-mail], endereço: [endereço]
5. Domínio: [domínio], fotos reais: [onde estão as fotos, ou "use stock"]
6. Quem vai revisar o texto em inglês: [pessoa, ou "ninguém"]

Primeiro confirme o servidor com list_servers e execute scaffold_site com style="universal", primeiro com confirm=false e depois com confirm=true após a minha aprovação. Leia site_design_guide e site_seo_guide. Escreva em _kaynak/ART.md uma decisão de design luxuosa e acolhedora e mostre para mim: uma fonte serifada refinada para títulos da Fontshare (por exemplo Boska 300) com uma fonte simples para o corpo do texto (por exemplo Synonym), tons de café escuro e linho, um único destaque em cobre, rótulos pequenos com espaçamento entre letras generoso e fotografia em tela cheia. O elemento de assinatura é a primeira imagem em tela cheia na página inicial e seu paralaxe suave. Não coloque um cabeçalho transparente sobre a foto; em páginas claras o texto claro do menu desaparece (na demo, isso derrubou a acessibilidade para 95 nas páginas de quartos e contato). Dê à barra um fundo escuro.

Estrutura de idiomas:
1. As páginas em turco ficam na raiz e suas gêmeas em inglês em /en/. Toda página em turco tem uma gêmea em inglês e as duas apontam uma para a outra. Mantenha os pares de páginas em uma única lista em assets/site.config.js e monte o menu, o rodapé e o seletor de idioma a partir dela; o seletor sempre leva à página correspondente, nunca à página inicial.
2. O <head> de cada página traz hreflang="tr", hreflang="en" e hreflang="x-default" apontando para a página em turco, todos como URLs absolutas; escreva os mesmos pares no sitemap.xml como entradas xhtml:link.
3. As páginas em inglês usam <html lang="en">, título, descrição e breadcrumb em inglês, e WebPage inLanguage "en". O seo-stamp.mjs carimba og:locale tr_TR em todas as páginas; no build.mjs, depois do carimbo, mude para en_GB nas páginas em inglês e adicione og:locale:alternate nos dois idiomas.
4. Escreva o inglês como um redator nativo escreveria, não como tradução, e mantenha os nomes de lugares na grafia turca.

Páginas e schema (cada uma nos dois idiomas):
1. Início: primeira imagem em tela cheia, o que é o lugar em um parágrafo, fatos rápidos (número de quartos, check-in, check-out, temporada), cartões de quartos e um link para o guia local. Schema: WebPage e, no nó do negócio, o tipo Hotel com checkinTime, checkoutTime, numberOfRooms, amenityFeature e os quartos em containsPlace. Para um projeto residencial, use Residence ou ApartmentComplex.
2. Uma página de quartos e uma página para cada tipo de quarto: tamanho, cama, número de hóspedes, comodidades, para quem é indicado e um link para o outro tipo de quarto. Schema: HotelRoom (bed, occupancy, floorSize, amenityFeature, containedInPlace #business). Para um projeto residencial, um RealEstateListing por tipo de unidade com um Apartment dentro (numberOfRooms, floorSize). Se eu não informei preços, não escreva offers e diga no texto "envie suas datas e informaremos a tarifa para elas".
3. Guia local: conhecimento local com data da última atualização. Schema: WebPage.
4. Contato e reserva: telefone, formulário de WhatsApp, e-mail, endereço, "Como chegar", notas de viagem e condições de reserva. Schema: ContactPage.
5. Uma página 404 (curta, nos dois idiomas).

Não declare classificação por estrelas, prêmios, notas de hóspedes nem "o melhor"; não adicione starRating nem aggregateRating.

Para abrir fotos grandes rapidamente: entregue a primeira imagem com <picture>; em telas de até 767 pixels use um recorte vertical com 600 e 900 pixels de largura (recortado no endereço de origem e baixado com site_fetch), e em telas maiores a versão horizontal com 1200, 1600 e 2000 pixels. Sem o recorte vertical, a imagem horizontal é ampliada para preencher a tela do celular e fica borrada ou baixa um arquivo desnecessariamente grande.

Sem invenção: não escreva avaliações, notas, prêmios, certificados, números de clientes nem afirmações como "o melhor" que não sejam reais. Não adicione ao schema ou ao texto horários de funcionamento, coordenadas, preços ou um e-mail que eu não tenha informado; deixe o campo de fora e liste-o como ausente no relatório. Não use travessões longos nem slogans genéricos, e faça o primeiro parágrafo de cada página responder diretamente à pergunta daquela página.

Trabalho de SEO compartilhado: cada página recebe um title único de 48 a 60 caracteres, uma description de 145 a 158 caracteres, um único H1 e um canonical terminado em barra. Adicione a cada página seu próprio nó WebPage e BreadcrumbList, ligados ao grafo base por @id. No robots.txt escreva Allow: / para Googlebot, Bingbot, OAI-SearchBot, ChatGPT-User, GPTBot, Claude-SearchBot, Claude-User, ClaudeBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended e CCBot, explique a decisão em um comentário e anote o que mudar se eu quiser bloquear os rastreadores de treinamento. O sitemap.xml traz datas lastmod reais. O llms.txt descreve o negócio com precisão em duas frases e lista o NAP e as páginas importantes com links.

Configuração técnica (o caminho padrão do kit não é usado neste site, pelos motivos abaixo):
1. Compile o Tailwind e elimine a CDN. O kit carrega o Tailwind pela CDN Play, que compila no navegador, exibe um aviso no console e reduz o desempenho no celular. Escreva _kaynak/package.json com site_write_file, instale com site_run_command("cd _kaynak && npm i -D tailwindcss@3 html-validate", background=true) e aguarde com site_command_status. Em _kaynak/tailwind.config.js defina content como "./*.html", "./**/*.html", "!./_kaynak/**" e "./_kaynak/chrome.mjs". Mova as regras @font-face, as linhas @tailwind e o anel de foco, o skip link e a proteção contra overflow do app.css do kit para _kaynak/site.css. Gere a saída em assets/app.css, porque o design-check.mjs procura as fontes nesse arquivo, e adicione ?v=<hash do conteúdo> ao link em todas as páginas para que o cache de borda nunca sirva o arquivo antigo.
2. Hospede as fontes você mesmo. Leia a URL do CSS das famílias da Fontshare escolhidas (api.fontshare.com/v2/css?f[]=...) com site_read_url, baixe os arquivos woff2 com site_fetch em assets/fonts/ e declare-os com @font-face e font-display: swap. Faça preload de cada peso usado acima da dobra com <link rel="preload" as="font" type="font/woff2" crossorigin>, no máximo três arquivos. Sem isso a troca de fonte desloca o layout; na demo o CLS no desktop era 0,078 por esse motivo e caiu para 0 com o preload.
3. Faça o menu e o rodapé em HTML estático. Os componentes <site-nav> e <site-footer> do kit dependem de JavaScript, e a maioria dos rastreadores de IA nunca vê o menu, o endereço nem o telefone. Remova os scripts chrome.js e motion.js de todas as páginas. Em _kaynak/chrome.mjs escreva duas funções que montem o HTML do cabeçalho e do rodapé a partir de assets/site.config.js; monte o menu mobile sem JavaScript usando <details> e <summary>, e marque a página atual com aria-current="page". Escreva na raiz do site o build.mjs que, nesta ordem, executa node seo-stamp.mjs, recarimba tudo entre  e  (e o mesmo para o rodapé) em cada página, compila o Tailwind e atualiza o hash no link do CSS. Depois de cada alteração, execute apenas site_run_command("node build.mjs").
4. Paralaxe sem JavaScript. Dê à primeira imagem data-parallax e mova-a lentamente com uma animação CSS controlada por rolagem (animation-timeline: scroll(root)) usando apenas transform; dê às seções uma entrada data-reveal que também use apenas transform, nunca opacity. Envolva as regras em @media (prefers-reduced-motion: no-preference) e @supports (animation-timeline: scroll()); com movimento reduzido, ou em um navegador sem suporte, a imagem fica parada. Não carregue GSAP, Lenis nem Swiper.
5. Reduza as imagens. Baixe cada foto com site_fetch em arquivos separados usando resize="480x", "800x", "1200x", "1600x", image_format="webp" e qualidade entre 60 e 68. Dê a cada <img> srcset, sizes, width e height que correspondam à proporção real; se recortar, adicione uma classe de proporção como aspect-[4/3] com object-cover, senão o layout se desloca quando a imagem carrega. A imagem da primeira tela recebe fetchpriority="high" e não é lazy; todas as outras recebem loading="lazy". Baixe a imagem de compartilhamento como JPG 1200x630 com site_fetch.
6. Pequenos detalhes que custam pontos: adicione um favicon SVG com <link rel="icon"> (senão o navegador solicita /favicon.ico, o 404 aparece como erro no console e Boas práticas cai). Escreva DOCTYPE em maiúsculas, não use atributos style e não deixe espaços no fim das linhas. Use &nbsp; em vez de espaços no texto visível dos links de telefone (a regra tel-non-breaking do html-validate). Os links do menu, rodapé, breadcrumb e títulos devem ter pelo menos 44 pixels de altura e largura. Não incorpore um iframe do Google Maps; o site não deve fazer requisições externas, então mostre o endereço e um link "Como chegar".
7. Nenhuma requisição pode sair do site: fontes, scripts, estilos e imagens ficam no seu próprio servidor. Não há tratador de formulário, então o formulário de contato é um formulário method="get" apontando para https://wa.me/[número do WhatsApp] com uma textarea pré-preenchida chamada "text"; não é necessário JavaScript.

Portões (nesta ordem; só considere concluído quando todos passarem):
1. Execute node build.mjs com site_run_command e depois node seo-check.mjs: 0 erros, 0 avisos. Um aviso de conteúdo duplicado significa que duas páginas não são diferentes o bastante; reescreva-as.
2. node design-check.mjs: 0 erros. Se você escolheu um estilo sem movimento, informe o aviso "no motion" como uma decisão deliberada, com o motivo.
3. _kaynak/node_modules/.bin/html-validate em todos os arquivos HTML: 0 erros. Coloque uma linha _kaynak/ em um arquivo .htmlvalidateignore na raiz do site para que as dependências não sejam analisadas.
4. Verificação de idiomas: mostre em uma tabela que a gêmea hreflang de cada página existe, retorna 200 e aponta de volta; o seo-check não deve dar nenhum aviso de hreflang.
5. Veja todas as páginas com site_preview em view="mobile", view="desktop" e também em larguras de 360 e 768. Corrija rolagem horizontal, títulos que transbordam, botões apertados ou texto ilegível e olhe de novo.
6. Meça todas as páginas com core_web_vitals em strategy="mobile" e strategy="desktop", e obtenha as notas de acessibilidade, boas práticas e SEO com seo_audit. A meta no mobile é 100 em acessibilidade, boas práticas e SEO e pelo menos 95 em desempenho; no desktop, pelo menos 95 nos quatro. Em uma página que não atingir a meta, execute core_web_vitals com resources=true, encontre o elemento LCP e qualquer imagem grande demais, corrija e repita o seo_audit com runs=2, porque uma única execução de laboratório pode oscilar.
7. As requisições de rede não devem conter nenhum endereço fora do domínio do próprio site.

Depois de publicar: envie o sitemap.xml com gsc_submit_sitemap e verifique a página inicial e as três páginas mais importantes com gsc_inspect_urls. Nenhuma ferramenta consegue clicar em "Solicitar indexação"; liste o que eu preciso solicitar manualmente no Search Console.

Termine com este relatório: a lista de páginas com as notas de mobile e desktop por página em uma tabela (desempenho, acessibilidade, boas práticas, SEO, LCP, CLS), o resultado de cada portão, as correções que você fez e as informações que ainda precisa de mim. Se alguma meta não foi atingida, diga isso claramente em vez de dar como concluído.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um site de restaurante ou café rico em fotos, mas rápido, com cardápio em HTML, caminho de reserva e localização

Cria um site de várias páginas, com estilo natural e acolhedor, para um restaurante ou café no seu servidor de hospedagem. Publica o cardápio em HTML com schema Menu em vez de PDF, liga a reserva ao telefone e ao WhatsApp e passa no teste de velocidade mobile mesmo com muitas fotos.

Quando usarSeu cardápio está em um PDF ou em uma foto, as pessoas têm dificuldade para encontrar seus horários e como reservar, ou seu site cheio de fotos carrega devagar no celular.

Crie do zero um novo site para o meu restaurante no meu servidor de hospedagem [nome do servidor]. Detalhes:
1. Nome: [nome do negócio], tipo: [restaurante / café / casa de café da manhã], culinária: [culinária]
2. Cardápio com seções, descrições e preços: [cardápio e preços]
3. Informações sobre opções vegetarianas, veganas, sem glúten e alérgenos: [informações alimentares]
4. Horário de funcionamento (separado para café da manhã e jantar, se forem diferentes): [horários]
5. Como as reservas são feitas: [telefone / WhatsApp / ambos], telefone: [telefone], WhatsApp: [WhatsApp]
6. Endereço e orientações de acesso: [endereço], [estacionamento e transporte]
7. De onde vêm os ingredientes e a nossa história: [produtores e história]
8. Domínio: [domínio], fotos reais: [onde estão as fotos, ou "use banco de imagens"]

Primeiro confirme o servidor com list_servers e execute scaffold_site com style="restaurant", primeiro com confirm=false e depois com confirm=true após a minha aprovação. Leia site_design_guide e site_seo_guide. Escreva uma decisão de design natural e orgânica em _kaynak/ART.md e mostre para mim: uma fonte de exibição serifada e acolhedora da Fontshare (por exemplo Gambarino) com uma fonte de texto suave (por exemplo Supreme), fundo cor de areia, texto em tons terrosos, dois tons quentes em verde-oliva e terracota, e o mesmo canto arredondado em todos os cartões. O elemento de assinatura é uma caixa de "quadro do dia" na página do cardápio. Se a fonte escolhida não tiver o glifo ₺, escreva os preços com "TL".

Páginas e schema:
1. Início: a primeira tela diz o que você serve e onde, com os botões "Reservar uma mesa" e "Ver o cardápio" e uma foto grande. Depois, três pratos do cardápio, de onde vêm os ingredientes, um resumo de horários e localização e 4 perguntas frequentes. Schema: WebPage, FAQPage, e adicione servesCuisine, acceptsReservations (a URL da página de reservas) e hasMenu ao nó #business.
2. Cardápio: em HTML, não em PDF. Cada seção tem um título e um link âncora, cada prato tem nome, descrição, preço e etiquetas de dieta, e o topo da página mostra a data da última atualização e um aviso sobre alérgenos. Use preços apenas da lista que forneci; nunca invente um preço que esteja faltando. Schema: Menu com MenuSection em hasMenuSection, MenuItem em hasMenuItem, Offer em offers (price, priceCurrency TRY) e suitableForDiet quando se aplicar.
3. Reservas: como as reservas funcionam, telefone e WhatsApp, um formulário de WhatsApp com mensagem pré-preenchida (data, horário, número de pessoas, jardim ou salão) e 3 perguntas frequentes (atraso, grupos grandes, cancelamento). Schema: WebPage, FAQPage.
4. Nossa história e produtores: quem está à frente do lugar, de quem vêm os ingredientes e uma tabela sazonal mostrando qual ingrediente está no cardápio em quais meses. Schema: AboutPage.
5. Localização e horários: endereço, tabela de horários, um link "Como chegar", como chegar de carro, do centro da cidade e de transporte público, e uma observação sobre acessibilidade. Schema: ContactPage.
6. Uma página 404.

Para continuar rápido apesar das fotos: uma imagem grande na primeira tela e todas as outras com carregamento lazy; WebP com qualidade de 60 a 65 e no máximo oito imagens por página; não carregue uma biblioteca de slider para a galeria.

Sem invenções: não escreva avaliações, notas, prêmios, certificados, números de clientes nem afirmações como "o melhor" que não sejam reais. Não adicione ao schema nem ao texto horários de funcionamento, coordenadas, preços ou e-mail que eu não tenha fornecido; deixe o campo de fora e liste-o como ausente no relatório. Não use travessões longos nem slogans genéricos, e faça o primeiro parágrafo de cada página responder diretamente à pergunta daquela página.

Trabalho de SEO compartilhado: cada página recebe um title único de 48 a 60 caracteres, uma description de 145 a 158 caracteres, um único H1 e um canonical terminando em barra. Adicione o nó WebPage próprio de cada página e um BreadcrumbList, ligados ao grafo base por @id. No robots.txt escreva Allow: / para Googlebot, Bingbot, OAI-SearchBot, ChatGPT-User, GPTBot, Claude-SearchBot, Claude-User, ClaudeBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended e CCBot, explique a decisão em um comentário e indique o que mudar se eu quiser bloquear os rastreadores de treinamento. O sitemap.xml traz datas lastmod reais. O llms.txt descreve o negócio com precisão em duas frases e lista o NAP e as páginas importantes com links.

Configuração técnica (o caminho padrão do kit não é usado neste site, pelos motivos abaixo):
1. Compile o Tailwind e elimine o CDN. O kit carrega o Tailwind pelo Play CDN, que compila no navegador, mostra um aviso no console e reduz o desempenho no mobile. Escreva _kaynak/package.json com site_write_file, instale com site_run_command("cd _kaynak && npm i -D tailwindcss@3 html-validate", background=true) e aguarde com site_command_status. Em _kaynak/tailwind.config.js defina content como "./*.html", "./**/*.html", "!./_kaynak/**" e "./_kaynak/chrome.mjs". Mova as regras @font-face, as linhas @tailwind e o anel de foco, o skip link e a proteção contra overflow do app.css do kit para _kaynak/site.css. Gere a saída em assets/app.css, porque o design-check.mjs procura as fontes nesse arquivo, e adicione ?v=<hash do conteúdo> ao link em todas as páginas para que o cache de borda nunca sirva o arquivo antigo.
2. Hospede as fontes você mesmo. Leia a URL de CSS das famílias da Fontshare que você escolheu (api.fontshare.com/v2/css?f[]=...) com site_read_url, baixe os arquivos woff2 com site_fetch para assets/fonts/ e declare-os com @font-face e font-display: swap. Faça preload de cada peso usado acima da dobra com <link rel="preload" as="font" type="font/woff2" crossorigin>, no máximo três arquivos. Se pular isso, a troca de fontes desloca o layout; na demonstração, o CLS no desktop foi 0,078 por esse motivo e caiu para 0 com o preload.
3. Transforme o menu e o rodapé em HTML estático. Os componentes <site-nav> e <site-footer> do kit funcionam com JavaScript, e a maioria dos rastreadores de IA nunca vê o menu, o endereço nem o telefone. Remova os scripts chrome.js e motion.js de todas as páginas. Em _kaynak/chrome.mjs escreva duas funções que montem o HTML do cabeçalho e do rodapé a partir de assets/site.config.js; construa o menu mobile sem JavaScript usando <details> e <summary>, e marque a página atual com aria-current="page". Escreva build.mjs na raiz do site que, em ordem, execute node seo-stamp.mjs, reaplique tudo entre  e  (e o mesmo para o rodapé) em todas as páginas, compile o Tailwind e atualize o hash no link do CSS. Após cada alteração, execute apenas site_run_command("node build.mjs").
4. Movimento apenas com CSS, e de forma sutil. Coloque data-reveal nos cartões de imagem e construa o efeito de revelação com uma animação CSS orientada por rolagem (animation-timeline: view()) usando apenas transform; não anime a opacidade, porque o texto que começa com opacidade zero desaparece em navegadores sem JavaScript e falha na verificação de contraste das auditorias de acessibilidade. Envolva a regra em @media (prefers-reduced-motion: no-preference) e @supports (animation-timeline: view()). Não carregue GSAP, Lenis nem Swiper.
5. Reduza as imagens. Baixe cada foto com site_fetch em arquivos separados usando resize="480x", "800x", "1200x", "1600x", image_format="webp" e qualidade entre 60 e 68. Dê a cada <img> srcset, sizes, e width e height compatíveis com a proporção real; se você recortar, adicione uma classe de proporção como aspect-[4/3] com object-cover, caso contrário o layout se desloca quando a imagem carrega. A imagem da primeira tela recebe fetchpriority="high" e não é lazy; todas as outras recebem loading="lazy". Baixe a imagem de compartilhamento como JPG 1200x630 com site_fetch.
6. Pequenos detalhes que custam pontos: adicione um favicon SVG com <link rel="icon"> (caso contrário o navegador solicita /favicon.ico, o 404 aparece como erro no console e a pontuação de Boas Práticas cai). Escreva DOCTYPE em maiúsculas, não use atributos style e não deixe espaços em branco no final das linhas. Use &nbsp; em vez de espaços no texto visível dos links de telefone (a regra tel-non-breaking do html-validate). Os links no menu, no rodapé, no breadcrumb e nos títulos devem ter pelo menos 44 pixels de altura e largura. Não incorpore um iframe do Google Maps; o site não deve fazer requisições externas, então mostre o endereço e um link "Como chegar".
7. Nenhuma requisição pode sair do site: fontes, scripts, estilos e imagens ficam todos no seu próprio servidor. Não há um processador de formulários, então o formulário de contato é um formulário method="get" apontando para https://wa.me/[número do WhatsApp] com um textarea pré-preenchido chamado "text"; não é preciso JavaScript.

Verificações (nesta ordem; só considere concluído quando todas passarem):
1. Execute node build.mjs com site_run_command e depois node seo-check.mjs: 0 erros, 0 avisos. Um aviso de conteúdo duplicado significa que duas páginas não são diferentes o suficiente; reescreva-as.
2. node design-check.mjs: 0 erros. Se você escolheu um estilo sem movimento, relate o aviso de "sem movimento" como uma decisão deliberada, com o motivo.
3. _kaynak/node_modules/.bin/html-validate em todos os arquivos HTML: 0 erros. Coloque uma linha _kaynak/ em um arquivo .htmlvalidateignore na raiz do site para que as dependências não sejam analisadas.
4. Veja todas as páginas com site_preview em view="mobile", view="desktop" e também em larguras de 360 e 768. Corrija rolagem horizontal, títulos que transbordam, botões apertados ou texto ilegível e veja novamente.
5. Meça todas as páginas com core_web_vitals em strategy="mobile" e strategy="desktop", e obtenha as pontuações de acessibilidade, boas práticas e SEO com seo_audit. A meta no mobile é 100 em acessibilidade, boas práticas e SEO e pelo menos 95 em desempenho; no desktop, pelo menos 95 nas quatro. Em uma página que não atingir a meta, execute core_web_vitals com resources=true, encontre o elemento LCP e qualquer imagem grande demais, corrija e repita seo_audit com runs=2, porque uma única execução de laboratório pode oscilar.
6. As requisições de rede não devem conter nenhum endereço fora do domínio do próprio site.

Após publicar: envie o sitemap.xml com gsc_submit_sitemap e verifique a página inicial e as três páginas mais importantes com gsc_inspect_urls. Nenhuma ferramenta consegue clicar em "Solicitar indexação"; liste o que preciso solicitar manualmente no Search Console.

Termine com este relatório: a lista de páginas com as pontuações de mobile e desktop por página em uma tabela (desempenho, acessibilidade, boas práticas, SEO, LCP, CLS), o resultado de cada verificação, as correções que você fez e as informações que ainda precisa de mim. Se alguma meta não foi atingida, diga isso claramente em vez de considerar concluído.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um site de clínica odontológica ou estética em conformidade com a regulamentação de publicidade em saúde da Turquia, com dados do médico, aviso legal e caminho de agendamento

Cria um site rápido e com várias páginas para uma clínica odontológica ou estética no seu servidor de hospedagem. Aplica item por item as proibições da regulamentação, adiciona o aviso legal e os dados do médico a todas as páginas e verifica o texto e o JSON-LD com um script de varredura.

Quando usarVocê está criando um novo site para sua clínica, ou adequando seu site atual à regulamentação, sem abrir mão da velocidade nem da visibilidade nas buscas.

Crie do zero um novo site para a minha clínica no meu servidor de hospedagem [nome do servidor]. Detalhes:
1. Nome registrado (licenciado): [nome licenciado], tipo: [policlínica odontológica / consultório particular / clínica de estética]
2. Gerente responsável: [gerente responsável], médico responsável pelo conteúdo: [médico responsável pelo conteúdo], editor do site: [editor do site]
3. Médicos com títulos, formação e áreas de atuação: [lista de médicos]
4. Tratamentos para os quais escrever páginas informativas, e o médico que prepara cada uma: [tratamentos]
5. Telefone: [telefone], WhatsApp: [WhatsApp], endereço: [endereço], horário de funcionamento: [horários]
6. Domínio: [domínio], preferência de cor: [preferência de cor], fotos reais: [onde estão as fotos, ou "nenhuma"]

Este site deve cumprir integralmente o Regulamento da Turquia sobre Atividades de Promoção e Informação em Serviços de Saúde (Diário Oficial de 12.11.2025, nº 33075). As regras:
1. Nada de avaliações de pacientes, mensagens de agradecimento, estrelas ou notas. Nada de aggregateRating nem review no JSON-LD também; o Google não aceita no markup uma nota que o próprio negócio atribui a si mesmo.
2. Nada de preços, descontos, campanhas, parcelamento, formas de pagamento ou frases como "consulta grátis". Nada de offers, price ou priceRange no JSON-LD.
3. Nada de promoção de produtos ou marcas: não cite marcas de implantes, alinhadores, restaurações ou aparelhos.
4. Nada de superioridade ou promessa de resultado: evite "o melhor", "líder", "garantido", "solução definitiva", "sem dor", "impecável", "100 por cento". Use "varia de pessoa para pessoa e fica claro após o exame".
5. Nada de números não verificáveis: nada de "15 anos de experiência", "5.000 pacientes" ou "milhares de implantes".
6. Títulos corretos: um dentista sem especialidade é "Dt.", um especialista é "Uzm. Dt."; "Dr." só é usado com doutorado. Uma policlínica indica um "mesul müdür" (gerente responsável), não um "médico-chefe".
7. Nada de fotos de pacientes, nem imagens de cirurgia ou de áreas íntimas. Imagens de antes e depois só podem ser publicadas com o consentimento escrito do paciente, no mesmo ambiente e com a mesma técnica, com a data do procedimento e a data em que a imagem foi feita; se eu não tiver isso, não use imagens de antes e depois. Se usar, adicione esta frase literalmente logo abaixo: "Her cerrahi veya girişimsel işlemde sonuçlar kişiden kişiye değişiklik gösterebilir. İşlem öncesinde hekiminizden detaylı görüş almanız önerilir." Coloque-a também nas páginas de procedimentos invasivos.
8. Um expediente institucional em todas as páginas: nome registrado, gerente responsável, médico responsável pelo conteúdo, editor do site e data da última atualização.
9. Conteúdo de turismo de saúde não pertence a este site; ele exige uma autorização própria e uma plataforma separada.

Para verificar essas regras automaticamente, escreva o uyum-check.mjs na raiz do site. Ele varre o texto visível e o texto alternativo das imagens de cada página, separadamente dos blocos JSON-LD: expressões de avaliação e nota; números com TL, ₺; as palavras preço, valor, desconto, campanha, parcela, grátis, melhor, garantia, sem dor, solução definitiva; nomes de marcas; números como "15+ anos" ou "5000 pacientes"; "Dr." e "médico-chefe"; "antes e depois"; turismo de saúde; e aggregateRating, review, offers, price no JSON-LD. Ele também verifica os cinco campos do expediente em todas as páginas, lastReviewed e reviewedBy nas páginas de tratamento, e a frase de aviso nas páginas de procedimentos invasivos. Marque as frases que explicam o regulamento (por exemplo "este site não exibe preços") com data-uyum="aciklama"; o script não as conta como erros, mas as lista para revisão manual. Encerre com código de saída 1 em caso de qualquer violação.

Depois confirme o servidor com list_servers e execute scaffold_site com style="clinic", primeiro com confirm=false e depois com confirm=true, após a minha aprovação. Leia site_design_guide e site_seo_guide. Escreva uma decisão editorial de design em _kaynak/ART.md e mostre-a para mim: uma fonte serifada refinada para títulos da Fontshare (por exemplo Zodiak) com uma fonte de texto calma (por exemplo Switzer), fundo creme, texto verde-escuro quase preto, um único destaque em azul-petróleo profundo e bastante espaço em branco. O elemento de assinatura é um cartão "médico que preparou esta página" ao lado de cada página de tratamento: o nome do médico com título, a área e a data da revisão médica. Se não houver foto do médico, não use foto de banco de imagens de uma pessoa; use um simples selo com as iniciais. Nenhum paciente pode aparecer nas fotos das instalações.

Páginas e schema:
1. Início: o que é a clínica, quantos médicos atuam em quais áreas, a abordagem "primeiro o exame, depois decidimos juntos", tratamentos, médicos, etapas do agendamento e 4 perguntas frequentes. Schema: WebPage, FAQPage. No grafo base, o tipo de negócio é Dentist (MedicalClinic para uma clínica estética).
2. Uma página de tratamentos e uma página informativa para cada tratamento: o primeiro parágrafo diz o que é o tratamento e para quem ele é considerado; depois para quem é indicado ou não, as etapas de avaliação, o curso do tratamento, riscos e precauções, cuidados posteriores e 3 perguntas frequentes. Schema: MedicalWebPage (about um MedicalProcedure, reviewedBy e author como o nó Person do médico, lastReviewed), FAQPage.
3. Nossos médicos: nome com título, especialidade, formação e áreas de atuação de cada um. Schema: um Person com @id para cada médico (honorificPrefix, jobTitle, worksFor #business, knowsAbout). O tipo Physician do schema.org descreve uma organização; não o use para uma pessoa.
4. Agendamento e contato: telefone, formulário de WhatsApp, endereço, horários, uma lista de "o que levar" e como chegar. Schema: ContactPage.
5. Uma página de expediente, privacidade e princípios de publicação, e uma página 404.

Nada de invenção: não escreva avaliações, notas, prêmios, certificados, números de clientes nem afirmações como "o melhor" que não sejam reais. Não acrescente ao schema nem ao texto horários de funcionamento, coordenadas, preços ou e-mail que eu não tenha informado; deixe o campo de fora e liste-o como ausente no relatório. Não use travessões longos nem slogans genéricos, e faça o primeiro parágrafo de cada página responder diretamente à pergunta daquela página.

SEO compartilhado: cada página recebe um title único de 48 a 60 caracteres, uma description de 145 a 158 caracteres, um único H1 e um canonical terminado em barra. Adicione a cada página o seu próprio nó WebPage e um BreadcrumbList, ligados ao grafo base por @id. No robots.txt escreva Allow: / para Googlebot, Bingbot, OAI-SearchBot, ChatGPT-User, GPTBot, Claude-SearchBot, Claude-User, ClaudeBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended e CCBot, explique a decisão em um comentário e anote o que mudar caso eu queira bloquear os crawlers de treinamento. O sitemap.xml traz datas lastmod reais. O llms.txt descreve o negócio com precisão em duas frases e lista o NAP e as páginas importantes com links.

Configuração técnica (o caminho padrão do kit não é usado neste site, pelos motivos abaixo):
1. Compile o Tailwind e elimine o CDN. O kit carrega o Tailwind pelo Play CDN, que compila no navegador, exibe um aviso no console e reduz o desempenho no celular. Escreva _kaynak/package.json com site_write_file, instale com site_run_command("cd _kaynak && npm i -D tailwindcss@3 html-validate", background=true) e aguarde com site_command_status. Em _kaynak/tailwind.config.js defina content como "./*.html", "./**/*.html", "!./_kaynak/**" e "./_kaynak/chrome.mjs". Mova as regras @font-face, as linhas @tailwind e o anel de foco, o skip link e a proteção contra overflow do app.css do kit para _kaynak/site.css. Gere a saída em assets/app.css, porque o design-check.mjs procura as fontes nesse arquivo, e adicione ?v=<hash do conteúdo> ao link em todas as páginas para que o cache de borda nunca sirva o arquivo antigo.
2. Hospede as fontes você mesmo. Leia a URL do CSS das famílias da Fontshare que escolheu (api.fontshare.com/v2/css?f[]=...) com site_read_url, baixe os arquivos woff2 com site_fetch para assets/fonts/ e declare-os com @font-face e font-display: swap. Faça preload de cada peso usado acima da dobra com <link rel="preload" as="font" type="font/woff2" crossorigin>, no máximo três arquivos. Se pular isso, a troca de fonte desloca o layout; na demonstração, o CLS no desktop foi 0,078 por esse motivo e caiu para 0 com o preload.
3. Torne o menu e o rodapé HTML estático. Os componentes <site-nav> e <site-footer> do kit rodam em JavaScript, e a maioria dos crawlers de IA nunca vê o menu, o endereço nem o telefone. Remova os scripts chrome.js e motion.js de todas as páginas. Em _kaynak/chrome.mjs escreva duas funções que montem o HTML do cabeçalho e do rodapé a partir de assets/site.config.js; construa o menu mobile sem JavaScript usando <details> e <summary>, e marque a página atual com aria-current="page". Escreva na raiz do site o build.mjs que, nesta ordem, executa node seo-stamp.mjs, reaplica em todas as páginas tudo o que está entre  e  (e o mesmo para o rodapé), compila o Tailwind e atualiza o hash no link do CSS. Após cada alteração, execute apenas site_run_command("node build.mjs").
4. Sem animação. Não carregue GSAP, Lenis, Swiper nem qualquer script de animação; o briefing é um site informativo, calmo e legível.
5. Reduza as imagens. Baixe cada foto com site_fetch em arquivos separados usando resize="480x", "800x", "1200x", "1600x", image_format="webp" e qualidade entre 60 e 68. Dê a cada <img> srcset, sizes, e width e height que correspondam à proporção real; se recortar, adicione uma classe de proporção como aspect-[4/3] com object-cover, senão o layout se desloca quando a imagem carrega. A imagem da primeira tela recebe fetchpriority="high" e não é lazy; todas as outras recebem loading="lazy". Baixe a imagem de compartilhamento como um JPG 1200x630 com site_fetch.
6. Pequenos detalhes que custam pontos: adicione um favicon SVG com <link rel="icon"> (caso contrário o navegador solicita /favicon.ico, o 404 aparece como erro no console e a pontuação de Boas Práticas cai). Escreva DOCTYPE em maiúsculas, não use atributos style e não deixe espaços no fim das linhas. Use &nbsp; em vez de espaços no texto visível dos links de telefone (regra tel-non-breaking do html-validate). Links no menu, rodapé, breadcrumb e títulos devem ter pelo menos 44 pixels de altura e largura. Não incorpore um iframe do Google Maps; o site não deve fazer nenhuma requisição externa, então mostre o endereço e um link "Como chegar".
7. Nenhuma requisição pode sair do site: fontes, scripts, estilos e imagens ficam todos no seu próprio servidor. Não há processador de formulário, então o formulário de contato é um formulário method="get" apontando para https://wa.me/[número do WhatsApp] com um textarea pré-preenchido chamado "text"; nenhum JavaScript é necessário.

Verificações (nesta ordem; não diga que terminou até que todas passem):
1. Execute node build.mjs com site_run_command e depois node seo-check.mjs: 0 erros, 0 avisos. Um aviso de conteúdo duplicado significa que duas páginas não são diferentes o bastante; reescreva-as.
2. node design-check.mjs: 0 erros. Se você escolheu um estilo sem animação, informe o aviso de "sem animação" como uma decisão deliberada, com o motivo.
3. _kaynak/node_modules/.bin/html-validate em todos os arquivos HTML: 0 erros. Coloque uma linha _kaynak/ em um arquivo .htmlvalidateignore na raiz do site para que as dependências não sejam analisadas.
4. node uyum-check.mjs: 0 violações. Leia todas as frases explicativas da lista de revisão manual e confirme que elas explicam, e não promovem.
5. Veja todas as páginas com site_preview em view="mobile", view="desktop", e também em 360 e 768 de largura. Corrija rolagem horizontal, títulos que transbordam, botões apertados ou texto ilegível e confira de novo.
6. Meça todas as páginas com core_web_vitals em strategy="mobile" e strategy="desktop", e obtenha as pontuações de acessibilidade, boas práticas e SEO com seo_audit. A meta no mobile é 100 em acessibilidade, boas práticas e SEO e pelo menos 95 em desempenho; no desktop, pelo menos 95 nos quatro. Em uma página que não atingir a meta, execute core_web_vitals com resources=true, encontre o elemento LCP e qualquer imagem grande demais, corrija e repita o seo_audit com runs=2, porque uma única execução de laboratório pode oscilar.
7. As requisições de rede não podem conter nenhum endereço fora do domínio do próprio site.

Após a publicação: envie o sitemap.xml com gsc_submit_sitemap e verifique a página inicial e as três páginas mais importantes com gsc_inspect_urls. Nenhuma ferramenta consegue clicar em "Solicitar indexação"; liste o que eu preciso solicitar manualmente no Search Console.

No fim do relatório, adicione o checklist do regulamento: para cada uma das nove regras, "em conformidade" ou "não conforme" com a evidência. Este trabalho não é aconselhamento jurídico; pergunte-me sobre qualquer frase da qual você não tenha certeza.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um site focado em ligação e WhatsApp para um negócio de serviços locais, com páginas de região reais e NAP igual ao do seu Business Profile

Cria um site rápido, com várias páginas e sem JavaScript, no seu servidor de hospedagem para um encanador, chaveiro ou serviço de ar-condicionado. Escreve uma página com conteúdo genuinamente local para cada região atendida e faz com que nome, endereço e telefone sejam exatamente iguais aos da sua ficha no Business Profile.

Quando usarSeus clientes entram em contato por telefone ou WhatsApp, você atende mais de uma região e quer aparecer para essas regiões nas buscas e nas respostas de IA.

Crie um site novo para o meu negócio do zero no meu servidor de hospedagem [nome do servidor]. Detalhes:
1. Nome do negócio: [nome do negócio], ramo: [encanador / chaveiro / serviço de ar-condicionado / outro]
2. Nome ou domínio no Business Profile: [nome no Business Profile]
3. Serviços (cada um terá sua própria página): [serviços]
4. Bairros/regiões que atendo e onde fica minha oficina: [regiões], [local da oficina]
5. Telefone: [telefone], WhatsApp: [WhatsApp], endereço: [endereço, ou "escondo meu endereço"], horário de funcionamento: [horários]
6. Domínio: [domínio], preferência de cor: [preferência de cor], fotos reais: [onde estão as fotos, ou "nenhuma"]
7. Trabalhos que não faço: [serviços não oferecidos]

Primeiro, leia a ficha [nome no Business Profile] com gbp_location_details. Compare em uma única tabela o nome, telefone, endereço, site, horário de funcionamento, categoria principal, serviços e link do mapa com o que passei a você. Onde houver diferença, pergunte qual está certo; não altere nada no Business Profile. No site, use o nome, o endereço e o telefone exatamente como estão escritos no Business Profile. Se a ficha esconde o endereço, não mostre endereço de rua no site e liste apenas as áreas atendidas. Pegue as coordenadas somente do pino do mapa na ficha, nunca as invente. Escolha o subtipo de LocalBusiness no schema a partir da categoria principal (Plumber, Locksmith, HVACBusiness, Electrician e assim por diante).

Depois, confirme o servidor com list_servers, chame scaffold_site com style="service" e confirm=false primeiro para mostrar o que será sobrescrito, e execute com confirm=true após a minha aprovação. Leia site_design_guide e site_seo_guide. Antes de escrever código, escreva a decisão de design em _kaynak/ART.md e mostre para mim: um layout minimalista suíço, uma fonte display grotesca pesada da Fontshare (por exemplo Cabinet Grotesk 800) com uma fonte de texto simples (por exemplo General Sans 400 e 600), fundo off-white, texto azul-marinho escuro, uma cor de destaque com contraste de pelo menos 4,5:1 com texto branco e um verde de WhatsApp separado. O elemento de assinatura é um par de botões grandes fixos na parte inferior da tela no celular: "Ligar agora" e "Enviar mensagem no WhatsApp".

Páginas e schema:
1. Início: a primeira tela diz em uma frase o que você faz e quais regiões atende, com botões de ligar e WhatsApp e horário de funcionamento. Depois, cards de serviços, cards de regiões, as etapas de um atendimento e um FAQ de 4 perguntas. Schema: WebPage, FAQPage.
2. Uma página de serviços e uma página por serviço: o primeiro parágrafo responde diretamente "o que você faz e como"; depois sintomas, as etapas no local, quando é emergência, como o preço é definido (sem inventar valores), 3 FAQs específicos da página, o autor e a data. Schema: Service (provider #business, areaServed as regiões), FAQPage.
3. Uma página de região para cada bairro/região. Elas NÃO podem ser cópias com o nome da cidade trocado. Cada uma traz os nomes dos bairros daquela região, as falhas mais frequentes que você encontra ali considerando o tipo de construção local (uma tabela cujas linhas mudam de região para região), uma nota sobre deslocamento e estacionamento, a distância da oficina, dois FAQs específicos daquela região e links para as outras áreas. Escreva pelo menos 300 palavras de texto original; se a verificação de duplicidade do seo-check encontrar mais de 50% de sobreposição entre duas páginas de região, reescreva-as. Não crie página para uma região que eu não atendo de verdade. Schema: AdministrativeArea (containedInPlace a província, containsPlace os bairros), Service, FAQPage.
4. Sobre: quem você é, como trabalha, com quais equipamentos e quais serviços você não aceita. Schema: AboutPage, e Person se eu informar um nome real.
5. Contato: NAP, horários, um link "Como chegar" e o formulário de WhatsApp. Schema: ContactPage com mainEntity #business.
6. Uma página de aviso de privacidade e uma página 404.

Sem invenção: não escreva avaliações, notas, prêmios, certificados, número de clientes nem afirmações como "o melhor" que não sejam reais. Não adicione ao schema ou ao texto horários, coordenadas, preços ou e-mail que eu não informei; deixe o campo de fora e liste-o como faltante no relatório. Não use travessões longos nem slogans genéricos, e faça o primeiro parágrafo de cada página responder diretamente à pergunta daquela página.

Configuração técnica (o caminho padrão do kit não é usado neste site, pelos motivos abaixo):
1. Compile o Tailwind e elimine o CDN. O kit carrega o Tailwind pelo Play CDN, que compila no navegador, mostra um aviso no console e reduz o desempenho no celular. Escreva _kaynak/package.json com site_write_file, instale com site_run_command("cd _kaynak && npm i -D tailwindcss@3 html-validate", background=true) e aguarde com site_command_status. Em _kaynak/tailwind.config.js defina content como "./*.html", "./**/*.html", "!./_kaynak/**" e "./_kaynak/chrome.mjs". Mova as regras @font-face, as linhas @tailwind e o anel de foco, o skip link e a proteção contra overflow do app.css do kit para _kaynak/site.css. Gere a saída em assets/app.css, porque o design-check.mjs procura as fontes nesse arquivo, e adicione ?v=<hash do conteúdo> ao link em todas as páginas para que o cache de borda nunca sirva o arquivo antigo.
2. Hospede as fontes você mesmo. Leia a URL de CSS das famílias da Fontshare que você escolheu (api.fontshare.com/v2/css?f[]=...) com site_read_url, baixe os arquivos woff2 com site_fetch para assets/fonts/ e declare-os com @font-face e font-display: swap. Faça preload de cada peso usado acima da dobra com <link rel="preload" as="font" type="font/woff2" crossorigin>, no máximo três arquivos. Se pular isso, a troca de fontes desloca o layout; na demonstração, o CLS no desktop foi 0,078 por esse motivo e caiu para 0 com o preload.
3. Torne o menu e o rodapé HTML estático. Os componentes <site-nav> e <site-footer> do kit rodam com JavaScript, e a maioria dos rastreadores de IA nunca vê o menu, o endereço nem o telefone. Remova os scripts chrome.js e motion.js de todas as páginas. Em _kaynak/chrome.mjs escreva duas funções que montam o HTML do cabeçalho e do rodapé a partir de assets/site.config.js; construa o menu mobile sem JavaScript usando <details> e <summary>, e marque a página atual com aria-current="page". Escreva build.mjs na raiz do site que, em ordem, executa node seo-stamp.mjs, reaplica tudo entre  e  (e o mesmo para o rodapé) em cada página, compila o Tailwind e atualiza o hash no link do CSS. Após cada alteração, execute apenas site_run_command("node build.mjs").
4. Sem animação. Não carregue GSAP, Lenis, Swiper nem qualquer script de animação neste site; os visitantes chegam pelo celular para ligar ou enviar mensagem rapidamente.
5. Reduza as imagens. Baixe cada foto com site_fetch em arquivos separados usando resize="480x", "800x", "1200x", "1600x", image_format="webp" e qualidade entre 60 e 68. Dê a cada <img> srcset, sizes, e width e height que correspondam à proporção real; se você recortar, adicione uma classe de proporção como aspect-[4/3] com object-cover, caso contrário o layout se desloca quando a imagem carrega. A imagem da primeira tela recebe fetchpriority="high" e não é lazy; todas as outras recebem loading="lazy". Baixe a imagem de compartilhamento como JPG 1200x630 com site_fetch.
6. Pequenos detalhes que custam pontos: adicione um favicon SVG com <link rel="icon"> (senão o navegador solicita /favicon.ico, o 404 aparece como erro no console e a nota de Boas práticas cai). Escreva DOCTYPE em maiúsculas, não use atributos style e não deixe espaços no final das linhas. Use &nbsp; em vez de espaços no texto visível dos links de telefone (regra tel-non-breaking do html-validate). Links no menu, rodapé, breadcrumb e títulos devem ter pelo menos 44 pixels de altura e largura. Não incorpore um iframe do Google Maps; o site não deve fazer requisições externas, então mostre o endereço e um link "Como chegar".
7. Nenhuma requisição pode sair do site: fontes, scripts, estilos e imagens ficam todos no seu próprio servidor. Não há manipulador de formulário, então o formulário de contato é um formulário method="get" apontando para https://wa.me/[número do WhatsApp] com uma textarea pré-preenchida chamada "text"; não é necessário JavaScript.

Critérios de aprovação (nesta ordem; não diga que terminou até que todos passem):
1. Execute node build.mjs com site_run_command e depois node seo-check.mjs: 0 erros, 0 avisos. Um aviso de conteúdo duplicado significa que duas páginas não são diferentes o bastante; reescreva-as.
2. node design-check.mjs: 0 erros. Se você escolheu um estilo sem animação, informe o aviso de "sem animação" como uma decisão deliberada, com o motivo.
3. _kaynak/node_modules/.bin/html-validate em todos os arquivos HTML: 0 erros. Coloque uma linha _kaynak/ em um arquivo .htmlvalidateignore na raiz do site para que as dependências não sejam analisadas.
4. Verificação do NAP: mostre em uma tabela que o nome, o endereço e o telefone no site correspondem, letra por letra, à saída de gbp_location_details.
5. Veja cada página com site_preview em view="mobile", view="desktop" e também em larguras de 360 e 768. Corrija rolagem horizontal, títulos que transbordam, botões apertados ou texto ilegível e confira de novo.
6. Meça cada página com core_web_vitals em strategy="mobile" e strategy="desktop", e obtenha as notas de acessibilidade, boas práticas e SEO com seo_audit. A meta no mobile é 100 em acessibilidade, boas práticas e SEO e pelo menos 95 em desempenho; no desktop, pelo menos 95 nos quatro. Em uma página que não atingir a meta, execute core_web_vitals com resources=true, encontre o elemento LCP e qualquer imagem grande demais, corrija e repita seo_audit com runs=2, pois uma única execução de laboratório pode oscilar.
7. As requisições de rede não devem conter nenhum endereço fora do domínio do próprio site.

Termine com este relatório: a lista de páginas com as notas de mobile e desktop por página em uma tabela (desempenho, acessibilidade, boas práticas, SEO, LCP, CLS), o resultado de cada critério, as correções que você fez e as informações que ainda precisa de mim. Se alguma meta não foi atingida, diga isso claramente em vez de dizer que terminou.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Meça meu site hospedado página por página, passe por todas as verificações de qualidade e relate o antes e o depois

Mede um site estático ativo hospedado na Opus Growth sem alterá-lo, corrige os problemas por ordem de prioridade e repete as mesmas medições. Velocidade, acessibilidade, SEO, preparo para a busca com IA e layout mobile acabam em uma única tabela de antes e depois.

Quando usarQuando você não tem certeza de que o seu site hospedado na Opus Growth é rápido, funciona em celulares e pode ser encontrado por mecanismos de busca e de IA, e quer tudo corrigido com comprovação.

Meu site [endereço do site] está no ar na minha hospedagem da Opus Growth. O nome do servidor é [nome do servidor] e, se for um site adicional, a chave dele é [chave do site ou "site principal"]. Quero que você leve este site ao mais alto padrão, passando todas as páginas por verificações mensuráveis. Primeiro meça sem alterar nada, depois corrija os problemas por ordem de prioridade e, por fim, meça de novo da mesma forma. Não dê o trabalho por concluído até que os critérios abaixo sejam atendidos.

Dados da empresa, com "nenhum" onde eu não souber: [nome da empresa], [setor], [serviços], [telefone], [endereço], [área de atendimento], [horário de funcionamento], [e-mail], [onde estão as fotos reais].

1. Preparação. Leia os guias com site_design_guide e site_seo_guide. Liste os arquivos com site_list_files e a versão atual com site_versions, e anote-a como ponto de restauração. Liste as páginas publicadas, deixando de fora a página 404. Não chame scaffold_site, porque ele sobrescreve o index.html e a pasta assets existentes.
2. Medição antes, sem alterar nada:
   1. Para cada página, obtenha com core_web_vitals a nota de desempenho, o LCP, o CLS e o TBT no mobile e no desktop.
   2. Para a página inicial e [página de serviço mais importante], use seo_audit para listar, elemento por elemento, as falhas de acessibilidade, SEO e boas práticas no mobile. Esta ferramenta usa créditos, então me diga primeiro quantas chamadas você fará.
   3. Com site_run_command, execute `node seo-check.mjs`, `node design-check.mjs` e `npx --yes html-validate "**/*.html"` na raiz do site. Se as ferramentas do kit não estiverem na raiz, use seo_technical_audit no lugar dessas três e informe isso no relatório.
   4. Abra cada página com site_preview em 360, 390, 768 e 1440 pixels de largura. Procure rolagem horizontal, títulos que transbordam, elementos sobrepostos e áreas de toque menores que 44 pixels.
   5. Leia a página inicial com site_read_url e text=true. Diga se um navegador que não executa JavaScript enxerga o menu, os links internos, o telefone e o endereço. Com a mesma ferramenta, verifique se robots.txt, sitemap.xml e llms.txt retornam 200.
   6. Marque esta lista para a busca com IA: o robots.txt está aberto para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot e CCBot; o sitemap.xml traz datas lastmod reais; o llms.txt dá um resumo curto e preciso do site e das páginas principais; cada página traz JSON-LD ligado em um único grafo @id (Organization, o subtipo correto de LocalBusiness, WebSite, WebPage, BreadcrumbList em todas as páginas exceto a inicial, FAQPage somente onde houver perguntas reais exibidas); a página de serviço responde à pergunta diretamente no primeiro parágrafo; existem uma data visível de última atualização e as informações da empresa.
   Coloque tudo isso em uma tabela de "antes" por página e dispositivo.
3. Plano de correção. Ordene os achados assim, mostre arquivo por arquivo o que vai mudar e aguarde minha aprovação:
   1. Acesso: links internos quebrados, endereços que retornam 404, canonicals errados, bloqueios no robots.txt, noindex não intencional.
   2. Conteúdo: marcadores não preenchidos, títulos e descrições ausentes ou duplicados, mais ou menos de um h1, corpo com menos de 150 palavras. Nunca invente nada; não escreva horários, coordenadas, avaliações, preços, depoimentos, prêmios ou números de clientes que eu não tenha informado, pergunte-me.
   3. Acessibilidade: contraste, níveis de título pulados, imagens sem texto alternativo, áreas de toque com menos de 44 pixels. O rodapé padrão do kit usa títulos de coluna em cinza claro que não passam no contraste e são elementos h4 que quebram a ordem dos títulos; reescreva-os como parágrafos normais em texto cinza escuro.
   4. Menu e rodapé: `<site-nav>` e `<site-footer>` são gerados por JavaScript, então navegadores que não o executam nunca veem o menu nem os dados de contato, e a página se desloca quando o menu carrega. Escreva um pequeno script `chrome-stamp.mjs` que os imprima como HTML estático em todas as páginas: ele lê o site.config.js como o seo-stamp.mjs faz, reescreve a área entre `` e `` (chrome:footer para o rodapé) a cada execução, monta o menu mobile com `<details>` e sem JavaScript, define aria-current na página atual, mantém todos os links com pelo menos 44 pixels de altura e imprime o nome, o endereço e o telefone no rodapé. Continue gerenciando o menu apenas no site.config.js.
   5. Validade do HTML: `<!DOCTYPE html>` em maiúsculas, sem atributos style inline, um type em cada input, `&nbsp;` no lugar de espaços em um telefone visível (o html-validate reporta isso como tel-non-breaking), width e height em cada imagem.
   6. Schema e arquivos de AEO: preencha as lacunas da lista de AEO acima. Coloque o JSON-LD específico de cada página no final do body. Reaplique o grafo base com `node seo-stamp.mjs`. Se um endereço precisar mudar, faça um redirecionamento 301 do antigo com site_redirects; nunca use meta refresh.
   7. Desempenho: troque o Tailwind Play CDN por CSS compilado e minificado, hospede as fontes você mesmo, gere novamente as imagens em WebP e AVIF com srcset, remova scripts não usados e confira os cabeçalhos de cache com site_headers. Nenhuma requisição pode sair da origem do próprio site, inclusive o favicon.
4. Aplicação após minha aprovação. Depois de cada alteração, execute novamente `node seo-stamp.mjs`, `node chrome-stamp.mjs` e a build do CSS, nessa ordem. Se algo quebrar, volte à versão anotada com site_restore.
5. Medição depois: repita todas as medições da etapa 2 nas mesmas páginas e dispositivos. Use runs=2 no seo_audit, porque os resultados de laboratório variam de uma execução para outra. Critérios: em todas as páginas, desempenho mobile de pelo menos 95 e acessibilidade, boas práticas e SEO de 100; no desktop, os quatro de pelo menos 95; seo-check com 0 erros e 0 avisos; design-check com 0 erros (explique cada aviso); html-validate com 0 erros; nenhum overflow em nenhuma das quatro larguras. Corrija e meça de novo qualquer página que não atenda a algum critério.
6. Após a publicação: confirme com site_read_url que a página inicial no ar mudou, envie o sitemap.xml com gsc_submit_sitemap e mostre o status de indexação da página inicial com gsc_url_inspect. Minha propriedade do Search Console é [propriedade do Search Console, ou "nenhuma"].

Formate a saída assim: primeiro um resumo de duas frases. Depois uma tabela de antes e depois: página, dispositivo, desempenho, acessibilidade, boas práticas, SEO, LCP, CLS. Depois uma tabela de verificações: verificação, antes, depois. Depois a lista dos arquivos alterados e o motivo de cada alteração. Por fim, tudo o que não pôde ser corrigido ou está aguardando informações minhas.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Pacote de desempenho para site hospedado: Tailwind compilado, fontes próprias, WebP/AVIF e zero requisições de terceiros

Transforma o Tailwind do kit, que roda no navegador, em um único arquivo CSS minificado, leva fontes e imagens para o seu próprio servidor, remove scripts não usados e o menu em JavaScript e define os cabeçalhos de cache. A velocidade é medida antes e depois.

Quando usarQuando seu site criado com o kit de sites tem pontuação baixa de velocidade no celular, carrega fontes e bibliotecas de outros servidores ou precisa rodar sob uma política de segurança que bloqueia recursos de terceiros.

Meu site [endereço do site] no meu servidor Opus Growth (servidor [nome do servidor], chave do site [chave do site] se for um site adicional) foi criado com o kit de sites e está lento no celular. O kit carrega o Tailwind pelo Play CDN, que compila no navegador, as fontes pela Fontshare e as bibliotecas de animação pela jsDelivr, e gera o menu com JavaScript. Sem mudar a aparência do site, transforme tudo isso em arquivos compilados hospedados no meu próprio servidor. O objetivo: enquanto uma página carrega, o site não envia nenhuma requisição para fora do próprio domínio.

1. Linha de base. Anote a versão atual com site_versions. Execute core_web_vitals na página inicial e em [página mais pesada] no celular e no desktop com resources=true. Coloque em uma tabela a pontuação de desempenho, o LCP, o CLS, o total de requisições, o tamanho total e as requisições que saem do seu domínio. Liste os arquivos HTML com site_list_files e extraia de cada página todas as tags `<script>` e `<link>`.
2. Mostre-me o plano e aguarde minha aprovação. Liste todos os arquivos que serão alterados ou adicionados.
3. Compile o Tailwind. Mova a configuração inline `tailwind.config` das páginas para `_src/tailwind.config.js`; defina content como `["./*.html", "./**/*.html"]` e adicione qualquer arquivo JavaScript que ainda gere classes. Crie `_src/input.css` com as linhas `@tailwind base; @tailwind components; @tailwind utilities;` seguidas do conteúdo de assets/app.css. Execute `npx --yes tailwindcss@3 -c _src/tailwind.config.js -i _src/input.css -o assets/site.css --minify` com site_run_command. Dê ao arquivo um nome derivado do hash do conteúdo, por exemplo `assets/site.3f9a1c2b.css`, atualize o link em todas as páginas e apague o script do Play CDN e a configuração inline. Recompile depois de cada edição de HTML que altere classes, senão as novas classes ficam faltando no CSS.
4. Hospede as fontes você mesmo. Busque o CSS da Fontshare com uma requisição SEPARADA para cada família e peso, por exemplo `https://api.fontshare.com/v2/css?f[]=satoshi@400&display=swap`; vimos outras famílias voltarem quando várias famílias ou pesos eram pedidos de uma vez, então confira o nome da font-family retornada todas as vezes. Baixe os arquivos woff2 para `assets/fonts/`, escreva as regras `@font-face` com `font-display: swap` no topo de assets/app.css (o design-check procura tipografia distintiva ali) e faça o preload da fonte do corpo do texto e da fonte usada no título grande da primeira tela com `<link rel="preload" as="font" type="font/woff2" crossorigin>`. Apague os links `preconnect` e de stylesheet da Fontshare. Verifique se a licença da fonte permite hospedagem própria.
5. Regenere as imagens. Mova os arquivos JPG e PNG de origem para `_src/img/`. Instale o sharp fora da pasta do site: inicie `mkdir -p /data/_build && cd /data/_build && npm init -y && npm i sharp` com site_run_command e background=true, e acompanhe com site_command_status; se essa pasta não for gravável, explique o motivo. Com um script node, gere WebP (qualidade 72) e AVIF (qualidade 50) em larguras de 480, 800, 1200 e 1600 pixels para cada imagem. No HTML, envolva cada imagem em `<picture>`: um `<source type="image/avif" srcset sizes>` para AVIF, um `<img>` WebP como alternativa com seu próprio srcset e sizes, e a largura e a altura reais da imagem de origem. A imagem principal da primeira tela recebe `fetchpriority="high"` e não usa lazy; todas as outras recebem `loading="lazy" decoding="async"`. Escreva sizes de acordo com a largura que a imagem realmente ocupa.
6. Limpe os scripts. Se o site não tem animação, ou apenas ganchos decorativos como `data-reveal`, remova por completo GSAP, ScrollTrigger, SplitText, Lenis, Swiper, motion.js e o script inline que adiciona a classe `anim`, e apague as regras de Lenis e anim do app.css. Se a animação for realmente necessária, copie a biblioteca para `assets/vendor/`, carregue-a com `defer` apenas nas páginas que a usam e confirme que o conteúdo continua visível com `prefers-reduced-motion`. Transforme o menu e o rodapé em HTML estático com um script `chrome-stamp.mjs`: ele lê site.config.js, escreve entre os marcadores ``, `` e chrome:footer, monta o menu mobile com `<details>`, mantém os links com pelo menos 44 pixels de altura e usa parágrafos, não h4, para os títulos das colunas do rodapé. Depois remova chrome.js e a tag de script do site.config.js das páginas; site.config.js permanece apenas como arquivo de dados que os scripts leem.
7. Zere as requisições de terceiros. Com site_run_command, procure no HTML e no CSS valores de src e href que comecem com `https://`; mova para o site, ou remova, todo recurso fora do seu domínio, exceto links tel:, mailto: e wa.me. Coloque o favicon em `assets/img/` e faça o link em todas as páginas, senão o navegador solicita /favicon.ico e registra um 404 no console.
8. Cabeçalhos de cache. Execute site_headers com mode="list". Se nenhum arquivo em assets for substituído mantendo o mesmo nome (o nome do CSS leva um hash, as imagens ganham um novo nome quando mudam), mostre a prévia da linha `/assets/* Cache-Control: public, max-age=31536000, immutable` com confirm=false e aplique com confirm=true após a minha aprovação. Não peça Cache-Control para HTML; a plataforma já serve o HTML como no-cache.
9. Critérios e nova medição. Execute `node seo-stamp.mjs`, `node chrome-stamp.mjs`, o build do CSS, `node seo-check.mjs`, `node design-check.mjs` e `npx --yes html-validate "**/*.html"` nessa ordem e leve todos a zero erros. Verifique cada página com site_preview em larguras de 360, 390, 768 e 1440 pixels. Repita a medição core_web_vitals do passo 1 nas mesmas páginas e execute também seo_audit com runs=2 na página inicial. Se o desempenho no celular ficar abaixo de 95, encontre a causa nas listas de resources=true e corrija; a causa mais comum é o deslocamento de layout por causa de uma fonte de título sem preload.

Resultado: uma tabela de antes e depois (página, dispositivo, desempenho, LCP, CLS, número de requisições, total em KB, número de requisições de terceiros), a lista de arquivos adicionados e apagados, as linhas ativas de site_headers e uma breve nota sobre quais comandos reexecutar, e em que ordem, após a próxima edição. Se alguma etapa quebrar o site, volte à versão que você anotou com site_restore e me avise.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Criar um blog e hub de conhecimento com páginas de categoria e autor e schema completo no meu site hospedado

Gera um blog estático a partir de posts em markdown com o blog-build.mjs do kit e preenche suas lacunas com uma etapa de acabamento: páginas de categoria e autor, breadcrumbs de quatro níveis, posts anterior/próximo e relacionados, schema BlogPosting, CollectionPage e ProfilePage, RSS e sitemap.

Quando usarQuando você quer adicionar ao seu site hospedado no Opus Growth um blog ou hub de conhecimento bem estruturado, sem banco de dados, que mecanismos de busca e respostas de IA possam citar.

Quero que você crie um blog e hub de conhecimento no meu site [endereço do site] no meu servidor Opus Growth. Tema: [tema]. Categorias: [2 a 6 nomes de categorias]. Autor: [nome real do autor e uma breve biografia; se não houver, "publicar com o nome da empresa"]. Temas ou rascunhos dos primeiros posts: [temas ou textos de rascunho]. Fotos de capa reais: [localização, ou "nenhuma"].

1. Preparação. Leia a seção de blog do site_seo_guide. Liste os arquivos com site_list_files e anote a versão de restauração com site_versions. Se o site ainda usa o Tailwind Play CDN e fontes de terceiros, migre primeiro para CSS compilado e fontes auto-hospedadas, pois o blog-build.mjs copia o `<head>` do index.html para todas as páginas do blog. Pelo mesmo motivo, não deixe no `<head>` do index.html nenhum JSON-LD específico da página inicial nem preload de imagem; mova o schema da página inicial para o final do body.
2. Configuração. No bloco `blog` do site.config.js, escreva o título, uma descrição de 110 a 165 caracteres, uma introdução de pelo menos três frases para a página de listagem e, para cada categoria, um nome, uma descrição de 110 a 165 caracteres e uma introdução original de pelo menos dois parágrafos e, para o autor, um nome, um cargo, uma bio e uma meta description de 110 a 165 caracteres. Adicione a página de posts e as categorias ao menu. Se nenhum nome real de autor for informado, não invente um; publique sob o nome do negócio e não gere página de autor.
3. Posts. Escreva cada post como `blog/_posts/YYYY-MM-DD-slug.md`. Front matter: title (menos de 65 caracteres incluindo o sufixo da marca), description (110 a 165 caracteres), date, updated somente se você realmente atualizou, image, author, category (a chave da categoria) e tags. Corpo: o primeiro parágrafo responde à pergunta, depois subtítulos, passos numerados onde fizer sentido, 3 a 6 links internos e um FAQ final com duas ou três perguntas. IMPORTANTE: o blog-build.mjs eleva em um os níveis de título do markdown; `#` vira H2 e `##` vira H3. Se você começar com `##` como o guia mostra, a página salta de h1 para h3 e a pontuação de acessibilidade cai. Sem aberturas clichê ("Hoje em dia..."), sem estatísticas ou fontes inventadas, e não apresente como regra algo que depende do caso.
4. Imagens. Produza as imagens de capa em WebP e AVIF em 480, 800, 1200 e 1600 pixels com o método do pacote de performance e escreva `/assets/img/<name>-1200.webp` no campo image do front matter.
5. Geração. Execute `node seo-stamp.mjs` e depois `node blog-build.mjs` com site_run_command. O blog-build deixa as lacunas a seguir, então escreva um script `blog-extras.mjs` que rode logo depois dele:
   1. Nas páginas de post e de listagem: `<!DOCTYPE html>` em maiúsculas, um único charset e um único viewport (o blog-build os adiciona novamente além dos que copia do index.html), classes em vez de estilos inline, `<main id="main">`.
   2. Imagem de capa: o blog-build escreve `src` como endereço absoluto incluindo o domínio e não informa dimensões; substitua por um `<picture>` com caminho relativo à raiz, com srcset AVIF e WebP, width, height e `fetchpriority="high"`.
   3. Remova as tags de script site.config.js, chrome.js e motion.js que o blog-build adiciona (depois que você migrar para o menu estático, esses arquivos deixam de existir e o console mostra erros 404).
   4. Adicione a cada post um breadcrumb visível Início › Posts › Categoria › Post, as datas de publicação e atualização, um link para a categoria, uma caixa de autor com link para a página do autor, o post anterior e o próximo, e dois posts relacionados, dando preferência à mesma categoria. Adicione articleSection, dateModified e um nó de autor Person com url ao schema BlogPosting; estenda o BreadcrumbList para quatro níveis.
   5. Adicione og:image, o texto de introdução e os links das categorias à página de listagem.
   6. Gere uma página `/blog/kategori/<slug>/` para cada categoria: CollectionPage, um ItemList com numberOfItems e BreadcrumbList; mostre apenas a data e o título nos cards, porque repetir as descrições dos posts da página de listagem aciona o aviso de conteúdo duplicado do seo-check.
   7. Gere uma página `/blog/yazar/<slug>/` para o autor: ProfilePage e Person, com a bio e a lista de posts.
   8. Adicione as novas páginas ao sitemap.xml com lastmod. O blog-build gera o feed RSS; coloque um link para ele na página inicial.
6. Menu e CSS. Transforme as tags vazias `<site-nav>` e `<site-footer>` das páginas do blog no menu estático com `node chrome-stamp.mjs` e depois recompile o Tailwind, porque o blog-extras adiciona novas classes. Sempre que adicionar ou alterar um post, execute esta sequência desde o início: seo-stamp, blog-build, blog-extras, chrome-stamp, build do CSS.
7. Gates. `node seo-check.mjs` com 0 erros e 0 avisos (pelo menos 150 palavras em todas as páginas e parcela de duplicação entre páginas abaixo de 50 por cento), `node design-check.mjs` com 0 erros, `npx --yes html-validate "**/*.html"` com 0 erros. Adicione as categorias, os posts e o endereço do RSS ao llms.txt. Execute core_web_vitals no mobile e no desktop para a página inicial, a listagem, um post, uma categoria e a página do autor; seo_audit para um post. Abra a listagem e um post com site_preview nas larguras de 360, 390, 768 e 1440 pixels. Se a performance mobile estiver abaixo de 95, encontre a causa; se os títulos usarem uma fonte separada, faça preload dela também.
8. Após a publicação. Envie o sitemap.xml com gsc_submit_sitemap e verifique os posts e as páginas de categoria com gsc_inspect_urls. Minha propriedade do Search Console: [propriedade do Search Console, ou "nenhuma"].

Saída: a lista de endereços gerados (posts, listagem, categorias, autor, RSS, sitemap), uma tabela de schema por tipo de página, um mapa de links internos (qual página linka para qual), uma tabela de pontuações por página e dispositivo e a sequência de comandos de cinco etapas a seguir ao adicionar um novo post.

SiteAltera após sua aprovação

Leve um site WordPress com Elementor ao padrão de mobile, SEO e busca por IA

Corrige estouro no mobile, hierarquia de títulos, campos meta e schema nas páginas principais pelo próprio design do Elementor, ativa as configurações seguras de velocidade e verifica o robots.txt, o llms.txt e o acesso de crawlers de IA, preenchendo as lacunas após a sua aprovação.

Quando usarQuando o seu site WordPress com Elementor tem seções que estouram no celular, títulos bagunçados ou meta e schema ausentes, e você quer ter certeza de que os assistentes de IA conseguem lê-lo.

Meu site WordPress [endereço do site] foi criado com Elementor. Quero que minhas páginas principais funcionem perfeitamente em celulares e sejam legíveis para mecanismos de busca e assistentes de IA. Páginas: [endereços de até 10 páginas principais; se vazio, a página inicial, as páginas de serviços e a de contato]. Dados do negócio: [nome do negócio], [telefone], [endereço], [área de atendimento]; não invente nada que você não saiba.

1. Leia a configuração. Obtenha o tema e as versões com wordpress_site_info e, com wordpress_list_plugins, encontre o plugin de SEO (Yoast, Rank Math etc.), o plugin de cache, o Elementor e se o WPCode está instalado. Liste as páginas publicadas e seus ids com wordpress_list_posts.
2. Meça, sem alterar nada:
   1. Para cada página, desempenho mobile, LCP e CLS com core_web_vitals.
   2. Para a página inicial e [página de serviço mais importante], falhas de acessibilidade e SEO com seo_audit, especialmente falhas de área de toque, contraste, viewport e ordem dos títulos. Isso usa créditos; diga quantas chamadas serão feitas.
   3. Para cada página, site_read_url com outline=true: a contagem de h1 e a árvore de títulos de h1 a h6. Com text=true na mesma ferramenta: o texto, o telefone e o endereço que aparecem sem JavaScript.
   4. Para cada página, o título meta, a descrição, o canonical e o noindex com wordpress_seo.
   5. Leia o robots.txt e o llms.txt com site_read_url; leia a opção `blog_public` com wordpress_option e write=false (0 significa que o site está oculto dos mecanismos de busca).
   6. O estouro no mobile não pode ser medido pixel a pixel com essas ferramentas. Use os achados de viewport e área de toque do seo_audit e me dê uma lista curta de páginas para verificar em um celular com 360 pixels de largura.
   Mostre os achados em uma tabela por página.
3. Estouro no mobile e áreas de toque. Em uma página com problema, obtenha a lista de elementos com wordpress_page_design, abra o elemento suspeito com o parâmetro element e encontre uma largura fixa, um tamanho de fonte grande, uma margem negativa ou colunas que continuam lado a lado. Faça a correção com wordpress_edit_page_design apenas na configuração mobile: não adivinhe nomes de chaves, use a versão `_mobile` da chave que você vê nas configurações do elemento (por exemplo, typography_font_size_mobile). Altere um elemento por vez em cada página; se algo quebrar, reverta com restore=true.
4. Hierarquia de títulos. Cada página tem exatamente um h1 e nenhum nível de título pulado. Em um elemento de título do Elementor, altere o nível pelo campo `header_size` com wordpress_edit_page_design. Se o título vier de um arquivo de template do tema, use antes wordpress_theme_file com action="list" e "get", faça a prévia com mode="replace" e confirm=false, e aplique com confirm=true após a minha aprovação.
5. Meta e schema. Escreva títulos e descrições ausentes ou duplicados com wordpress_set_seo: títulos de 50 a 60 caracteres, descrições de 140 a 160, únicos em cada página. Leia o JSON-LD no HTML bruto da página com site_read_url; se o tipo de negócio no grafo do plugin de SEO estiver errado ou ausente, tente resolver primeiro nas configurações do plugin. Para um subtipo de LocalBusiness que o plugin não consegue gerar, ou um FAQPage para perguntas realmente exibidas na página, prepare um pequeno snippet PHP vinculado ao `wp_head` com wordpress_snippet; os snippets são criados inativos, então mostre o código e ative com toggle após a minha aprovação. Nunca invente horários, coordenadas, avaliações, preços ou depoimentos.
6. Velocidade. Leia as configurações atuais e os interruptores marcados como arriscados com wordpress_performance. Com wordpress_set_performance, proponha apenas os seguros: page_cache, browser_cache, minify_css, minify_js, lazy_load. Não ative combine, defer ou css_async em um site Elementor; se forem necessários, faça um de cada vez, com confirm_risky, olhando a página após cada um. Para a imagem principal da primeira tela, obtenha os tamanhos reais e o srcset com wordpress_media usando media_id e verifique se ela não está com lazy load e se é entregue no tamanho certo. Chame wordpress_purge_cache após cada alteração.
7. Crawlers de IA e robots.txt. O robots.txt não deve bloquear GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot ou CCBot, e deve apontar para o sitemap. Se não houver um arquivo robots.txt físico, o WordPress o gera; proponha as regras ausentes como um snippet PHP adicionado ao filtro `robots_txt` com wordpress_snippet. Se houver um arquivo físico, ou se o plugin de SEO gerenciar o robots.txt, diga-me para fazer a alteração lá. Se um plugin de segurança ou CDN bloquear esses crawlers, informe e diga claramente que você não consegue verificar isso com as ferramentas.
8. llms.txt. Se não houver nenhum, prepare um texto llms.txt com um resumo preciso do site em duas ou três frases, a lista de páginas principais e os dados de contato, e mostre para mim. Após a minha aprovação, instale um snippet PHP com wordpress_snippet que responda `/llms.txt` como `text/plain; charset=utf-8`, chame wordpress_purge_cache e confirme com site_read_url que retorna 200.
9. Menu. Com wordpress_menus, verifique se o menu principal e o menu do rodapé apontam para todas as páginas principais. Se faltar algum link, mostre sua proposta para wordpress_edit_menu.
10. Meça novamente. Repita as medições da etapa 2 nas mesmas páginas, usando runs=2 para seo_audit. Se a minha propriedade do Search Console for [propriedade do Search Console], verifique as páginas alteradas com gsc_inspect_urls.

Regras: antes de cada escrita, mostre o campo que será alterado, seu valor atual e o novo valor, e aguarde a minha aprovação. No Elementor, altere um elemento por vez. Resultado: uma tabela de antes e depois por página (desempenho mobile, LCP, CLS, contagem de h1, ordem dos títulos, tamanho do título meta e da descrição, tipos de schema), o estado do robots.txt e do llms.txt, a lista de alterações feitas e as páginas que preciso verificar manualmente.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um site de estúdio criativo no estilo Awwwards: tipografia gigante, marquee em rolagem e rastro de imagens no cursor

Cria um site de estúdio ou agência com títulos gigantes revelados linha por linha com SplitText, um marquee infinito, botões magnéticos e um rastro de imagens no cursor no desktop. Todo efeito entra depois da primeira renderização, é desativado em dispositivos touch e com redução de movimento, e o Lighthouse mobile é medido e mantido acima de 95.

Quando usarQuando você quer um site marcante e cheio de efeitos para o seu estúdio de design ou agência, sem abrir mão de velocidade, acessibilidade ou visibilidade nas buscas.

No meu servidor de hospedagem Opus Growth [nome do servidor], construa um site rápido de várias páginas para [nome do estúdio], com a cara dos sites de estúdios criativos exibidos na Awwwards. Estúdio: [o que projeta, para quem], cidade e bairro: [cidade, bairro], equipe: [número de pessoas, nomes e funções]. Serviços: [3 serviços]. Trabalhos: [para cada um, nome do cliente, tipo de trabalho, ano, uma frase sobre o desafio, uma sobre a solução, as partes entregues, link da imagem]. Contato: [e-mail], [telefone], [número de WhatsApp], [endereço]. Domínio: [domínio]. Preferência de cor: [cor ou "você escolhe"].

Páginas: home (/: hero com título gigante, marquee de serviços em rolagem, trabalhos selecionados, o que fazemos, processo, FAQ, call to action final), trabalhos (/isler/: o desafio, o que fizemos e o que entregamos em cada projeto), estúdio (/studyo/: equipe e regras de trabalho), contato (/iletisim/), privacidade e KVKK (/gizlilik/) e 404.html. Sem formulário na página de contato; informe e-mail, telefone e um link de WhatsApp com mensagem pré-preenchida, além de uma lista do que incluir na primeira mensagem. Sem números aprovados pelo cliente, descreva os resultados de forma qualitativa e não escreva porcentagens nem números de crescimento.

Estilo: estúdio criativo no estilo Awwwards. Fundo off-white, texto preto e uma única cor de destaque usada apenas como fundo (com texto preto sobre ela, contraste mínimo de 4,5:1). Uma fonte de exibição da Fontshare que se sustente em tamanhos muito grandes (por exemplo Clash Display 600) e uma fonte de texto serena (por exemplo Ranade). O título do hero preenche a tela com clamp entre 3.2rem e 12.5rem e espaçamento entre letras reduzido, sem estourar em 360 px. A lista de trabalhos é um conjunto de linhas com imagens grandes e títulos grandes em uma grade assimétrica que alterna colunas 7/5 e 5/7.

Regras de movimento (a parte mais difícil, siga-as à risca):
1. Bibliotecas: GSAP 3.13 core, ScrollTrigger, SplitText e Lenis, somente nas páginas home e trabalhos. Nenhum script nas páginas de estúdio, contato e privacidade. Não carregue Swiper, WebGL nem vídeo.
2. SplitText: o h1 acima da dobra é o elemento LCP, então nunca o inicie oculto nem deslizando para cima. O h1 começa visível em uma cor esmaecida que ainda passa no contraste AA e o SplitText leva suas linhas à cor plena uma a uma (type "lines", mask "lines", aria "auto"). Mantenha a entrada com linhas mascaradas deslizando para cima nos títulos h2 abaixo da dobra e execute-a com ScrollTrigger once:true. Divida o texto depois de document.fonts.ready para que as quebras de linha fiquem corretas.
3. Marquee infinito: escreva os nomes dos serviços uma única vez no HTML. Sem JS e com movimento reduzido, a lista aparece como um grupo estático com quebra de linha; reduza esse estado estático em celulares, porque na demo ele ocupava a tela como um muro de seis linhas. O JS duplica o grupo uma vez, marca a cópia com aria-hidden e move x em loop infinito; ele acelera brevemente com a velocidade da rolagem e para enquanto o marquee está fora da tela. Movimento com mais de cinco segundos exige um botão "Pausar" visível pela WCAG 2.2.2 (type="button", aria-pressed), exibido apenas enquanto o marquee realmente se move. O foco dentro do marquee também o pausa.
4. Botões magnéticos: somente em dispositivos que correspondam a `(hover: hover) and (pointer: fine)`, use gsap.quickTo para mover a transformação x e y em 30 a 40 por cento da distância do ponteiro ao centro do botão, com retorno elástico quando o ponteiro sai. A área clicável do botão não deve mudar.
5. Rastro de imagens do cursor: somente no desktop, sob a mesma condição de ponteiro preciso, na área do hero. O JS adiciona ao hero uma camada com aria-hidden, pointer-events:none e posicionada ABAIXO do título (z-index). As imagens do rastro não devem ser baixadas no carregamento da página; as miniaturas WebP de 280 px carregam no primeiro movimento do ponteiro. A cada 90 px de deslocamento do ponteiro, a próxima imagem do conjunto aparece no ponteiro, cresce a partir de pequena, depois desliza para baixo e desaparece; mova-a com transform, não com left/top.
6. Ative o Lenis somente em dispositivos `(pointer: fine)` e conduza-o a partir do gsap.ticker; dispositivos de toque mantêm a rolagem nativa. Em links internos da página, mova o foco para o destino depois de rolar.

Configuração e armadilhas conhecidas (cada uma custou pontos ou quebrou algo na medição da demo, não pule nenhuma):
1. Se já houver um site no ar no servidor, avise-me primeiro, porque a configuração sobrescreve index.html e a pasta assets. Mostre a prévia de scaffold_site com confirm=false e chame confirm=true após a minha aprovação. Depois leia site_design_guide e site_seo_guide. Antes de escrever código, coloque a direção de design (tipografia, cor, grade, elemento marcante, linguagem de movimento e as bibliotecas que NÃO serão carregadas) em um ART.md curto fora de assets e mostre-o para mim.
2. Compile o Tailwind, não o carregue pela CDN. Instale `npm i -D tailwindcss@3` com site_run_command e background=true, e acompanhe com site_command_status. Os caminhos de content em `tailwind.config.js` devem cobrir todos os arquivos HTML, todos os templates e todos os arquivos JS que escrevem classes. `_src/tw.css` contém uma linha `@import "../assets/app.css";` e as três linhas `@tailwind`; compile-o em um único arquivo com `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Remova o script cdn.tailwindcss.com e o tailwind.config inline das páginas e vincule apenas `/assets/site.css`. Recompile após cada alteração no HTML.
3. Hospede as fontes você mesmo. Primeiro verifique se a família da Fontshare escolhida tem as letras turcas (ş, ğ, ı, İ, ç, ö, ü): na demo, a Tanker não tinha o ı sem ponto e a Outfit não tinha ş, ğ nem İ, então essas letras cairiam em outra fonte nos títulos. Baixe o woff2 de cada peso separadamente com site_fetch para `assets/fonts/`, escreva as regras @font-face com `font-display: swap` em `assets/app.css` (o design-check procura a fonte personalizada ali) e confira o nome do font-family no CSS que você baixou. Faça preload das fontes de título e de texto usadas acima da dobra em todas as páginas com `<link rel="preload" as="font" type="font/woff2" crossorigin>`, antes da folha de estilo; não faça preload de mais de dois arquivos, porque o preload de um terceiro peso na demo deixou o LCP no celular 0,2 segundo mais longo. A maioria das fontes da Fontshare não tem o símbolo ₺, então escreva "TL" nos preços.
4. Faça o menu e o rodapé em HTML estático. Não carregue chrome.js nem site.config.js nas páginas. Escreva um pequeno `chrome-stamp.mjs` que leia a lista de navegação de site.config.js e carimbe `_src/header.tpl` e `_src/footer.tpl` entre os marcadores `` e `` em todas as páginas, adicionando aria-current="page" ao link ativo. Os templates não devem terminar em .html e devem usar marcadores como `[[NAV]]` em vez de `{{...}}`. Construa o menu mobile sem JS usando `<details>`. Mantenha o nome da organização, o endereço e o telefone como texto simples no rodapé, e faça todo alvo de toque ter pelo menos 44x44 px, incluindo os links do rodapé e do breadcrumb.
5. Converta as imagens ao baixá-las com site_fetch: grave a mesma foto com resize="480x", "800x" e "1200x", image_format="webp", quality=65 em arquivos separados. O site_fetch nunca recorta; quando uma foto do Unsplash precisar de outra proporção, baixe a versão recortada adicionando parâmetros como `?w=1600&h=1200&fit=crop` à URL. Dê a todo `<img>` srcset, sizes e width e height que correspondam à proporção real. A imagem principal acima da dobra recebe fetchpriority="high" e não é lazy; as demais recebem loading="lazy" decoding="async". Se a imagem principal preencher a tela no celular, sirva um recorte menor com `<picture>`.
6. Escreva a versão SVG do logo como favicon.svg com site_write_file e adicione `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` a todas as páginas. Sem favicon, o navegador registra um 404 e as Boas Práticas caem para 96.
7. Regras do validador de HTML: comece com um `<!DOCTYPE html>` em maiúsculas, use `&nbsp;` nos espaços do texto visível dos links tel:, nunca use o atributo style="", dê type="button" a todo botão e não coloque um `<details>` dentro de um `<figure>` depois do figcaption.
8. Baixe as bibliotecas de movimento (GSAP, ScrollTrigger, SplitText, Lenis) do jsdelivr para `assets/vendor/` com site_fetch, fixe a versão e carregue-as somente nas páginas home e trabalhos. Não use `<script defer>`; coloque um pequeno loader no final da página que espere o evento load, duas chamadas de requestAnimationFrame e depois requestIdleCallback, e acrescente os scripts em ordem com async=false. Um script de uma linha no `<head>` adiciona a classe `js` ao `<html>` e a classe `anim`, a menos que prefers-reduced-motion seja "reduce"; sem `anim`, o loader não baixa nada. Defina estados iniciais ocultos apenas sob `.anim` e adicione uma animação CSS como rede de segurança que revele todo elemento oculto após 2,5 segundos, caso a biblioteca nunca chegue. Em demos anteriores, bibliotecas com defer empurraram o LCP no celular para 3,2 segundos; com este loader as páginas mediram de 99 a 100. Dê o nome data-reveal ao atributo dos elementos revelados na rolagem; o design-check só reconhece movimento por esse nome.

SEO, AEO e GEO:
1. Use URLs em estilo de diretório com barra final (/isler/, /studyo/, /iletisim/, /gizlilik/). Preencha o bloco seo de site.config.js e execute `node seo-stamp.mjs`. Escreva o schema específico de cada página (home WebPage e FAQPage; trabalhos CollectionPage com um CreativeWork por projeto em hasPart; estúdio AboutPage com entradas Person para a equipe; contato ContactPage; BreadcrumbList nas páginas internas. Para um estúdio com escritório, businessType ProfessionalService em site.config.js) em blocos `<script type="application/ld+json">` separados e vincule-os ao grafo base por @id. Não aninhe o BreadcrumbList dentro de @graph; mantenha-o em seu próprio bloco, porque é a única forma de o seo-check enxergá-lo.
2. Mantenha os títulos em 60 caracteres ou menos (o seo-check marca como erro qualquer um acima de 65), as descrições entre 120 e 158 caracteres, um h1 por página e nenhum nível de título pulado (um h3 logo após o h1 derrubou a acessibilidade para 98). Toda página precisa de pelo menos 150 palavras de conteúdo principal; as páginas de contato e privacidade costumam ficar abaixo disso.
3. O primeiro parágrafo de cada página responde diretamente à pergunta da página. Escreva FAQs específicas de cada página com `<details>` e marque-as como FAQPage. Mostre a organização que publica e uma data de "Última atualização" em `<time>`.
4. No robots.txt, registre e justifique sua decisão para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot e CCBot, e aponte para o sitemap. Dê ao sitemap.xml datas lastmod reais. O llms.txt traz um resumo preciso do site em duas frases, os fatos principais e uma lista das páginas importantes.
5. Sem invenção: não escreva avaliações, notas, prêmios, números de clientes, certificados, horários de funcionamento, coordenadas nem preços sem me perguntar. Deixe totalmente de fora do schema qualquer campo que você não conheça.

Portões de verificação (em ordem; não diga "pronto" até que todos passem):
1. Com site_run_command, execute `node chrome-stamp.mjs`, o build do Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 erros, 0 avisos), `node design-check.mjs` (0 erros; justifique qualquer aviso restante) e `npx html-validate "**/*.html"` (0 erros).
2. Veja cada página com site_preview usando view="mobile" e view="desktop". O site_preview captura a página com o movimento desligado (reduced-motion); se faltar conteúdo nessa captura, o estado sem movimento está quebrado. Imagens lazy mais abaixo podem aparecer em branco na captura da página inteira; não conte isso como erro, mas confira os caminhos delas.
3. Execute core_web_vitals com strategy="mobile" e strategy="desktop" para cada página. Critério de aceitação: no celular, Performance de pelo menos 95 e Acessibilidade, Boas Práticas e SEO 100; no desktop, as quatro notas de pelo menos 95. Para uma página que não atinja, encontre o arquivo lento com resources=true, corrija e meça de novo. Depois execute seo_audit na página inicial com strategy="mobile" e runs=2. Nenhum endereço fora do seu próprio domínio pode permanecer na lista de requisições de rede.
4. Sem rolagem horizontal em 360, 390, 768 e 1440 px, alvos de toque de pelo menos 44 px e nenhum erro no console. O site também deve ficar impecável dentro de um quadro de 390x790 e de 1440x898, como nas páginas de prompts.

Verificação de movimento: o site_preview não consegue mostrar movimento, então diga-me o que observar no meu próprio navegador. No desktop, as linhas do título do hero devem escurecer uma após a outra, o marquee deve se mover, acelerar com a rolagem e parar com o botão Pausar, os botões devem se inclinar levemente em direção ao ponteiro, mover o ponteiro sobre o hero deve deixar imagens que aparecem e desaparecem atrás dele, e o texto deve ficar sempre acima das imagens. No celular não deve haver rastro nem efeito magnético, e a rolagem continua nativa. Com movimento reduzido ativado no sistema operacional, nada deve se mover e o marquee aparece como uma lista estática. O anel de foco deve ser visível em todo lugar ao navegar com Tab.

Depois de publicar: faça a prévia da regra `/assets/* Cache-Control: public, max-age=31536000, immutable` com site_headers e aplique-a após a minha aprovação; a partir daí, versione o nome do arquivo sempre que o CSS ou o JS mudar (site-v2.css e assim por diante). Envie o sitemap.xml com gsc_submit_sitemap e verifique a página inicial com gsc_url_inspect. Por fim, entregue-me: uma tabela de notas por página (página, quatro notas no celular, quatro notas no desktop, LCP, CLS), os resultados dos portões, o resultado das interações testadas em um navegador e a lista das correções aplicadas.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um site de portfólio com rolagem horizontal e páginas de projeto para arquiteto ou fotógrafo

Cria uma galeria de projetos fixa que se move para o lado conforme você rola a página para baixo no desktop, com imagens reveladas por clip-path e uma página de detalhes para cada projeto. Em celulares, sem JavaScript e com movimento reduzido, a galeria vira uma pilha vertical; funciona com o teclado e o Lighthouse no mobile é medido e mantido acima de 95.

Quando usarQuando você quer que seu escritório de arquitetura ou seu trabalho de fotografia seja exibido em imagens grandes, como numa caminhada por uma exposição, sem sacrificar os visitantes no celular nem a visibilidade nas buscas.

No meu servidor de hospedagem Opus Growth [nome do servidor], construa um site de portfólio com rolagem horizontal para [nome do escritório ou do fotógrafo]. O que eu faço: [arquitetura, design de interiores ou fotografia; que tipo de trabalho], cidade: [cidade, bairro], ano de fundação e equipe: [ano, número de pessoas, nome do fundador]. Projetos: [para cada um, nome, local, ano, status, área construída ou tipo de ensaio, resumo em uma frase, questão, abordagem, processo, materiais ou técnica, pelo menos dois links de fotos]. Trabalhos em andamento: [nome, local, ano, uma frase]. Registro profissional: [se houver]. Contato: [e-mail], [telefone], [número de WhatsApp], [endereço]. Domínio: [domínio].

Páginas: home (/: hero, galeria horizontal de projetos, abordagem, FAQ), uma página por projeto (/projeler/[nome-do-projeto]/: imagem em largura total, ficha técnica, questão, abordagem, processo, materiais, uma segunda imagem, link para o próximo projeto), escritório e contato (/ofis/, com a seção de contato na âncora #iletisim), privacidade e KVKK (/gizlilik/) e 404.html. Sem formulário; e-mail, telefone e um link de WhatsApp com mensagem pré-preenchida bastam. Se um projeto em andamento não tiver página de detalhes, não transforme o card dele em link.

Estilo: um portfólio calmo, com cara de galeria. Fundo cor de calcário, texto escuro, cantos retos e linhas finas; a cor de destaque aparece apenas no hover e no foco. Uma fonte display serifada da Fontshare (por exemplo Erode) e uma fonte de texto grotesca simples (por exemplo Archivo). No desktop, o hero ocupa a tela inteira, então a galeria começa abaixo da primeira dobra.

Regras de movimento (a parte mais difícil, siga ao pé da letra):
1. Bibliotecas: GSAP 3.13 core, ScrollTrigger e Lenis, na home e nas páginas de projeto. SplitText e Swiper NÃO são carregados; nenhum script nas páginas de escritório e de privacidade.
2. O HTML e o CSS padrão é uma pilha vertical: uma coluna no celular, uma grade de duas colunas no desktop. Sem JS, com movimento reduzido e no celular, a galeria continua assim.
3. Deixe o CSS, e não o JS, montar o layout horizontal: a partir de 768 px e quando a classe `.anim` estiver presente, a trilha é `display:flex`, `width:max-content` e `height:calc(100vh - altura do header)` desde a primeira renderização, e o wrapper rola sozinho com `overflow-x:auto`. Assim o layout não muda quando o JS chega (CLS 0), e se a biblioteca nunca chegar a galeria ainda pode ser rolada para os lados.
4. Com gsap.matchMedia, apenas para `(min-width: 768px)`, fixe o wrapper com ScrollTrigger, scrub 0.8, um end igual ao excedente da trilha ("+=" + (track.scrollWidth - innerWidth)) e invalidateOnRefresh ativado; adicione uma classe que dê `overflow:hidden` ao wrapper. Uma linha fina de progresso avança com scaleX.
5. Revelação das imagens: as imagens da galeria se abrem da esquerda para a direita com containerAnimation, de clip-path `inset(0 100% 0 0)` para `inset(0)`. Nunca esconda o painel visível na primeira dobra nem a imagem do hero. No celular e nas páginas de projeto, apenas as imagens que estão abaixo da tela no carregamento se abrem para cima com clip-path.
6. Teclado: quando o Tab chega a um card que está fora da tela na trilha, o navegador rola o wrapper internamente e o card desaparece. No focusin, zere o scrollLeft do wrapper e role a página até a posição vertical em que o card entra na tela (scrollTrigger.start + (end - start) * deslocamento à esquerda do card / excedente total). Sem esse passo, o terceiro card alcançado com Tab ficou fora da tela na demo.
7. Ative o Lenis apenas em dispositivos `(pointer: fine)` e conecte-o ao ScrollTrigger.update; em links internos como #projeler, mova o foco para o destino após a rolagem.

Configuração e armadilhas conhecidas (cada uma custou pontos ou quebrou algo na medição da demo, não pule nenhuma):
1. Se já houver um site no ar no servidor, avise-me primeiro, porque a configuração sobrescreve index.html e a pasta assets. Mostre uma prévia do scaffold_site com confirm=false e chame com confirm=true após a minha aprovação. Depois leia site_design_guide e site_seo_guide. Antes de escrever código, coloque a direção de design (tipografia, cor, grade, elemento marcante, linguagem de movimento e as bibliotecas que NÃO serão carregadas) em um ART.md curto fora de assets e mostre para mim.
2. Compile o Tailwind, não carregue pelo CDN. Instale `npm i -D tailwindcss@3` com site_run_command e background=true, e acompanhe com site_command_status. Os caminhos de content em `tailwind.config.js` devem cobrir todos os arquivos HTML, todos os templates e todos os arquivos JS que escrevem classes. `_src/tw.css` contém uma linha `@import "../assets/app.css";` e as três linhas `@tailwind`; compile-o em um único arquivo com `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Remova o script cdn.tailwindcss.com e o tailwind.config inline das páginas e vincule apenas `/assets/site.css`. Recompile após cada alteração no HTML.
3. Hospede as fontes você mesmo. Primeiro verifique se a família da Fontshare escolhida tem as letras turcas (ş, ğ, ı, İ, ç, ö, ü): na demo a Tanker não tinha o ı sem ponto e a Outfit não tinha ş, ğ nem İ, então essas letras cairiam em outra fonte nos títulos. Baixe o woff2 de cada peso separadamente com site_fetch para `assets/fonts/`, escreva as regras @font-face com `font-display: swap` em `assets/app.css` (o design-check procura a fonte personalizada ali) e confira o nome do font-family no CSS que você baixou. Faça preload das fontes de título e de texto usadas acima da dobra em todas as páginas com `<link rel="preload" as="font" type="font/woff2" crossorigin>`, antes da folha de estilo; não faça preload de mais de dois arquivos, porque o preload de um terceiro peso na demo aumentou o LCP no celular em 0,2 segundo. A maioria das fontes da Fontshare não tem o símbolo ₺, então escreva "TL" nos preços.
4. Faça o menu e o rodapé em HTML estático. Não carregue chrome.js nem site.config.js nas páginas. Escreva um pequeno `chrome-stamp.mjs` que leia a lista de navegação de site.config.js e carimbe `_src/header.tpl` e `_src/footer.tpl` entre os marcadores `` e `` em todas as páginas, adicionando aria-current="page" ao link ativo. Os templates não devem terminar em .html e devem usar placeholders como `[[NAV]]` em vez de `{{...}}`. Construa o menu mobile sem JS usando `<details>`. Mantenha o nome da organização, o endereço e o telefone como texto simples no rodapé, e faça todo alvo de toque ter pelo menos 44x44 px, incluindo os links do rodapé e do breadcrumb.
5. Converta as imagens enquanto as baixa com site_fetch: grave a mesma foto com resize="480x", "800x" e "1200x", image_format="webp", quality=65 em arquivos separados. O site_fetch nunca recorta; quando uma foto do Unsplash precisar de outra proporção, baixe a versão recortada adicionando parâmetros como `?w=1600&h=1200&fit=crop` à URL. Dê a todo `<img>` srcset, sizes e width e height compatíveis com a proporção real. A imagem principal acima da dobra recebe fetchpriority="high" e não é lazy; as demais recebem loading="lazy" decoding="async". Se a imagem principal ocupar a tela no celular, sirva um recorte menor com `<picture>`.
6. Escreva a versão SVG do logotipo como favicon.svg com site_write_file e adicione `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` a todas as páginas. Sem favicon, o navegador registra um 404 e Best Practices cai para 96.
7. Regras do validador de HTML: comece com `<!DOCTYPE html>` em maiúsculas, use `&nbsp;` nos espaços do texto visível dos links tel:, nunca use o atributo style="", dê type="button" a todo botão e não coloque um `<details>` dentro de uma `<figure>` depois do figcaption.
8. Baixe as bibliotecas de movimento (GSAP, ScrollTrigger, Lenis) do jsdelivr para `assets/vendor/` com site_fetch, fixe a versão e carregue-as apenas na home e nas páginas de projeto. Não use `<script defer>`; coloque um pequeno loader no final da página que espere o evento load, dois requestAnimationFrame e depois requestIdleCallback, e anexe os scripts em ordem com async=false. Um script de uma linha no `<head>` adiciona a classe `js` ao `<html>` e a classe `anim`, a menos que prefers-reduced-motion seja "reduce"; sem `anim` o loader não baixa nada. Defina os estados iniciais ocultos apenas sob `.anim` e adicione uma animação CSS de segurança que revele todos os elementos ocultos após 2,5 segundos, caso a biblioteca nunca chegue. Em demos anteriores, bibliotecas com defer levaram o LCP no celular a 3,2 segundos; com este loader as páginas mediram de 99 a 100. Dê o nome data-reveal ao atributo dos elementos revelados na rolagem; o design-check só reconhece movimento por esse nome.

SEO, AEO e GEO:
1. Use URLs em estilo de diretório com barra final (/projeler/[nome-do-projeto]/, /ofis/, /gizlilik/). Preencha o bloco seo de site.config.js e execute `node seo-stamp.mjs`. Escreva o schema específico de cada página (home: WebPage e FAQPage; cada página de projeto: WebPage com um CreativeWork como mainEntity, incluindo dateCreated, locationCreated e image; escritório: AboutPage com uma Person para o fundador; BreadcrumbList nas páginas internas. Para um estúdio de arquitetura ou fotografia com escritório, businessType ProfessionalService) em blocos `<script type="application/ld+json">` separados e vincule-os ao grafo base por @id. Não aninhe o BreadcrumbList dentro do @graph; mantenha-o em um bloco próprio, porque é a única forma de o seo-check enxergá-lo.
2. Mantenha os títulos com 60 caracteres ou menos (o seo-check marca como erro tudo acima de 65), as descrições entre 120 e 158 caracteres, um h1 por página e nenhum nível de título pulado (um h3 logo após o h1 derrubou a acessibilidade para 98). Toda página precisa de pelo menos 150 palavras de conteúdo principal; as páginas de contato e de privacidade costumam ficar abaixo disso.
3. O primeiro parágrafo de cada página responde diretamente à pergunta da página. Escreva FAQs específicas de cada página com `<details>` e marque-as como FAQPage. Mostre a organização responsável pela publicação e uma data de "Última atualização" em `<time>`.
4. No robots.txt, escreva e justifique sua decisão para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot e CCBot, e aponte para o sitemap. Dê ao sitemap.xml datas lastmod reais. O llms.txt traz um resumo preciso do site em duas frases, os fatos principais e uma lista das páginas importantes.
5. Sem invenções: não escreva avaliações, notas, prêmios, número de clientes, certificados, horários de funcionamento, coordenadas nem preços sem me perguntar. Deixe totalmente fora do schema qualquer campo que você não conheça.

Portões de qualidade (em ordem; não diga "pronto" até que todos passem):
1. Com site_run_command, execute `node chrome-stamp.mjs`, o build do Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 erros, 0 avisos), `node design-check.mjs` (0 erros; justifique qualquer aviso restante) e `npx html-validate "**/*.html"` (0 erros).
2. Veja cada página com site_preview usando view="mobile" e view="desktop". O site_preview captura a página com o movimento desligado (reduced-motion); se faltar conteúdo nessa captura, o estado sem movimento está quebrado. Imagens lazy mais abaixo podem aparecer em branco na captura da página inteira; não conte isso como erro, mas confira os caminhos delas.
3. Execute core_web_vitals com strategy="mobile" e strategy="desktop" para cada página. Critério de aceitação: no celular, Performance de pelo menos 95 e Accessibility, Best Practices e SEO 100; no desktop, as quatro de pelo menos 95. Para uma página que não atingir, encontre o arquivo lento com resources=true, corrija e meça de novo. Depois execute seo_audit na home com strategy="mobile" e runs=2. Nenhum endereço fora do seu próprio domínio pode restar na lista de requisições de rede.
4. Sem rolagem horizontal em 360, 390, 768 e 1440 px, alvos de toque de pelo menos 44 px e nenhum erro no console. O site também deve ficar impecável dentro de um frame de 390x790 e de um de 1440x898, como nas páginas de prompts.

Verificação de movimento: o site_preview não consegue mostrar movimento, então diga-me o que observar no meu próprio navegador. No desktop, a galeria deve ficar fixa no topo quando você chegar à seção Projetos, os cards devem fluir para a esquerda conforme você rola para baixo, as imagens devem se abrir da esquerda para a direita e a linha de progresso deve se preencher; depois do último card a página volta ao fluxo normal. Ao navegar entre os cards com Tab, o card em foco deve estar sempre na tela. No celular e com movimento reduzido ativado, a galeria é uma pilha de cards e nada fica fixo.

Depois de publicar: mostre uma prévia da regra `/assets/* Cache-Control: public, max-age=31536000, immutable` com site_headers e aplique-a após a minha aprovação; a partir daí, versione o nome do arquivo sempre que o CSS ou o JS mudar (site-v2.css e assim por diante). Envie o sitemap.xml com gsc_submit_sitemap e verifique a home com gsc_url_inspect. Por fim, entregue-me: uma tabela de notas por página (página, as quatro notas no celular, as quatro notas no desktop, LCP, CLS), os resultados dos portões, o resultado das interações que você testou em um navegador e a lista das correções aplicadas.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um site de lançamento de app mobile com um mockup de celular cuja tela muda conforme você rola a página

Cria um site para o seu app com uma moldura de celular que permanece fixa no desktop e mostra a tela do recurso que você está lendo, além de lista de recursos, tabela de preços, FAQ, botões das lojas e páginas de suporte e privacidade. As telas são desenhadas em HTML, nos celulares cada recurso aparece com a sua própria tela, e o Lighthouse mobile é medido e mantido acima de 95.

Quando usarQuando você quer um site de aterrissagem rápido e pesquisável, que explique seu aplicativo mobile melhor do que a página da loja, mesmo antes de as capturas de tela ficarem prontas.

No meu servidor de hospedagem do Opus Growth [nome do servidor], crie um site de apresentação (landing site) para o aplicativo móvel [nome do app]. App: [o que faz, para quem é], plataformas e versões mínimas: [versões do iOS e do Android]. Os quatro recursos principais e o que cada tela mostra: [recurso, descrição em uma frase, itens na tela]. Planos e preços: [nome do plano, preço, período, recursos incluídos, duração do teste; impostos incluídos ou não]. Links das lojas: [link da App Store], [link do Google Play]. Perguntas de suporte: [respostas reais sobre exclusão de conta, cancelamento, exportação de dados e assim por diante]. Empresa e contato: [nome da empresa], [endereço], [e-mail de suporte], [telefone]. Domínio: [domínio]. Capturas de tela reais: [links ou "nenhuma, desenhe-as em HTML"].

Páginas: início (/: hero, apresentação dos recursos conduzida pelo celular #ozellikler, quem usa, preços #fiyatlar, FAQ, chamada para download #indir), suporte (/destek/: perguntas frequentes e contato de suporte), privacidade e KVKK (/gizlilik/: cobrindo o app e o site; as lojas pedem a URL de uma política de privacidade) e 404.html. A seção de preços tem cards de planos e, abaixo deles, uma comparação em `<table>` real; não dê min-width à tabela, porque na demonstração uma largura mínima fixa empurrou colunas para fora da tela em celulares.

Estilo: uma landing page de app acolhedora e confiável. Fundo creme, uma cor de marca escura e um único destaque vibrante usado apenas como fundo. Uma fonte de exibição arredondada e amigável da Fontshare (por exemplo, Chillax) e uma fonte de texto legível (por exemplo, Manrope). Desenhe a moldura do celular em CSS (aspect-ratio 9/19, cantos arredondados, um notch) e construa as telas em HTML e CSS em vez de arquivos de imagem; os cards de tela são decoração com aria-hidden e o texto ao lado descreve o recurso. Para um app real, baixe os selos oficiais da Apple e do Google para o seu próprio servidor para os botões das lojas e siga as diretrizes deles; adicione a nota de marca registrada ao rodapé.

Regras de movimento (a parte mais difícil, siga-as à risca):
1. Bibliotecas: somente o núcleo do GSAP 3.13 e o ScrollTrigger, somente na página inicial. Lenis, SplitText, Swiper, Lottie e vídeo NÃO são carregados; nenhum script nas páginas de suporte e privacidade.
2. Cada seção de recurso traz no HTML o seu próprio celular pequeno e a sua tela. Em celulares, sem JS e com movimento reduzido, cada recurso aparece com a sua própria tela, empilhados (lado a lado em telas maiores); esse estado deve ser completo por si só.
3. A partir de 1024 px, quando o movimento é permitido, o JS copia as telas das seções para o único celular na coluna da direita, adiciona uma classe `has-phone` à seção e oculta os celulares pequenos. Não escreva as telas duas vezes no HTML. Como a seção de recursos fica abaixo da primeira dobra, essa mudança de classe não conta como mudança de layout; a demonstração mediu CLS 0.
4. Mantenha o celular no lugar com `position: sticky` em CSS (top: calc(50vh - metade da altura do celular)) em vez de um pin do ScrollTrigger. Nenhum pin-spacer é adicionado, funciona sem JS e a página não dá saltos.
5. Troca de tela: para cada seção de recurso use ScrollTrigger.create com start "top 55%", end "bottom 55%" e onToggle; mostre a tela ativa com autoAlpha do gsap e oculte a anterior com autoAlpha 0. Não use apenas opacity; as telas ocultas devem estar com visibility:hidden para que a auditoria de acessibilidade não as leia. O título da seção ativa muda de cor (sem esmaecer com opacity), e pontos ao lado do celular mostram qual recurso está ativo.
6. Cards e caixas de preços aparecem com data-reveal, deslizando 20 px para cima ao rolar; limpe as telas copiadas na função de reversão do matchMedia para que o layout não quebre quando a janela for estreitada.

Configuração e armadilhas conhecidas (cada uma custou pontos ou quebrou algo na medição da demonstração, não pule nenhuma):
1. Se já houver um site no ar no servidor, avise-me primeiro, porque a configuração sobrescreve o index.html e a pasta assets. Veja a prévia de scaffold_site com confirm=false e chame confirm=true após a minha aprovação. Depois leia site_design_guide e site_seo_guide. Antes de escrever código, coloque a direção de design (tipografia, cor, grade, elemento marcante, linguagem de movimento e as bibliotecas que NÃO serão carregadas) em um ART.md curto fora de assets e mostre-o para mim.
2. Compile o Tailwind, não o carregue pela CDN. Instale `npm i -D tailwindcss@3` com site_run_command e background=true, e acompanhe com site_command_status. Os caminhos de content em `tailwind.config.js` devem cobrir todos os arquivos HTML, todos os templates e todos os arquivos JS que escrevem classes. `_src/tw.css` contém uma linha `@import "../assets/app.css";` e as três linhas `@tailwind`; compile-o em um único arquivo com `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Remova o script cdn.tailwindcss.com e o tailwind.config inline das páginas e vincule apenas `/assets/site.css`. Recompile após cada alteração no HTML.
3. Hospede as fontes você mesmo. Primeiro verifique se a família da Fontshare que você escolher tem as letras turcas (ş, ğ, ı, İ, ç, ö, ü): na demonstração a Tanker não tinha o ı sem ponto e a Outfit não tinha ş, ğ nem İ, então essas letras cairiam em outra fonte nos títulos. Baixe o woff2 de cada peso separadamente com site_fetch para `assets/fonts/`, escreva as regras @font-face com `font-display: swap` em `assets/app.css` (o design-check procura a fonte personalizada ali) e confira o nome do font-family no CSS que você baixou. Faça preload das fontes de título e de texto usadas acima da dobra em cada página com `<link rel="preload" as="font" type="font/woff2" crossorigin>`, antes da folha de estilo; não faça preload de mais de dois arquivos, porque na demonstração o preload de um terceiro peso aumentou o LCP no celular em 0,2 segundo. A maioria das fontes da Fontshare não tem o símbolo ₺, então escreva "TL" nos preços.
4. Faça o menu e o rodapé em HTML estático. Não carregue chrome.js nem site.config.js nas páginas. Escreva um pequeno `chrome-stamp.mjs` que leia a lista de navegação de site.config.js e carimbe `_src/header.tpl` e `_src/footer.tpl` entre os marcadores `` e `` em cada página, adicionando aria-current="page" ao link ativo. Os templates não devem terminar em .html e devem usar marcadores como `[[NAV]]` em vez de `{{...}}`. Construa o menu móvel sem JS usando `<details>`. Mantenha o nome da organização, o endereço e o telefone como texto simples no rodapé, e faça todo alvo de toque ter pelo menos 44x44 px, incluindo os links do rodapé e do breadcrumb.
5. Converta as imagens ao baixá-las com site_fetch: grave a mesma foto com resize="480x", "800x" e "1200x", image_format="webp", quality=65 em arquivos separados. O site_fetch nunca recorta; quando uma foto do Unsplash precisar de outra proporção, baixe a versão recortada adicionando parâmetros como `?w=1600&h=1200&fit=crop` à URL. Dê a todo `<img>` srcset, sizes e width e height que correspondam à proporção real. A imagem principal acima da dobra recebe fetchpriority="high" e não é lazy; as demais recebem loading="lazy" decoding="async". Se a imagem principal preencher a tela no celular, sirva um recorte menor com `<picture>`.
6. Escreva a versão SVG do logotipo como favicon.svg com site_write_file e adicione `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` a todas as páginas. Sem favicon o navegador registra um 404 e as Práticas recomendadas caem para 96.
7. Regras do validador de HTML: comece com `<!DOCTYPE html>` em maiúsculas, use `&nbsp;` nos espaços do texto visível dos links tel:, nunca use o atributo style="", dê type="button" a todo botão e não coloque um `<details>` dentro de uma `<figure>` depois do figcaption.
8. Baixe as bibliotecas de movimento (GSAP, ScrollTrigger) do jsdelivr para `assets/vendor/` com site_fetch, fixe a versão e carregue-as somente na página inicial. Não use `<script defer>`; coloque um pequeno loader no fim da página que espere o evento load, duas chamadas de requestAnimationFrame e depois requestIdleCallback, e anexe os scripts em ordem com async=false. Um script de uma linha no `<head>` adiciona a classe `js` ao `<html>` e a classe `anim`, a menos que prefers-reduced-motion seja "reduce"; sem `anim` o loader não baixa nada. Defina os estados iniciais ocultos somente sob `.anim` e adicione uma animação CSS de segurança que revele todos os elementos ocultos após 2,5 segundos caso a biblioteca nunca chegue. Em demonstrações anteriores, bibliotecas com defer levaram o LCP no celular a 3,2 segundos; com este loader as páginas mediram de 99 a 100. Dê o nome data-reveal ao atributo dos elementos revelados na rolagem; o design-check só reconhece movimento por esse nome.

SEO, AEO e GEO:
1. Use URLs em estilo de diretório com barra final (/destek/, /gizlilik/). Preencha o bloco seo de site.config.js e execute `node seo-stamp.mjs`. Escreva o schema específico de cada página (início: WebPage, MobileApplication (operatingSystem, applicationCategory, as duas URLs das lojas como downloadUrl, os planos que eu informei como offers com preços em TRY; NÃO adicione aggregateRating, porque a nota de uma loja não é uma avaliação coletada no seu site) e FAQPage; suporte: WebPage e FAQPage; privacidade: WebPage; BreadcrumbList nas páginas internas. Para uma empresa de software sem loja física, localBusiness:false em site.config.js) em blocos `<script type="application/ld+json">` separados e vincule-os ao grafo base por @id. Não aninhe BreadcrumbList dentro de @graph; mantenha-o em seu próprio bloco, pois essa é a única forma de o seo-check enxergá-lo.
2. Mantenha os títulos com 60 caracteres ou menos (o seo-check marca como erro qualquer um acima de 65), as descrições entre 120 e 158 caracteres, um h1 por página e nenhum nível de título pulado (um h3 logo após o h1 derrubou a acessibilidade para 98). Toda página precisa de pelo menos 150 palavras de conteúdo principal; páginas de contato e privacidade costumam ficar abaixo disso.
3. O primeiro parágrafo de cada página responde diretamente à pergunta da página. Escreva FAQs específicas de cada página com `<details>` e marque-as como FAQPage. Mostre a organização que publica e uma data de "Última atualização" em `<time>`.
4. No robots.txt, registre e justifique a sua decisão para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot e CCBot, e aponte para o sitemap. Dê ao sitemap.xml datas lastmod reais. O llms.txt traz um resumo preciso do site em duas frases, os fatos principais e uma lista das páginas importantes.
5. Sem invenção: não escreva avaliações, notas, prêmios, números de clientes, certificados, horários de funcionamento, coordenadas nem preços sem me perguntar. Deixe totalmente fora do schema qualquer campo que você não conheça.

Portões de qualidade (em ordem; não diga "pronto" até que todos passem):
1. Com site_run_command execute `node chrome-stamp.mjs`, a compilação do Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 erros, 0 avisos), `node design-check.mjs` (0 erros; justifique qualquer aviso restante) e `npx html-validate "**/*.html"` (0 erros).
2. Veja todas as páginas com site_preview usando view="mobile" e view="desktop". O site_preview captura a página com o movimento desligado (reduced-motion); se faltar conteúdo nessa captura, o estado sem movimento está quebrado. Imagens lazy mais abaixo podem aparecer em branco na captura da página inteira; não conte isso como erro, mas confira os caminhos delas.
3. Execute core_web_vitals com strategy="mobile" e strategy="desktop" para todas as páginas. Critério de aceitação: no celular, Performance de pelo menos 95 e Acessibilidade, Práticas recomendadas e SEO 100; no desktop, as quatro de pelo menos 95. Para uma página que não atingir, encontre o arquivo lento com resources=true, corrija e meça de novo. Depois execute seo_audit na página inicial com strategy="mobile" e runs=2. Nenhum endereço fora do seu próprio domínio pode permanecer na lista de requisições de rede.
4. Sem rolagem horizontal em 360, 390, 768 e 1440 px, alvos de toque de pelo menos 44 px e nenhum erro no console. O site também deve ficar impecável dentro de um quadro de 390x790 e de 1440x898, como nas páginas de prompts.

Verificação de movimento: o site_preview não consegue mostrar movimento, então diga-me o que observar no meu próprio navegador. No desktop, ao chegar à seção de Recursos, o celular deve ficar fixo no meio da tela, à direita, a tela dele deve mudar para cada recurso conforme o título chega ao meio, o título deve ganhar cor e o ponto ao lado dele deve avançar. Em um celular e com movimento reduzido ativado, cada recurso mostra a sua própria tela pequena e nada fica fixo no lugar. Os botões das lojas devem abrir a loja certa.

Depois de publicar: veja a prévia da regra `/assets/* Cache-Control: public, max-age=31536000, immutable` com site_headers e aplique-a após a minha aprovação; a partir daí, versione o nome do arquivo sempre que o CSS ou o JS mudar (site-v2.css e assim por diante). Envie o sitemap.xml com gsc_submit_sitemap e verifique a página inicial com gsc_url_inspect. Por fim, entregue-me: uma tabela de notas por página (página, quatro notas no celular, quatro notas no desktop, LCP, CLS), os resultados dos portões, o resultado das interações que você testou em um navegador e a lista das correções que você aplicou.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um site de relatório anual ou de impacto com scrollytelling e gráficos que se desenham ao rolar a página

Transforma seu relatório anual ou de impacto em um site de leitura longa: gráficos de linha em SVG que se desenham ao rolar, números que contam, navegação por capítulos, uma nota metodológica e schema Report. Números e gráficos ficam totalmente visíveis sem JavaScript, cada gráfico tem uma tabela de dados e o Lighthouse mobile é medido e mantido acima de 95.

Quando usarQuando você quer transformar o relatório anual ou de impacto da sua associação, fundação ou empresa, hoje em PDF, em um site compartilhável que os mecanismos de busca e as respostas de IA possam citar.

No meu servidor de hospedagem do Opus Growth [nome do servidor], crie o relatório de impacto de [ano] de [nome da organização] como um site que conta sua história conforme a pessoa rola a página. Organização: [o que faz, onde, ano de fundação]. A mensagem principal do relatório: [uma frase]. Os quatro números de destaque: [número, unidade, explicação em uma frase]. Dados dos gráficos: [para cada gráfico, título, períodos e valores]. Orçamento: [fontes de receita e linhas de despesa, valores e percentuais]. Capítulos: [nomes dos capítulos e o texto ou as anotações de cada um]. Plano do próximo ano: [itens]. De onde vêm os números e quais são seus limites: [quais registros, como os dados ausentes foram tratados]. Elaborado por e data de publicação: [nome do editor, data]. Contato: [e-mail], [telefone], [endereço]. Domínio: [domínio]. Fotos: [links; sem rostos de crianças ou beneficiários].

Páginas: relatório (/: título da capa, parágrafo de resumo com a resposta logo no início, autor e data, imagem de capa, navegação fixa por capítulos e, nesta ordem, resumo do ano, capítulos, orçamento, plano do próximo ano e perguntas sobre o relatório), metodologia (/yontem/: a fonte e os limites de cada número), organização e contato (/dernek/ ou um nome que combine com a sua organização), privacidade e KVKK (/gizlilik/) e 404.html. Escreva os gráficos como SVG estático gerado a partir dos valores que informei, sem Chart.js nem D3; não arredonde os valores e confira se os totais fecham. Mostre o orçamento como uma `<table>` sem nenhuma largura mínima, não como gráfico.

Estilo: uma leitura longa, como uma reportagem de dados de jornal. Fundo na cor de papel, uma fonte serifada da Fontshare para os títulos (por exemplo, Bespoke Serif) e uma fonte de texto legível que suporte tabular-nums (por exemplo, Epilogue), com no máximo duas cores nos gráficos. No desktop, uma lista fixa de capítulos de 220 px à esquerda; no celular, uma faixa de capítulos com rolagem horizontal que fica fixa no topo, com uma linha fina de progresso de leitura abaixo dela.

Regras de movimento (a parte mais difícil, siga à risca):
1. Bibliotecas: apenas o núcleo do GSAP 3.13 e o ScrollTrigger, somente na página do relatório. O Lenis NÃO é carregado, porque a rolagem nativa é mais confortável para uma leitura longa; SplitText e bibliotecas de gráficos também não são carregados. Nenhum script nas páginas de metodologia, organização e privacidade.
2. Gráficos de linha: cada linha é um `<path pathLength="1">` e já vem totalmente desenhada no HTML. O JS define strokeDasharray 1 e strokeDashoffset 1 apenas nos gráficos que estão abaixo da tela no carregamento e leva o offset a 0 com ScrollTrigger scrub (start "top 75%", end "bottom 65%"); os pontos de dados surgem conforme a linha passa por eles. Faça o texto do SVG ter pelo menos 22 unidades em um viewBox de 600 unidades, para que fique acima de 12 px no celular, e deixe pelo menos 40 unidades à direita para que o último rótulo do eixo não seja cortado.
3. Todo gráfico é um `<svg role="img" aria-labelledby>` com title e desc que informa todos os valores em uma frase; a figcaption mostra a fonte e aponta para a nota de metodologia e, LOGO APÓS a figure, um `<details>` com o rótulo "Ver os dados em tabela" traz uma `<table>` de verdade. Essa tabela é a versão em texto dos dados, tanto para acessibilidade quanto para busca com IA.
4. Contadores: o valor final é escrito no HTML no formato turco (como 31.540). O número visual fica em um span com aria-hidden e o mesmo valor fica em um span sr-only para leitores de tela. O JS zera apenas os contadores que estão abaixo da tela no carregamento e os faz contar com Intl.NumberFormat("tr-TR") quando entram na tela; nunca volte a zero um número que já está visível. Aplique tabular-nums ao número e uma largura mínima igual ao número de caracteres do valor final (com uma classe do Tailwind, não um atributo style) para que a linha não se mova durante a contagem.
5. Navegação por capítulos: os links são âncoras que funcionam sem JS. O JS usa um ScrollTrigger por capítulo para encontrar o ativo, define aria-current="true" no link dele e rola a faixa do celular na horizontal para que o link ativo fique visível (a faixa, não a página). Coloque o comportamento fixo na barra lateral (aside) que é filha direta do grid que ocupa todo o relatório, não no nav interno; na demonstração, o sticky no nav interno nunca funcionou no celular.
6. Nenhum outro movimento além da linha de progresso de leitura e das imagens que aparecem com data-reveal.

Configuração e armadilhas conhecidas (cada uma custou pontos ou quebrou algo na medição da demonstração, não pule nenhuma):
1. Se já houver um site no ar no servidor, avise-me primeiro, porque a configuração sobrescreve o index.html e a pasta assets. Mostre a prévia do scaffold_site com confirm=false e chame confirm=true depois da minha aprovação. Em seguida, leia site_design_guide e site_seo_guide. Antes de escrever código, coloque a direção de design (tipografia, cor, grid, elemento de assinatura, linguagem de movimento e as bibliotecas que NÃO serão carregadas) em um ART.md curto fora de assets e mostre para mim.
2. Compile o Tailwind, não o carregue pela CDN. Instale com `npm i -D tailwindcss@3` usando site_run_command com background=true e acompanhe com site_command_status. Os caminhos de content em `tailwind.config.js` devem cobrir todos os arquivos HTML, todos os templates e todos os arquivos JS que escrevem classes. `_src/tw.css` contém uma linha `@import "../assets/app.css";` e as três linhas `@tailwind`; compile-o em um único arquivo com `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Remova o script cdn.tailwindcss.com e o tailwind.config inline das páginas e vincule apenas `/assets/site.css`. Recompile após cada alteração no HTML.
3. Hospede as fontes você mesmo. Primeiro verifique se a família da Fontshare escolhida tem as letras turcas (ş, ğ, ı, İ, ç, ö, ü): na demonstração, a Tanker não tinha o ı sem ponto e a Outfit não tinha ş, ğ nem İ, então essas letras cairiam em outra fonte nos títulos. Baixe o woff2 de cada peso separadamente com site_fetch para `assets/fonts/`, escreva as regras @font-face com `font-display: swap` em `assets/app.css` (o design-check procura a fonte personalizada ali) e confira o nome do font-family no CSS que você baixou. Faça preload das fontes de título e de texto usadas acima da dobra em todas as páginas com `<link rel="preload" as="font" type="font/woff2" crossorigin>`, antes da folha de estilo; não faça preload de mais de dois arquivos, porque o preload de um terceiro peso na demonstração aumentou o LCP no celular em 0,2 segundo. A maioria das fontes da Fontshare não tem o símbolo ₺, então escreva "TL" nos preços.
4. Deixe o menu e o rodapé como HTML estático. Não carregue chrome.js nem site.config.js nas páginas. Escreva um pequeno `chrome-stamp.mjs` que leia a lista de navegação de site.config.js e carimbe `_src/header.tpl` e `_src/footer.tpl` entre os marcadores `` e `` em todas as páginas, adicionando aria-current="page" ao link ativo. Os templates não devem terminar em .html e devem usar placeholders como `[[NAV]]` em vez de `{{...}}`. Construa o menu mobile sem JS usando `<details>`. Mantenha o nome da organização, o endereço e o telefone como texto simples no rodapé e faça todo alvo de toque ter pelo menos 44x44 px, incluindo os links do rodapé e do breadcrumb.
5. Converta as imagens durante o download com site_fetch: grave a mesma foto com resize="480x", "800x" e "1200x", image_format="webp", quality=65 em arquivos separados. O site_fetch nunca recorta; quando uma foto do Unsplash precisar de outra proporção, baixe a versão recortada adicionando parâmetros como `?w=1600&h=1200&fit=crop` à URL. Dê a todo `<img>` srcset, sizes, além de width e height compatíveis com a proporção real. A imagem principal acima da dobra recebe fetchpriority="high" e não é lazy; as demais recebem loading="lazy" decoding="async". Se a imagem principal ocupar a tela inteira no celular, sirva um recorte menor com `<picture>`.
6. Escreva a versão SVG do logo como favicon.svg com site_write_file e adicione `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` a todas as páginas. Sem favicon, o navegador registra um 404 e as Práticas Recomendadas caem para 96.
7. Regras do validador de HTML: comece com um `<!DOCTYPE html>` em maiúsculas, use `&nbsp;` nos espaços do texto visível dos links tel:, nunca use o atributo style="", dê type="button" a todo botão e não coloque um `<details>` dentro de uma `<figure>` depois da figcaption.
8. Baixe as bibliotecas de movimento (GSAP, ScrollTrigger) do jsdelivr para `assets/vendor/` com site_fetch, fixe a versão e carregue-as somente na página do relatório. Não use `<script defer>`; coloque um pequeno loader no final da página que espere o evento load, duas chamadas de requestAnimationFrame e depois requestIdleCallback, e acrescente os scripts em ordem com async=false. Um script de uma linha no `<head>` adiciona a classe `js` ao `<html>` e a classe `anim`, a menos que prefers-reduced-motion seja "reduce"; sem `anim`, o loader não baixa nada. Defina os estados iniciais ocultos somente sob `.anim` e adicione uma animação CSS de segurança que revele todos os elementos ocultos após 2,5 segundos, caso a biblioteca nunca chegue. Em demonstrações anteriores, bibliotecas com defer levaram o LCP no celular a 3,2 segundos; com este loader, as páginas ficaram entre 99 e 100. Chame o atributo dos elementos revelados na rolagem de data-reveal; o design-check só reconhece movimento por esse nome.

SEO, AEO e GEO:
1. Use URLs em estilo de diretório com barra final (/yontem/, /dernek/, /gizlilik/). Preencha o bloco seo de site.config.js e execute `node seo-stamp.mjs`. Escreva o schema específico de cada página (página do relatório: WebPage com um Report como mainEntity, incluindo headline, datePublished, dateModified, image, author (Person, o editor) e publisher, além de FAQPage; metodologia: Article; página da organização: AboutPage com um subtipo adequado à organização (por exemplo, NGO); BreadcrumbList nas páginas internas. Se não houver um escritório que as pessoas visitem, defina localBusiness:false em site.config.js) em blocos `<script type="application/ld+json">` separados e conecte-os ao grafo base por @id. Não aninhe BreadcrumbList dentro de @graph; mantenha-o em um bloco próprio, porque é a única forma de o seo-check enxergá-lo.
2. Mantenha os títulos com 60 caracteres ou menos (o seo-check marca como erro qualquer um acima de 65), as descrições entre 120 e 158 caracteres, um h1 por página e nenhum nível de título pulado (um h3 logo após o h1 derrubou a acessibilidade para 98). Toda página precisa de pelo menos 150 palavras de conteúdo principal; páginas de contato e privacidade costumam ficar abaixo disso.
3. O primeiro parágrafo de cada página responde diretamente à pergunta da página. Escreva FAQs específicas de cada página com `<details>` e marque-as como FAQPage. Mostre a organização que publica e uma data de "Última atualização" em `<time>`.
4. No robots.txt, registre e justifique sua decisão para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot e CCBot, e aponte para o sitemap. Dê ao sitemap.xml datas lastmod reais. O llms.txt traz um resumo preciso do site em duas frases, os fatos principais e uma lista das páginas importantes.
5. Sem invenção: não escreva avaliações, notas, prêmios, número de clientes, certificados, horários de funcionamento, coordenadas nem preços sem me perguntar. Deixe de fora do schema qualquer campo que você não conheça.

Portões de qualidade (em ordem; não diga "pronto" até que todos passem):
1. Com site_run_command, execute `node chrome-stamp.mjs`, o build do Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 erros, 0 avisos), `node design-check.mjs` (0 erros; justifique qualquer aviso restante) e `npx html-validate "**/*.html"` (0 erros).
2. Veja cada página com site_preview usando view="mobile" e view="desktop". O site_preview captura a página com o movimento desligado (reduced-motion); se faltar conteúdo nessa captura, o estado sem movimento está quebrado. Imagens lazy mais abaixo podem aparecer em branco na captura de página inteira; não conte isso como erro, mas confira os caminhos delas.
3. Execute core_web_vitals com strategy="mobile" e strategy="desktop" para cada página. Critério de aceitação: no celular, Performance de pelo menos 95 e Acessibilidade, Práticas Recomendadas e SEO em 100; no desktop, as quatro notas de pelo menos 95. Para uma página que não atingir, encontre o arquivo lento com resources=true, corrija e meça de novo. Depois, execute seo_audit na página inicial com strategy="mobile" e runs=2. Nenhum endereço fora do seu próprio domínio pode restar na lista de requisições de rede.
4. Sem rolagem horizontal em 360, 390, 768 e 1440 px, alvos de toque de pelo menos 44 px e nenhum erro no console. O site também deve ficar impecável dentro de um quadro de 390x790 e de 1440x898, como nas páginas de prompts.

Verificação de movimento: o site_preview não consegue mostrar movimento, então diga-me o que observar no meu próprio navegador. No desktop, os contadores devem contar de zero até o valor final quando entrarem na tela, as linhas dos gráficos devem ser desenhadas da esquerda para a direita conforme a rolagem, com os pontos surgindo um a um, e a lista de capítulos à esquerda deve marcar o capítulo que está sendo lido. No celular, a faixa de capítulos deve ficar fixa no topo e deslizar o capítulo ativo para a vista. Com movimento reduzido ativado e com o JavaScript desligado, todo número mostra o valor final e todo gráfico aparece totalmente desenhado; as tabelas de dados podem ser abertas.

Depois de publicar: faça a prévia da regra `/assets/* Cache-Control: public, max-age=31536000, immutable` com site_headers e aplique-a após a minha aprovação; a partir daí, versione o nome do arquivo sempre que o CSS ou o JS mudar (site-v2.css e assim por diante). Envie o sitemap.xml com gsc_submit_sitemap e verifique a página inicial com gsc_url_inspect. Por fim, entregue-me: uma tabela de notas por página (página, quatro notas no celular, quatro notas no desktop, LCP, CLS), os resultados dos portões, o resultado das interações que você testou em um navegador e a lista das correções aplicadas.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um site de conferência com programação em abas por dia, modais de palestrantes e uma contagem regressiva que continua correta sem JavaScript

Cria um site em estilo pôster para a sua conferência ou evento no servidor de hospedagem: uma programação em abas por dia, uma grade de palestrantes cujas biografias abrem em um modal, uma contagem regressiva que mostra a data correta mesmo com o JavaScript desativado, uma barra de ingressos fixa no celular e schema Event com ofertas e local. Nenhuma biblioteca é carregada, um arquivo de calendário é fornecido e cada página é medida.

Quando usarQuando você quer um site rápido para sua conferência, summit ou evento com várias sessões, que reúna programação, palestrantes e ingressos e seja lido corretamente como um evento pelos mecanismos de busca.

No site [nome do servidor] do meu servidor de hospedagem Opus Growth, crie um site de evento estático e rápido para [nome do evento]. Evento: [o que é, para quem é, qual edição, duas frases]. Data e horário: [início e término, fuso horário]. Local: [nome do local, endereço completo, transporte, estacionamento, instalações de acessibilidade]. Programação: [para cada dia, o horário, o título da sessão, o palestrante e a sala]. Palestrantes: [nome, cargo, organização, título da palestra, bio, link da foto e permissão para publicar a foto]. Ingressos: [ticket types, prices, whether VAT is included, valid dates, the link on the ticketing platform, refund and transfer terms]. Organizador: [nome da organização], [e-mail], [telefone]. Política de gravação e fotos: [se as palestras são gravadas e se são tiradas fotos]. Domínio: [domínio].

Páginas: início (uma linha com data e local, contagem regressiva, breve introdução, o que vai acontecer, quatro dos palestrantes, um resumo do local, FAQ), programação (/program/: abas por dia e um arquivo de calendário .ics), palestrantes (/konusmacilar/), ingressos (/bilet/: tipos de ingresso, o que está incluído, reembolsos, FAQ sobre nota fiscal), local (/mekan/: endereço, transporte, acessibilidade, hospedagem), privacidade (/gizlilik/, incluindo a escolha sobre fotos e gravação) e 404.html.

Estilo: um pôster de conferência. Se nenhuma [preferência de cor] for informada, use uma faixa hero amarelo-sinalização, fundo creme, texto preto e bordas pretas de 2 pixels. Uma fonte larga e em negrito da Fontshare em caixa alta para os títulos (por exemplo Panchang 700) e uma sans arredondada para o texto (por exemplo Chillax 400 e 500); faça preload dos três arquivos da primeira tela. A caixa alta exige `<html lang="tr">`, caso contrário o "i" vira "I". Se um palestrante não tiver foto ou não tiver autorizado a publicação, use um monograma com as iniciais; nunca use a foto de outra pessoa.

Regras de interação (sem biblioteca, um único `ix.js` com defer, somente nas páginas de início, programação e palestrantes):
1. A contagem regressiva fica correta mesmo com JS desativado: o HTML contém o texto "Starts: <time datetime="2027-05-13T09:00:00+03:00">Thursday 13 May 2027, 09.00</time> (Turkey time)" dentro de uma caixa de altura fixa. O JS lê as datas ISO com deslocamento de fuso horário de data-start e data-end com Date.parse e escreve caixas de dia, hora e minuto dentro da mesma caixa. A caixa deve ter a mesma altura nos dois estados (min-height no CSS e uma altura fixa por unidade), caso contrário a primeira tela se desloca. Não exiba segundos; atualize a cada minuto e pare enquanto a aba estiver oculta. As caixas de números ficam com aria-hidden, com uma única frase visualmente oculta para leitores de tela ao lado delas, e sem região live (aria-live), porque seria lida a cada minuto. Quando o evento tiver começado, escreva "happening now"; depois que terminar, escreva "has ended"; nunca mostre números negativos para uma data passada.
2. Abas por dia: no HTML, cada dia é uma seção separada com seu próprio título (id="gun-1", "gun-2") e links para essas seções acima delas; com JS desativado, todos os dias aparecem um sob o outro. O contêiner em volta dos links leva role="group" e um aria-label. O JS os transforma em abas ARIA (tablist, tab, tabpanel, aria-selected, tabindex, teclas de seta, Home e End), seleciona o segundo dia quando a página abre com #gun-2 e atualiza a URL com history.replaceState quando a aba muda, para que um dia possa ser compartilhado como link. Cada sessão é uma linha de lista com um `<time datetime>`: horário, título, um link para a âncora do palestrante na página de palestrantes e a sala; os intervalos têm um fundo separado.
3. Bio do palestrante: no HTML, ela fica em um `<details>` em cada card, para ser legível com JS desativado e pelos mecanismos de busca. O JS intercepta o clique no summary, monta um único `<dialog>`, copia nele o nome, o cargo, o título da palestra e a bio com textContent, abre com showModal e move o foco para o botão "Close"; Esc e um clique no fundo fecham, e o foco volta ao summary. Adicione aria-haspopup="dialog" ao summary. O id de cada card é o slug do palestrante, que é para onde apontam os links da programação.
4. CTA fixo de ingressos: um botão "Get tickets" no cabeçalho no desktop e, no celular, uma barra fixa na parte inferior da tela (data, menor preço e "Get tickets"). A barra é HTML estático no template do rodapé e fica com position: fixed desde a primeira renderização; adicioná-la depois com JS causa mudança de layout. No celular, dê ao body um padding inferior igual à altura da barra para que os últimos links não fiquem escondidos sob ela, adicione `env(safe-area-inset-bottom)` e oculte a barra na página de ingressos por meio de uma classe no body.
5. Arquivo de calendário: `/assets/[evento].ics` baixado a partir da página de programação (VCALENDAR com um VEVENT, DTSTART e DTEND em UTC, SUMMARY, LOCATION, URL, quebras de linha CRLF). Dê ao link o atributo download.

Schema: o mesmo Event (@id /#event) nas páginas de início, programação e ingressos: name, description, startDate e endDate com deslocamento de fuso horário, eventStatus EventScheduled, eventAttendanceMode OfflineEventAttendanceMode, location como um Place com um PostalAddress completo, três imagens nas proporções 1x1, 4x3 e 16x9, organizer, os palestrantes como performer e um array offers (para cada tipo de ingresso name, price, priceCurrency "TRY", availability, validFrom, validThrough para early bird, e a página de vendas como url). O resultado avançado de evento do Google exige location e startDate e não mescla @id entre páginas, então escreva o Event por completo em todas as páginas que o usam; na página de programação, adicione também cada sessão como subEvent. Se o evento for adiado ou cancelado, defina eventStatus como EventPostponed ou EventCancelled em vez de excluir a página. Place na página do local e BreadcrumbList em todas as páginas internas. Patrocinadores, número de participantes ou "esgotado" só devem ser escritos se forem verdadeiros.

Configuração e armadilhas conhecidas (cada uma custou pontos nas medições da demo, não pule nenhuma):
1. Se já houver um site no ar no servidor, avise-me primeiro, porque a configuração sobrescreve index.html e a pasta assets. Mostre a prévia de scaffold_site com confirm=false e chame com confirm=true somente depois que eu aprovar. Em seguida, leia site_design_guide e site_seo_guide. Antes de escrever código, coloque a direção de design (tipografia, cores, grade, elemento marcante, linguagem de movimento e as bibliotecas que NÃO serão carregadas) em um arquivo curto ART.md fora de assets e mostre-o para mim.
2. Compile o Tailwind, não o carregue pela CDN. Instale-o com site_run_command e background=true (`npm i -D tailwindcss@3`) e acompanhe com site_command_status. Os caminhos content em `tailwind.config.js` devem cobrir todos os arquivos HTML, os templates de `_src` e qualquer arquivo JS que escreva classes. `_src/tw.css` contém a linha `@import "../assets/app.css";` mais as três linhas `@tailwind`; compile-o em um único arquivo com `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Remova o script cdn.tailwindcss.com e o tailwind.config inline de todas as páginas e vincule apenas `/assets/site.css`. Recompile após cada alteração no HTML.
3. Hospede as fontes você mesmo. Leia o CSS da família Fontshare escolhida, baixe o woff2 de cada peso separadamente com site_fetch para `assets/fonts/` e escreva as regras @font-face com `font-display: swap` em `assets/app.css`, que é onde o design-check procura uma fonte personalizada. Verifique o nome do font-family no CSS baixado e confirme que a família tem as letras turcas ı, İ, ş e ğ (a Tanker não tem ı). Faça preload de TODOS os pesos usados na primeira tela com `<link rel="preload" as="font" type="font/woff2" crossorigin>`, colocado antes da linha da folha de estilo; se forem mais de três arquivos, use menos pesos. Na demo, um único peso de corpo sem preload levou o LCP no celular a 2,6 segundos e o Performance a 97. A maioria das fontes da Fontshare não tem o símbolo ₺, então escreva os preços com "TL".
4. Faça o menu e o rodapé em HTML estático. Não carregue chrome.js, motion.js nem site.config.js nas páginas. Escreva um pequeno `chrome-stamp.mjs` que leia a lista de navegação de site.config.js e carimbe `_src/header.tpl` e `_src/footer.tpl` entre os marcadores `` e `` em todas as páginas, adicionando aria-current="page" ao link ativo. Use placeholders como `[[NAV]]` em vez de `{{...}}` e não dê aos templates a extensão .html, caso contrário o design-check e o seo-check os tratam como páginas inacabadas. Construa o menu mobile com um `<details>` sem JS. Mantenha o nome da empresa, o endereço e o telefone como texto simples no rodapé e faça os links do rodapé e do breadcrumb terem pelo menos 44 pixels de altura.
5. Converta as imagens ao buscá-las com site_fetch: grave a mesma imagem em arquivos separados com resize="480x", "800x" e "1200x", image_format="webp", quality=60 (site_fetch não recorta, então peça a origem na proporção de que você precisa). Dê a cada `<img>` srcset, sizes e width e height que correspondam à proporção real. A imagem que é o elemento LCP da página recebe fetchpriority="high" e não é lazy; todas as outras imagens recebem loading="lazy" decoding="async". Se uma imagem preencher a primeira tela no celular, sirva um recorte menor para o celular com `<picture>`.
6. Adicione `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` a todas as páginas e crie um apple-touch-icon de 180 pixels a partir do logotipo com site_fetch e resize="180x180". Sem um link de favicon, o navegador solicita /favicon.ico, registra um 404 e o Best Practices cai para 96.
7. Regras do validador de HTML: comece cada documento com um `<!DOCTYPE html>` em maiúsculas; cada espaço no texto visível de um link tel: deve ser `&nbsp;`, inclusive o que vem depois de um prefixo como "Call:&nbsp;0212..."; não use style=""; dê a todo botão um type; coloque aria-label apenas em landmarks, formulários ou elementos interativos (em um ul ou em uma div sem role, foi um erro); nunca dê o mesmo nome a dois landmarks; não deixe espaços em branco no final das linhas.
8. Não pule níveis de título: em uma página de lista, títulos de card como h3 logo após o h1 derrubaram o Accessibility para 98. Ao reutilizar um card, defina o nível do título por página (h2 em uma página de lista, h3 dentro de uma seção h2).
9. Chame o atributo de movimento de data-reveal (o design-check só reconhece movimento por esse nome). O JS dá o estado inicial oculto apenas aos blocos que ficam abaixo da tela quando a página abre e nunca oculta o conteúdo da primeira tela; use transform, porque esmaecer com opacity reduz a auditoria de contraste. Coloque o atributo no bloco que envolve um título e sua descrição, não só no título; na demo, um título em espera deslizou sobre o parágrafo abaixo dele. Com prefers-reduced-motion: reduce nada é ocultado e as animações ficam desativadas.

SEO, AEO e GEO:
1. Use URLs em estilo de diretório com barra final. Preencha o bloco seo de site.config.js e execute `node seo-stamp.mjs`. Escreva o schema específico de cada página em blocos `<script type="application/ld+json">` separados, vinculados ao grafo base por @id. Não aninhe BreadcrumbList dentro de @graph; mantenha-o em seu próprio bloco, que é a única forma de o seo-check vê-lo.
2. Títulos com no máximo 60 caracteres (o seo-check sinaliza como erro qualquer um abaixo de 25 ou acima de 65), descrições de 130 a 158 caracteres, um h1 por página e pelo menos 150 palavras de conteúdo principal em cada página. Páginas de contato, privacidade e de lista tendem a ficar curtas; acrescente informações específicas da página, não encheção de linguiça.
3. O primeiro parágrafo de cada página responde diretamente à pergunta da página. Escreva FAQs específicas de cada página com `<details>` e marque-as como FAQPage. Mostre o publisher e uma data de "Last updated" em um elemento `<time>`.
4. No robots.txt, escreva sua decisão com o motivo para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot e CCBot, e aponte para o sitemap. O sitemap.xml traz datas lastmod reais. O llms.txt contém um resumo preciso do site em duas frases e uma lista das páginas importantes.
5. Sem invenção: não escreva avaliações, notas, prêmios, números de clientes, certificados, horários de funcionamento, coordenadas ou preços sem me perguntar. Deixe totalmente fora do schema qualquer campo que você não conheça.

Gates (em ordem; não diga "pronto" até que todos passem):
1. Com site_run_command, execute `node chrome-stamp.mjs`, o build do Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 erros, 0 avisos), `node design-check.mjs` (0 erros; justifique qualquer aviso restante) e `npx html-validate "**/*.html"` (0 erros).
2. Veja cada página com site_preview, view="mobile" e view="desktop". O site_preview captura a página com o movimento desativado (reduced-motion); se faltar conteúdo nessa captura, o estado estático está quebrado. Em capturas de página inteira, elementos fixos como uma barra fixa podem aparecer no meio da página e imagens lazy mais abaixo podem aparecer em branco; não conte isso como erro, mas verifique os caminhos delas.
3. Execute core_web_vitals para cada página com strategy="mobile" e strategy="desktop". Critério de aceitação: no celular, Performance de pelo menos 95 (meta de 99 a 100) e Accessibility, Best Practices e SEO 100; no desktop, os quatro em 100. Para uma página que não atingir, use resources=true para encontrar o arquivo que a atrasa, corrija e meça de novo. Depois execute seo_audit na página inicial com strategy="mobile" e runs=2. Nenhum endereço fora do seu próprio domínio pode permanecer na lista de requisições de rede.
4. Sem rolagem horizontal em 360, 390, 768 e 1440 pixels de largura, alvos de toque de pelo menos 44 pixels, sem erros no console.

Verificação de interação: o site_preview não consegue mostrar tempo, abas nem diálogos. Diga-me como verificar que a contagem regressiva mostra a data correta com JavaScript desativado e se transforma em caixas de mesma altura com JS ativado, que /program/#gun-2 abre o segundo dia e que as abas mudam com as teclas de seta, que a bio de um palestrante abre em um modal e o foco volta após o Esc, que no celular a barra de ingressos não cobre os últimos links da página, que o arquivo de calendário chega ao calendário do celular no horário certo e que o Rich Results Test do Google mostra o Event sem erros.

Depois de publicar: faça a prévia da regra `/assets/* Cache-Control: public, max-age=31536000, immutable` com site_headers e aplique-a quando eu aprovar; a partir daí, versione o nome do arquivo sempre que o CSS ou o JS mudar (site-v2.css e assim por diante). Envie o sitemap.xml com gsc_submit_sitemap e verifique a página inicial com gsc_url_inspect. No final, entregue-me: uma tabela de pontuação por página (página, quatro pontuações no celular, quatro no desktop, LCP, CLS), o resultado de cada gate e a lista das correções que você aplicou.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um portfólio escuro para desenvolvedor no estilo Linear e Vercel, com cards com spotlight e menu de comandos Ctrl K

Cria um site de portfólio escuro e sóbrio com o seu nome, como desenvolvedor ou designer: cards de projetos com um spotlight que segue o ponteiro, um menu de comandos Ctrl K que busca em um arquivo JSON local, páginas de estudo de caso e uma lista de textos. Nenhuma biblioteca é usada, o arquivo de busca carrega na primeira abertura e todas as páginas são medidas.

Quando usarQuando você quer um portfólio com o seu próprio nome que explique o seu trabalho por meio de estudos de caso e tenha um visual escuro e amigável ao teclado, como os sites da Linear ou da Vercel.

No site [nome do servidor] do meu servidor de hospedagem Opus Growth, crie um portfólio pessoal estático para [meu nome completo], com o clima escuro e calmo dos sites da Linear e da Vercel. Sobre mim: [meu cargo, minha cidade, o que faço e há quantos anos, duas frases]. Projetos: [for each one the name, year, my role, whether I may publish the client's name, the technologies, context, constraints, approach and outcome notes, and a screenshot link]. Posts: [título, data, texto ou rascunho]. Experiência: [períodos em anos e cargos]. Contato: [e-mail]; perfis que quero publicar: [GitHub, LinkedIn etc. ou "nenhum"]. Aberto a novos trabalhos: [sim e a partir de quando, ou não]. Domínio: [domínio].

Páginas: home (introdução curta, trabalhos selecionados, últimos posts, o que estou fazendo agora, FAQ), projetos (/projeler/), uma página para cada estudo de caso (/projeler/[slug]/: contexto, restrições, abordagem, resultado, dados do projeto), textos (/yazilar/), uma página para cada post (/yazilar/[slug]/), sobre (/hakkimda/) e 404.html. Se o cliente não aprovou os números, não escreva porcentagens nem prazos em um estudo de caso; descreva o resultado de forma qualitativa.

Estilo: escuro e minimalista. Um fundo em torno de #09090B, cards um tom mais claros, uma borda cinza-escura de 1 pixel, texto quase branco, texto secundário em um cinza com contraste de pelo menos 7:1 sobre o fundo, e uma única cor de destaque usada somente em um ponto de status, no anel de foco e nos links. Dois pesos de uma grotesca da Fontshare (por exemplo Bespoke Sans 400 e 500); para datas e rótulos, use a pilha monoespaçada do sistema sem baixar uma fonte (ui-monospace, SFMono-Regular, Menlo, Consolas). Se os numerais parecerem old-style, defina `font-variant-numeric: lining-nums`. O hero não tem imagem; linhas finas de grade que desaparecem sob uma máscara são desenhadas atrás dele com CSS.

Regras de interação:
1. GSAP, Lenis, Swiper e bibliotecas de busca prontas (Fuse.js e similares) NÃO são carregados. Cada página recebe um único `ix.js` pequeno com defer (spotlight, gatilho do menu de comandos, data-reveal) e o próprio menu de comandos fica em um `ara.js` separado. O ara.js não é baixado com a página; ele carrega quando o ponteiro entra no gatilho ou o foco chega até ele, ou quando o menu é aberto pela primeira vez. Na demonstração, as páginas de post não tinham ix.js e Ctrl K não fazia nada nelas; o menu deve se comportar da mesma forma em todas as páginas.
2. Cards com spotlight: uma luz suave no ::before do card com `radial-gradient(420px circle at var(--mx) var(--my), ...)` e um brilho de destaque na borda de 1 pixel no ::after usando mask-composite. O JS adiciona um único listener de pointermove ao contêiner que envolve os cards, limita a frequência com requestAnimationFrame, grava --mx e --my relativos à caixa de cada card e os limpa quando o ponteiro sai. Isso roda apenas em dispositivos que correspondem a `(hover: hover) and (pointer: fine)` e que não pedem movimento reduzido; no toque o card permanece simples. O link no título do card cobre o card inteiro com um ::after.
3. Menu de comandos: o item "Buscar" no cabeçalho é um link real para /projeler/ no HTML (útil com JS desativado) e carrega aria-keyshortcuts="Control+K Meta+K". O JS intercepta o clique; Ctrl K, Cmd K e a tecla / (fora de campos de texto) abrem o menu. O menu é um `<dialog>` criado pelo JS na primeira abertura e aberto com showModal: uma caixa de busca com role="combobox", aria-expanded, aria-controls, aria-autocomplete="list" e aria-activedescendant, uma lista de resultados com role="listbox" e uma região role="status" que lê a quantidade de resultados. As setas movem a seleção, Enter vai para a página selecionada, Esc fecha pelo comportamento próprio do dialog, clicar no backdrop fecha e o foco volta ao gatilho ao fechar.
4. Índice de busca `/assets/ara.json`: título, tipo (Project, Post, Page), URL, um resumo de uma frase e palavras-chave para cada projeto, post e página principal. Não escreva esse arquivo à mão; gere-o a partir dos mesmos dados que você usa para as páginas de projetos e posts, para que os dois nunca se desencontrem. Faça a busca ignorar os caracteres turcos (toLocaleLowerCase("tr"), depois normalizar ı, ş, ğ, ü, ö, ç), exigir que todas as palavras correspondam e dar mais peso às correspondências no título.
5. Uma página de estudo de caso abre com uma tabela de dados (ano, função, cliente, tecnologia) e a captura de tela que é seu elemento LCP (fetchpriority="high", sem lazy); os títulos dos cards são h2 nas páginas de lista e h3 dentro de uma seção h2 na home.

Schema: ProfilePage na home e em sobre (mainEntity Person), Person (@id /#person: name, jobTitle, url, email, um endereço apenas com cidade e país, knowsAbout e sameAs somente para os perfis que eu informei). O bloco Organization que o seo-stamp escreve representa o seu negócio de empresário individual; ligue a Person a ele com worksFor. Os projetos recebem CollectionPage com hasPart; cada estudo de caso é um CreativeWork (creator Person, dateCreated, image, keywords); os textos recebem Blog e cada post um BlogPosting (headline, image, datePublished, dateModified, author Person; o seo-check gera um erro se image ou datePublished estiver ausente). Palestras, prêmios e listas de clientes contêm apenas fatos verificáveis.

Configuração e armadilhas conhecidas (cada uma custou pontos nas medições da demonstração, não pule nenhuma):
1. Se já houver um site no ar no servidor, avise-me primeiro, porque a configuração sobrescreve index.html e a pasta assets. Mostre a prévia de scaffold_site com confirm=false e chame com confirm=true somente depois que eu aprovar. Depois leia site_design_guide e site_seo_guide. Antes de escrever código, coloque a direção de design (tipografia, cores, grade, elemento marcante, linguagem de movimento e as bibliotecas que NÃO serão carregadas) em um arquivo ART.md curto fora de assets e mostre-o para mim.
2. Compile o Tailwind, não o carregue pelo CDN. Instale-o com site_run_command e background=true (`npm i -D tailwindcss@3`) e acompanhe com site_command_status. Os caminhos de content em `tailwind.config.js` devem cobrir todos os arquivos HTML, os templates `_src` e qualquer arquivo JS que escreva classes. `_src/tw.css` contém a linha `@import "../assets/app.css";` mais as três linhas `@tailwind`; compile-o em um único arquivo com `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Remova o script cdn.tailwindcss.com e o tailwind.config inline de todas as páginas e vincule somente `/assets/site.css`. Recompile após cada alteração no HTML.
3. Hospede as fontes você mesmo. Leia o CSS da família Fontshare escolhida, baixe o woff2 de cada peso separadamente com site_fetch em `assets/fonts/` e escreva as regras @font-face com `font-display: swap` em `assets/app.css`, que é onde o design-check procura uma fonte personalizada. Confira o nome do font-family no CSS baixado e confirme que a família tem as letras turcas ı, İ, ş e ğ (a Tanker não tem ı). Faça preload de TODOS os pesos usados na primeira tela com `<link rel="preload" as="font" type="font/woff2" crossorigin>`, colocado antes da linha da folha de estilo; se forem mais de três arquivos, use menos pesos. Na demonstração, um único peso de corpo sem preload levou o LCP no mobile a 2,6 segundos e o Performance a 97. A maioria das fontes da Fontshare não tem o símbolo ₺, então escreva os preços com "TL".
4. Faça o menu e o rodapé em HTML estático. Não carregue chrome.js, motion.js nem site.config.js nas páginas. Escreva um pequeno `chrome-stamp.mjs` que lê a lista de navegação de site.config.js e carimba `_src/header.tpl` e `_src/footer.tpl` entre os marcadores `` e `` em cada página, adicionando aria-current="page" ao link ativo. Use placeholders como `[[NAV]]` em vez de `{{...}}` e não dê aos templates a extensão .html, caso contrário o design-check e o seo-check os tratam como páginas inacabadas. Construa o menu mobile com um `<details>` sem JS. Mantenha o nome da empresa, o endereço e o telefone como texto simples no rodapé e faça os links do rodapé e do breadcrumb com pelo menos 44 pixels de altura.
5. Converta as imagens ao buscá-las com site_fetch: grave a mesma imagem em arquivos separados com resize="480x", "800x" e "1200x", image_format="webp", quality=60 (o site_fetch não recorta, então peça a origem na proporção de que você precisa). Dê a cada `<img>` srcset, sizes e width e height compatíveis com a proporção real. A imagem que é o elemento LCP da página recebe fetchpriority="high" e não é lazy; todas as outras imagens recebem loading="lazy" decoding="async". Se uma imagem preencher a primeira tela do mobile, sirva um recorte menor ao mobile com `<picture>`.
6. Adicione `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` a todas as páginas e crie um apple-touch-icon de 180 pixels a partir do logotipo com site_fetch e resize="180x180". Sem um link de favicon, o navegador solicita /favicon.ico, registra um 404 e o Best Practices cai para 96.
7. Regras do validador de HTML: comece cada documento com `<!DOCTYPE html>` em maiúsculas; cada espaço no texto visível de um link tel: deve ser `&nbsp;`, inclusive o que vem depois de um prefixo como "Ligue:&nbsp;0212..."; não use style=""; dê um type a cada button; coloque aria-label apenas em landmarks, formulários ou elementos interativos (em um ul ou em um div sem role isso era um erro); nunca dê o mesmo nome a dois landmarks; não deixe espaços em branco no final das linhas.
8. Não pule níveis de título: em uma página de lista, títulos de card como h3 logo após o h1 derrubaram o Accessibility para 98. Ao reutilizar um card, defina o nível do título por página (h2 em uma página de lista, h3 dentro de uma seção h2).
9. Dê ao atributo de movimento o nome data-reveal (o design-check só reconhece movimento por esse nome). O JS aplica o estado inicial oculto apenas aos blocos que estão abaixo da tela quando a página abre e nunca esconde o conteúdo da primeira tela; use transform, pois o fade com opacity reduz a auditoria de contraste. Coloque o atributo no bloco que envolve um título e sua descrição, não apenas no título; na demonstração, um título em espera deslizou por cima do parágrafo abaixo dele. Com prefers-reduced-motion: reduce nada é ocultado e as animações ficam desativadas.

SEO, AEO e GEO:
1. Use URLs em estilo de diretório com barra final. Preencha o bloco seo de site.config.js e execute `node seo-stamp.mjs`. Escreva o schema específico de cada página em blocos `<script type="application/ld+json">` separados, ligados ao grafo base por @id. Não aninhe BreadcrumbList dentro de @graph; mantenha-o em um bloco próprio, que é a única forma de o seo-check enxergá-lo.
2. Títulos com no máximo 60 caracteres (o seo-check sinaliza como erro qualquer um com menos de 25 ou mais de 65), descrições com 130 a 158 caracteres, um h1 por página e pelo menos 150 palavras de conteúdo principal em cada página. Páginas de contato, privacidade e de lista tendem a ficar curtas; adicione informações específicas da página, não enchimento.
3. O primeiro parágrafo de cada página responde diretamente à pergunta da página. Escreva FAQs específicas da página com `<details>` e marque-as como FAQPage. Mostre o publisher e uma data de "Última atualização" em um elemento `<time>`.
4. No robots.txt, escreva sua decisão com um motivo para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot e CCBot, e aponte para o sitemap. O sitemap.xml traz datas lastmod reais. O llms.txt contém um resumo preciso do site em duas frases e uma lista das páginas importantes.
5. Sem invenções: não escreva avaliações, notas, prêmios, números de clientes, certificados, horários de funcionamento, coordenadas nem preços sem me perguntar. Deixe totalmente fora do schema qualquer campo que você não conheça.

Portões (em ordem; não diga "pronto" até que todos passem):
1. Com site_run_command, execute `node chrome-stamp.mjs`, o build do Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 erros, 0 avisos), `node design-check.mjs` (0 erros; justifique qualquer aviso restante) e `npx html-validate "**/*.html"` (0 erros).
2. Veja cada página com site_preview, view="mobile" e view="desktop". O site_preview captura a página com o movimento desativado (reduced-motion); se faltar conteúdo nessa captura, o estado estático está quebrado. Em capturas de página inteira, elementos fixos como uma barra sticky podem aparecer no meio da página e imagens lazy mais abaixo podem aparecer em branco; não conte isso como erro, mas confira os caminhos delas.
3. Execute core_web_vitals para cada página com strategy="mobile" e strategy="desktop". Critério de aceitação: no mobile, Performance de pelo menos 95 (meta de 99 a 100) e Accessibility, Best Practices e SEO 100; no desktop, os quatro em 100. Para uma página que não atingir, use resources=true para encontrar o arquivo que a atrasa, corrija e meça de novo. Depois execute seo_audit na home com strategy="mobile" e runs=2. Nenhum endereço fora do seu próprio domínio pode permanecer na lista de requisições de rede.
4. Sem rolagem horizontal em 360, 390, 768 e 1440 pixels de largura, alvos de toque de pelo menos 44 pixels, sem erros no console.

Verificação de interação: o site_preview não consegue mostrar hover, atalhos de teclado nem dialogs. Explique como verificar em um desktop que a luz acompanha o ponteiro sobre os cards; que Ctrl K, Cmd K e / abrem o menu; que digitar sem os caracteres turcos ainda encontra resultados ("erisilebilir" e similares); que as setas e o Enter levam a um post; que o foco volta ao botão Buscar após o Esc; e que, com o JavaScript desativado, o link Buscar abre a página de projetos.

Depois de publicar: mostre a prévia da regra `/assets/* Cache-Control: public, max-age=31536000, immutable` com site_headers e aplique-a quando eu aprovar; a partir daí, versione o nome do arquivo sempre que o CSS ou o JS mudar (site-v2.css e assim por diante). Envie o sitemap.xml com gsc_submit_sitemap e verifique a home com gsc_url_inspect. No final, entregue: uma tabela de pontuações por página (página, quatro pontuações mobile, quatro pontuações desktop, LCP, CLS), o resultado de cada portão e a lista das correções aplicadas.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um site imobiliário com grade de imóveis filtrável e páginas de anúncio geradas a partir de um único arquivo JSON

Cria um site para a sua imobiliária no seu servidor de hospedagem que gera todos os anúncios a partir de um único arquivo JSON: os filtros de bairro, quartos e preço são gravados na URL e podem ser compartilhados, e cada imóvel ganha uma página estática com galeria, mapa e schema RealEstateListing. Nenhuma biblioteca de mapa ou galeria é carregada e todos os imóveis ficam visíveis com o JavaScript desativado.

Quando usarQuando você quer publicar os imóveis da sua imobiliária no seu próprio site como uma lista filtrável, com uma página própria e rápida para cada imóvel, que os mecanismos de busca consigam ler.

No site [nome do servidor] do meu servidor de hospedagem Opus Growth, crie um site de anúncios estático e rápido para minha imobiliária [nome da agência], que gere todos os anúncios a partir de um único arquivo JSON. Imobiliária: [cidade, os bairros em que atuo, venda ou aluguel]. Número do meu registro profissional de corretagem de imóveis (Taşınmaz Ticareti Yetki Belgesi): [número da licença]. Anúncios: [for each listing the listing no, title, district, neighbourhood, rooms, gross and net square metres, floor, year built, heating, service charge, title deed status, price, listing date, a two-paragraph description, four key features, photo links and the location detail the owner has agreed to show]. Contato: [telefone], [número do WhatsApp], [e-mail], [endereço do escritório]. Domínio: [domínio].

Páginas: início (um formulário de busca por bairro/região, quartos e preço máximo, anúncios em destaque, um guia das regiões, FAQ), anúncios (/ilanlar/: filtros, contagem de resultados, grade de anúncios, FAQ dos anúncios), uma página por anúncio (/ilanlar/[bairro-regiao-a-venda-quartos-tipo]/), sobre (/hakkimizda/: as etapas da compra e o registro profissional), contato (/iletisim/, sem formulário), privacidade (/gizlilik/) e 404.html.

Estilo: imobiliário editorial e acolhedor. Fundo areia claro, texto cor de tinta, um único tom de destaque escuro, como verde-pinho (texto branco nos botões), uma fonte serifada da Fontshare para títulos e preços (por exemplo, Sentient 500) e uma sem serifa para o texto corrido (por exemplo, Ranade 400). Cards de anúncio com foto 4:3, preço grande em serifa e pequenas tags para quartos, metros quadrados e andar. A foto do card dá um leve zoom ao passar o mouse. Nenhuma biblioteca de mapa, nenhum iframe do Google Maps e nenhuma biblioteca de galeria ou slider são carregados.

Fonte única e geração:
1. Todos os dados dos anúncios ficam em `assets/ilanlar.json`. Escreva um pequeno `ilan-build.mjs` e execute-o com site_run_command como `node ilan-build.mjs`: (a) ele gera `ilanlar/[slug]/index.html` para cada anúncio a partir do template `_src/ilan.tpl`, (b) ele preenche todos os cards entre `` em `ilanlar/index.html` e os destacados entre `` na página inicial, (c) ele escreve o schema ItemList da página de anúncios entre ``. Use placeholders como `[[PREÇO]]` no template, não `{{...}}`. Ordem: ilan-build, chrome-stamp, build do Tailwind, seo-stamp. Adicionar um anúncio ou remover um já vendido deve significar editar o JSON e executar essa ordem novamente; quando a página de um anúncio vendido for excluída, redirecione a URL dela para /ilanlar/ com site_redirects.
2. Os cards são HTML estático gerado no servidor, então todo anúncio fica visível com JS desativado e para os mecanismos de busca. Cada card tem os atributos data-ilce, data-oda, data-fiyat, data-m2 e data-tarih para o filtro; os nomes de classe dos componentes não devem conflitar com utilitários do Tailwind (use um prefixo como lcard).

Regras do filtro:
1. O filtro é um formulário de verdade com action="/ilanlar/" e method="get": selects com rótulos para bairro/região, quartos, preço mínimo, preço máximo e ordenação, mais um botão "Filtrar". Com JS desativado, o formulário preenche a URL, mas a lista não muda; diga isso em uma frase dentro de `<noscript>`.
2. O `ilan-filtre.js` é carregado com defer somente em /ilanlar/: ao carregar, ele lê ?ilce=&oda=&min=&max=&sira= com URLSearchParams (aceitando só valores que existam nos selects), oculta e mostra cards com hidden, reordena o DOM para a ordenação e atualiza a URL com history.replaceState a cada mudança. A lista filtrada pode ser compartilhada como link e o histórico do botão voltar não fica cheio.
3. Anuncie a contagem de resultados em uma frase com role="status" ("2 de 6 anúncios correspondem aos seus filtros"). Sem resultados, mostre uma mensagem de estado vazio e um link "Limpar filtros". A caixa de filtro fica na primeira tela, então o JS não deve adicionar nem ocultar nada ali; só os cards mudam, caso contrário ocorre mudança de layout (CLS).
4. Na página de anúncios, a foto do primeiro card não é lazy e as demais são; os títulos dos cards são h2 nessa página e h3 sob o h2 "Anúncios em destaque" na página inicial.

Página do anúncio:
1. O primeiro parágrafo resume o anúncio em uma frase: bairro, região, quartos, metros quadrados, ano de construção e preço. Depois vem a faixa de fotos: figures que rolam na horizontal com CSS scroll-snap e sem JS, com miniaturas abaixo que são links internos para cada foto. O `galeri.js` (somente nas páginas de anúncio) intercepta os cliques nas miniaturas, rola apenas a faixa sem fazer a página pular e marca a miniatura da foto visível com aria-current="true" por meio de um IntersectionObserver. A primeira foto é o elemento LCP da página: fetchpriority="high", sem lazy.
2. Uma caixa de preço fixa (sticky) na coluna da direita: o preço, uma lista de dados (dl: preço, nº do anúncio, quartos, metros quadrados brutos e líquidos, andar, ano de construção, aquecimento, taxa de condomínio, escritura, data do anúncio), um link de WhatsApp com mensagem preenchida que inclui o número do anúncio, o telefone e o número do registro profissional. As regras turcas exigem o número do registro nos anúncios de imóveis; coloque-o também no rodapé.
3. Localização: não publique o endereço completo. Use uma imagem de mapa estática local que mostre a localização aproximada no nível que o proprietário autorizou (geralmente o bairro) e diga abaixo dela que o endereço completo é informado na visita. Se você montar o mapa com tiles do OpenStreetMap, siga a política de uso de tiles (uma vez por anúncio, poucos tiles, sem downloads em massa): busque os tiles com site_fetch em `_src/harita/`, instale o sharp com site_run_command e background=true (`npm i -D sharp`), depois use um pequeno script para unir os tiles, recortar em torno do centro, marcar a área aproximada com um círculo semitransparente e salvar arquivos WebP de 480 e 768 pixels. Se o recorte passar da área dos tiles, aparece uma faixa preta na borda; busque pelo menos 5x3 tiles em torno do centro. Escreva o crédito "© OpenStreetMap contributors" tanto dentro da imagem quanto como link embaixo dela. O mapa carrega de forma lazy e nenhum script de mapa externo entra na página.

Schema: na página do anúncio, RealEstateListing (url, name, description, datePosted, um array de imagens, offers com um Offer: price, priceCurrency "TRY", availability e o @id do negócio como seller) com um Apartment ou SingleFamilyResidence como mainEntity (numberOfRooms, numberOfBedrooms, numberOfBathroomsTotal, floorSize como QuantitativeValue com unitCode "MTK", yearBuilt e um address apenas com região, província e país). O Google não mostra um rich result específico para esses tipos; o objetivo é que os mecanismos de busca e de IA leiam corretamente o preço, o número de quartos e a localização. CollectionPage e ItemList na página de anúncios, businessType "RealEstateAgent" no seo-stamp para a imobiliária, BreadcrumbList em todas as páginas internas. Use preço, metros quadrados, taxa de condomínio e dados da escritura somente a partir da declaração escrita do proprietário; deixe de fora, tanto do JSON quanto do schema, qualquer coisa que você não saiba.

Configuração e armadilhas conhecidas (cada uma custou pontos nas medições da demo, não pule nenhuma):
1. Se já houver um site no ar no servidor, avise-me primeiro, porque a configuração sobrescreve o index.html e a pasta assets. Faça a prévia do scaffold_site com confirm=false e chame-o com confirm=true somente depois da minha aprovação. Depois leia site_design_guide e site_seo_guide. Antes de escrever código, coloque a direção de design (tipografia, cores, grade, elemento marcante, linguagem de movimento e as bibliotecas que NÃO serão carregadas) em um pequeno arquivo ART.md fora de assets e mostre para mim.
2. Compile o Tailwind, não o carregue pela CDN. Instale-o com site_run_command e background=true (`npm i -D tailwindcss@3`) e acompanhe com site_command_status. Os caminhos de content em `tailwind.config.js` devem cobrir todos os arquivos HTML, os templates de `_src` e qualquer arquivo JS que escreva classes. O `_src/tw.css` contém a linha `@import "../assets/app.css";` mais as três linhas `@tailwind`; compile-o em um único arquivo com `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Remova o script cdn.tailwindcss.com e o tailwind.config inline de todas as páginas e vincule apenas `/assets/site.css`. Recompile após cada alteração no HTML.
3. Hospede as fontes você mesmo. Leia o CSS da família Fontshare escolhida, baixe o woff2 de cada peso separadamente com site_fetch em `assets/fonts/` e escreva as regras @font-face com `font-display: swap` em `assets/app.css`, que é onde o design-check procura uma fonte personalizada. Confira o nome do font-family no CSS baixado e confirme que a família tem as letras turcas ı, İ, ş e ğ (a Tanker não tem ı). Faça preload de TODOS os pesos usados na primeira tela com `<link rel="preload" as="font" type="font/woff2" crossorigin>`, colocado antes da linha do stylesheet; se forem mais de três arquivos, use menos pesos. Na demo, um único peso de texto sem preload levou o LCP mobile a 2,6 segundos e a Performance a 97. A maioria das fontes da Fontshare não tem o símbolo ₺, então escreva os preços com "TL".
4. Faça o menu e o rodapé em HTML estático. Não carregue chrome.js, motion.js nem site.config.js nas páginas. Escreva um pequeno `chrome-stamp.mjs` que leia a lista de navegação de site.config.js e preencha `_src/header.tpl` e `_src/footer.tpl` entre os marcadores `` e `` em todas as páginas, adicionando aria-current="page" ao link ativo. Use placeholders como `[[NAV]]` em vez de `{{...}}` e não dê aos templates a extensão .html, senão o design-check e o seo-check os tratam como páginas inacabadas. Construa o menu mobile com um `<details>` sem JS. Mantenha o nome da empresa, o endereço e o telefone como texto simples no rodapé e faça os links do rodapé e do breadcrumb terem pelo menos 44 pixels de altura.
5. Converta as imagens ao buscá-las com site_fetch: grave a mesma imagem em arquivos separados com resize="480x", "800x" e "1200x", image_format="webp", quality=60 (o site_fetch não recorta, então peça a origem na proporção de que você precisa). Dê a cada `<img>` srcset, sizes e width e height compatíveis com a proporção real. A imagem que é o elemento LCP da página recebe fetchpriority="high" e não é lazy; todas as outras imagens recebem loading="lazy" decoding="async". Se uma imagem preencher a primeira tela do mobile, sirva um recorte menor para mobile com `<picture>`.
6. Adicione `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` a todas as páginas e crie um apple-touch-icon de 180 pixels a partir do logo com site_fetch e resize="180x180". Sem o link do favicon, o navegador solicita /favicon.ico, registra um 404 e as Boas Práticas caem para 96.
7. Regras do validador de HTML: comece cada documento com `<!DOCTYPE html>` em maiúsculas; todo espaço no texto visível de um link tel: deve ser `&nbsp;`, inclusive o que vem depois de um prefixo como "Ligue:&nbsp;0212..."; não use style=""; dê um type a todo botão; coloque aria-label apenas em landmarks, formulários ou elementos interativos (em um ul ou em uma div sem role foi erro); nunca dê o mesmo nome a dois landmarks; não deixe espaços em branco no fim das linhas.
8. Não pule níveis de título: em uma página de lista, títulos de card como h3 logo depois do h1 derrubaram a Acessibilidade para 98. Ao reutilizar um card, defina o nível do título por página (h2 em uma página de lista, h3 dentro de uma seção h2).
9. Dê ao atributo de movimento o nome data-reveal (o design-check só reconhece movimento por esse nome). O JS aplica o estado inicial oculto apenas aos blocos que ficam abaixo da tela quando a página abre e nunca oculta o conteúdo da primeira tela; use transform, porque desvanecer com opacity reduz a auditoria de contraste. Coloque o atributo no bloco que envolve um título e sua descrição, não apenas no título; na demo, um título em espera deslizou por cima do parágrafo abaixo. Com prefers-reduced-motion: reduce nada é ocultado e as animações ficam desativadas.

SEO, AEO e GEO:
1. Use URLs em estilo de diretório com barra final. Preencha o bloco seo de site.config.js e execute `node seo-stamp.mjs`. Escreva o schema específico de cada página em blocos `<script type="application/ld+json">` separados, ligados ao grafo base por @id. Não aninhe o BreadcrumbList dentro do @graph; mantenha-o em um bloco próprio, que é a única forma de o seo-check enxergá-lo.
2. Títulos com no máximo 60 caracteres (o seo-check marca como erro qualquer um com menos de 25 ou mais de 65), descrições de 130 a 158 caracteres, um h1 por página e pelo menos 150 palavras de conteúdo principal em cada página. As páginas de contato, privacidade e lista tendem a ficar curtas; adicione informações específicas da página, não enchimento.
3. O primeiro parágrafo de cada página responde diretamente à pergunta da página. Escreva FAQs específicas de cada página com `<details>` e marque-as como FAQPage. Mostre o publisher e uma data de "Última atualização" em um elemento `<time>`.
4. No robots.txt, escreva sua decisão, com o motivo, para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot e CCBot, e aponte para o sitemap. O sitemap.xml traz datas lastmod reais. O llms.txt contém um resumo preciso do site em duas frases e uma lista das páginas importantes.
5. Sem invenções: não escreva avaliações, notas, prêmios, números de clientes, certificados, horários de funcionamento, coordenadas nem preços sem me perguntar. Deixe qualquer campo que você não conheça totalmente fora do schema.

Portões de qualidade (em ordem; não diga "pronto" até que todos passem):
1. Com site_run_command, execute `node chrome-stamp.mjs`, o build do Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 erros, 0 avisos), `node design-check.mjs` (0 erros; justifique qualquer aviso restante) e `npx html-validate "**/*.html"` (0 erros).
2. Veja cada página com site_preview, view="mobile" e view="desktop". O site_preview captura a página com movimento desativado (reduced-motion); se faltar conteúdo nessa captura, o estado estático está quebrado. Em capturas de página inteira, elementos fixos como uma barra sticky podem aparecer no meio da página e imagens lazy mais abaixo podem aparecer em branco; não conte isso como erro, mas confira os caminhos delas.
3. Execute core_web_vitals para cada página com strategy="mobile" e strategy="desktop". Critério de aceitação: no mobile, Performance de pelo menos 95 (meta de 99 a 100) e Acessibilidade, Boas Práticas e SEO em 100; no desktop, as quatro em 100. Para uma página que não atingir, use resources=true para encontrar o arquivo que a atrasa, corrija e meça de novo. Depois execute seo_audit na página inicial com strategy="mobile" e runs=2. Nenhum endereço fora do seu próprio domínio pode restar na lista de requisições de rede.
4. Sem rolagem horizontal em 360, 390, 768 e 1440 pixels de largura, alvos de toque de pelo menos 44 pixels e nenhum erro no console.

Verificação de interação: o site_preview não consegue operar o filtro. Diga-me como verificar que abrir /ilanlar/?ilce=[bairro]&oda=3%2B1 mostra apenas os anúncios correspondentes e preenche o formulário, que alterar um select atualiza a barra de endereço, que a mensagem de estado vazio aparece quando nada corresponde, que todos os anúncios são exibidos com JavaScript desativado e que clicar em uma miniatura na página de um anúncio rola apenas a faixa de fotos sem fazer a página pular.

Depois de publicar: faça a prévia da regra `/assets/* Cache-Control: public, max-age=31536000, immutable` com site_headers e aplique-a quando eu aprovar; a partir daí, versione o nome do arquivo sempre que o CSS ou o JS mudar (site-v2.css e assim por diante). Envie o sitemap.xml com gsc_submit_sitemap e verifique a página inicial com gsc_url_inspect. No final, entregue-me: uma tabela de notas por página (página, as quatro notas mobile, as quatro notas desktop, LCP, CLS), o resultado de cada portão e a lista das correções aplicadas.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um site de produto SaaS com bento grid estilo Webflow e alternância de preço mensal/anual

Cria um site de marketing para o seu produto de software no seu servidor de hospedagem, no estilo dos templates SaaS do Webflow: um bento grid de recursos, uma faixa de logos com pausa, uma vitrine de produto com abas e uma alternância de preço mensal/anual que funciona sem JavaScript. As interações usam 3 KB de JS puro, nenhum depoimento inventado é adicionado e todas as páginas são medidas.

Quando usarQuando você quer um visual no estilo de template do Webflow para o seu produto de software, com blocos bento e um seletor de preços, mas sem mensalidade de plataforma, scripts pesados ou depoimentos falsos.

No site [nome do servidor] do meu servidor de hospedagem Opus Growth, crie um site de marketing estático e rápido para o meu produto de software [nome do produto], com a cara dos templates modernos de SaaS do Webflow, mas sem usar o Webflow. Produto: [o que faz e para quem, em uma frase]. Principais recursos: [seis recursos, uma frase para cada]. Capturas de tela do app: [links para três capturas de tela e o que cada uma mostra]. Planos: [nomes dos planos, preços mensais e anuais, se os impostos estão incluídos, o que cada plano inclui]. Logos de clientes que tenho autorização por escrito para exibir: [arquivos de logotipo ou "nenhum"]. Depoimentos de clientes: [depoimento aprovado, nome, cargo, empresa ou "nenhum"]. Empresa: [razão social], [endereço], [telefone], [e-mail], [número do WhatsApp]. Caminho de cadastro ou demonstração: [URL da página de cadastro ou "pedidos de demonstração por WhatsApp e e-mail"]. Domínio: [domínio].

Páginas: home (hero com uma captura de tela do produto, faixa de logos, grade bento de recursos, vitrine do produto em abas, depoimentos de clientes, FAQ, chamada final para ação), recursos (/ozellikler/, cada recurso com seu próprio título e âncora), preços (/fiyatlar/: alternador, cards de planos, tabela comparativa, FAQ de cobrança), contato (/iletisim/, sem formulário; e-mail, WhatsApp com mensagem pré-preenchida e telefone), privacidade (/gizlilik/) e 404.html.

Estilo: SaaS moderno com fundo claro. Se nenhuma [preferência de cor] for informada, use um fundo off-white quente, texto preto-tinta e um único destaque vibrante (usado apenas como fundo, com texto escuro sobre ele). Dois pesos de uma mesma família da Fontshare (por exemplo, Satoshi 400 e 700). Tiles bento grandes e arredondados, botões em formato de pílula, a captura de tela do produto dentro de uma moldura de janela escura. Sem gradientes de roxo para azul e sem efeito de vidro em tudo.

Regras de interação (interações do Webflow sem biblioteca):
1. GSAP, Lenis e Swiper NÃO são carregados. Escreva as interações em CSS mais um único arquivo JS puro de no máximo 3 KB, carregado com defer apenas na home. O alternador de preços não precisa de script.
2. Grade bento: uma grade CSS de 4 colunas no desktop, com um tile 2x2 e dois tiles de 2 colunas de largura, organizados de modo que nenhuma célula fique vazia; uma coluna no mobile. Cada tile traz um link real para o título correspondente na página de recursos e o tile inteiro é clicável: dê ao link um ::after com inset:0 (um stretched link) e não coloque um segundo link no tile. Ao passar o mouse e em :focus-within, a borda escurece, o tile sobe 4 pixels com transform e o pequeno fragmento de interface dentro dele se move (uma lista de passos desliza para o lado, barras crescem com scaleY).
3. A faixa de logos usa apenas logos de clientes que deram autorização por escrito; se não houver nenhum, deixe a seção de fora e não a substitua por logos fictícios nem por uma lista inventada de "integrações". A faixa é feita de duas cópias da mesma lista (a segunda com aria-hidden="true") que se movem com um @keyframes translate3d(-50%, 0, 0) em CSS; ela pausa ao passar o mouse e ao receber foco. Como o movimento dura mais de cinco segundos, a WCAG 2.2.2 exige um botão "Pausar faixa": o botão fica oculto no HTML, o JS o revela e atualiza aria-pressed e o rótulo. Dê à linha que contém o botão um min-height igual à altura do botão; na demonstração a linha crescia quando o botão aparecia e foi medido um pequeno deslocamento (CLS 0,002) no desktop. Com prefers-reduced-motion a animação para, a cópia fica oculta e os logos viram uma grade estática com quebra de linha.
4. Vitrine do produto em abas: no HTML, as abas são links internos da página para os painéis (href="#ekran-x") e os três painéis ficam visíveis um embaixo do outro, de modo que o conteúdo fica completo com o JS desativado e para os crawlers. Dê ao contêiner das abas role="group" e um aria-label. O JS as transforma em role="tablist", "tab" e "tabpanel", gerencia aria-selected, aria-controls, tabindex e hidden, oferece suporte às setas esquerda e direita, Home e End, e seleciona a aba correspondente quando a página é aberta com #ekran-x. Os painéis ficam abaixo da primeira tela, então ocultá-los não causa deslocamento de layout; as imagens dos painéis usam loading="lazy".
5. O alternador de preços funciona sem JS: dois botões de opção (radio) dentro de um fieldset (Mensal marcado por padrão) e regras como `.pricing:has(#donem-yillik:checked) .price-m { display: none }` que revelam os preços anuais. Oculte o radio visualmente, mas mantenha o label inteiro clicável e focável pelo teclado; mostre o anel de foco com `label:has(input:focus-visible)`. Na visão mensal, cada plano exibe uma linha "Cobrado anualmente: X TL", de modo que os dois preços existam no texto.
6. Os depoimentos de clientes vêm apenas de citações aprovadas que possam ser verificadas por nome, cargo e empresa. Se você não tiver nenhuma, remova a seção; se usar uma durante o rascunho, faça dela um card placeholder com borda tracejada informando que será preenchido quando chegar um depoimento real, e pergunte-me antes de publicar. Não escreva schema de Review nem de aggregateRating.
7. A captura de tela do produto no hero é o elemento LCP no desktop: fetchpriority="high", sem lazy, com sizes indicando sua largura real. No mobile o LCP costuma ser o texto do título; a captura de tela ainda deve carregar a versão de 480 pixels por meio do srcset.

Schema: SoftwareApplication na home e na página de preços (name, applicationCategory "BusinessApplication", operatingSystem, url, image, publisher e uma Offer por plano e período de cobrança: name, price, priceCurrency "TRY", url). O Google exige uma avaliação ou review para o rich result de aplicativo de software; sem avaliações genuínas coletadas no seu próprio site, nenhuma estrela será exibida, e isso não deve ser resolvido com uma nota inventada. FAQPage na home, em recursos e em preços, ContactPage em contato, BreadcrumbList nas páginas internas. O primeiro parágrafo da página de preços responde diretamente: "Os preços do [nome do produto] começam em N TL por mês". A tabela comparativa é uma `<table>` de verdade e rola na horizontal em telas estreitas dentro de `<section tabindex="0" aria-label="...">`; na demonstração, uma div com role="region" disparou prefer-native-element, e duas sections rotuladas pelo mesmo título dispararam unique-landmark.

Configuração e armadilhas conhecidas (cada uma custou pontos nas medições da demonstração, não pule nenhuma):
1. Se já houver um site no ar no servidor, avise-me primeiro, porque a configuração sobrescreve o index.html e a pasta assets. Faça a prévia de scaffold_site com confirm=false e chame-o com confirm=true somente depois que eu aprovar. Em seguida, leia site_design_guide e site_seo_guide. Antes de escrever código, coloque a direção de design (tipografia, cores, grade, elemento de assinatura, linguagem de movimento e as bibliotecas que NÃO serão carregadas) em um pequeno arquivo ART.md fora de assets e mostre-o para mim.
2. Compile o Tailwind, não o carregue pelo CDN. Instale-o com site_run_command e background=true (`npm i -D tailwindcss@3`) e acompanhe com site_command_status. Os caminhos de content em `tailwind.config.js` devem cobrir todos os arquivos HTML, os templates de `_src` e qualquer arquivo JS que escreva classes. `_src/tw.css` contém a linha `@import "../assets/app.css";` mais as três linhas `@tailwind`; compile-o em um único arquivo com `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Remova o script cdn.tailwindcss.com e o tailwind.config inline de todas as páginas e vincule apenas `/assets/site.css`. Recompile após cada alteração no HTML.
3. Hospede as fontes você mesmo. Leia o CSS da família Fontshare escolhida, baixe o woff2 de cada peso separadamente com site_fetch em `assets/fonts/` e escreva as regras @font-face com `font-display: swap` em `assets/app.css`, que é onde o design-check procura uma fonte personalizada. Confira o nome do font-family no CSS baixado e confirme que a família tem as letras turcas ı, İ, ş e ğ (a Tanker não tem ı). Faça preload de TODOS os pesos usados na primeira tela com `<link rel="preload" as="font" type="font/woff2" crossorigin>`, posicionado antes da linha do stylesheet; se forem mais de três arquivos, use menos pesos. Na demonstração, um único peso de texto sem preload empurrou o LCP no mobile para 2,6 segundos e a Performance para 97. A maioria das fontes da Fontshare não tem o símbolo ₺, então escreva os preços com "TL".
4. Faça o menu e o rodapé em HTML estático. Não carregue chrome.js, motion.js nem site.config.js nas páginas. Escreva um pequeno `chrome-stamp.mjs` que leia a lista de navegação de site.config.js e carimbe `_src/header.tpl` e `_src/footer.tpl` entre os marcadores `` e `` em todas as páginas, adicionando aria-current="page" ao link ativo. Use placeholders como `[[NAV]]` em vez de `{{...}}` e não dê aos templates a extensão .html, senão o design-check e o seo-check os tratam como páginas inacabadas. Construa o menu mobile com um `<details>` sem JS. Mantenha o nome da empresa, o endereço e o telefone como texto simples no rodapé e faça os links do rodapé e do breadcrumb terem pelo menos 44 pixels de altura.
5. Converta as imagens ao buscá-las com site_fetch: grave a mesma imagem como arquivos separados com resize="480x", "800x" e "1200x", image_format="webp", quality=60 (o site_fetch não recorta, então peça a origem na proporção de que você precisa). Dê a cada `<img>` srcset, sizes, width e height que correspondam à proporção real. A imagem que é o elemento LCP da página recebe fetchpriority="high" e não é lazy; todas as outras imagens recebem loading="lazy" decoding="async". Se uma imagem preencher a primeira tela no mobile, sirva um recorte menor para o mobile com `<picture>`.
6. Adicione `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` a todas as páginas e gere um apple-touch-icon de 180 pixels a partir do logo com site_fetch e resize="180x180". Sem o link de favicon, o navegador solicita /favicon.ico, registra um 404 e as Práticas recomendadas caem para 96.
7. Regras do validador de HTML: comece cada documento com um `<!DOCTYPE html>` em maiúsculas; todo espaço no texto visível de um link tel: deve ser `&nbsp;`, inclusive o que vem depois de um prefixo como "Ligue:&nbsp;0212..."; não use style=""; dê um type a todo botão; coloque aria-label apenas em landmarks, formulários ou elementos interativos (em um ul ou em uma div sem role, deu erro); nunca rotule dois landmarks com o mesmo nome; não deixe espaços em branco no final das linhas.
8. Não pule níveis de título: em uma página de lista, títulos de cards como h3 logo após o h1 derrubaram a Acessibilidade para 98. Ao reutilizar um card, defina o nível do título por página (h2 em uma página de lista, h3 dentro de uma seção h2).
9. Chame o atributo de movimento de data-reveal (o design-check só reconhece movimento por esse nome). O JS dá o estado inicial oculto apenas aos blocos que estão abaixo da tela quando a página abre e nunca oculta o conteúdo da primeira tela; use transform, pois fazer fade com opacity reduz a auditoria de contraste. Coloque o atributo no bloco que envolve um título e sua descrição, não só no título; na demonstração, um título em espera deslizou sobre o parágrafo abaixo dele. Com prefers-reduced-motion: reduce nada é ocultado e as animações ficam desativadas.

SEO, AEO e GEO:
1. Use URLs no estilo de diretório com barra final. Preencha o bloco seo de site.config.js e execute `node seo-stamp.mjs`. Escreva o schema específico de cada página em blocos `<script type="application/ld+json">` separados, vinculados ao grafo base por @id. Não aninhe BreadcrumbList dentro de @graph; mantenha-o em seu próprio bloco, que é a única forma de o seo-check enxergá-lo.
2. Títulos com no máximo 60 caracteres (o seo-check sinaliza como erro qualquer um abaixo de 25 ou acima de 65), descrições de 130 a 158 caracteres, um h1 por página e pelo menos 150 palavras de conteúdo principal em cada página. Páginas de contato, privacidade e de lista tendem a ficar curtas; acrescente informações específicas da página, não enchimento.
3. O primeiro parágrafo de cada página responde diretamente à pergunta da página. Escreva FAQs específicas de cada página com `<details>` e marque-as como FAQPage. Mostre o publisher e uma data de "Última atualização" em um elemento `<time>`.
4. No robots.txt, escreva sua decisão com o motivo para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot e CCBot, e aponte para o sitemap. O sitemap.xml traz datas lastmod reais. O llms.txt contém um resumo preciso do site em duas frases e uma lista das páginas importantes.
5. Sem invenções: não escreva avaliações, notas, prêmios, números de clientes, certificados, horários de funcionamento, coordenadas nem preços sem me perguntar. Deixe totalmente de fora do schema qualquer campo que você não conheça.

Gates (em ordem; não diga "pronto" até que todos passem):
1. Com site_run_command, execute `node chrome-stamp.mjs`, o build do Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 erros, 0 avisos), `node design-check.mjs` (0 erros; justifique qualquer aviso restante) e `npx html-validate "**/*.html"` (0 erros).
2. Veja todas as páginas com site_preview, view="mobile" e view="desktop". O site_preview captura a página com o movimento desativado (reduced-motion); se faltar conteúdo nessa captura, o estado estático está quebrado. Em capturas de página inteira, elementos fixos, como uma barra sticky, podem aparecer no meio da página e imagens lazy mais abaixo podem ficar em branco; não conte isso como erro, mas confira os caminhos delas.
3. Execute core_web_vitals para cada página com strategy="mobile" e strategy="desktop". Critério de aceitação: no mobile, Performance de pelo menos 95 (meta de 99 a 100) e Acessibilidade, Práticas recomendadas e SEO 100; no desktop, os quatro em 100. Para uma página que não atingir a meta, use resources=true para encontrar o arquivo que a atrasa, corrija e meça de novo. Depois execute seo_audit na home com strategy="mobile" e runs=2. Nenhum endereço fora do seu próprio domínio pode permanecer na lista de requisições de rede.
4. Sem rolagem horizontal em 360, 390, 768 e 1440 pixels de largura, alvos de toque de pelo menos 44 pixels, sem erros no console.

Verificação de interação: o site_preview não consegue mostrar hover nem movimento. Diga-me como verificar em um navegador desktop que os tiles bento sobem ao passar o mouse e ao focar com Tab, que o botão "Pausar faixa" para a faixa, que as abas mudam com as setas do teclado, que o alternador de preços mostra os preços anuais mesmo com o JavaScript desativado, e que, em um celular com movimento reduzido, os logos viram uma grade estática.

Depois de publicar: faça a prévia da regra `/assets/* Cache-Control: public, max-age=31536000, immutable` com site_headers e aplique-a quando eu aprovar; a partir daí, versione o nome do arquivo sempre que o CSS ou o JS mudar (site-v2.css e assim por diante). Envie o sitemap.xml com gsc_submit_sitemap e verifique a home com gsc_url_inspect. No final, entregue-me: uma tabela de pontuação página por página (página, quatro notas no mobile, quatro notas no desktop, LCP, CLS), o resultado de cada gate e a lista das correções que você aplicou.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um site rápido de produto de IA com fundo aurora em CSS, cartões de vidro e alternância entre tema escuro e claro

Cria um site de produto de IA no seu servidor de hospedagem com fundo aurora em CSS puro, cartões de vidro fosco e uma alternância entre tema escuro e claro que acompanha a configuração do sistema e lembra a escolha. O contraste é medido nos dois temas, o vidro tem um fallback sólido e todas as páginas são medidas no mobile até chegar a 100.

Quando usarQuando você quer um site moderno e luminoso, com modo escuro, para o seu produto de IA ou software, sem que os efeitos prejudiquem a velocidade ou a legibilidade.

Crie um site de produto com várias páginas, com fundo aurora, cartões de vidro fosco e temas claro e escuro, para [nome do produto de IA] no site [nome do servidor] no meu servidor de hospedagem do Opus Growth. Produto: [o que faz, para quem]. Como funciona: [três etapas]. O que produz ou faz: [4 a 6 recursos]. Dados e segurança: [onde os dados são armazenados, por quanto tempo, se são usados para treinar modelos]. Caminho de teste ou cadastro: [duração do teste, URL de cadastro]. Contato: [e-mail], [telefone], [número do WhatsApp], [endereço]. Domínio: [domínio]. Cores da marca: [cores, ou "você escolhe"]. Capturas de tela ou fotos do produto: [links, ou "nenhum"].

Páginas: início (/), recursos (/ozellikler/), segurança (/guvenlik/), contato (/iletisim/), privacidade (/gizlilik/) e 404.html. Seções da página inicial, em ordem: hero (h1, introdução de duas frases, dois botões e o cartão do produto, que é o elemento marcante), três passos, para quem é (com uma foto), perguntas frequentes e uma chamada final para ação. Em produtos de IA, a página de segurança é metade da decisão de compra; declare com clareza retenção, acesso e treinamento de modelos. Sem formulário na página de contato, porque o servidor serve apenas arquivos estáticos.

Estilo: aurora e vidro. Uma luz suave e multicolorida deslizando devagar ao fundo (a aurora), com o conteúdo sobre cartões de vidro fosco. Nada de paleta do roxo ao azul; escolha três tons suaves que combinem com a marca, como menta, damasco e azul gelo. Tipografia: uma fonte display serifada e suave da Fontshare (por exemplo Gambetta 500) com uma fonte de texto calma (por exemplo Synonym 400 e 600). Use o efeito de vidro apenas nas superfícies dos cartões; não afogue a página em vidro. Sem canvas, WebGL, vídeo, GSAP, Lenis ou Swiper. O único JavaScript é um pequeno alternador de tema inline. Elemento marcante: um cartão de vidro no hero com um exemplo real em HTML do que o produto faz (por exemplo, uma decisão e uma tarefa extraídas da transcrição de uma reunião).

Regras de aurora, vidro e tema (onde este estilo mais facilmente prejudica o desempenho e o contraste):
1. Faça a aurora em CSS puro: uma camada `position: fixed` com aria-hidden, dois pseudoelementos (::before e ::after) e três radial-gradients grandes dentro deles. Anime apenas com transform (translate3d, rotate, scale) em um loop `alternate` de 25 a 35 segundos e adicione `will-change: transform`. Não anime o gradiente em si, background-position nem filter: blur; eles repintam a cada quadro. Coloque a animação dentro de `@media (prefers-reduced-motion: no-preference)`; com movimento reduzido a aurora para, mas continua visível.
2. Defina as cores como variáveis CSS (--bg, --fg, --mute, --line, --card, --solid, --acc, --accfg e os tons da aurora) e aponte as cores do Tailwind para elas (por exemplo colors: {bg: "var(--bg)"}). Escreva os valores escuros tanto em `:root[data-theme="dark"]` quanto em `@media (prefers-color-scheme: dark) { :root:not([data-theme="light"]) }`, para que o tema do sistema valha mesmo com JavaScript desativado.
3. Alternador de tema: um script de uma linha no `<head>`, depois da folha de estilo, lê a escolha salva no localStorage, grava data-theme em `<html>` e adiciona a classe `js`; como roda antes da primeira renderização, a página nunca pisca no tema errado. Envolva o acesso ao localStorage em try. Um pequeno script no fim da página troca o tema ao clicar, salva a escolha e atualiza o botão quando o tema do sistema muda. O botão é um `<button type="button">` de verdade com `aria-pressed` verdadeiro enquanto o escuro estiver ativo, e mantém seu nome acessível ("Tema escuro") mesmo quando só o ícone aparece no celular. Oculte o botão sem JavaScript (`html:not(.js) .theme-toggle { display: none }`). Adicione também `<meta name="color-scheme" content="light dark">`.
4. Mantenha o cartão de vidro em uma única classe `.glass`: primeiro um fundo sólido (--solid), depois, dentro de `@supports (backdrop-filter: blur(1px))`, um fundo translúcido com `backdrop-filter: blur(18px) saturate(140%)` (com o prefixo -webkit- para o Safari). Em `@media (prefers-reduced-transparency: reduce), (prefers-contrast: more)` o cartão fica sólido e a aurora é ocultada. Não use o utilitário backdrop-blur no HTML; o design-check alerta sobre "glassmorphism em todo lugar" quando vê mais de cinco em uma página.
5. Meça o contraste nos DOIS temas. O Lighthouse audita só o tema claro; se você não verificar o escuro separadamente, textos fracos no modo escuro passam despercebidos. Deixe o fundo translúcido do cartão opaco o bastante para manter o texto acima de 4,5:1 mesmo sobre a cor mais brilhante da aurora (na demo, branco a 66 por cento no claro e verde-escuro a 58 por cento no escuro). Troque a cor do texto do botão de destaque por tema (branco sobre verde-pinheiro escuro no claro, verde-escuro sobre menta clara no escuro).
6. Dê ao cartão do hero sua animação de entrada apenas com transform e um atributo data-reveal (o design-check reconhece movimento por esse atributo); nunca oculte nem faça fade no h1, porque ele é o elemento do LCP.

Configuração e armadilhas conhecidas (cada uma custou pontos ou reprovou em um gate na medição da demo, não pule):
1. Se já houver um site no ar no servidor, avise-me primeiro, porque a configuração sobrescreve index.html e a pasta assets. Faça antes a prévia de scaffold_site com confirm=false e só chame confirm=true depois que eu aprovar. Depois leia site_design_guide e site_seo_guide. Antes de escrever código, escreva a direção de design (tipografia, cor, grade, elemento marcante, linguagem de movimento e as bibliotecas que NÃO serão carregadas) em um ART.md curto fora de assets e mostre-o para mim.
2. Compile o Tailwind, não o carregue pela CDN. Instale `npm i -D tailwindcss@3` com site_run_command e background=true, e acompanhe com site_command_status. Os caminhos de content em `tailwind.config.js` devem cobrir todos os arquivos HTML, inclusive subpastas, os modelos `_src/*.tpl` e qualquer arquivo JS que escreva classes. `_src/tw.css` contém a linha `@import "../assets/app.css";` e as três linhas `@tailwind`; compile-o em um único arquivo com `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Remova das páginas o script cdn.tailwindcss.com, o tailwind.config inline, chrome.js e motion.js, e vincule apenas `/assets/site.css`. Recompile após cada alteração no HTML. Como as cores do tema são variáveis, os atalhos de opacidade do Tailwind (como bg-fg/50) não funcionam; defina uma variável separada se precisar de uma cor translúcida.
3. Hospede as fontes você mesmo. Leia o CSS da Fontshare com uma requisição por família e peso (`https://api.fontshare.com/v2/css?f[]=family@weight`), baixe cada arquivo woff2 em `assets/fonts/` com site_fetch e escreva as regras @font-face com `font-display: swap` em `assets/app.css`; o design-check procura a fonte personalizada ali. Faça preload de TODOS os pesos usados acima da dobra (título, texto e botões) em todas as páginas com `<link rel="preload" as="font" type="font/woff2" crossorigin>` e coloque essas linhas antes do link da folha de estilo. A maioria das fontes da Fontshare não tem o sinal ₺, então escreva os preços com "TL".
4. Faça o menu e o rodapé em HTML estático. Escreva um pequeno `chrome-stamp.mjs` que leia a lista de navegação de site.config.js e carimbe `_src/header.tpl` e `_src/footer.tpl` entre os marcadores `` e `` em todas as páginas, adicionando aria-current="page" ao link ativo. Não dê aos modelos a extensão .html e use marcadores como `[[NAV]]` em vez de `{{...}}`. Construa o menu móvel com `<details>` e sem JS. Mantenha o nome da empresa, o endereço e o telefone no rodapé como texto simples, e faça os links do rodapé e do breadcrumb terem pelo menos 44 pixels de altura.
5. Converta as imagens ao baixá-las com site_fetch: grave a mesma foto em arquivos separados com resize="480x", "800x" e "1120x" (ou as larguras que a página precisar), image_format="webp" e quality=65. Dê a cada `<img>` srcset, sizes e width e height que correspondam à proporção real. A imagem principal acima da dobra recebe fetchpriority="high" e não é lazy; dê fetchpriority apenas ao elemento real do LCP, e loading="lazy" decoding="async" ao restante.
6. Escreva um pequeno `favicon.svg` na raiz do site e adicione `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` a todas as páginas; se houver um logotipo em PNG, crie um apple-touch-icon com site_fetch, resize="180x180" e image_format="png". Sem favicon, o navegador registra um 404 para /favicon.ico e Best Practices cai para 96.
7. Regras do validador de HTML: comece todo documento com `<!DOCTYPE html>` em maiúsculas, coloque os atributos entre aspas duplas, use `&nbsp;` nos espaços do texto visível dos links tel:, nunca use o atributo style="" (se precisar de uma variável CSS, use uma classe de propriedade arbitrária do Tailwind como `[--r:-4deg]`), dê type="button" a todo botão, não coloque aria-label em elementos sem role, como `<ul>` ou `<div>`, e use `<section aria-label="...">` em vez de role="region".

SEO, AEO e GEO:
1. Use URLs em estilo de diretório com barra final (/ozellikler/, /guvenlik/, /iletisim/, /gizlilik/ ou seus equivalentes no seu idioma). Preencha o bloco seo de site.config.js e execute `node seo-stamp.mjs`. Para uma empresa de software sem loja física, defina localBusiness:false em site.config.js. Schemas das páginas: início WebPage e FAQPage; recursos SoftwareApplication (applicationCategory, operatingSystem, featureList) e FAQPage; segurança WebPage e FAQPage; contato ContactPage; BreadcrumbList nas páginas internas. Não liste um certificado de segurança ou documento de conformidade que você não possua; se possuir, informe o número e a data de validade. Escreva cada schema específico da página em seu próprio bloco `<script type="application/ld+json">` e ligue-o ao grafo base com @id. Não aninhe BreadcrumbList dentro de @graph; mantenha-o em seu próprio bloco, porque é a única forma de o seo-check enxergá-lo.
2. Títulos de 48 a 60 caracteres (o seo-check trata mais de 65 como erro), descrições de 145 a 158 caracteres, um h1 por página. O conteúdo principal de cada página tem pelo menos 150 palavras. Na demo, as páginas de contato e privacidade ficaram com 84 e 116 palavras na primeira tentativa e foram completadas com informações reais, como "o que acontece durante o teste" e "com quem os dados são compartilhados".
3. O primeiro parágrafo de cada página responde diretamente à pergunta da página, e o h1 é formulado como essa pergunta. Escreva o FAQ próprio da página com `<details>` e marque-o como FAQPage. Mostre a organização que publica e uma data de "Última atualização" com `<time datetime>`.
4. No robots.txt, escreva sua decisão com o motivo para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot e CCBot, e aponte para o sitemap. O sitemap.xml tem um lastmod real. O llms.txt tem um resumo preciso do site em duas frases e uma lista das páginas importantes.
5. Sem invenção: não escreva avaliações, notas, prêmios, número de clientes, certificados, horários de funcionamento, coordenadas, preços ou números do produto sem me perguntar. Deixe de fora do schema qualquer campo que você não conheça.

Gates (em ordem; não diga "pronto" até todos passarem):
1. Com site_run_command, execute em ordem `node chrome-stamp.mjs`, o build do Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 erros, 0 avisos), `node design-check.mjs` (0 erros; justifique qualquer aviso restante) e `npx html-validate "**/*.html"` (0 erros).
2. Veja todas as páginas com site_preview, view="mobile" e view="desktop". O site_preview captura a página com o movimento desativado; se o conteúdo não estiver completo nessa captura, o estado sem movimento está quebrado. Imagens lazy mais abaixo podem aparecer em branco em uma captura de página inteira; não conte isso como erro, mas confira os caminhos. Verifique também o tema escuro: como o site_preview não consegue mudar o tema do sistema, execute uma auditoria de contraste no modo escuro (por exemplo, a regra color-contrast do axe-core com prefers-color-scheme: dark) ou deixe o escuro como padrão temporariamente e veja uma prévia uma vez.
3. Execute core_web_vitals em todas as páginas com strategy="mobile" e strategy="desktop". Critério de aceitação: no mobile, Performance de pelo menos 95 e Accessibility, Best Practices e SEO em 100; no desktop, as quatro de pelo menos 95, meta 100. Para uma página que não atingir, encontre o arquivo lento com resources=true, corrija e meça de novo. Depois execute seo_audit na página inicial com strategy="mobile" e runs=2. A lista de requisições de rede não deve conter nenhum endereço fora do seu próprio domínio (links de loja e de WhatsApp são links, não requisições).
4. Sem rolagem horizontal em 360, 390, 768 e 1440 pixels de largura, alvos de toque de pelo menos 44 pixels, sem erros no console.

Verificação de interação: como o site_preview não consegue executar movimento nem trocar temas, diga-me o que observar no meu próprio navegador: a luz ao fundo desliza bem devagar; clicar no alternador troca o tema, a escolha sobrevive à mudança de página e a página nunca pisca no outro tema durante o carregamento; se o sistema operacional estiver no modo escuro, o site abre escuro; com movimento reduzido ativado, a aurora para; com transparência reduzida ativada, os cartões ficam sólidos; com JavaScript desativado, o alternador fica oculto, mas o tema do sistema continua valendo.

Depois de publicar: faça a prévia da regra `/assets/* Cache-Control: public, max-age=31536000, immutable` com site_headers e aplique-a quando eu aprovar; a partir daí, versione o nome do arquivo sempre que o CSS ou o JS mudar (site-v2.css e assim por diante). Envie o sitemap.xml com gsc_submit_sitemap e verifique a página inicial com gsc_url_inspect. No final, entregue-me: uma tabela de pontuação por página (página, quatro pontuações mobile, quatro pontuações desktop, LCP, CLS), os resultados dos gates e a lista das correções aplicadas.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um site de lookbook de moda com transições de página View Transitions e GSAP Flip

Cria um site de lookbook com várias páginas no seu servidor de hospedagem, em que a imagem do produto cresce da coleção até a página do produto, e o filtro da coleção e a visualização rápida são animados com GSAP Flip. Não há checkout, todo produto traz marcação Product e Offer, e o Flip é carregado apenas na página da coleção depois da primeira renderização.

Quando usarQuando você quer um site com qualidade de revista para sua marca de roupas, acessórios ou têxteis para casa, que mostre os produtos com transições suaves entre as páginas enquanto você vende pelo WhatsApp ou na loja.

Crie um site de moda ou lifestyle em estilo lookbook, com várias páginas e transições de imagem entre elas, para [nome da marca] no site [nome do servidor] do meu servidor de hospedagem Opus Growth. Marca: [o que produz, onde, para quem]. Nome da estação ou coleção: [nome]. Produtos: [para cada um, nome, categoria, cor, material, preço e link da foto]. Tabela de medidas: [medidas, ou "nenhuma"]. Como as pessoas compram: [endereço da oficina ou loja, número de WhatsApp, link da loja, se houver]. Envio e trocas: [se houver]. Contato: [e-mail], [telefone], [endereço]. Domínio: [domínio]. Fotos do lookbook: [links].

Páginas: home do lookbook (/), coleção (/koleksiyon/), uma página separada por produto (/urun/[nome-do-produto]/), ateliê ou sobre (/atolye/), contato (/iletisim/) e 404.html. Seções da home: hero (h1, breve apresentação da marca, dois botões e uma foto principal vertical e alta), um lookbook de três fotos logo abaixo, em que cada foto leva a um produto, a história do material ou da confecção e FAQ. Página da coleção: filtros por categoria e a grade de produtos. Página do produto: imagem grande, nome, preço, um primeiro parágrafo dizendo o que é o produto, uma lista com material, cor, tamanhos e cuidados, uma caixa "Como compro?", a tabela de medidas e dois produtos da mesma coleção. Sem carrinho e sem checkout; a compra acontece pelo WhatsApp, na loja ou no ateliê, e toda página de produto diz isso de forma clara.

Estilo: moda editorial, como um lookbook impresso. Fundo com tom de tecido, fotos em largura total com cantos retos, linhas finas de 1 pixel, rótulos pequenos em maiúsculas com espaçamento entre letras e bastante espaço em branco. Tipografia: uma serifa de moda de alto contraste da Fontshare (por exemplo Melodrama 400 e 600) com um corpo de texto em grotesca calma (por exemplo Archivo 400 e 500). Uma única cor de destaque (por exemplo argila) apenas para anéis de foco e hover. Distribua o trio do lookbook em 5, 4 e 3 colunas de uma grade de 12 colunas, com deslocamento vertical escalonado. Há dois elementos de assinatura: a transição de imagem entre páginas e a visualização rápida com Flip na grade da coleção. Lenis, Swiper, ScrollTrigger e SplitText não são carregados.

Regras da transição de página e do Flip (siga exatamente):
1. View Transitions entre documentos: escreva `@view-transition { navigation: auto; }` em `assets/app.css`. A imagem do card da coleção e a imagem principal da página do produto levam o MESMO view-transition-name; defina-o com uma classe de propriedade arbitrária do Tailwind (`[view-transition-name:u-product-name]`), não com style="". Cada nome pode aparecer apenas uma vez por página, porque o navegador cancela a transição quando dois elementos compartilham um nome; os cards de "mesma coleção" em uma página de produto podem levar os nomes dos seus próprios produtos. Dê ao menu superior `view-transition-name: site-header` para que ele fique parado durante a transição. Duração do grupo de 0,5 segundo, cross-fade da raiz de 0,3 segundo. Dentro de `@media (prefers-reduced-motion: reduce)` escreva `@view-transition { navigation: none; }`. Navegadores sem suporte simplesmente navegam normalmente; não escreva fallback em JavaScript.
2. Carregue o GSAP e o Flip somente na página da coleção; nenhuma outra página tem script. Baixe o núcleo do GSAP 3.13 e o plugin Flip do jsdelivr para `assets/vendor/` com site_fetch e fixe a versão. Um script de uma linha no `<head>` adiciona a classe `js` ao `<html>`, e a classe `anim` a menos que prefers-reduced-motion seja "reduce". Um pequeno loader no fim da página espera o evento load, duas chamadas de requestAnimationFrame e requestIdleCallback, não baixa nada se `anim` estiver ausente e, caso contrário, adiciona gsap.min.js, Flip.min.js e um arquivo minúsculo contendo `gsap.registerPlugin(Flip)`, nessa ordem, com async=false.
3. Separe a interação do Flip: `assets/koleksiyon.js` (defer) executa o filtro e a visualização rápida TAMBÉM sem Flip. A cada mudança, se Flip e `anim` estiverem presentes, chame primeiro `Flip.getState(cards)`, altere o DOM e depois chame `Flip.from(state, {duration: 0.6, ease: "power3.inOut", nested: true})`; caso contrário, aplique a mudança instantaneamente. Assim, quem não quer movimento ainda consegue usar o filtro e a visualização rápida.
4. Filtro: os botões "Todos" e de categoria ficam em um contêiner com `role="group"` e um aria-label, cada um com `aria-pressed`. Os cards que não correspondem recebem `hidden`; no Flip use `absolute: true`, onEnter para os cards que entram (opacity e scale de 0,92 a 1) e onLeave para os que saem. Um elemento com `aria-live="polite"` anuncia o resultado, como "3 produtos exibidos".
5. Visualização rápida (a transformação da imagem da grade para o detalhe): todo card tem um botão "Ver rápido" com `aria-expanded` e `aria-controls` e um painel de detalhes com `hidden` (descrição, dica de estilo, link para a página do produto). Quando aberto, o card ocupa toda a largura com `grid-column: 1 / -1` e, no desktop, se divide em duas colunas, imagem à esquerda e detalhes à direita; o Flip anima a imagem crescendo do tile pequeno para a visualização grande. Atualize o `sizes` da imagem aberta para a visualização grande, de modo que um arquivo maior seja carregado. Apenas um card fica aberto por vez, o texto do botão passa a ser "Fechar" e o foco vai para o painel, que tem tabindex="-1".
6. Sem JavaScript, os botões de filtro e de visualização rápida ficam ocultos (`.js-only` aparece apenas sob `.js`), e todos os links de cards e páginas de produto continuam funcionando. O link principal do card sempre leva à página do produto; a visualização rápida é um botão separado.

Configuração e armadilhas conhecidas (cada uma custou pontos ou reprovou em uma verificação na medição da demo, não pule nenhuma):
1. Se já houver um site no ar no servidor, avise-me primeiro, porque a configuração sobrescreve o index.html e a pasta assets. Mostre a prévia de scaffold_site com confirm=false primeiro e só depois chame com confirm=true, quando eu aprovar. Em seguida, leia site_design_guide e site_seo_guide. Antes de escrever código, escreva a direção de design (tipografia, cor, grade, elemento de assinatura, linguagem de movimento e as bibliotecas que NÃO serão carregadas) em um ART.md curto fora de assets e mostre-o para mim.
2. Compile o Tailwind, não o carregue pela CDN. Instale `npm i -D tailwindcss@3` com site_run_command e background=true, e acompanhe com site_command_status. Os caminhos de content em `tailwind.config.js` devem cobrir todos os arquivos HTML, incluindo subpastas, os templates `_src/*.tpl` e qualquer arquivo JS que escreva classes. `_src/tw.css` contém a linha `@import "../assets/app.css";` e as três linhas `@tailwind`; compile-o em um único arquivo com `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Remova das páginas o script cdn.tailwindcss.com, o tailwind.config inline, chrome.js e motion.js, e vincule apenas `/assets/site.css`. Recompile após cada alteração de HTML. Adicione também `assets/koleksiyon.js` à lista de content, porque ele escreve classes como `is-open`.
3. Hospede as fontes localmente. Leia o CSS da Fontshare com uma requisição por família e peso (`https://api.fontshare.com/v2/css?f[]=family@weight`), baixe cada arquivo woff2 para `assets/fonts/` com site_fetch e escreva as regras @font-face com `font-display: swap` em `assets/app.css`; o design-check procura a fonte personalizada ali. Faça preload de TODOS os pesos usados acima da dobra (título, corpo e botões) em todas as páginas com `<link rel="preload" as="font" type="font/woff2" crossorigin>` e coloque essas linhas antes do link da folha de estilo. A maioria das fontes da Fontshare não tem o símbolo ₺, então escreva os preços com "TL".
4. Faça o menu e o rodapé em HTML estático. Escreva um pequeno `chrome-stamp.mjs` que leia a lista de navegação de site.config.js e carimbe `_src/header.tpl` e `_src/footer.tpl` entre os marcadores `` e `` em todas as páginas, adicionando aria-current="page" ao link ativo. Não dê aos templates a extensão .html e use marcadores como `[[NAV]]` em vez de `{{...}}`. Construa o menu mobile com `<details>` e sem JS. Mantenha o nome da empresa, o endereço e o telefone no rodapé como texto simples, e faça os links do rodapé e do breadcrumb terem pelo menos 44 pixels de altura.
5. Converta as imagens ao baixá-las com site_fetch: grave a mesma foto em arquivos separados com resize="480x", "800x" e "1120x" (ou as larguras de que a página precisar), image_format="webp" e quality=65. Dê a cada `<img>` srcset, sizes e width e height correspondentes à proporção real. A imagem principal acima da dobra recebe fetchpriority="high" e não é lazy; dê fetchpriority apenas ao elemento LCP real, e loading="lazy" decoding="async" ao restante.
6. Escreva um pequeno `favicon.svg` na raiz do site e adicione `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` a todas as páginas; se houver um logotipo em PNG, crie um apple-touch-icon com site_fetch, resize="180x180" e image_format="png". Sem favicon, o navegador registra um 404 para /favicon.ico e Boas Práticas cai para 96.
7. Regras do validador de HTML: comece todo documento com `<!DOCTYPE html>` em maiúsculas, coloque os atributos entre aspas duplas, use `&nbsp;` para os espaços no texto visível dos links tel:, nunca use o atributo style="" (se precisar de uma variável CSS, use uma classe de propriedade arbitrária do Tailwind como `[--r:-4deg]`), dê a todo botão type="button", não coloque aria-label em elementos sem role, como `<ul>` ou `<div>`, e use `<section aria-label="...">` em vez de role="region".
8. Baixe as imagens dos produtos com site_fetch em proporção retrato 4:5 com resize="400x", "640x" e "960x"; mantenha todas as fotos de produto na mesma proporção para que a grade fique uniforme e a transição do Flip não dê saltos. A imagem principal de uma página de produto é o elemento LCP dessa página e recebe fetchpriority="high".
9. Verifique os dígitos da fonte de exibição: na demo, o zero da Melodrama era cortado por uma barra e "2026" no h1 parecia "2Ø26" à distância. Mantenha números fora dos títulos na fonte de exibição, ou componha os dígitos na fonte do corpo.

SEO, AEO e GEO:
1. Use URLs em estilo de diretório com barra final (/koleksiyon/, /urun/[nome-do-produto]/, /atolye/, /iletisim/ ou os equivalentes no seu idioma). Preencha o bloco seo de site.config.js e execute `node seo-stamp.mjs`. Se houver ateliê ou loja física, defina em site.config.js o businessType mais específico (por exemplo ClothingStore) e o endereço; adicione horário de funcionamento apenas se eu informar. Schemas por página: home WebPage e FAQPage; coleção CollectionPage e um ItemList com a url de cada produto; toda página de produto ItemPage e Product (name, description, image, sku, color, material, category, brand e uma Offer com price, priceCurrency TRY, availability, itemCondition, url e seller @id); ateliê AboutPage; contato ContactPage; BreadcrumbList nas páginas internas (Lookbook, Coleção, produto). Mesmo sem checkout, a Offer leva o preço correto e o status de estoque; se eu informar condições de envio e de troca, adicione shippingDetails e hasMerchantReturnPolicy à Offer. Não invente avaliações nem notas (aggregateRating). Escreva cada schema específico de página em seu próprio bloco `<script type="application/ld+json">` e vincule-o ao grafo base com @id. Não aninhe BreadcrumbList dentro de @graph; mantenha-o em seu próprio bloco, porque essa é a única forma de o seo-check enxergá-lo.
2. Títulos de 48 a 60 caracteres (o seo-check trata mais de 65 como erro), descrições de 145 a 158 caracteres, um h1 por página. O conteúdo principal de cada página tem pelo menos 150 palavras. Na demo, as páginas do ateliê e de contato saíram com 113 e 95 palavras na primeira tentativa e foram completadas com informações reais, como "o que fazemos no ateliê" e "o que incluir ao escrever para nós". Nas páginas de produto, escreva as frases compartilhadas (cuidados, tecido) como itens de lista curtos e escreva a descrição separadamente para cada produto; o seo-check alerta sobre conteúdo duplicado quando as páginas compartilham mais de 50 por cento das frases.
3. O primeiro parágrafo de cada página responde diretamente à pergunta da página, e o h1 é formulado como essa pergunta. Escreva o FAQ próprio da página com `<details>` e marque-o como FAQPage. Mostre a organização responsável pela publicação e uma data de "Última atualização" com `<time datetime>`.
4. No robots.txt, escreva sua decisão com o motivo para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot e CCBot, e indique o sitemap. O sitemap.xml tem um lastmod real. O llms.txt tem um resumo preciso do site em duas frases e uma lista das páginas importantes.
5. Sem invenção: não escreva avaliações, notas, prêmios, números de clientes, certificados, horários de funcionamento, coordenadas, preços ou números de produto sem me perguntar. Deixe totalmente fora do schema qualquer campo que você não conheça.

Verificações (em ordem; não diga "pronto" até todas passarem):
1. Com site_run_command, execute em ordem `node chrome-stamp.mjs`, a compilação do Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 erros, 0 avisos), `node design-check.mjs` (0 erros; justifique qualquer aviso restante) e `npx html-validate "**/*.html"` (0 erros).
2. Veja cada página com site_preview, view="mobile" e view="desktop". O site_preview captura a página com o movimento desativado; se o conteúdo não estiver completo nessa captura, o estado sem movimento está quebrado. Imagens lazy mais abaixo podem aparecer em branco em uma captura de página inteira; não conte isso como erro, mas confira os caminhos delas.
3. Execute core_web_vitals para cada página com strategy="mobile" e strategy="desktop". Critério de aceitação: no mobile, Performance de pelo menos 95 e Acessibilidade, Boas Práticas e SEO em 100; no desktop, as quatro de pelo menos 95, com meta de 100. Para uma página que não atingir, encontre o arquivo lento com resources=true, corrija e meça novamente. Depois execute seo_audit na home com strategy="mobile" e runs=2. A lista de requisições de rede não deve conter nenhum endereço fora do seu próprio domínio (links da loja e do WhatsApp são links, não requisições).
4. Sem rolagem horizontal em larguras de 360, 390, 768 e 1440 pixels, alvos de toque de pelo menos 44 pixels, sem erros no console.

Verificação de interação: como o site_preview não consegue mostrar movimento, diga-me o que observar no meu próprio navegador: no Chrome ou no Edge, clicar em um produto na coleção faz a imagem crescer do card até o seu lugar na página do produto enquanto o menu fica parado; no Firefox a página simplesmente abre; ao pressionar um filtro, os cards deslizam para uma nova ordem; "Ver rápido" abre o card dentro da grade e a imagem cresce; com redução de movimento ativada, as mesmas ações acontecem instantaneamente; com o JavaScript desativado, todos os produtos ficam visíveis. Em uma verificação local, também vi `document.documentElement.matches(':active-view-transition')` retornar true na página do produto durante a transição; você pode executar a mesma verificação.

Depois de publicar: mostre a prévia da regra `/assets/* Cache-Control: public, max-age=31536000, immutable` com site_headers e aplique-a quando eu aprovar; a partir daí, versione o nome do arquivo sempre que o CSS ou o JS mudar (site-v2.css e assim por diante). Envie o sitemap.xml com gsc_submit_sitemap e verifique a home com gsc_url_inspect. No final, entregue-me: uma tabela de pontuação por página (página, quatro pontuações mobile, quatro pontuações desktop, LCP, CLS), os resultados das verificações e a lista das correções aplicadas.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie um site de startup neo-brutalista: bordas grossas, sombras duras, selos adesivos, zero JS

Cria um site de produto no seu servidor de hospedagem com bordas pretas grossas, sombras duras, cores vivas chapadas e selos adesivos. As cores são escolhidas com uma tabela de contraste, os deslocamentos divertidos no hover usam apenas transform, e o site é medido página por página até chegar a 100, sem nenhum JavaScript.

Quando usarQuando você quer um site marcante, de cores ousadas, para o seu app ou startup, e que continue rápido e legível para todos.

Crie um site de produto neo-brutalista, com várias páginas e sem JavaScript, para [nome do produto ou startup] no site [nome do servidor] no meu servidor de hospedagem da Opus Growth. Produto: [o que faz, para quem]. Como funciona: [três passos]. Principais recursos: [4 a 6 recursos]. Preços: [nomes e preços dos planos, ou "sem página de preços"]. Links de download ou cadastro: [App Store, Google Play ou URL de cadastro]. Contato: [e-mail], [telefone], [número de WhatsApp], [endereço]. Domínio: [domínio]. Cores da marca: [cores, ou "você escolhe"]. Fotos ou capturas de tela reais: [links, ou "nenhuma"].

Páginas: início (/), como funciona (/nasil-calisir/ ou /how-it-works/), preços (/fiyat/), sobre (/hakkimizda/), contato (/iletisim/), privacidade (/gizlilik/) e 404.html. Seções da página inicial, em ordem: hero (h1, introdução de duas frases, dois botões, selos em formato de adesivo e o elemento de assinatura), faixa de categorias, três passos, para quem é (com uma foto), recursos, FAQ e uma chamada final para ação. Sem formulário na página de contato; em vez disso, e-mail, telefone, um link de WhatsApp com mensagem pré-preenchida e os links de download, porque o servidor só serve arquivos estáticos.

Estilo: neo-brutalista, mas com cara de produto, não de brinquedo. Bordas pretas grossas (3 pixels), sombras duras sem desfoque (somente pretas, deslocamento de 4, 6 e 10 pixels), blocos de cor chapada e vibrante (no máximo cinco cores chapadas, como tomate, limão, menta, azul-céu e lilás sobre um fundo creme), selos levemente inclinados que parecem adesivos. Tipografia: uma fonte de exibição robusta e com personalidade da Fontshare (por exemplo, Chubbo) com uma grotesca calma para o texto (por exemplo, Supreme 400 e 700). Sem gradientes, sem efeito de vidro, sem sombras suaves e sem degradês de roxo para azul. O site não tem nenhum JavaScript; GSAP, Lenis e Swiper não são carregados. Elemento de assinatura: à direita do hero, um card de borda grossa que desenha a tela principal do produto em HTML real, em vez de uma imagem (por exemplo, as despesas do mês de uma casa e o acerto de contas do fim do mês), com adesivos colados ao redor.

Regras de cor, contraste e movimento (onde esse estilo perde pontos com mais facilidade):
1. Escreva o texto em preto sobre qualquer fundo colorido e nunca use texto branco. Calcule a taxa de contraste de cada cor contra o preto e coloque em ART.md como uma tabela; escureça qualquer cor abaixo de 4,5. Na demonstração, a menor taxa foi 6,7 no laranja tomate, e a acessibilidade ficou em 100 em todas as páginas.
2. Faça o anel de foco com 3 pixels de preto e 3 pixels de deslocamento, mudando para amarelo-limão em um rodapé preto. Use outline-offset para que o anel de foco não se misture com a borda grossa.
3. Faça o deslocamento divertido de botões e cards apenas com transform e box-shadow: ao passar o mouse, translate(-2px, -2px) e uma sombra maior; ao pressionar, translate(4px, 4px) e sem sombra. Os botões têm pelo menos 48 pixels de altura, os botões pequenos pelo menos 44.
4. Coloque a inclinação dos adesivos na propriedade separada `rotate`, não em transform, e defina o ângulo com uma classe de propriedade arbitrária do Tailwind, como `[--r:-4deg]`. Assim, os adesivos continuam inclinados mesmo quando a regra de reduced-motion zera o transform, e nenhum atributo style="" é necessário.
5. Faça a entrada "slap on" dos adesivos apenas com `scale` e `translate`, dentro de `@media (prefers-reduced-motion: no-preference)` e com um atributo data-reveal="slap" (o design-check reconhece movimento por esse atributo). Sem esconder com opacity, e o h1 nunca se move. Com prefers-reduced-motion: reduce, toda animação e transição ficam desligadas.
6. Marque os adesivos decorativos com aria-hidden="true"; selos que carregam informação (por exemplo, "grátis para até 6 pessoas") continuam como itens de lista comuns. No mobile, esconda um adesivo decorativo abaixo de 640 pixels se ele se sobrepuser a outro selo no canto do card; na demonstração, o adesivo "recibo adicionado" cobria o selo "3 pessoas" em 390 pixels.

Configuração e armadilhas conhecidas (cada uma custou pontos ou reprovou em uma verificação na medição da demonstração, não pule):
1. Se já houver um site no ar no servidor, avise-me primeiro, porque a configuração sobrescreve index.html e a pasta assets. Mostre uma prévia de scaffold_site com confirm=false primeiro e depois chame confirm=true quando eu aprovar. Em seguida, leia site_design_guide e site_seo_guide. Antes de escrever código, escreva a direção de design (tipografia, cor, grade, elemento de assinatura, linguagem de movimento e as bibliotecas que NÃO serão carregadas) em um ART.md curto fora de assets e mostre para mim.
2. Compile o Tailwind, não carregue pelo CDN. Instale `npm i -D tailwindcss@3` com site_run_command e background=true, e acompanhe com site_command_status. Os caminhos de content em `tailwind.config.js` devem cobrir todos os arquivos HTML, incluindo subpastas, os templates `_src/*.tpl` e qualquer arquivo JS que escreva classes. `_src/tw.css` contém a linha `@import "../assets/app.css";` e as três linhas `@tailwind`; compile-o em um único arquivo com `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Remova das páginas o script cdn.tailwindcss.com, o tailwind.config inline, chrome.js e motion.js, e vincule apenas `/assets/site.css`. Recompile após cada alteração no HTML. Este site não tem arquivos JavaScript, então a lista de content não precisa de entradas de JS.
3. Hospede as fontes você mesmo. Leia o CSS da Fontshare com uma requisição por família e peso (`https://api.fontshare.com/v2/css?f[]=family@weight`), baixe cada arquivo woff2 em `assets/fonts/` com site_fetch e escreva as regras @font-face com `font-display: swap` em `assets/app.css`; o design-check procura a fonte personalizada ali. Faça preload de TODOS os pesos usados acima da dobra (título, texto e botões) em todas as páginas com `<link rel="preload" as="font" type="font/woff2" crossorigin>` e coloque essas linhas antes do link da folha de estilo. A maioria das fontes da Fontshare não tem o símbolo ₺, então escreva os preços com "TL".
4. Faça o menu e o rodapé em HTML estático. Escreva um pequeno `chrome-stamp.mjs` que leia a lista de navegação de site.config.js e carimbe `_src/header.tpl` e `_src/footer.tpl` entre os marcadores `` e `` em todas as páginas, adicionando aria-current="page" ao link ativo. Não dê aos templates a extensão .html e use marcadores como `[[NAV]]` em vez de `{{...}}`. Construa o menu mobile com `<details>` e sem JS. Mantenha o nome da empresa, o endereço e o telefone no rodapé como texto simples, e faça os links do rodapé e do breadcrumb com pelo menos 44 pixels de altura.
5. Converta as imagens ao baixá-las com site_fetch: grave a mesma foto em arquivos separados com resize="480x", "800x" e "1120x" (ou as larguras de que a página precisar), image_format="webp" e quality=65. Dê a cada `<img>` srcset, sizes e width e height que correspondam à proporção real. A imagem principal acima da dobra recebe fetchpriority="high" e não é lazy; dê fetchpriority apenas ao elemento LCP real, e loading="lazy" decoding="async" ao restante.
6. Escreva um pequeno `favicon.svg` na raiz do site e adicione `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` a todas as páginas; se houver um logotipo em PNG, crie um apple-touch-icon com site_fetch, resize="180x180" e image_format="png". Sem um favicon, o navegador registra um 404 para /favicon.ico e Best Practices cai para 96.
7. Regras do validador de HTML: comece todo documento com `<!DOCTYPE html>` em maiúsculas, coloque os atributos entre aspas duplas, use `&nbsp;` para os espaços no texto visível dos links tel:, nunca use o atributo style="" (se precisar de uma variável CSS, use uma classe de propriedade arbitrária do Tailwind, como `[--r:-4deg]`), dê a todo botão type="button", não coloque aria-label em elementos sem role, como `<ul>` ou `<div>`, e use `<section aria-label="...">` em vez de role="region".
8. Se o rodapé tiver fundo preto, faça seus links creme com hover em amarelo-limão, e mantenha cada um com pelo menos 44 pixels de altura.

SEO, AEO e GEO:
1. Use URLs em estilo de diretório com barra final (/nasil-calisir/, /fiyat/, /hakkimizda/, /iletisim/, /gizlilik/ ou seus equivalentes no seu idioma). Preencha o bloco seo de site.config.js e execute `node seo-stamp.mjs`. Para uma startup sem loja física, defina localBusiness:false em site.config.js. Schemas das páginas: início WebPage e FAQPage; como funciona WebPage e FAQPage; preços SoftwareApplication (applicationCategory, operatingSystem e uma Offer por plano) e FAQPage; sobre AboutPage; contato ContactPage; BreadcrumbList nas páginas internas. Como você não vai adicionar avaliações nem notas de usuários ao SoftwareApplication, o Google pode não mostrar um rich result de app; tudo bem, não invente uma nota. Escreva cada schema específico de página em seu próprio bloco `<script type="application/ld+json">` e vincule-o ao grafo base com @id. Não aninhe BreadcrumbList dentro de @graph; mantenha-o em um bloco próprio, porque essa é a única forma de o seo-check enxergá-lo.
2. Títulos de 48 a 60 caracteres (o seo-check trata mais de 65 como erro), descrições de 145 a 158 caracteres, um h1 por página. O conteúdo principal de cada página tem pelo menos 150 palavras. Na demonstração, as páginas sobre, contato e privacidade ficaram com 113 a 148 palavras na primeira tentativa; adicione informações reais a elas, como "o que incluir em um pedido de suporte" ou "com quem os dados são compartilhados".
3. O primeiro parágrafo de cada página responde diretamente à pergunta da página, e o h1 é formulado como essa pergunta. Escreva o FAQ próprio da página com `<details>` e marque-o como FAQPage. Mostre a organização que publica e uma data de "Última atualização" com `<time datetime>`.
4. No robots.txt, escreva sua decisão com o motivo para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot e CCBot, e aponte para o sitemap. O sitemap.xml tem um lastmod real. O llms.txt tem um resumo preciso do site em duas frases e uma lista das páginas importantes.
5. Sem invenção: não escreva avaliações, notas, prêmios, número de clientes, certificados, horários de funcionamento, coordenadas, preços ou números do produto sem me perguntar. Deixe qualquer campo que você não conheça totalmente fora do schema.

Verificações (em ordem; não diga "pronto" até que todas passem):
1. Com site_run_command, execute em ordem `node chrome-stamp.mjs`, o build do Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 erros, 0 avisos), `node design-check.mjs` (0 erros; justifique qualquer aviso restante) e `npx html-validate "**/*.html"` (0 erros).
2. Veja todas as páginas com site_preview, view="mobile" e view="desktop". O site_preview captura a página com o movimento desligado; se o conteúdo não estiver completo nessa captura, o estado sem movimento está quebrado. Imagens lazy mais abaixo podem aparecer em branco em uma captura de página inteira; não conte isso como erro, mas confira os caminhos.
3. Execute core_web_vitals para todas as páginas com strategy="mobile" e strategy="desktop". Critério de aceitação: no mobile, Performance de pelo menos 95 e Accessibility, Best Practices e SEO em 100; no desktop, as quatro de pelo menos 95, meta 100. Para uma página que não atingir, encontre o arquivo lento com resources=true, corrija e meça de novo. Depois, execute seo_audit na página inicial com strategy="mobile" e runs=2. A lista de requisições de rede não deve conter nenhum endereço fora do seu próprio domínio (links da loja e do WhatsApp são links, não requisições).
4. Sem rolagem horizontal em 360, 390, 768 e 1440 pixels de largura, alvos de toque de pelo menos 44 pixels, sem erros no console.

Verificação de interação: como o site_preview não consegue mostrar movimento, diga-me o que observar no meu próprio navegador: um botão sobe e vai para a esquerda ao passar o mouse e afunda na sombra ao ser pressionado; os adesivos "grudam" suavemente quando a página carrega; ao navegar com Tab, um anel de foco preto grosso aparece em todos os links; com reduzir movimento ativado no sistema operacional, nada se move, mas os adesivos continuam inclinados; com o JavaScript desligado, o menu mobile ainda abre.

Depois de publicar: mostre uma prévia da regra `/assets/* Cache-Control: public, max-age=31536000, immutable` com site_headers e aplique-a quando eu aprovar; a partir daí, versione o nome do arquivo sempre que o CSS ou o JS mudar (site-v2.css e assim por diante). Envie o sitemap.xml com gsc_submit_sitemap e verifique a página inicial com gsc_url_inspect. No final, entregue-me: uma tabela de notas por página (página, quatro notas no mobile, quatro notas no desktop, LCP, CLS), os resultados das verificações e a lista de correções que você aplicou.

SiteAltera após sua aprovaçãoDemonstração ao vivo

Crie uma página D2C de produto único: vitrine 3D, seletor de cores sem deslocamento de layout e barra de compra fixa

Cria uma página direct-to-consumer para um único produto no seu servidor de hospedagem: uma vitrine 3D em CSS que se inclina com o mouse, um seletor de cores sem JavaScript que nunca desloca o layout, tabelas de especificações e de comparação de modelos, FAQ e uma barra de compra fixa para mobile. A marcação usa ProductGroup, Offer, política de devolução e FAQPage, e cada página é medida antes da entrega.

Quando usarQuando você vende um único produto ou uma família de produtos sob a sua própria marca e quer enviar o tráfego dos anúncios para uma página rápida, que explique bem o produto antes da página da loja.

Crie uma página de produto direto ao consumidor e algumas páginas de apoio para [nome da marca], minha marca de produto único, no site [nome do servidor] no meu servidor de hospedagem Opus Growth. Produto: [nome do produto, o que faz, para quem]. Preço: [preço]. Cores ou variantes: [para cada uma, um nome, um código de cor e um link de foto tirada do MESMO ângulo no MESMO canvas]. Especificações: [dimensões, material, peso e números de desempenho com suas condições de teste]. Modelos para comparar: [seus outros modelos e seus números]. Link de compra: [URL da loja e parâmetro da variante]. Frete, devoluções e garantia: [prazos e condições]. Contato: [e-mail], [telefone], [número do WhatsApp], [endereço]. Domínio: [domínio].

Páginas: home do produto (/), garantia e devoluções (/garanti-ve-iade/), contato (/iletisim/), privacidade (/gizlilik/) e 404.html. Seções da home em ordem: hero (vitrine 3D à esquerda; rótulo, h1, introdução de duas frases, preço, seletor de cores, botão de compra e um resumo de frete, devoluções e garantia à direita), três seções curtas sobre como o produto funciona, uma tabela de especificações (#ozellikler), uma tabela de comparação de tamanhos ou modelos (#karsilastir), FAQ (#sss). O menu leva a essas seções na própria página, além das páginas de garantia e contato. Este site não tem carrinho nem checkout; o botão de compra leva à página da loja com a variante selecionada, e a página diz isso claramente.

Estilo: uma página de produto direto ao consumidor, limpa e moderna. Um fundo off-white quente, uma cor de marca que combine com o produto, um botão de compra preto e arredondado e tabelas limpas. Tipografia: uma grotesca de exibição compacta da Fontshare (por exemplo Familjen Grotesk 500 e 700) com uma fonte de texto legível (por exemplo Ranade 400 e 500). A foto do produto é a estrela; guarde a ousadia para a vitrine 3D. GSAP, Lenis e Swiper não são carregados; o único JavaScript é um script inline de menos de 1 KB que inclina a vitrine.

Regras da vitrine 3D, do seletor de cores e da barra de compra (siga exatamente):
1. Construa a vitrine 3D com CSS: `perspective: 1100px` no contêiner, `transform: rotateX(var(--rx, 3deg)) rotateY(var(--ry, -7deg))` e `transform-style: preserve-3d` no cartão interno, e uma transição de transform de 0,3 segundo. Sem JavaScript e em telas touch, o cartão fica nesta pose levemente inclinada. Dois selos pequenos (por exemplo capacidade e um número de desempenho) flutuam na frente do cartão com `translateZ(60px)` e são aria-hidden; a mesma informação também está no texto. Coloque um destaque suave que acompanha o ponteiro sobre a imagem (um radial-gradient controlado por --gx e --gy).
2. O script de inclinação fica inline no final da página e só roda quando `matchMedia("(pointer: fine) and (prefers-reduced-motion: no-preference)")` corresponde. Em pointermove, ele mapeia a posição do ponteiro dentro do cartão para -0,5 a 0,5, define --ry em no máximo 8 e --rx em no máximo 6 graus, e limita as escritas com requestAnimationFrame; em pointerleave, remove as variáveis e volta à pose padrão. Só o transform muda, o layout nunca se desloca. Adicione um atributo data-reveal="tilt" ao contêiner da vitrine para que o design-check reconheça o movimento.
3. Construa o seletor de cores sem JavaScript: dentro de um `<fieldset>` e `<legend>`, um `<input type="radio" name="colour">` de verdade por variante, envolvido por um `<label>` de 44x44 pixels; o radio fica visualmente oculto (sr-only), a bolinha de cor recebe um anel duplo via `input:checked + .dot` e um anel de foco via `input:focus-visible + .dot`; as teclas de seta trocam a cor. Todas as imagens das variantes ficam sobrepostas na mesma caixa com `aspect-ratio`, com `position: absolute; inset: 0`, e só a `opacity` muda, então o layout nunca se desloca quando a cor muda (CLS 0 na demo). Reflita a escolha com `.product:has(#r-colour:checked)` na imagem, no nome da cor na legend e no link de compra. Se o navegador não suportar :has, a imagem, o nome e o link da variante padrão continuam visíveis.
4. A imagem da variante padrão é o elemento LCP: fetchpriority="high", sem lazy. As outras imagens de variante recebem loading="lazy" decoding="async". As fotos das variantes devem ser tiradas do mesmo ângulo, no mesmo canvas e com o mesmo recorte; caso contrário, o produto dá um salto quando a cor muda. Pergunte-me sobre isso em vez de tentar igualar fotos de ângulos diferentes por recorte.
5. Não deixe o valor de `display` de uma classe de botão, como `.btn-buy`, sobrescrever a visibilidade dos links de compra das variantes. Na demo, a regra `.vb { display: none }` foi sobrescrita por `.btn-buy { display: inline-flex }` mais abaixo, e os quatro botões de compra apareceram ao mesmo tempo; escreva a regra com um seletor mais específico, como `.product :is(.vb)`, e confira no navegador que só um botão aparece.
6. Barra de compra fixa no mobile: abaixo de 768 pixels, uma barra com `position: fixed; bottom: 0` com o nome e o preço do produto, o nome da cor selecionada e um único botão "Comprar" (de pelo menos 48 pixels). Mantenha o texto do botão curto e em uma linha (`whitespace-nowrap`); coloque o nome da cor dentro do botão como texto sr-only para leitores de tela. Dê ao body um padding inferior igual à altura da barra para que ela nunca cubra o conteúdo ou o rodapé, e confira que o último link no final da página fica acima da barra. A barra fica oculta no desktop.
7. Tabelas: a tabela de especificações tem cabeçalhos de linha `<th scope="row">`, um `<caption>` visualmente oculto e uma frase indicando as condições de teste (por exemplo temperatura ambiente, tampa fechada). Na tabela de comparação, compare apenas seus próprios modelos, sem nomes de concorrentes nem alegações sobre concorrentes; destaque o modelo à venda com uma cor de fundo, mas não dependa só da cor. Envolva a tabela em `<section aria-label="..." tabindex="0" class="overflow-x-auto">` para que nunca estoure em telas estreitas; não escreva role="region", pois o html-validate o sinaliza como prefer-native-element.

Configuração e armadilhas conhecidas (cada uma custou pontos ou reprovou em um gate na medição da demo, não pule):
1. Se já houver um site no ar no servidor, avise-me primeiro, porque a configuração sobrescreve index.html e a pasta assets. Veja a prévia de scaffold_site com confirm=false primeiro e depois chame confirm=true quando eu aprovar. Em seguida, leia site_design_guide e site_seo_guide. Antes de escrever código, escreva a direção de design (tipografia, cor, grid, elemento de assinatura, linguagem de movimento e as bibliotecas que NÃO serão carregadas) em um ART.md curto fora de assets e mostre-me.
2. Compile o Tailwind, não o carregue pelo CDN. Instale `npm i -D tailwindcss@3` com site_run_command e background=true, e acompanhe com site_command_status. Os caminhos de content em `tailwind.config.js` devem cobrir todos os arquivos HTML, incluindo subpastas, os templates `_src/*.tpl` e qualquer arquivo JS que escreva classes. `_src/tw.css` contém a linha `@import "../assets/app.css";` e as três linhas `@tailwind`; compile-o em um único arquivo com `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Remova das páginas o script cdn.tailwindcss.com, o tailwind.config inline, o chrome.js e o motion.js, e vincule apenas `/assets/site.css`. Recompile após cada alteração de HTML. Se você definir as bolinhas de cor com classes de valor arbitrário como `bg-[#28385C]`, elas são compiladas porque aparecem no HTML.
3. Hospede as fontes você mesmo. Leia o CSS da Fontshare com uma requisição por família e peso (`https://api.fontshare.com/v2/css?f[]=family@weight`), baixe cada arquivo woff2 em `assets/fonts/` com site_fetch e escreva as regras @font-face com `font-display: swap` em `assets/app.css`; o design-check procura a fonte personalizada ali. Faça o preload de TODOS os pesos usados acima da dobra (título, texto e botões) em todas as páginas com `<link rel="preload" as="font" type="font/woff2" crossorigin>` e coloque essas linhas antes do link da folha de estilo. A maioria das fontes da Fontshare não tem o símbolo ₺, então escreva os preços com "TL".
4. Faça o menu e o rodapé em HTML estático. Escreva um pequeno `chrome-stamp.mjs` que leia a lista de navegação de site.config.js e carimbe `_src/header.tpl` e `_src/footer.tpl` entre os marcadores `` e `` em todas as páginas, adicionando aria-current="page" ao link ativo. Não dê aos templates a extensão .html e use marcadores como `[[NAV]]` em vez de `{{...}}`. Construa o menu mobile com `<details>` e sem JS. Mantenha o nome da empresa, o endereço e o telefone no rodapé como texto simples, e faça os links do rodapé e do breadcrumb terem pelo menos 44 pixels de altura.
5. Converta as imagens ao baixá-las com site_fetch: grave a mesma foto em arquivos separados com resize="480x", "800x" e "1120x" (ou as larguras de que a página precisar), image_format="webp" e quality=65. Dê a cada `<img>` srcset, sizes e width e height que correspondam à proporção real. A imagem principal acima da dobra recebe fetchpriority="high" e não é lazy; dê fetchpriority apenas ao elemento LCP real, e loading="lazy" decoding="async" ao resto. Baixe as imagens das variantes em 4:5 com resize="480x", "720x" e "960x".
6. Escreva um pequeno `favicon.svg` na raiz do site e adicione `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` a todas as páginas; se houver um logo em PNG, crie um apple-touch-icon com site_fetch, resize="180x180" e image_format="png". Sem favicon, o navegador registra um 404 para /favicon.ico e Best Practices cai para 96.
7. Regras do validador de HTML: comece todo documento com `<!DOCTYPE html>` em maiúsculas, coloque os atributos entre aspas duplas, use `&nbsp;` nos espaços do texto visível dos links tel:, nunca use o atributo style="" (se precisar de uma variável CSS, use uma classe de propriedade arbitrária do Tailwind como `[--r:-4deg]`), dê a todo botão type="button", não coloque aria-label em elementos sem role, como `<ul>` ou `<div>`, e use `<section aria-label="...">` em vez de role="region".
8. Uma auditoria de alvos de toque pode sinalizar o radio visualmente oculto como 1 pixel; o alvo de toque real é o label ao redor dele. Meça que o label tem pelo menos 44x44 pixels e registre o motivo no relatório.

SEO, AEO e GEO:
1. Use URLs em estilo de diretório com barra final (/garanti-ve-iade/, /iletisim/, /gizlilik/ ou seus equivalentes no seu idioma). Preencha o bloco seo de site.config.js e execute `node seo-stamp.mjs`. Para uma marca sem loja física, defina localBusiness:false em site.config.js. Página inicial: ItemPage (mainEntity o produto), o schema de produto e FAQPage. Schema de produto: com uma única variante, Product e Offer; com variantes de cor, um ProductGroup (productGroupID, variesBy https://schema.org/color, brand, description, material) e, dentro de hasVariant, um Product por cor (sku, color, image) com uma Offer (price, priceCurrency TRY, availability, itemCondition, a URL da loja da variante como url, seller @id, shippingDetails com OfferShippingDetails e hasMerchantReturnPolicy com MerchantReturnPolicy). Publique o mesmo MerchantReturnPolicy com seu @id em um bloco próprio na página de garantia e devoluções. Adicione GTIN, avaliações ou reviews apenas se eu tiver valores reais. Escreva cada schema específico de página em seu próprio bloco `<script type="application/ld+json">` e vincule-o ao grafo base com @id. Não aninhe BreadcrumbList dentro de @graph; mantenha-o em um bloco próprio, porque é a única forma de o seo-check enxergá-lo.
2. Títulos de 48 a 60 caracteres (o seo-check trata mais de 65 como erro), descrições de 145 a 158 caracteres, um h1 por página. O conteúdo principal de cada página tem pelo menos 150 palavras. Na demo, as páginas de garantia e devoluções, privacidade e contato ficaram com 141, 124 e 106 palavras na primeira tentativa e foram completadas com informações reais, como "etapas da devolução", "com quem os dados são compartilhados" e "o que um pedido de garantia exige".
3. O primeiro parágrafo de cada página responde diretamente à pergunta da página, e o h1 é formulado como essa pergunta. Escreva o FAQ próprio da página com `<details>` e marque-o como FAQPage. Mostre a organização que publica e uma data de "Última atualização" com `<time datetime>`.
4. No robots.txt, escreva sua decisão com o motivo para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot e CCBot, e aponte para o sitemap. O sitemap.xml tem um lastmod real. O llms.txt tem um resumo preciso de duas frases do site e uma lista das páginas importantes.
5. Sem invenção: não escreva avaliações, notas, prêmios, números de clientes, certificados, horários de funcionamento, coordenadas, preços ou números do produto sem me perguntar. Deixe totalmente fora do schema qualquer campo que você não conheça.

Gates (em ordem; não diga "pronto" até que todos passem):
1. Com site_run_command, execute em ordem `node chrome-stamp.mjs`, o build do Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 erros, 0 avisos), `node design-check.mjs` (0 erros; justifique qualquer aviso restante) e `npx html-validate "**/*.html"` (0 erros).
2. Veja cada página com site_preview, view="mobile" e view="desktop". O site_preview captura a página com o movimento desligado; se o conteúdo não estiver completo nessa captura, o estado sem movimento está quebrado. Imagens lazy mais abaixo podem aparecer em branco em uma captura de página inteira; não conte isso como erro, mas confira os caminhos.
3. Execute core_web_vitals para cada página com strategy="mobile" e strategy="desktop". Aceitação: no mobile, Performance de pelo menos 95 e Accessibility, Best Practices e SEO em 100; no desktop, as quatro de pelo menos 95, meta 100. Para uma página que não atingir, encontre o arquivo lento com resources=true, corrija e meça de novo. Depois execute seo_audit na página inicial com strategy="mobile" e runs=2. A lista de requisições de rede não deve conter nenhum endereço fora do seu próprio domínio (links da loja e do WhatsApp são links, não requisições).
4. Sem rolagem horizontal em 360, 390, 768 e 1440 pixels de largura, alvos de toque de pelo menos 44 pixels, sem erros no console.

Verificação de interação: como o site_preview não mostra movimento nem cliques, diga-me o que observar no meu próprio navegador: no desktop, ao mover o mouse sobre o produto, o cartão se inclina na direção do ponteiro com os selos flutuando na frente e volta à pose inclinada quando o mouse sai; clicar em uma bolinha de cor ou pressionar uma tecla de seta muda a imagem, o nome da cor e o link de compra sem que nada na página se desloque; com o JavaScript desligado, o seletor de cores continua funcionando; no celular, a barra inferior está sempre visível e não cobre os links do final da página; com reduzir movimento ativado, o cartão não se inclina.

Depois de publicar: veja a prévia da regra `/assets/* Cache-Control: public, max-age=31536000, immutable` com site_headers e aplique-a quando eu aprovar; a partir daí, versione o nome do arquivo sempre que o CSS ou o JS mudar (site-v2.css e assim por diante). Envie o sitemap.xml com gsc_submit_sitemap e verifique a página inicial com gsc_url_inspect. No final, entregue-me: uma tabela de pontuações por página (página, quatro pontuações mobile, quatro pontuações desktop, LCP, CLS), os resultados dos gates e a lista das correções que você aplicou.

SiteAltera após sua aprovação

Escreva um llms.txt e um llms-full.txt precisos para o seu site hospedado

Lê as páginas e o conteúdo real do seu site e redige um arquivo de resumo no formato da proposta llms.txt, usando apenas fatos que aparecem no site. Opcionalmente adiciona o texto limpo das principais páginas como llms-full.txt, publica após a aprovação e verifica no ar.

Quando usarSeu site roda na hospedagem da Opus Growth e você quer que os assistentes de IA encontrem um resumo único, preciso e atualizado do seu negócio.

Escreva um arquivo llms.txt para o meu site [URL do site] na hospedagem da Opus Growth. Fatos sobre o meu negócio que não estão no site, mas que eu confirmo estarem corretos: [fatos extras, ou "nenhum"]. Quero também o llms-full.txt: [sim ou não].

Antes de começar, tenha isto em mente e me diga também: o llms.txt é uma proposta publicada em llmstxt.org. Ele serve para ajudar assistentes de IA a entender um site de forma rápida e correta, mas grandes provedores como Google e OpenAI não disseram usá-lo como sinal de ranqueamento ou de citação. Portanto, o objetivo é um arquivo pequeno e preciso, não um texto promocional.

1. Leia o estado atual. Verifique [URL do site]/llms.txt com site_read_url. Se já existir um arquivo, mostre-o e sinalize o que está desatualizado. Leia as regras de SEO da plataforma com site_seo_guide.
2. Reúna as páginas. Liste as páginas HTML com site_list_files e leia [URL do site]/sitemap.xml com site_read_url. Anote as páginas que estão no sitemap mas não na lista de arquivos, ou o contrário. Separe as páginas legais, as páginas de agradecimento e a página 404.
3. Leia o conteúdo. Leia a página inicial, as páginas de serviço ou produto, a sobre, a de contato e a de preços com site_read_url e text=true. Se a resposta indicar truncated como true, leia de novo com max_bytes=1000000. Para cada página, escreva uma descrição de uma frase baseada somente no que ela realmente diz.
4. Escreva o rascunho no formato llms.txt:
   1. A primeira linha é o título `# [nome da empresa]`.
   2. Abaixo dela, um resumo de uma ou duas frases começando com `>`: o que fazemos, para quem, onde.
   3. Depois, um parágrafo curto com os fatos principais: área de atuação, como entrar em contato, como trabalhamos. Use somente fatos que estejam no site ou que eu informei acima. Se preços, horário de funcionamento, avaliações, número de clientes, prêmios ou certificados não estiverem no site, não os escreva.
   4. Depois, seções como `## Services`, `## FAQ`, `## Company`. Cada linha segue `- [Nome da página](full URL): one-sentence description`. Use a URL canônica que retorna 200; nesta plataforma, as URLs de diretório terminam com barra.
   5. Coloque os links secundários, como páginas legais e o blog, por último, em `## Optional`.
   6. Se o site tiver vários idiomas, dê a cada idioma a sua própria seção e informe qual URL está em qual idioma.
   7. Termine o arquivo com `Last updated: [data de hoje]`.
5. Se eu quiser o llms-full.txt: reúna o texto limpo das principais páginas em um único arquivo, com cada página começando com `## Page name` e `Source: full URL`. Remova menus, rodapés e textos de cookies. Se o arquivo passar de 500 KB, inclua apenas as páginas de serviços, preços, FAQ e sobre.
6. Verifique. Execute seo_content_lint no texto do llms.txt e corrija frases infladas ou com cara de IA. Teste cada link com site_read_url e max_bytes=0 e remova qualquer um que não retorne 200.
7. Mostre uma prévia. Entregue o arquivo completo e uma tabela curta de fontes mostrando de onde veio cada fato: fato, página de origem. Aguarde a minha aprovação.
8. Publique após a aprovação. Grave o llms.txt (e o llms-full.txt, se eu pedi) na raiz do site com site_write_file. Leia os dois com site_read_url e mostre que o status é 200 e o content-type é text/plain. Avise se o robots.txt bloquear /llms.txt. Não adicione o llms.txt ao sitemap, porque o sitemap é para páginas HTML.

Termine com uma nota de manutenção: em três pontos, diga quais mudanças (uma nova página de serviço, uma atualização de preço, uma mudança de endereço) significam que este arquivo também precisa ser atualizado.

SiteAltera após sua aprovação

Publique o llms.txt no seu site WordPress: tente primeiro o plugin de SEO, depois um snippet seguro

Verifica se o seu plugin de SEO consegue gerar o llms.txt e se o resultado é bom o bastante. Se não for, monta um arquivo manualmente a partir das páginas reais do site, publica em /llms.txt por meio de um snippet do WPCode após a sua aprovação e verifica ao vivo.

Quando usarSeu site roda em WordPress e você quer publicar um llms.txt que descreva o seu negócio corretamente, mas não sabe se o seu plugin de SEO já faz isso nem como servir o arquivo.

Publique um llms.txt preciso em /llms.txt no meu site WordPress [site WordPress]. Fatos sobre o meu negócio que não estão no site, mas que eu confirmo que estão corretos: [fatos extras, ou "nenhum"].

O llms.txt é uma proposta publicada em llmstxt.org. Ele ajuda assistentes de IA a entender um site corretamente, mas os principais provedores não disseram que o usam como sinal de ranqueamento ou de citação. Diga isso uma única vez e mantenha o trabalho pequeno e preciso.

1. Mapeie o estado atual. Encontre o site com list_wordpress_sites, encontre o plugin de SEO e sua versão com wordpress_list_plugins e leia as configurações do plugin no nível do site com wordpress_seo. Verifique [site WordPress]/llms.txt com site_read_url: mostre o código de status e o conteúdo, se houver.
2. O caminho pelo plugin. As versões atuais do Yoast SEO, Rank Math e All in One SEO incluem um recurso que gera o llms.txt. Leia o registro de configurações do plugin com wordpress_option e write=false (no Yoast, o nome da opção é `wpseo`) e descubra se o recurso de llms.txt está ativado. Se não tiver certeza do nome da chave, não adivinhe: diga qual tela do painel do plugin eu devo verificar. Se o recurso estiver ativado, avalie o resultado: ele lista apenas os posts recentes do blog? As páginas de serviços e de contato estão lá? As descrições estão corretas? Se estiver bom o bastante, pare aqui e me dê uma avaliação curta.
3. Monte manualmente (sem o recurso do plugin, ou com resultado insuficiente). Liste as páginas com wordpress_list_posts, type='page' e status='publish', e depois os 10 posts mais importantes. Leia a página inicial, as páginas de serviços ou produtos, sobre, contato e preços com site_read_url e text=true; se a resposta indicar truncated como true, leia novamente com max_bytes=1000000. Escreva o rascunho assim: primeira linha `# [nome da empresa]`, abaixo dela um resumo de uma ou duas frases começando com `>`, um parágrafo curto com os fatos principais, depois as seções `## Services`, `## FAQ` e `## Company`, com cada linha no formato `- [Nome da página](full URL): one-sentence description`, e por fim as páginas legais e o blog em `## Optional`. Use apenas fatos que estão no site ou que eu forneci; se preços, horário de funcionamento, avaliações, número de clientes ou certificados não estiverem no site, deixe-os de fora. Termine o arquivo com `Last updated: [data de hoje]`. Execute seo_content_lint no texto e corrija as expressões sinalizadas. Teste cada link com site_read_url e max_bytes=0.
4. Prévia. Mostre o arquivo completo, a página de origem de cada fato e o caminho de publicação. O caminho é um snippet PHP criado com wordpress_snippet, localização 'everywhere'. No hook `init`, quando o caminho da requisição for exatamente `/llms.txt`, o código envia `Content-Type: text/plain; charset=utf-8`, imprime o texto e encerra, sem tocar em nenhuma outra requisição. Mostre o código também na prévia. Se o recurso de llms.txt do próprio plugin estiver ativado, me diga para desativá-lo antes, para que as duas fontes não entrem em conflito. Aguarde a minha aprovação.
5. Aplique após a aprovação. Crie o snippet com wordpress_snippet action='create'. Ele é criado inativo; ative-o com action='toggle' e active=true. Se a ativação retornar um erro, o snippet continua desativado, então me mostre o erro. Se houver um plugin de cache ativo, limpe o cache com wordpress_purge_cache.
6. Verifique. Leia /llms.txt com site_read_url: o status deve ser 200, o content-type text/plain e o conteúdo, o texto que eu aprovei. Se a URL retornar 404, o servidor web não está repassando requisições .txt ao WordPress. Nesse caso, desative o snippet e explique como enviar o arquivo para a raiz do site pelo painel de hospedagem ou por FTP. Verifique também com site_read_url se a página inicial continua retornando 200.

Termine com o caminho de reversão: o ID do snippet e como desativá-lo com wordpress_snippet. Lembre-me também de que uma nova página de serviço, uma mudança de preço ou uma mudança de endereço significam que o texto do snippet precisa ser atualizado.

SiteAltera após sua aprovação

Defina uma política de robots.txt para crawlers de IA e publique com segurança

Ajuda você a decidir a quais crawlers de IA o site deve ficar aberto, separando os papéis de busca, acesso do usuário e treinamento. Mostra uma prévia de um novo robots.txt que mantém suas regras atuais, grava no seu site hospedado ou WordPress após a aprovação e verifica no ar.

Quando usarVocê quer que seu site seja citado nas buscas por IA, mas quer decidir separadamente sobre o treinamento de modelos, ou não sabe o que seu robots.txt diz hoje aos crawlers de IA.

Refaça o robots.txt do meu site [URL do site] com base em uma política deliberada para crawlers de IA. Tipo de site: [hospedagem Opus Growth ou WordPress]. Minha preferência: [A: aberto a todos / B: busca aberta, treinamento fechado / C: personalizada, explique].

1. Leia o estado atual. Leia [URL do site]/robots.txt com site_read_url. Se o site estiver na hospedagem Opus Growth, leia também o robots.txt com site_read_file e confirme que corresponde ao que está no ar. Se for WordPress, descubra qual plugin de SEO o gerencia com wordpress_seo e verifique com wordpress_snippet action='list' se algum snippet já mexe no robots.txt. Liste cada grupo de regras existente, cada linha Disallow e cada linha Sitemap.
2. Explique os papéis. Separe os crawlers em três grupos e me diga em uma frase cada o que eu perco ou ganho:
   1. Busca e citação: OAI-SearchBot, Claude-SearchBot, PerplexityBot, Bingbot, Googlebot, Applebot. Bloquear esses crawlers impede que o site seja citado como fonte nas respostas desse assistente.
   2. Acesso ao vivo em nome de um usuário: ChatGPT-User, Claude-User, Perplexity-User. Eles chegam quando um usuário compartilha meu link ou o assistente abre uma página para responder. Segundo a documentação dos provedores, o robots.txt pode não se aplicar em todos os casos a essas solicitações iniciadas pelo usuário, então diga que uma regra aqui não é garantia.
   3. Treinamento de modelos: GPTBot, ClaudeBot, Google-Extended, Applebot-Extended, CCBot, meta-externalagent. Bloquear esses crawlers limita o uso do conteúdo em treinamentos futuros, mas não remove conteúdo de modelos já treinados. Bloquear o Google-Extended não afeta a Pesquisa Google nem as Visões Gerais criadas por IA.
3. Escreva o rascunho. Prepare o novo robots.txt para a minha preferência e siga estas regras:
   1. Quando você escreve um grupo com o nome próprio de um crawler, esse crawler deixa de ler o grupo `User-agent: *`. Então copie todas as linhas Disallow do grupo * (área administrativa, carrinho, resultados de busca interna e assim por diante) para cada grupo nomeado, caso contrário você abrirá áreas privadas sem perceber.
   2. Não bloqueie arquivos CSS, JavaScript ou de imagem, porque os crawlers precisam deles para renderizar a página.
   3. Mantenha as linhas Sitemap existentes e adicione a URL completa do sitemap se estiver faltando.
   4. Não bloqueie nenhum crawler de busca, a menos que eu peça explicitamente.
   5. Deixe em paz os crawlers de SEO de concorrentes (como AhrefsBot e SemrushBot), a menos que eu peça, pois estão fora do escopo deste trabalho.
4. Mostre uma prévia. Compare o arquivo antigo e o novo linha a linha e mostre uma tabela com a decisão antes e depois para cada crawler: crawler, papel, decisão antiga, decisão nova. Espere minha aprovação.
5. Aplique após a aprovação.
   1. Site hospedado: grave o robots.txt com site_write_file. A plataforma tira um snapshot de versão antes de cada gravação, então me diga a qual versão de site_versions posso voltar.
   2. WordPress: quando não existe um arquivo físico no servidor, o WordPress gera o robots.txt por conta própria e o filtro `robots_txt` pode alterá-lo. Crie um snippet PHP com wordpress_snippet que use esse filtro, localização 'everywhere'. O snippet é criado inativo, então mostre o código e ative-o somente depois da minha aprovação. Se houver um plugin de cache ativo, limpe o cache com wordpress_purge_cache.
6. Leia de volta. Leia o robots.txt novamente com site_read_url e mostre que o novo conteúdo está no ar. No WordPress, se o conteúdo não mudou, existe um arquivo robots.txt físico no servidor e o filtro não consegue alcançá-lo. Nesse caso, desative o snippet e me oriente a alterar o arquivo no editor de arquivos do plugin de SEO (Yoast: Ferramentas, Editor de arquivos; Rank Math: Configurações gerais, Editar robots.txt) ou no painel da hospedagem.

Termine com uma nota de duas frases: a alteração passa a valer quando os crawlers relerem o arquivo (geralmente em até um dia), e se uma regra de CDN ou firewall bloqueia pelo nome do crawler, o robots.txt sozinho não basta.

SiteAltera após sua aprovação

Reconstrua o menu do site em torno das páginas que realmente convertem

Cruza o desempenho das páginas de destino no GA4 com os menus do seu WordPress, aponta páginas valiosas que faltam na barra de navegação, peso morto e links quebrados, e propõe um menu principal mais enxuto.

Quando usarQuando o menu do seu site parece desorganizado ou desatualizado e você suspeita que ele não leva os visitantes às páginas que realmente trazem conversões.

Compare o meu menu de navegação com o que realmente converte.

Na propriedade do GA4 [propriedade do GA4], puxe os últimos 90 dias por página de destino: sessões e eventos-chave. Calcule a taxa de eventos-chave como eventos-chave / sessões.

Depois, leia todos os menus de [site WordPress], incluindo a barra de navegação principal e o rodapé, com todos os seus links.

Correspondência entre links do menu e linhas do GA4 pelo caminho da URL (ignore o domínio, barras finais e query strings). Quando um link não tiver linha no GA4, trate-o como zero sessões e informe isso.

Verifique problemas em cada link do menu:
- Acesse cada URL vinculada e registre o status HTTP. Qualquer 4xx ou 5xx é quebrado; vale anotar os redirecionamentos.
- Sinalize links que apontam para páginas em rascunho ou privadas, para slugs antigos ou para http em vez de https.

Entregue três listas:
1. Páginas com pelo menos 20 eventos-chave que não estão no menu principal.
2. Links do menu que apontam para páginas com menos de 50 sessões ou zero eventos-chave em 90 dias.
3. Links quebrados ou desatualizados, com o motivo de cada um.

Em seguida, proponha um novo menu principal:
- No máximo 7 itens de primeiro nível, ordenados por importância comercial.
- Rótulos exatos de 2 a 3 palavras, em linguagem simples que um cliente usaria.
- A página de contato fica como último item.
- Mova páginas de baixo valor para o menu do rodapé em vez de excluí-las.

Mostre o menu atual e o menu proposto lado a lado, com a lista exata de ações de menu que você executaria (adicionar, renomear, religar, reordenar, remover), como prévia. Não edite nada até eu aprovar. Depois da aprovação, aplique as alterações, limpe o cache e leia os menus de volta para confirmar a estrutura final.

SiteAltera após sua aprovação

Verificação de saúde de plugins e rastreamento antes que quebre suas conversões

Uma lista de ações plugin por plugin que sinaliza plugins desatualizados, duplicados e conflitantes e tags disparando em dobro.

Quando usarQuando seu site WordPress tem plugins demais, atualizações acumuladas, ou você teme que tags duplicadas estejam inflando as conversões para as quais seus anúncios otimizam.

Faça uma verificação de saúde de plugins e rastreamento em [site WordPress].

Leia o seguinte:
- As versões do WordPress e do PHP.
- Todos os plugins instalados, com o status de ativação e se há atualização disponível.
- Todos os lugares em que uma tag do GTM ou do GA4 é disparada.
- As configurações atuais de cache e velocidade.

Entregue uma tabela com estas colunas: plugin, ativo?, atualização disponível?, função (SEO, cache, formulários, rastreamento, page builder, outro), risco, recomendação (manter, atualizar, desativar ou excluir).

Sinalize explicitamente estes problemas:
- Mais de um plugin de SEO.
- Mais de um plugin de cache.
- Plugins inativos que podem ser excluídos.
- Qualquer tag do GTM ou do GA4 que seja disparada de mais de um lugar. O disparo duplo infla as conversões para as quais meus anúncios otimizam.

Não mexa no page builder, no plugin de formulários nem no WooCommerce.

Mostre a lista de ações primeiro como prévia. Depois aja em um plugin por vez, e somente depois que eu aprovar cada um. Após cada alteração, confirme que a página inicial continua retornando status 200 antes de seguir em frente.

SiteAltera após sua aprovação

Substitua um telefone antigo em todo o site, com segurança

Um mapa completo de onde o número antigo aparece, um diff em simulação da substituição em massa e uma lista de locais que exigem correção manual.

Quando usarQuando seu número de telefone mudou e você precisa ter certeza de que o antigo não aparece mais em nenhum lugar do seu site.

Nosso telefone mudou de [número antigo] para [número novo]. Anúncios e visitantes orgânicos não podem ver o número antigo em lugar nenhum.

1. Encontre todos os posts e páginas do meu site WordPress que contenham o número antigo em qualquer formato comum: com espaços, sem espaços, com o código do país e dentro de links tel:.
2. Verifique os menus em busca de links tel: e as configurações do Contact Form 7 em busca do número antigo.
3. Leia o local do meu Business Profile e me diga qual número ele mostra atualmente.

Entregue:
- Uma lista de páginas com o número de ocorrências em cada uma.
- Qualquer lugar que uma busca e substituição de conteúdo não alcance, como menus, configurações de formulário ou Business Profile.

Execute primeiro a busca e substituição em massa como simulação e mostre o diff de cada página. Aplique somente depois da minha aprovação e, em seguida, limpe o cache.

Não altere o Business Profile nesta tarefa. Apenas me diga se ele precisa ser atualizado.

SiteAltera após sua aprovação

Verifique se suas páginas que geram receita estão indexadas e se os canonicals estão corretos

Inspeciona em lote suas principais páginas do WordPress no Search Console, compara o canonical do Google com o definido no seu plugin de SEO, sinaliza problemas de noindex e de sitemap e prepara correções para a sua aprovação.

Quando usarQuando páginas importantes podem estar ausentes do Google, ou você suspeita que tags noindex, canonicals errados ou lacunas no sitemap as estejam mantendo fora da busca.

Verifique se o Google indexou as páginas mais importantes do meu site [site WordPress]. A propriedade do Search Console é [propriedade do Search Console].

Estas são as páginas que uso como páginas de destino de anúncios: [cole as URLs das páginas de destino dos seus anúncios ou escreva "nenhuma"]

1. Liste as páginas e posts publicados no site WordPress para ter cada URL e o respectivo ID do post.
2. Puxe os dados de páginas do Search Console dos últimos 90 dias, ordenados por impressões.
3. Escolha até 50 URLs principais: páginas de serviços, categorias de produtos, a página de contato, as páginas de destino de anúncios que listei acima e as páginas com mais impressões. Mostre-me a lista antes de inspecionar.
4. Inspecione-as com a inspeção de URLs em lote, 20 URLs por chamada (ou seja, até 3 chamadas). Se atingir a cota do Google, pare, diga quais URLs ainda não foram verificadas e continue depois.
5. Para cada URL, informe: veredito de indexação e estado de cobertura, data do último rastreamento, canonical selecionado pelo Google e estado de indexação ou de robots.
6. Verificação de sitemap: liste os sitemaps enviados e o status deles (erros, avisos, pendentes). Depois, use o estado de cobertura de cada URL para identificar lacunas no sitemap. Um estado como "Indexed, not submitted in sitemap" ou "URL is unknown to Google" indica que a página provavelmente não está no sitemap. Trate isso como um sinal forte, não como prova.
7. Para cada página com problema, leia seus campos de SEO no WordPress: meta title, canonical, palavra-chave foco e noindex. Compare o canonical declarado com o escolhido pelo Google. Se uma única URL precisar de mais detalhes (usabilidade em dispositivos móveis, resultados avançados, o canonical declarado pelo usuário como o Google o vê), execute uma inspeção de URL individual nela.

Entregue uma tabela ordenada por gravidade, nesta ordem: não indexada, divergência de canonical, noindex, provavelmente ausente do sitemap. Para cada linha, informe a causa provável e a correção exata.

Se um canonical do WordPress apontar para a URL errada, ou se uma página que deveria ranquear estiver com noindex, mostre-me o campo exato, o valor atual e o novo valor, e aguarde a minha aprovação antes de definir. Não reenvie nenhum sitemap sem me perguntar antes. Lembre-se de que nenhuma ferramenta consegue clicar em "Solicitar indexação", então, para as páginas que precisam de novo rastreamento, liste-as para que eu as solicite manualmente no Search Console (cerca de 10 por dia).

SiteSomente leitura

Descubra os cliques de anúncios do Meta perdidos por páginas de destino lentas

Cruza a taxa de visualização da página de destino de cada URL de destino do Meta com os Core Web Vitals em dispositivos móveis e estima o gasto perdido antes de a página carregar.

Quando usarQuando seus anúncios do Meta recebem muitos cliques, mas muito menos visualizações da página de destino, e você suspeita que páginas lentas estão desperdiçando orçamento.

Na conta de anúncios do Meta [conta], liste os anúncios ativos que gastaram dinheiro nos últimos 14 dias. Leia o link de destino de cada anúncio. Remova os parâmetros UTM e depois agrupe os anúncios por URL de página de destino única.

Para cada URL:
- Nos Insights, puxe o gasto, os cliques no link e as visualizações da página de destino.
- Calcule a taxa de visualização da página de destino: visualizações da página de destino divididas pelos cliques no link.
- Execute uma verificação de Core Web Vitals em dispositivos móveis. O tráfego do Meta é majoritariamente móvel, então é o móvel que conta.

Entregue uma tabela com estas colunas: URL, número de anúncios, gasto, cliques no link, taxa de visualização da página de destino, LCP, INP, CLS.

Sinalize uma URL se a taxa de visualização da página de destino estiver abaixo de 70% e o LCP acima de 2,5 s. Para cada URL sinalizada, estime o gasto perdido como gasto × (1 − taxa de visualização da página de destino). Ordene a tabela por gasto perdido.

Para as três principais URLs, recomende correções de velocidade específicas.

Não pause, edite nem duplique nenhum anúncio.

SiteSomente leitura

Transforme um rastreamento de velocidade do site inteiro em tickets para desenvolvedores por template

Rastreia o site inteiro, puxa a lista completa de URLs de cada problema relacionado à velocidade, agrupa as páginas por template, audita URLs de amostra de cada template com detalhes por recurso e entrega uma lista ordenada de tickets para desenvolvedores com contagens de páginas honestas.

Quando usarQuando o site inteiro tem problemas de velocidade ou de mudança de layout e você precisa entregar aos desenvolvedores uma lista clara e priorizada do que corrigir.

Primeiro, verifique no histórico do meu complemento de SEO se há um rastreamento de [domínio] que ainda possa ser reutilizado gratuitamente. Se existir, reutilize-o. Se não, lembre-me de que um rastreamento do site inteiro consome créditos do complemento de SEO e aguarde o meu aval antes de iniciar um rastreamento de até [máximo de páginas] páginas. O rastreamento roda em segundo plano: inicie-o e depois consulte o andamento com o id da tarefa a cada um ou dois minutos até o resumo ficar pronto.

No resumo do rastreamento, pegue todos os tipos de problema relacionados à velocidade ou à estabilidade do layout, se aparecerem nos dados. Exemplos: página muito pesada, tempo de carregamento lento, cadeias de redirecionamento, recursos que bloqueiam a renderização, imagens superdimensionadas, imagens sem largura/altura. Use os nomes dos problemas exatamente como o resumo os retorna. Para cada um desses problemas, puxe a lista completa de URLs (percorra todas as páginas de resultados), não apenas os 5 primeiros exemplos.

Agrupe as URLs afetadas por template ou padrão de caminho, por exemplo /blog/, /product/, /category/ e páginas de destino. Para cada template, conte as páginas afetadas por problema a partir dessas listas completas.

Em seguida, escolha a pior URL de cada template. Antes de executar as auditorias técnicas, diga quantas pretende executar (elas também consomem créditos do complemento) e aguarde o meu OK. Em cada pior URL, execute uma auditoria técnica e uma verificação de Core Web Vitals em dispositivo móvel com as listas de recursos ativadas. Use as listas de recursos para nomear os arquivos reais: quais folhas de estilo e scripts bloqueiam a renderização, quantos bytes de CSS e JS não utilizados, quais imagens estão superdimensionadas ou fora de um formato moderno, o total de requisições e o elemento do LCP.

Para ver se um achado da auditoria vale para o template todo ou é pontual, execute a verificação gratuita de Core Web Vitals em dispositivo móvel (com listas de recursos) em mais 2 URLs do mesmo template.

Regra de contagem: somente problemas que vêm das listas de URLs do rastreamento recebem contagem de páginas. Para problemas encontrados apenas nas auditorias, escreva "confirmado em X de 3 URLs amostradas" em vez de uma contagem de páginas. Não extrapole uma contagem de páginas a partir de uma única URL.

Entregue uma lista de tickets com estas colunas: template, problema, páginas afetadas (ou proporção da amostra), URL de exemplo, arquivos ou elementos envolvidos, correção recomendada, esforço (S/M/L), métrica que deve melhorar (LCP, CLS, INP/TBT, peso da página). Ordene por páginas afetadas × gravidade; para problemas só de amostra, use a proporção da amostra e marque-os como tal.

Isto é somente leitura. Não altere nada no site.

SiteAltera após sua aprovação

Crie uma tag de compra do Google Ads com valor dinâmico no GTM

Uma configuração do GTM em etapas que envia valor do pedido, moeda e ID da transação ao Google Ads, revisada no workspace antes de publicar.

Quando usarQuando as conversões do Google Ads aparecem sem valor ou com valor errado e você precisa de rastreamento de compras com os valores reais dos pedidos pelo Google Tag Manager.

Configure o rastreamento de compras do Google Ads com valores dinâmicos no contêiner do GTM [GTM-XXXX] para a ação de conversão [nome da ação de conversão de compra].

1. Obtenha o ID de conversão (AW-...) e o rótulo dessa ação.
2. Revise as tags, os acionadores e as variáveis existentes. Se já existir uma tag de compra do Google Ads, pare e me avise em vez de criar uma segunda.
3. Planeje estes itens. Variáveis da camada de dados para ecommerce.value, ecommerce.currency e ecommerce.transaction_id (reutilize as que já existirem). Um acionador de evento personalizado para "purchase". Uma tag de acompanhamento de conversões do Google Ads que use essas variáveis, para que o ID da transação evite duplicidade em recarregamentos da página.
4. Mostre a configuração completa de cada item antes de criá-lo. Crie os itens no workspace somente depois da minha aprovação.
5. Mostre o status do workspace e a versão que está no ar agora. Não publique até eu confirmar que um pedido de teste disparou a tag uma única vez com o valor correto. Se algo quebrar após a publicação, a versão de reversão é a que está no ar agora.

SiteSomente leitura

Audite todos os formulários de contato do WordPress e teste se os leads chegam à caixa de entrada

Uma tabela por formulário com destinatários, configurações do remetente, campos obrigatórios e resultado de um teste real, com uma correção para cada formulário.

Quando usarQuando você suspeita que os leads dos formulários de contato do seu site WordPress nunca chegam à caixa de entrada ou caem no spam.

Verifique todos os formulários de contato do meu site WordPress [site] e me diga se os leads realmente chegam à nossa caixa de entrada.

1. Liste todos os formulários do Contact Form 7. Para cada um, mostre os campos, quais são obrigatórios e os endereços de destinatário e remetente nas configurações de e-mail.
2. Encontre as páginas que contêm o shortcode de cada formulário para eu saber onde ele é usado.
3. Sinalize estes problemas: o destinatário não é [e-mail da caixa de leads], o endereço do remetente usa um domínio diferente do próprio site (um motivo comum para o e-mail cair no spam), mais de 5 campos obrigatórios ou ausência de campo de telefone.
4. Envie um teste por formulário e informe o resultado: mail_sent, mail_failed, erro de validação ou spam.
5. Liste os plugins instalados e me diga se há um plugin de SMTP instalado e ativo.

Entregável: uma tabela com estas colunas: nome do formulário, páginas, destinatário, remetente, campos obrigatórios, resultado do teste e uma correção recomendada. Não edite nenhum formulário, configuração ou plugin. Se uma correção exigir alguma mudança, descreva exatamente o que você mudaria e aguarde minha aprovação.

SiteAltera após sua aprovação

Configure o envio de e-mails do formulário de contato no meu site hospedado com meu próprio Gmail

Verifica o formulário de contato do seu site hospedado, conecta seu próprio Gmail ou Yandex como remetente depois que você aprovar a configuração, envia um e-mail de teste e confirma que o lead foi registrado.

Quando usarQuando o formulário de contato do seu site hospedado precisa enviar novos leads para sua própria caixa de e-mail Gmail ou Yandex e você quer ter certeza de que funciona.

Nosso site roda no servidor de hospedagem da Opus Growth. O formulário de contato precisa enviar um e-mail para cada novo lead para [endereço Gmail ou Yandex].

1. Liste meus servidores. Se houver mais de um, pergunte qual deles hospeda este site. Depois mostre o endereço e o status do site.
2. Liste os arquivos do site, encontre a página de contato e leia o conteúdo dela. Diga qual formulário existe e quais campos ele realmente envia (nome, telefone, e-mail, serviço, mensagem). Sinalize qualquer campo dessa lista que esteja faltando e informe se o formulário já envia os dados para o relay da Opus Growth.
3. Diga exatamente o que você precisa de mim para conectar minha própria caixa de e-mail e por quê. No Gmail, é uma senha de app do Google, não minha senha normal. No Yandex, diga também se é necessária uma senha de app.
4. Antes de aplicar qualquer coisa, mostre a configuração que você pretende definir: provedor, conta de envio (from_email), destinatário (to_email) e uma linha de assunto fixa, por exemplo "Novo lead de [nome do site]". O relay usa um único assunto estático e não tem configuração de reply-to. O nome, o e-mail e os demais campos do visitante aparecerão no corpo do e-mail, então vou responder copiando o endereço dele de lá.
5. Aplique a configuração somente depois da minha confirmação, com send_test ativado para que um e-mail de teste seja enviado imediatamente. Diga se o teste foi enviado ou qual erro ele retornou.
6. Leia a página de contato publicada e confirme que o formulário envia os dados para o relay. Se o formulário precisar de ajuste (action errada, campo de telefone ausente, nomes de campos que não chegarão), mostre o código exato antes e depois e aguarde minha aprovação antes de editar o arquivo.
7. Peça que eu envie um registro de teste no formulário publicado. Em seguida, busque os envios do formulário do último dia e confirme que meu registro está lá com todos os campos preenchidos, e se ele foi entregue ou falhou com algum erro.

Se algo bloquear a entrega, como um destinatário errado, um erro de autenticação ou um campo ausente, liste o problema com a correção que você propõe e aguarde minha aprovação antes de alterar qualquer coisa.

SiteAltera após sua aprovação

Recupere os leads que o formulário de contato recebeu, mas nunca enviou por e-mail

Busca todos os envios do formulário de contato, separa os leads cujo e-mail falhou, monta uma lista de ligações sem spam, data o início das falhas e propõe uma correção do relay para sua aprovação.

Quando usarQuando você suspeita que os e-mails do formulário de contato pararam de chegar e que pode ter perdido leads sem saber.

Suspeito que estamos perdendo leads porque os e-mails do formulário não foram entregues. Liste meus servidores (pergunte qual deles se houver vários) e depois busque todos os envios do formulário de contato do meu site hospedado nos últimos [30] dias. Use um limite alto e me avise se o resultado parecer cortado, para reduzirmos o período.

1. Divida-os em dois grupos: entregues, e com falha ou não enviados (delivered:false).
2. Para o grupo com falha, monte uma tabela: data e hora, nome, telefone, e-mail, serviço solicitado, um resumo de uma linha da mensagem e o texto do erro armazenado. Use os campos que o formulário realmente envia e marque os ausentes como vazios. Ordene do mais recente para o mais antigo e marque como "ligar hoje" tudo que tiver menos de 48 horas. Se campos de rastreamento como gclid ou utm_source tiverem chegado, adicione uma coluna mostrando a origem.
3. Mova os prováveis spams para uma lista separada: sem telefone e sem e-mail, com links na mensagem ou com texto sem relação com nossos serviços.
4. Usando os horários dos registros, conte as falhas por dia e me diga quando começaram e se todos os envios falharam depois dessa data ou só alguns.

Termine com: total de leads reais perdidos, a causa mais provável com base nos textos de erro armazenados (por exemplo, senha de app expirada ou revogada, cota de envio, recusa temporária) e a correção que você recomenda. Agrupe erros idênticos. Se o campo de erro estiver vazio ou vago, diga claramente que a causa é uma inferência a partir do padrão das falhas, e não um diagnóstico confirmado. Se a correção for uma nova senha de app ou ajustes nas configurações de e-mail, mostre a configuração exata que você aplicaria e aguarde minha aprovação. Depois que eu aprovar, aplique com send_test ativado e informe se o e-mail de teste foi enviado.

SiteAltera após sua aprovação

Envie os serviços agendados a partir dos leads de formulário de volta para o Google Ads e a Meta

Verifica se os formulários de lead do seu WordPress capturam os IDs de clique, configura uma ação de conversão por importação de cliques, valida sua lista de serviços agendados e envia tudo ao Google Ads e à Meta Conversions API após a sua aprovação.

Quando usarQuando o Google Ads e a Meta só enxergam preenchimentos de formulário e você quer que otimizem para os serviços que realmente agendou.

Nem todo lead de formulário vira um serviço pago. Quero que o Google Ads e a Meta aprendam com os serviços que realmente agendamos, e não só com preenchimentos de formulário.

1. Em [site], liste os formulários do Contact Form 7 e leia os campos do principal formulário de lead. Depois, leia a página ao vivo [URL da página de contato] e procure campos ocultos no HTML. Existe um campo oculto capturando o gclid da URL de destino e outro capturando o fbclid (ou o cookie _fbc)? Se não, pare e me diga exatamente quais campos ocultos adicionar e o pequeno script que os preenche a partir da URL, antes de continuarmos. Não altere nada no site.
2. No Google Ads, liste as ações de conversão e suas configurações. Existe uma ação "Importar de cliques" para serviços agendados? Mostre o tipo de contagem, o valor padrão e a janela de retrospectiva de cliques, e me diga se as conversões otimizadas para leads estão ativadas no nível da conta. Se não existir uma ação adequada, mostre a prévia de uma nova: nome "Booked job", tipo UPLOAD_CLICKS, categoria PURCHASE, valor padrão [valor médio do serviço]. Crie somente depois da minha aprovação.
3. Encontre minha conta de anúncios da Meta e o pixel para o qual enviar os eventos do servidor.
4. Vou colar os serviços agendados dos últimos 30 dias: ID do serviço, nome, telefone, e-mail, gclid, fbclid (se capturado), data e hora do agendamento, valor do serviço. Valide a lista e sinalize:
   - linhas sem gclid (não podem ir para o Google),
   - cliques mais antigos que a janela de retrospectiva da ação ou que 90 dias,
   - linhas sem e-mail, sem telefone e sem fbclid (a Meta não consegue fazer a correspondência),
   - eventos da Meta com mais de 7 dias (a Meta rejeita a maioria dos eventos de servidor depois desse prazo, então me diga se preciso de uma rotina semanal),
   - IDs de serviço duplicados.
   Quando houver fbclid, monte o valor de fbc como fb.1.<click time in milliseconds>.<fbclid>.
5. Prepare os envios. Google: gclid, data e hora da conversão com fuso horário [diferença de fuso horário, ex.: +03:00], valor, moeda [moeda], order_id = ID do serviço. Meta: event_name Purchase, valor, moeda, e-mail e telefone (com hash feito pela ferramenta), fbc quando disponível, action_source system_generated, event_id = ID do serviço. Execute as duas ferramentas primeiro em modo de prévia e mostre a contagem de linhas por plataforma e todas as linhas ignoradas com o motivo. Para a Meta, ofereça enviar uma linha com um código de evento de teste antes do lote completo. Envie somente depois da minha confirmação.

SiteAltera após sua aprovação

Crie uma página de destino do Google Ads alinhada à mensagem do anúncio vencedor

Escolhe os títulos de RSA com melhor conversão, cria uma página de destino correspondente no seu site hospedado, com formulário funcionando, mostra a prévia no desktop e no celular e só publica após duas aprovações.

Quando usarQuando o tráfego do Google Ads chega a uma página genérica e você quer uma página dedicada, alinhada à mensagem do anúncio que já converte.

Crie uma página de destino dedicada no meu site hospedado para a campanha do Google Ads [nome da campanha].

1. Encontre a campanha e seus grupos de anúncios e leia os RSAs ativos. No relatório de recursos de RSA dos últimos 30 dias, escolha os 3 títulos com mais conversões, considerando apenas títulos com pelo menos 1.000 impressões. O título da página deve ecoar o primeiro, para que a mensagem corresponda ao que as pessoas clicaram. Se menos de 3 títulos se qualificarem, me avise e use os melhores disponíveis.
2. Leia o guia de design do site, liste os arquivos existentes e leia a página inicial e o CSS compartilhado para que a página reutilize os estilos, as fontes e as cores do site.
3. Verifique o formulário: a página terá um formulário curto, então precisa do relay de formulário para e-mail. Verifique os envios recentes de formulário; se não houver nenhum ou se a entrega falhar, proponha configurar o relay com a minha caixa de e-mail [endereço do Gmail ou do Yandex] enviando para [endereço do destinatário] (no caso do Gmail, vou colar uma senha de app). Mostre as configurações antes de aplicá-las e envie um teste. Adicione campos ocultos para gclid, gbraid, wbraid e parâmetros utm, para que a origem acompanhe cada lead.
4. Estrutura: hero com a mensagem vencedora, 3 blocos de benefícios, uma seção de provas (somente afirmações que eu possa comprovar, sem números ou depoimentos inventados), um formulário curto acima da dobra, 4 perguntas frequentes e um call to action repetido duas vezes. Sem menu de navegação e sem links externos.

Mostre-me primeiro o texto completo e a estrutura das seções e aguarde a minha aprovação. Depois, grave em /drafts/[slug da página] com uma meta tag noindex e me envie uma captura de tela no desktop e outra no celular. Após o meu segundo OK, grave a versão final (sem noindex) em /[slug da página], confirme que a URL ao vivo retorna HTTP 200 e tem exatamente um H1, e envie uma entrada de teste pelo formulário somente se eu concordar. Não mexa na URL final da campanha. Me dê a URL exata para que eu mesmo a atualize.

SiteAltera após sua aprovação

Corrija títulos, meta descrições e schema em todo o site hospedado

Uma tabela de problemas de SEO página por página, com correções propostas para títulos, descrições, H1, canonicals e JSON-LD, aplicadas somente após a sua aprovação.

Quando usarQuando os títulos, as meta descrições ou o schema do seu site estão inconsistentes, ausentes ou duplicados e você quer tudo corrigido de uma vez.

Audite o básico de SEO on-page de todas as páginas HTML do meu site hospedado e corrija tudo em uma única passada controlada.

Leia primeiro o guia de SEO do site e use suas regras para títulos, descrições, canonicals e o grafo @id do schema.org. Depois, liste os arquivos do site, leia cada página HTML e faça uma auditoria de SEO da página inicial e de [URL da página do serviço principal].

Entregue uma tabela: caminho da página, título atual (contagem de caracteres), meta descrição atual (contagem de caracteres), quantidade de H1, canonical, tipos de JSON-LD presentes, problema, correção proposta.

Sinalize uma página se: o título estiver fora de 50 a 60 caracteres, a descrição estiver fora de 140 a 160 caracteres ou duplicada, não houver H1 ou houver mais de um, o canonical estiver ausente ou não for autorreferenciado, ou o tipo de schema não combinar com o tipo de página do guia.

Escreva os títulos e as descrições propostos em linguagem simples e específica, com a palavra-chave principal perto do início. Sem keyword stuffing.

Mostre cada edição como um diff de antes/depois e aguarde a minha aprovação. Depois que eu aprovar, aplique as edições, releia 3 páginas alteradas ao vivo e confirme que as novas tags estão sendo servidas.

SiteAltera após sua aprovação

Proteja o tráfego orgânico após um redesign com um mapa de redirecionamentos 301

Encontra URLs antigas que geraram cliques orgânicos, verifica quais agora retornam 404 ou 410, associa cada uma à melhor página nova por tema e cria os 301 somente após a sua aprovação, depois verifica tudo.

Quando usarQuando você relançou ou redesenhou seu site e teme que URLs antigas agora retornem 404 e você esteja perdendo tráfego orgânico.

Relançamos o site no servidor de hospedagem em [data de relançamento] e preciso garantir que nenhum tráfego orgânico foi perdido por causa de URLs quebradas.

1. Encontre a propriedade do Search Console correspondente e o servidor de hospedagem de [domínio].
2. Extraia os dados do Search Console por página e consulta juntos, ordenados por cliques. O Search Console conta os dias a partir de hoje, então defina o período para cobrir os 90 dias antes de [data de relançamento] mais os dias desde então; me diga a janela exata que você usou e avise que ela inclui alguns cliques pós-relançamento. Se eu colar uma exportação do Search Console para a janela exata pré-relançamento, use-a no lugar. Com isso, mantenha as páginas com pelo menos 10 cliques e use a principal consulta de cada página a partir dos mesmos dados.
3. Acesse cada uma dessas URLs no site publicado, começando pelas com mais cliques, em lotes, e registre o status HTTP e qualquer cabeçalho Location.
4. Liste as regras de redirecionamento atuais e os arquivos atuais do site. Para cada URL que retornar 404 ou 410, proponha a página nova mais próxima por tema, não apenas por slug parecido (leia a estrutura da página candidata se necessário). Se não houver uma boa correspondência, diga isso em vez de enviá-la para a página inicial.

Entregue uma tabela: URL antiga, cliques (janela), principal consulta, status atual, destino 301 proposto, confiança (alta/média/baixa).

Ordene por cliques. Sinalize qualquer regra proposta que criaria uma cadeia ou loop com as regras de redirecionamento existentes. Mostre o mapa completo como uma prévia de redirecionamentos e aguarde a minha aprovação antes de criar qualquer redirecionamento.

Depois que eu aprovar, adicione os 301 (caminhos como origem, mantendo as regras existentes), acesse novamente cada URL antiga para confirmar que ela retorna um único 301 cujo destino retorna 200, e inspecione os 5 destinos com mais cliques no Search Console para confirmar que estão indexados ou indexáveis com o canonical esperado. Termine com 3 linhas que eu possa enviar à gestão: URLs corrigidas, cliques protegidos, pendências.

SiteAltera após sua aprovação

Encontre e desfaça uma edição que quebrou o site usando snapshots de versão

Rastreia uma quebra recente em um site hospedado até o snapshot e o arquivo que a causaram, compara o arquivo antes e depois e restaura apenas o necessário após a sua aprovação.

Quando usarQuando algo no seu site hospedado quebrou depois de uma edição recente e você precisa descobrir o que mudou e desfazer com segurança.

Algo no meu site hospedado quebrou depois de uma edição recente: [descreva o sintoma, ex.: formulário sumiu, layout quebrado no celular]. Encontre a causa e desfaça com o menor rollback possível.

0. Liste primeiro meus servidores e sites. Os snapshots de versão existem apenas em servidores de hospedagem da Opus Growth. Se [URL da página afetada] pertencer a um site WordPress conectado pelo plugin, pare e me avise, pois este método de rollback não se aplica lá. Se o servidor hospedar mais de um site, use o site que serve [URL da página afetada].

1. Leia [URL da página afetada] ao vivo: status HTTP, cabeçalhos de resposta e HTML (use a visão de estrutura se a página for grande). Tire capturas de tela em desktop e mobile.

2. Liste os snapshots automáticos, voltando página por página até cobrir os últimos 14 dias. Escolha os snapshots próximos de [horário aproximado da edição]. Os snapshots trazem horário e rótulo, não o nome de quem fez a edição, então use apenas horário e rótulo e não presuma quem alterou o quê.

3. Para cada arquivo suspeito, mostre o diff entre o snapshot imediatamente anterior à edição e o arquivo atual. Leia o arquivo atual se precisar de mais contexto. Explique em linguagem simples o que mudou e por que isso causa o sintoma.

4. Recomende a correção mais restrita: um arquivo, uma pasta, ou o site inteiro somente se vários arquivos estiverem envolvidos. Liste quaisquer mudanças posteriores a esse snapshot que também seriam perdidas. Se o site tiver uma pasta de código-fonte .src/ (um projeto de build), avise que a restauração será sobrescrita no próximo rebuild, a menos que a correção também seja levada para o código-fonte.

Execute a restauração primeiro como prévia e me mostre. Não aplique nada até eu aprovar. Depois que eu aprovar, aplique a restauração, leia a página ao vivo novamente, tire novas capturas de tela e confirme que o sintoma desapareceu e que o status é 200.

Termine com uma nota de incidente de 4 linhas para a gestão: o que quebrou, quando (com base nos horários dos snapshots), janela de impacto e o que foi restaurado.

SiteSomente leitura

Verifique se cada página de destino do Google Ads corresponde ao anúncio que envia o tráfego

Encontra suas 5 páginas de destino com maior gasto, lê cada página ao vivo e compara com o texto dos RSAs que apontam para ela, depois lista cada divergência de mensagem com uma correção em uma linha.

Quando usarQuando a taxa de conversão das suas páginas de destino do Google Ads está baixa e você suspeita que a página não corresponde à promessa feita no anúncio.

Na minha conta do Google Ads [nome da conta], encontre as páginas de destino que tiveram o maior gasto nos últimos 30 dias.

1. Execute uma consulta GAQL em landing_page_view para os últimos 30 dias com landing_page_view.unexpanded_final_url, metrics.cost_micros, metrics.clicks e metrics.conversions. Calcule a taxa de conversão como conversões divididas por cliques. Pegue as 5 URLs com maior custo.
2. Execute uma segunda consulta GAQL em ad_group_ad para anúncios responsivos de pesquisa ativados, retornando ad_group_ad.ad.id, ad_group.id, campaign.name e ad_group_ad.ad.final_urls, e associe cada anúncio às 5 URLs principais.
3. Para os anúncios associados, busque os títulos e as descrições com get_ad_details. Use rsa_asset_performance para ver quais títulos realmente tiveram mais impressões, assim você compara a página com o texto que as pessoas de fato viram.
4. Leia cada página ao vivo como um visitante a vê: uma vez com outline=true para o título, a meta description e o H1, e outra com text=true para o texto visível.
5. Compare tudo. O H1 e o texto de abertura da página repetem a promessa, a oferta ou o serviço dos anúncios? O preço ou o desconto do anúncio aparece em algum lugar da página? Existe uma única chamada para ação clara que corresponda à chamada para ação do anúncio?

Entregue uma tabela com estas colunas: URL, custo, taxa de conversão, promessa do anúncio, o que a página realmente diz, a divergência e uma correção em uma frase. Sinalize como prioridade qualquer página com taxa de conversão abaixo de [taxa de conversão alvo, ex.: 3%]. Não altere nenhum anúncio nem página. Esta é apenas uma revisão.

SiteAltera após sua aprovação

Verificação de velocidade mobile das páginas para onde vai seu orçamento de anúncios

Classifica suas páginas de destino por cliques no mobile, mede os Core Web Vitals mobile das 5 principais e, se elas estiverem no seu site WordPress, recomenda até 3 ajustes de velocidade seguros com prévia e desfazer.

Quando usarQuando a maioria dos cliques dos seus anúncios vem de celulares e você teme que páginas de destino lentas façam as pessoas saírem antes de ver qualquer coisa.

A maioria dos cliques dos meus anúncios vem de celulares, então quero saber se minhas páginas de destino perdem pessoas antes de carregar.

1. No Google Ads [nome da conta], execute uma consulta GAQL em landing_page_view para os últimos 30 dias, segmentada por segments.device, com landing_page_view.unexpanded_final_url, metrics.clicks, metrics.cost_micros, metrics.speed_score e metrics.mobile_friendly_clicks_percentage. Mantenha as linhas MOBILE e liste as URLs finais com mais cliques no mobile. Se a pontuação de velocidade ou a taxa de cliques compatíveis com mobile vierem vazias para alguma URL, diga isso em vez de adivinhar.
2. Execute core_web_vitals com strategy=mobile nas 5 URLs principais. Informe LCP, INP e CLS. Use o valor de campo de usuários reais para o INP quando existir; se não existir, informe o TBT dos dados de laboratório e indique que é um valor aproximado. Marque como reprovado LCP acima de 2,5 s, INP acima de 200 ms e CLS acima de 0,1.
3. Somente se essas URLs estiverem no meu site WordPress [URL do site], execute wordpress_performance e mostre qual plugin de cache está em uso, quais otimizações já estão ativas e quais estão sinalizadas como arriscadas para este site. Se as páginas estiverem em outro lugar, pule esta etapa e me avise.

Me entregue uma tabela com estas colunas: URL, cliques no mobile, custo, LCP, INP (ou TBT), CLS, aprovado ou reprovado e a causa provável. Depois recomende no máximo 3 ajustes de velocidade para ativar, começando pelos mais seguros (cache de página, cache do navegador, minificação, lazy load antes de qualquer coisa arriscada). Mostre exatamente o que mudaria e aguarde minha aprovação antes de aplicar qualquer coisa. Aplique as mudanças aprovadas uma de cada vez, limpe o cache após cada uma e execute core_web_vitals novamente na pior página. Explique como desfazer cada mudança (revert=true desfaz apenas a mais recente).

SiteSomente leitura

Verifique se as tags de conversão realmente disparam na minha página de destino dos anúncios

Um diagnóstico claro de tags do Google ausentes, duplicadas ou quebradas na sua página de destino e de quais ações de conversão não registram nada.

Quando usarQuando você duvida que seus anúncios registrem as conversões corretamente e quer saber se há tags ausentes, duplicadas ou quebradas.

Não tenho certeza de que meus anúncios registram as conversões corretamente. Verifique o rastreamento na minha principal página de destino [URL da página de destino].

1. Audite a página e liste todas as tags de medição que ela carrega (contêiner do GTM, GA4, tag do Google Ads).
2. No meu site WordPress, mostre todos os lugares onde uma tag do GTM ou do GA4 é adicionada: plugin, snippet, código do cabeçalho ou tema. Sinalize as duplicatas. O mesmo ID do GA4 ou do GTM carregando duas vezes é um problema.
3. No meu contêiner do GTM, liste as tags e seus acionadores. Verifique se a tag de conversão do Google Ads dispara na página de agradecimento ou no envio do formulário, e não em todas as visualizações de página.
4. No Google Ads, liste minhas ações de conversão e sinalize qualquer ação que seja principal, mas tenha registrado zero conversões nos últimos 30 dias. Compare o ID e o rótulo de conversão no GTM com os que o Google Ads espera.

Me dê um veredito curto: funcionando, parcialmente quebrado ou quebrado. Depois liste os problemas, ordenados pelo impacto nos lances. Não edite nem publique nada por enquanto. Apenas proponha as correções.

SiteAltera após sua aprovação

Teste o formulário de contato do qual meu tráfego pago depende

Audita o formulário do Contact Form 7 na sua página de destino de anúncios, envia um teste aprovado, verifica no GA4 se há um evento de formulário e identifica onde leads podem estar se perdendo.

Quando usarQuando você envia tráfego pago para uma página com um formulário do Contact Form 7 e suspeita que alguns leads nunca chegam à sua caixa de entrada.

Meus anúncios levam as pessoas a uma página com um formulário do Contact Form 7, e suspeito que alguns leads nunca chegam à minha caixa de entrada.

1. Liste os formulários do Contact Form 7 no meu site WordPress [URL do site]. Encontre o usado em [URL da página de destino] lendo essa página e cruzando o id do shortcode contact-form-7.
2. Mostre seus campos, quais são obrigatórios e os endereços de e-mail do destinatário e do remetente nas configurações. Sinalize excesso de campos obrigatórios (mais de 4 é um alerta para um formulário de leads) e qualquer endereço de destinatário que não seja [meu endereço de e-mail].
3. Prepare um envio de teste claramente identificado como "TEST - please ignore" e mostre a prévia primeiro, porque ele envia um e-mail real. Depois que eu aprovar, envie e me diga o resultado: mail_sent, mail_failed, validation_failed (com os campos rejeitados) ou spam. Se retornar mail_sent, lembre-me de conferir se o e-mail realmente chegou em [meu endereço de e-mail], inclusive na pasta de spam, já que a ferramenta só consegue confirmar que o WordPress o enviou.
4. No GA4, liste os eventos principais e depois execute ga4_report para os últimos 30 dias com dimension=landing_page e dimension2=event. Verifique se a página do formulário registra algum evento de envio de formulário ou de lead. Se essa combinação não for aceita, execute dimension=event e me diga a contagem do evento do formulário sem a divisão por página.

Resuma em no máximo 5 tópicos: o formulário funciona, onde leads podem estar se perdendo e a correção mais importante. Não altere o formulário, a página nem nenhum rastreamento. Se for necessária uma correção, descreva a mudança exata e aguarde minha aprovação.

SiteSomente leitura

Descubra onde os cliques dos anúncios do Meta se perdem antes de a página de destino carregar

Compara cliques no link com visualizações da página de destino por anúncio do Meta e depois verifica o destino de cada anúncio fraco: status, redirecionamentos, coerência da mensagem e LCP no mobile.

Quando usarQuando você paga por cliques no link do Meta, mas muita gente parece sair antes de a sua página de destino carregar.

No Meta, eu pago por cliques no link, mas muitas pessoas podem sair antes de a minha página carregar. Verifique isso na minha conta de anúncios [nome da conta de anúncios].

1. Liste os anúncios e mantenha aqueles cujo effective_status seja ACTIVE. Para os últimos 14 dias, busque spend, inline_link_clicks e actions no nível do anúncio (com ad_id e ad_name), e leia as visualizações da página de destino na ação landing_page_view. Calcule visualizações da página de destino divididas por cliques no link. Sinalize qualquer anúncio abaixo de 70% que tenha gasto mais de [gasto mínimo, ex.: 500 TL].
2. Para cada anúncio sinalizado, leia o criativo e obtenha o link de destino, o título e o texto principal, além de quaisquer parâmetros de URL que o criativo carregue.
3. Abra cada URL de destino como um visitante faria. Informe o status HTTP. Se a resposta for um redirecionamento (status 3xx ou cabeçalho Location), abra também o destino e continue até chegar a um 200 ou a um erro, para que você possa mostrar a cadeia de redirecionamentos. Leia a página final com outline=true e text=true e diga se o título e o conteúdo dela correspondem ao título e à oferta do anúncio, e se os parâmetros de URL sobreviveram até a URL final.
4. Execute core_web_vitals com strategy=mobile em cada destino final e informe o LCP.

Entregue uma tabela com estas colunas: nome do anúncio, gasto, cliques no link, visualizações da página de destino, proporção, URL de destino, status, redirecionamentos, LCP e a causa provável. Termine com as 3 correções que recuperariam mais cliques pagos. Esta é apenas uma análise, portanto não pause nem edite nenhum anúncio.

SiteAltera após sua aprovação

Detecte URLs finais quebradas ou com redirecionamento no Google e no Microsoft Ads

Coleta todas as URLs finais dos anúncios ativos e dos sitelinks no Google e no Microsoft Ads, verifica o status, os saltos de redirecionamento e a perda de parâmetros, e prepara as correções de URL como prévias para a sua aprovação.

Quando usarQuando você alterou ou removeu páginas do seu site e quer ter certeza de que nenhum anúncio do Google ou da Microsoft envia as pessoas para uma página inexistente ou com redirecionamento.

Alterei algumas páginas do meu site e quero ter certeza de que nenhum anúncio envia as pessoas para uma página inexistente.

1. Colete todas as URLs finais únicas:
   - Google Ads [conta do Google Ads]: execute uma consulta GAQL em ad_group_ad para os anúncios ativos em campanhas e grupos de anúncios ativos, retornando campaign.name, ad_group.name, ad_group_ad.ad.id e ad_group_ad.ad.final_urls. Depois liste os sitelinks com list_extension_assets e pegue as URLs finais deles.
   - Microsoft Ads [conta do Microsoft Ads]: liste as campanhas, depois os grupos de anúncios de cada uma e, em seguida, os anúncios de cada grupo, e pegue a URL final de cada anúncio. Liste os sitelinks com list_microsoft_ad_extensions.
   Mantenha um mapa de qual campanha, grupo de anúncios, anúncio ou sitelink usa cada URL.
2. Abra cada URL como um visitante faria, com um parâmetro de teste adicionado (?utm_source=opus_test&gclid=opus_test). Registre o código de status HTTP. Se a resposta for um redirecionamento (status 3xx ou cabeçalho Location), abra também o destino e repita até chegar a um 200 ou a um erro. Registre o número de redirecionamentos e a URL final alcançada.
3. Sinalize estes casos: erros 4xx ou 5xx; mais de um redirecionamento; um redirecionamento para a página inicial em vez da página específica; e os parâmetros de teste ausentes na URL final.

Agrupe os resultados por gravidade: quebradas (corrigir hoje), com redirecionamento (corrigir nesta semana), ok. Para cada URL quebrada, mostre o que a utiliza e sugira a página substituta correta do meu site. Para encontrar candidatas, leia [URL do site]/sitemap.xml; se o meu site for um site WordPress conectado, liste também as páginas e os posts publicados. Se nenhuma das duas opções funcionar, peça que eu cole a lista de URLs das páginas atuais.

Prepare as alterações de URL apenas como prévias (confirm=false): URLs finais de RSA no Google com update_rsa, sitelinks do Google com update_sitelink, RSAs da Microsoft com update_microsoft_responsive_search_ad. Um sitelink da Microsoft não pode ser editado diretamente, então mostre a prévia de removê-lo e adicioná-lo novamente com a nova URL. Não aplique nenhuma alteração até que eu aprove cada uma.

SiteSomente leitura

Corrija palavras-chave com experiência de página de destino abaixo da média

As palavras-chave que perdem Índice de Qualidade por causa da experiência da página de destino, agrupadas pela página para onde enviam o tráfego, com uma auditoria da página e uma lista de correções para cada uma.

Quando usarQuando suas palavras-chave do Google Ads mostram experiência de página de destino abaixo da média e seu Índice de Qualidade e seus custos estão sofrendo.

No Google Ads [nome da conta], encontre as palavras-chave em que o componente de experiência da página de destino do Índice de Qualidade está "abaixo da média". Inclua apenas palavras-chave que tiveram pelo menos [mínimo de cliques, ex.: 50] cliques nos últimos 30 dias.

1. Para cada uma dessas palavras-chave, mostre o Índice de Qualidade, o CTR, o custo e as conversões. Verifique o histórico do Índice de Qualidade e me diga se a experiência da página de destino caiu recentemente e, aproximadamente, quando.
2. Agrupe as palavras-chave pelo URL final para o qual seus anúncios apontam.
3. Para cada URL, faça uma auditoria da página (título, títulos de seção, relevância do conteúdo, usabilidade em dispositivos móveis, velocidade) e verifique os Core Web Vitals no mobile. Verifique se a própria palavra-chave ou uma variação próxima aparece no título da página e no H1.

Entregue uma seção por URL. Liste as palavras-chave afetadas e o dinheiro gasto com elas, depois as 3 mudanças na página com maior probabilidade de elevar a nota. Se uma palavra-chave claramente pertence a outra página que eu já tenho, diga isso. Não altere nenhuma palavra-chave nem anúncio.

SiteAltera após sua aprovação

Reescreva os meta títulos de páginas de produto do WooCommerce com CTR orgânico baixo

Encontra páginas de produto que aparecem na primeira ou na segunda página, mas recebem poucos cliques, associa cada uma ao seu produto do WooCommerce, redige meta títulos e descrições mais atraentes e aplica apenas as linhas que você aprovar, verificando-as em seguida.

Quando usarQuando suas páginas de produto do WooCommerce aparecem na primeira ou na segunda página do Google, mas recebem poucos cliques, e você suspeita de meta títulos e descrições fracos.

Site: [site WordPress]. Propriedade do Search Console: [propriedade]. Os URLs de produto contêm: [caminho do URL de produto].

1. Busque os últimos 90 dias de desempenho orgânico com gsc_performance, dimension=page, ordenado por impressões, com um limite alto o bastante para cobrir todas as páginas de produto. Mantenha apenas os URLs que contêm [caminho do URL de produto].
2. Mantenha apenas as páginas que atendem a todos estes critérios:
   - pelo menos 500 impressões
   - posição média entre 3 e 15
   - CTR abaixo de 2%
3. Para cada página restante, obtenha as 3 principais consultas por impressões: execute gsc_performance com dimension=query, page=<esse URL>, sort=impressions, limit=3.
4. Associe cada URL ao seu produto do WooCommerce:
   - Pegue o slug do URL e encontre o post do produto com wordpress_list_posts (type=product, search=as palavras do slug). Use o post cujo slug corresponde exatamente ao URL para obter o ID.
   - Consulte preço e estoque com wordpress_woo_products, pesquisando pelo nome do produto que você acabou de encontrar. Aceite o resultado somente se o nome corresponder exatamente a esse produto.
   - Se não houver correspondência exata ou houver mais de um candidato, não adivinhe. Marque a linha como "unmatched" e liste-a separadamente para que eu possa informar o ID do produto.
5. Ignore os produtos cujos dados de estoque os mostrem como esgotados.
6. Para cada página associada, leia o meta título e a meta descrição atuais com wordpress_seo (id=o ID do produto).

Para cada página restante, redija:
- Um novo meta título: no máximo 60 caracteres, com a consulta principal perto do início.
- Uma nova meta descrição: no máximo 155 caracteres, com o preço ou um benefício concreto e um motivo para clicar. Não invente alegações, condições de frete nem descontos.

Entregue uma tabela com estas colunas: URL, ID do produto, consulta principal, posição, CTR, título atual, título proposto, descrição atual, descrição proposta. Mostre a contagem de caracteres do título e da descrição propostos.

Trate esta tabela como a prévia. Não altere nada até que eu responda com as linhas que aprovo. Depois:
1. Grave o título e a descrição aprovados com wordpress_set_seo para cada ID de produto aprovado (overwrite=true, já que esses campos já têm valores).
2. Leia cada um de volta com wordpress_seo e confirme que o título e a descrição armazenados correspondem ao que aprovei. Informe qualquer linha que não tenha sido salva.
3. Limpe o cache com wordpress_purge_cache.
4. Lembre-me de comparar o CTR desses URLs no Search Console em 4 a 6 semanas.

SiteAltera após sua aprovação

Confira se os preços dos anúncios do Google e da Meta correspondem aos preços atuais do WooCommerce

Compara todo preço, desconto e informação de estoque nos RSAs, sitelinks e criativos da Meta ativos com o catálogo do WooCommerce e mostra a prévia de correções no próprio anúncio, que preservam o histórico.

Quando usarQuando você alterou preços ou estoque na sua loja WooCommerce e teme que anúncios ativos do Google e da Meta ainda mostrem preços, descontos ou disponibilidade antigos.

Os preços mudaram em [site WordPress]. Verifique se nossos anúncios ativos ainda correspondem à loja.

1. Percorra todos os produtos do WooCommerce, página por página: nome, SKU, preço atual e estoque.
2. Em [conta do Google Ads]:
   - Busque todos os RSAs ativos em grupos de anúncios e campanhas ativos em uma única consulta GAQL em ad_group_ad (ID do anúncio, campanha, grupo de anúncios, títulos, descrições, URL final). Use get_ad_details somente onde precisar dos fixados ou do anúncio completo.
   - Leia os sitelinks de todas as campanhas com list_extension_assets (campaign_id vazio).
3. Em [conta de anúncios da Meta], liste os anúncios com status efetivo ACTIVE (list_meta_ads para a conta inteira, nomes das campanhas de list_meta_campaigns) e leia o criativo de cada um com get_meta_ad_creative: título, texto principal, descrição, link de destino, imagem ou vídeo, botão, Página e se foi criado a partir de uma publicação existente do Facebook ou do Instagram.
4. Encontre toda menção a preço, desconto ou "em estoque" que se refira a um produto. Associe-a a um produto pelo nome, SKU ou URL de destino. Quando a correspondência for incerta, diga isso em vez de forçá-la.

Entregue uma tabela: plataforma, campanha, anúncio, texto encontrado, produto, preço na loja, status. O status é um destes: match, wrong price, out of stock, product not found, unsure match.

Para cada divergência, proponha um texto corrigido dentro dos limites:
- Títulos de RSA: 30 caracteres
- Descrições de RSA: 90 caracteres
- Texto de sitelink: 25 caracteres; linhas de descrição de sitelink: 35 caracteres cada, as duas ou nenhuma

Mostre todas as edições como prévias com confirm=false e aguarde minha aprovação. Após a aprovação:
- RSAs: update_rsa com remoção/adição de títulos e descrições, para que o mesmo anúncio mantenha o histórico. Mantenha os fixados existentes.
- Sitelinks: update_sitelink no próprio sitelink.
- Meta: update_meta_ad_creative, passando o page_id, image_hash ou video_id, link e botão atuais do criativo que você leu, para que só o texto mude e o anúncio mantenha seu ID e o aprendizado. Anúncios criados a partir de uma publicação existente do Facebook ou do Instagram não podem ter o texto reescrito dessa forma: liste-os para que eu os corrija na publicação original ou os substitua.
- Lembre-me de que os anúncios editados voltam para análise nas duas plataformas.

SiteAltera após sua aprovação

Lance um novo produto WooCommerce com um grupo de anúncios da Rede de Pesquisa do Google pronto

Cria um produto WooCommerce após a aprovação, verifica se a página dele está no ar e depois monta um grupo de anúncios da Rede de Pesquisa do Google pausado, com palavras-chave com volume verificado, negativas e um RSA, em uma campanha existente.

Quando usarQuando você estiver prestes a adicionar um novo produto à sua loja WooCommerce e quiser um grupo de anúncios da Rede de Pesquisa do Google pronto para anunciá-lo.

Adicione um novo produto a [site WordPress] e deixe-o pronto para anunciar em [conta do Google Ads].

Detalhes do produto: [nome, preço, SKU, descrição curta, quantidade em estoque].

Etapa 1: o produto
- Mostre-me, no chat, o produto simples do WooCommerce que você criaria: nome, SKU, preço, descrição (comece com a descrição curta e depois a descrição completa que você escrever a partir dos meus dados) e estoque.
- Crie-o somente depois que eu aprovar, com status publish para que a página fique no ar.
- Encontre a URL do produto na resposta, ou com wordpress_list_posts (tipo product, buscando pelo nome), e busque-a com site_read_url. Confirme que ela retorna HTTP 200 e que o título e o preço na página estão corretos. Se não estiverem, pare e me avise.

Etapa 2: o grupo de anúncios, na campanha existente [campanha]. Proponha:
- Um novo grupo de anúncios com CPC máximo padrão igual ao CPC médio da campanha nos últimos 30 dias (custo dividido por cliques, de performance_report no nível da campanha).
- De 10 a 15 palavras-chave em correspondência de frase e exata, criadas a partir do nome do produto, da categoria dele e de modificadores de intenção de compra.
- Volumes para todas as palavras-chave: execute keyword_planner e keyword_historical_metrics com turco ou o idioma da campanha e os locais da campanha (leia-os com get_campaign_targeting). Descarte termos com menos de 50 buscas mensais em média.
- Palavras-chave negativas do grupo de anúncios, como grátis, usado ou de segunda mão, somente quando forem irrelevantes para este produto.
- Um RSA com 12 títulos (máx. 30 caracteres) e 4 descrições (máx. 90 caracteres) apontando para a URL do produto, usando apenas fatos lidos na página ativa do produto.

Mostre o grupo de anúncios completo, a lista de palavras-chave, as negativas e o anúncio como prévias com confirm=false. Aguarde minha aprovação antes de criar qualquer coisa no Google Ads. Como a campanha já está ativa, após a aprovação faça nesta ordem: crie o grupo de anúncios, pause-o imediatamente com update_ad_group_status e depois adicione as palavras-chave, as negativas e o RSA (status do RSA ENABLED, de modo que ativar o grupo de anúncios seja o único interruptor restante). Não ative o grupo de anúncios até que eu diga.

SiteAltera após sua aprovação

Transforme um termo de pesquisa lucrativo em um rascunho de página de destino dedicada

Encontra termos de pesquisa com ROAS alto que hoje levam a uma página genérica, agrupa em temas, verifica a cobertura orgânica e a canibalização, e cria o rascunho de uma página WordPress dedicada com produtos, FAQ e campos meta.

Quando usarQuando alguns termos de pesquisa do Google Ads convertem bem, mas levam as pessoas à sua página inicial ou a uma categoria ampla, e você suspeita que uma página dedicada teria melhor desempenho.

Encontre, na conta do Google Ads [conta], os termos de pesquisa dos últimos 60 dias que convertem com lucro mas levam a uma página genérica, e transforme o melhor tema em um rascunho de página de destino dedicada.

1. Execute google_ads_query em search_term_view para os últimos 60 dias: termo de pesquisa, campanha, ID e nome do grupo de anúncios, custo, conversões e valor de conversão. Calcule o ROAS como valor de conversão dividido pelo custo. Mantenha os termos com pelo menos 3 conversões e ROAS igual ou superior a [ROAS alvo]. Use o bucket already_negative de search_terms_report para descartar tudo o que já está bloqueado.
2. Descubra para onde esses termos levam. Execute google_ads_query em ad_group_ad para os grupos de anúncios envolvidos e leia as URLs finais dos anúncios ativos. Um termo de pesquisa leva à URL final dos anúncios do seu grupo de anúncios, então, se um grupo usa várias URLs, mostre todas. Mantenha os termos cuja URL é genérica: a página inicial [URL da página inicial] ou uma categoria ampla, como [URLs de categorias amplas].
3. Agrupe os termos restantes em temas e apresente os 3 mais fortes. Para cada tema, mostre:
   - Os termos de pesquisa com custo, conversões, valor de conversão e ROAS.
   - O status orgânico de gsc_performance (dimensão page,query, filtrada pela consulta principal do tema): a página que ranqueia e sua posição média.
   - As páginas que já cobrem o tema, encontradas com wordpress_search_content nas frases-chave do tema, para que a nova página não canibalize essas páginas.

Pare aqui e deixe-me escolher um tema.

Depois, crie o rascunho da página:
- Um H1 que corresponda à intenção de busca.
- Uma introdução de 80 palavras.
- De 4 a 6 produtos em estoque de wordpress_woo_products, cada um com um motivo de compra em uma linha. Use apenas nomes e preços reais retornados pela ferramenta.
- Uma breve seção de comparação ou "como escolher".
- Um FAQ com 4 perguntas.
- Um meta title (máx. 60 caracteres) e uma meta description (máx. 155 caracteres).

Execute seo_content_lint no rascunho e corrija o que for apontado. Depois, mostre-me o rascunho completo, os campos meta e o slug que você pretende usar.

Depois que eu aprovar, crie a página com wordpress_create_post com status draft e type page, e defina o meta title e a description com wordpress_set_seo no novo id. Não publique a página e não altere nenhum anúncio, palavra-chave ou URL final.

SiteAltera após sua aprovação

Escreva descrições para categorias de produtos com pouco conteúdo que recebem impressões

Encontra categorias de produtos com muitas impressões no Search Console e quase nenhuma descrição, pesquisa palavras-chave relacionadas e escreve descrições de categoria aprovadas, além de meta titles e descriptions de arquivo.

Quando usarQuando suas categorias de produtos recebem impressões de busca, mas têm pouco ou nenhum texto de descrição, por isso ranqueiam mal e atraem poucos cliques.

Nossa frase de confiança para as descrições: [política de envio e devoluções]. Se eu deixei este placeholder sem preencher, peça-o a mim antes de escrever qualquer coisa.

1. Liste todas as categorias de produtos de [site] com wordpress_terms (action list, taxonomy product_cat). Conte você mesmo as palavras de cada descrição atual.
2. As URLs das categorias seguem [padrão de URL da categoria, ex.: https://site.com/urun-kategori/slug/]. Execute gsc_performance em [propriedade do site] para os últimos 90 dias com dimensão page,query e associe as linhas à URL de cada categoria: cliques, impressões, posição média e as 5 principais consultas por impressões.
3. Escolha as 8 categorias com mais impressões cuja descrição tenha menos de 50 palavras.
4. Pesquisa de palavras-chave: verifique primeiro seo_history para não pagarmos duas vezes pela mesma palavra inicial. Execute seo_keyword_research na consulta principal de cada categoria (localização [país], idioma [idioma]) e adicione 3 termos relacionados com volume de busca real. seo_keyword_research exige o complemento SEO Intelligence. Se ele não estiver disponível, use keyword_planner na minha conta do Google Ads [conta] com o idioma e a localização corretos e informe qual fonte você usou.

Depois, escreva para cada categoria:
- Uma descrição de 120 a 180 palavras. Comece com o que o comprador encontra na categoria, depois explique como escolher e feche com a frase de confiança acima. Use a consulta principal uma vez na primeira frase e os termos relacionados de forma natural. Sem repetir palavras para forçar palavras-chave e sem promessas que não possamos comprovar.
- Um meta title de arquivo (máx. 60 caracteres) e uma meta description (máx. 155 caracteres).

Execute seo_content_lint em cada descrição e corrija o que for apontado.

Entregue uma tabela com estas colunas: categoria, impressões, posição, consulta principal, número atual de palavras, meta title proposto. Coloque os textos completos abaixo da tabela.

Mostre tudo primeiro como prévia: execute wordpress_terms (action update, term_id, description) com confirm=false para que eu veja a alteração exata, e liste os valores de wordpress_set_seo (term_id, taxonomy product_cat, title, description) que você vai gravar. Em um site multilíngue, use o termo do idioma correto. Depois que eu aprovar, aplique as descrições com wordpress_terms confirm=true, defina os campos meta com wordpress_set_seo e depois limpe o cache com wordpress_purge_cache.

SiteSomente leitura

Classifique as páginas de destino do Google Ads por problemas de velocidade e gasto desperdiçado

Cruza os dados de custo e conversão das páginas de destino do Google Ads com os Core Web Vitals reais de mobile, estima o gasto perdido em páginas lentas e classifica quais páginas corrigir primeiro. Somente leitura.

Quando usarQuando os leads do seu Google Ads estão caindo e você suspeita que páginas de destino lentas estão desperdiçando seu orçamento de anúncios.

Eu tenho um negócio de serviços locais e a maioria dos meus leads vem do Google Ads na conta [conta]. Descubra quais páginas de destino perdem leads porque carregam devagar. Somente leitura: não altere nada na conta.

1. Execute google_ads_query em landing_page_view para os últimos 30 dias (segments.date DURING LAST_30_DAYS): landing_page_view.unexpanded_final_url, clicks, cost, conversions, speed_score e mobile_friendly_clicks_percentage. Calcule a taxa de conversão como conversões divididas por cliques por URL, e a média da conta como o total de conversões dividido pelo total de cliques em todas as URLs. Se speed_score ou mobile_friendly_clicks_percentage vierem vazios, marque como indisponíveis e continue.
2. Pegue as 8 URLs com maior custo e execute core_web_vitals em cada uma, strategy mobile, resources=true. Informe LCP, INP e CLS com dados de campo. Se uma página não tiver dados de campo para INP, informe o TBT de laboratório, marque o INP como "sem dados de campo" e não o conte como ruim. Diga, para cada métrica, se é dado de campo ou de laboratório.
3. Classifique cada métrica como boa, precisa melhorar ou ruim. LCP bom em até 2,5 s, ruim acima de 4 s. INP bom em até 200 ms, ruim acima de 500 ms. CLS bom em até 0,1, ruim acima de 0,25.
4. Indique o principal gargalo de cada página a partir das listas de recursos: o elemento do LCP, arquivos que bloqueiam a renderização, CSS ou JS não utilizado, ou imagens grandes demais.
5. Estime o gasto desperdiçado nas páginas que convertem abaixo da média da conta: custo × (1 − taxa de conversão da página ÷ taxa de conversão da conta). Páginas na média ou acima recebem 0.
6. Monte uma tabela com estas colunas: URL, custo, conversões, taxa de conversão, speed score, LCP, INP, CLS, quantidade de métricas ruins, gasto desperdiçado estimado, principal gargalo.
7. Classifique por prioridade: primeiro o gasto desperdiçado estimado, depois a quantidade de métricas ruins como critério de desempate. Se uma página tiver poucos cliques (menos de 50), diga que a taxa de conversão ainda não é confiável.

Sinalize toda página em que o LCP mobile esteja acima de 4 s e a taxa de conversão abaixo da média da conta. Essas páginas devem ser corrigidas primeiro. Termine com as 3 correções concretas mais importantes para cada página sinalizada, com base no que o Lighthouse realmente reportou.

SiteAltera após sua aprovação

Ajuste com segurança o cache e as configurações de velocidade do WordPress, com teste antes e depois

Um plano de alterações seguro e aprovado por você para as configurações de velocidade do seu WordPress, com Core Web Vitals medidos antes e depois.

Quando usarQuando o seu site WordPress está lento no celular e você quer acelerá-lo sem quebrar formulários ou botões de ligação.

Meu site WordPress [site] está lento no celular, e é de lá que vêm meus leads por telefone. Melhore as configurações de velocidade dele sem quebrar o site.

1. Leia a configuração atual com wordpress_performance. Quero saber qual plugin de cache está em uso, quais otimizações estão ativadas e quais estão sinalizadas como arriscadas para este site.
2. Meça uma linha de base com core_web_vitals no celular para estas páginas: a página inicial, [URL da página do serviço principal] e a página de contato. Informe LCP, INP e CLS.
3. Proponha até 5 alterações de configuração. Para cada alteração, informe o efeito esperado e o nível de risco. Deixe de fora tudo o que estiver sinalizado como arriscado, como o atraso agressivo de JS, que pode quebrar botões de ligação ou formulários.
4. Mostre as alterações exatas como prévia e aguarde a minha aprovação. Não aplique nada antes da minha confirmação.
5. Depois que eu aprovar, aplique as alterações, limpe o cache e execute core_web_vitals novamente nas mesmas páginas.
6. Entregue uma tabela de antes e depois.

Se alguma métrica piorar, ou se o botão de clique para ligar ou o formulário parar de funcionar, avise-me imediatamente. Depois ofereça desfazer a alteração em uma única etapa.

SiteAltera após sua aprovação

Encontre tags duplicadas do GA4 e do GTM no site WordPress

Uma tabela com todas as tags GA4/GTM do site, mostrando onde cada uma está instalada e quais contam em dobro, além de correções exibidas para aprovação.

Quando usarQuando os números do seu GA4 parecem inflados e você suspeita que tags do Google Tag Manager ou do GA4 estão carregando duas vezes no seu site WordPress.

Audite como o rastreamento dispara no meu site WordPress [URL do site]. Encontre todos os lugares onde ele carrega o Google Tag Manager ou uma tag do GA4: plugins, snippets do WPCode, código de cabeçalho e rodapé, arquivos do tema ativo e a própria saída do conector da Opus. Depois execute uma auditoria de tags de mensuração na página inicial e em [URL da página de destino principal].

Entregue uma tabela com estas colunas: ID da tag, onde está instalada, páginas em que dispara e duplicada (sim/não). Marque como crítico:
- qualquer ID de mensuração do GA4 ou contêiner do GTM que carregue mais de uma vez na mesma página,
- um snippet gtag fixo no código de um arquivo do tema junto com o GTM,
- qualquer ID de mensuração que não corresponda ao fluxo de dados da minha propriedade do GA4.

Termine com um resumo de 3 linhas que eu possa encaminhar para a diretoria. Ele deve dizer o que está sendo contado em dobro, o efeito provável nas sessões e conversões reportadas e a correção.

Não altere nada por enquanto. Para cada correção, mostre a mudança exata, ou seja, qual snippet desativar ou qual linha do tema remover, e aguarde minha aprovação. Depois que eu aprovar uma mudança, limpe o cache e audite a página novamente para confirmar que a tag agora carrega uma única vez.

SiteAltera após sua aprovação

Instale uma tag de conversão do Google Ads via GTM com prévia e reversão

Um workspace do GTM preparado com a tag de conversão do Google Ads e o acionador corretos, publicado somente após a aprovação e com um ponto de reversão claro.

Quando usarQuando você precisa rastrear uma conversão do Google Ads pelo Google Tag Manager e quer revisar e publicar com segurança.

Configure o rastreamento de conversões do Google Ads para a ação de conversão [nome da ação de conversão] por meio do contêiner GTM [GTM-XXXX]. Ele deve disparar somente em [caminho da página de agradecimento].

Faça estas etapas em ordem:
1. Leia o Conversion ID e o rótulo da ação (o valor de send_to).
2. Liste as tags, os acionadores e as variáveis existentes para não criarmos duplicatas. Verifique se já existe uma tag Conversion Linker disparando em todas as páginas.
3. Em um novo workspace, prepare o seguinte: uma tag de conversão do Google Ads com o valor de send_to correto, um acionador de Page View que corresponda exatamente ao caminho da página de agradecimento (não use "contém" se outros URLs compartilharem essa string) e um Conversion Linker, caso não exista.

Mostre-me o status do workspace com todas as alterações pendentes e eventuais conflitos, e aguarde minha aprovação antes de publicar.

Depois que eu aprovar e você publicar, informe o número da nova versão ativa e a versão que ela substituiu, para que possamos reverter em uma única etapa se as conversões parecerem erradas. Finalize com uma nota curta para a gestão: o que foi adicionado, quando entrou no ar e quando as primeiras conversões devem aparecer no Google Ads, o que geralmente leva de 24 a 48 horas.

SiteAltera após sua aprovação

Teste o formulário de contato de ponta a ponta e concilie com Ads e GA4

Verifica os destinatários de cada formulário do Contact Form 7, envia envios de teste aprovados, confere o acionador de sucesso do GTM e as tags que ele dispara, e concilia 14 dias de eventos de formulário do GA4 com as conversões de lead do Google Ads.

Quando usarQuando você não tem certeza de que os leads dos formulários do seu site estão realmente sendo recebidos e contabilizados, ou quando o GA4 e o Google Ads mostram números de leads diferentes.

Verifique se os leads do meu site WordPress [URL do site] estão sendo capturados e rastreados corretamente. As etapas 1, 3 e 4 são somente leitura.

1. Liste os formulários do Contact Form 7 e mostre os campos obrigatórios e os e-mails de notificação de cada um. Sinalize qualquer endereço de destinatário que pareça errado ou desatualizado. Nosso domínio atual é [domínio da empresa].
2. Os envios de teste enviam um e-mail de notificação REAL para os destinatários de cada formulário, e a entrada também pode chegar a qualquer CRM ou autoresponder conectado ao formulário. Antes de enviar qualquer coisa, execute cada teste como prévia (confirm=false). Mostre-me, por formulário, os campos e valores que seriam enviados e quais endereços receberiam o e-mail, e aguarde minha aprovação. Para cada formulário que eu aprovar, envie uma entrada com nome e mensagem definidos como "TEST - please ignore" e e-mail [e-mail de teste]. Informe o resultado: mail_sent, mail_failed, validation_failed (com os campos rejeitados) ou spam. Observe que esse teste passa pelo endpoint REST do CF7 no servidor, então nenhuma tag do navegador dispara. Ele comprova que o e-mail funciona, não o rastreamento, e não adiciona conversões ao GA4 nem ao Google Ads.
3. Verifique o que realmente dispara no site. Liste todas as fontes de GTM e GA4 no site e sinalize se dois contêineres diferentes estiverem ativos ao mesmo tempo. No contêiner GTM [GTM-XXXX], liste os acionadores e as tags e verifique se há um acionador que escuta um envio bem-sucedido do CF7 (um evento personalizado como wpcf7mailsent ou equivalente), e não apenas um clique no botão de envio ou um envio genérico de formulário. Confirme qual tag de evento do GA4 e qual tag de conversão do Google Ads ele dispara. Compare o ID e o rótulo de conversão dessa tag do Ads com as tags de conversão da conta, para sabermos se ela alimenta a ação de conversão de lead correta. Verifique se há alterações não publicadas no workspace, pois elas não rodam no site ativo.
4. Para os últimos 14 dias, compare a contagem do evento de formulário no GA4 (relatório do GA4 detalhado por evento) com as conversões do Google Ads da ação de conversão de lead.

Entregue um checklist de aprovado/reprovado por formulário (destinatários, entrega do e-mail, acionador de sucesso, tags disparadas, correspondência do rótulo de conversão) e uma tabela de conciliação mostrando a contagem do GA4, a contagem do Ads e a diferença em %. Se a diferença for superior a 20%, liste as causas prováveis em ordem: acionador no clique em vez de no sucesso, consentimento ou bloqueadores de anúncios, tag duplicada ou segundo contêiner, ou ação de conversão ou rótulo errado.

Isto é apenas diagnóstico. Proponha correções, mas não edite formulários, o rastreamento do site nem o GTM até que eu aprove cada uma. Para cada correção aprovada, mostre primeiro a prévia com confirm=false e aguarde meu aval. Nunca publique o contêiner do GTM sem a minha aprovação explícita.

SiteAltera após sua aprovação

Verificação da configuração de conversões B2B: metas do Microsoft UET e conversões do LinkedIn

Um relatório de status das tags UET, das metas de conversão da Microsoft e das regras de conversão do LinkedIn por campanha, com as peças que faltam propostas para aprovação.

Quando usarQuando você roda campanhas B2B de pedido de demonstração no Microsoft Ads e no LinkedIn e não sabe se as conversões estão sendo rastreadas, então o custo por demonstração fica incerto.

Verifique se o nosso pedido de demonstração em [URL da página de agradecimento] está sendo rastreado como conversão no Microsoft Advertising e no LinkedIn, para que a gestão veja o custo por demonstração em todos os canais.

Microsoft:
- Liste as tags UET e o status delas.
- Liste as metas de conversão, mostrando tipo, regra de URL, contagem e qual tag cada uma usa.
- Para os últimos 30 dias, mostre o gasto e as conversões por campanha.
- Sinalize qualquer campanha que gastou mais de [limite de gasto] sem nenhuma conversão, e qualquer estratégia de lance baseada em conversões rodando sem uma meta funcionando.

LinkedIn:
- Liste todas as regras de conversão.
- Liste as campanhas ativas e quais conversões cada uma tem associadas.
- Para os últimos 30 dias, mostre o gasto e as conversões por campanha.
- Sinalize qualquer campanha ativa sem conversão associada.

Entregue duas tabelas, uma por plataforma, e um resumo curto dizendo se o custo por demonstração pode ser reportado com confiabilidade em cada uma.

Se a meta do URL da demonstração estiver ausente na Microsoft, ou se as campanhas do LinkedIn não tiverem a conversão de demonstração, prepare a meta ou a associação exata e mostre-me primeiro. Aguarde minha aprovação antes de criar ou associar qualquer coisa.

SiteAltera após sua aprovação

Verifique a tag do Google no nosso site hospedado e passe-a para o modo first-party

Um checklist de aprovado/reprovado sobre o carregamento da tag, bloqueios de CSP e ID de medição no site hospedado, além de uma configuração do Google tag gateway proposta para aprovação.

Quando usarQuando você não tem certeza de que o rastreamento do Google funciona no site hospedado na Opus Growth, ou suspeita que bloqueadores de anúncios e cabeçalhos de segurança estejam consumindo seus dados.

Nosso site [domínio] roda na hospedagem da Opus Growth. Quero confirmar que o rastreamento do Google funciona nele e reduzir a perda de dados causada por bloqueadores de anúncios.

1. Leia a página inicial ao vivo e [URL da página de contato] exatamente como um navegador faz. Informe qual contêiner do GTM ou ID de medição do GA4 é carregado e se ele carrega uma vez ou mais de uma vez.
2. Compare esse ID com o fluxo de dados da minha propriedade do GA4 e sinalize qualquer divergência.
3. Verifique os cabeçalhos de resposta em busca de uma Content-Security-Policy que possa bloquear googletagmanager.com, google-analytics.com ou domínios do Google Ads.
4. Leia os relatórios de violação de CSP coletados e liste os que bloqueiam domínios de tags.

Entregue um checklist de aprovado/reprovado com estes itens: tag presente, ID correto, carregamento único, CSP permite as tags, sem relatórios de violação. Acrescente uma linha sobre o que cada falha significa para o nosso tráfego reportado.

Depois, proponha servir a tag do Google a partir do nosso próprio domínio por meio do Google tag gateway (modo first-party). Mostre a configuração exata e as alterações de cabeçalho necessárias, e aguarde a minha aprovação. Depois que eu aprovar, leia a página ao vivo novamente e verifique os usuários ativos em tempo real do GA4 para confirmar que os dados continuam chegando.

SiteAltera após sua aprovação

Crie o rascunho de uma landing page dedicada que combine com o seu melhor anúncio da Meta

Uma landing page em rascunho no WordPress criada a partir do texto do seu anúncio da Meta com melhor desempenho, com título e descrição meta, sem publicação automática.

Quando usarQuando seus anúncios da Meta enviam tráfego para a página inicial e você quer uma landing page focada que combine com o seu anúncio de melhor desempenho.

Minha campanha da Meta [nome da campanha] envia tráfego para a página inicial. Quero uma landing page dedicada no lugar dela.

Puxe os últimos 30 dias no nível do anúncio: gasto, cliques no link, CTR, resultados e custo por resultado. Leia o criativo dos 2 melhores anúncios em resultados: texto principal, título e botão.

Depois, escreva uma landing page com esta estrutura:
- Um H1 que repita a promessa do título do melhor anúncio.
- 3 blocos curtos de benefícios.
- Uma seção de prova social, com espaços reservados que eu vou preencher. Não invente avaliações.
- Um FAQ com 4 perguntas que respondam às prováveis objeções.
- Um CTA, exibido duas vezes, apontando para [link do formulário ou do WhatsApp].

Mantenha a página com menos de 400 palavras, em linguagem simples, sem exageros. Proponha também um título meta (máx. 60 caracteres) e uma descrição meta (máx. 155 caracteres).

Mostre-me primeiro o texto completo. Depois que eu aprovar, crie a página apenas como RASCUNHO, configure os campos de SEO e me envie o link de prévia. Não publique a página e não altere a URL de destino de nenhum anúncio.

SiteSomente leitura

Verificação mensal de Core Web Vitals em todos os sites dos clientes

Uma tabela em semáforo, com uma linha por cliente, dos Core Web Vitals da página inicial e das páginas principais, mais a lista de clientes que precisam de ação neste mês.

Quando usarQuando você gerencia vários sites de clientes e precisa de uma visão mensal de quais estão lentos ou piorando nos Core Web Vitals.

Liste todos os sites de clientes conectados a esta conta, tanto sites WordPress quanto servidores de hospedagem.

Para cada site, faça uma verificação de Core Web Vitals no mobile em:
- a página inicial
- a principal página de conversão desta lista: [cliente: lista de URLs das páginas principais]. Se algum cliente não estiver na lista, verifique apenas a página inicial e anote que ele foi ignorado.

Entregue uma tabela com estas colunas: cliente, página, LCP, INP, CLS, tipo de dado (campo ou laboratório), status.

Defina o status com estas regras:
- verde: todas as métricas estão boas (LCP de 2,5 s ou menos, INP de 200 ms ou menos, CLS de 0,1 ou menos)
- vermelho: qualquer métrica está ruim (LCP acima de 4 s, INP acima de 500 ms, CLS acima de 0,25)
- amarelo: qualquer outro caso

Se eu colar a tabela do mês passado, adicione uma coluna de variação. Marque qualquer métrica que piorou mais de 20%.

Termine com uma lista curta de "ação neste mês": clientes com a página de conversão em vermelho, ou com uma métrica que passou de verde para amarelo ou vermelho. Inclua uma linha com a causa provável de cada um.

Isto é somente leitura.

SiteAltera após sua aprovação

Retire pedidos reembolsados e cancelados das conversões do Google Ads

Confirma que a tag de compra envia o ID do pedido, coleta os pedidos do WooCommerce reembolsados e cancelados dos últimos 45 dias, monta um lote de retirada e reajuste com o impacto no ROAS e só envia após a aprovação.

Quando usarQuando o ROAS do seu Google Ads parece bom demais porque pedidos reembolsados e cancelados do WooCommerce ainda são contados como conversões.

Reembolsos e cancelamentos estão inflando o ROAS informado em [conta do Google Ads]. Limpe esses casos dos dados de conversão.

1. Identifique a ação de conversão de compra principal e confirme suas configurações (contagem, janela de atribuição, valor).
2. Liste as tags do contêiner do GTM [GTM-XXXX] com seus parâmetros. Verifique se a tag de conversão de compra do Google Ads envia o ID do pedido do WooCommerce como ID da transação (parâmetro orderId). Os ajustes só são associados por esse ID. Se ele estiver ausente ou vazio, pare e explique a correção.
3. Percorra os pedidos do WooCommerce em [site WordPress] até passar de 45 dias atrás e colete todos os pedidos com status reembolsado ou cancelado, com data e total. A lista de pedidos não mostra os valores de reembolsos parciais, porque um pedido parcialmente reembolsado geralmente mantém o status concluído. Por isso, peça que eu cole os reembolsos parciais (ID do pedido e valor restante do pedido) do WooCommerce, ou ignore-os se eu não tiver nenhum.
4. Monte um lote de ajustes com base no ID do pedido. Reembolsos totais e cancelamentos viram RETRACT. Reembolsos parciais viram RESTATE para o valor restante do pedido. Observe que pedidos cancelados que nunca tiveram o pagamento concluído, e pedidos que não vieram de um clique do Google Ads, provavelmente nunca foram registrados como conversões e serão rejeitados. Isso é esperado.
5. Busque 45 dias de custo da campanha e valor de conversão para calcular o ROAS antes e depois.

Entregue uma tabela de prévia com estas colunas: ID do pedido, data do pedido, valor original, tipo de ajuste, novo valor. Adicione um total mostrando quanto o valor de conversão informado vai cair no máximo e o ROAS estimado antes e depois.

Não envie nada até eu aprovar o lote. Execute o envio primeiro como prévia (confirm=false) e aplique depois da minha aprovação, informando quantos ajustes foram aceitos e quantos foram rejeitados, com os motivos retornados pelo envio.

SiteAltera após sua aprovação

Verifique se o Google Ads conta corretamente os leads do formulário de contato

Um veredito sobre se a ação de conversão do formulário está disparando, é primária e conta uma vez por lead, com uma lista de correções em prévia.

Quando usarQuando o Smart Bidding não está rendendo e você suspeita que a conversão de formulário do Google Ads está mal configurada, contada em duplicidade ou diferente dos leads que você realmente recebe.

O Smart Bidding na conta [conta] do Google Ads deve otimizar para leads reais do formulário de contato. Verifique se a conversão do formulário está configurada corretamente, usando os últimos 30 dias.

1. Liste as ações de conversão e identifique a(s) de envio de formulário. Sinalize as que estiverem pausadas, removidas ou com zero conversões registradas.
2. Para a ação do formulário, mostre categoria, tipo de contagem, janela de retrospectiva de cliques, modelo de atribuição e se ela é primária. Para um negócio de serviços locais, ela deve contar "uma" por clique e ser primária; visualizações de página, rolagens ou cliques em botão não devem ser primários.
3. Obtenha o ID e o rótulo da conversão e confirme que existe uma tag no GTM com os mesmos valores e que ela dispara no gatilho de sucesso, não no carregamento da página nem no clique do botão.
4. Compare as conversões de formulário no Google Ads com o número de leads de formulário que eu realmente recebi: [número real de leads]. Uma diferença acima de 20% indica que há algo errado.

Entregável: uma tabela de aprovado/reprovado para cada verificação e uma lista de correções priorizada. Mostre cada alteração como uma prévia e aguarde minha aprovação antes de aplicar qualquer coisa.

SiteAltera após sua aprovação

Adicione um formulário de lead do Google Ads para que usuários de celular façam contato sem acessar o site

Um formulário de lead no anúncio, elaborado com perguntas de qualificação, justificado pelos dados de velocidade da página de contato e anexado somente após a aprovação.

Quando usarQuando pessoas que pesquisam pelo celular clicam nos seus anúncios do Google, mas saem antes de preencher o formulário de contato, muitas vezes porque a página é lenta.

Muitos dos nossos visitantes de busca estão no celular e desistem antes de chegar ao formulário de contato. Ajude-me a decidir se devo adicionar um formulário de lead do Google Ads à campanha [campanha].

1. Verifique as Core Web Vitals de [URL da página de contato] no celular. Se o LCP for maior que 2,5 segundos ou a página for reprovada, registre isso como um motivo para oferecer um formulário no anúncio.
2. Mostre os cliques, as conversões e a taxa de conversão da campanha no celular versus no computador nos últimos 30 dias.
3. Verifique se já existe um recurso de formulário de lead na conta.
4. Elabore o formulário de lead: título e descrição no nosso tom, campos limitados a nome, telefone e CEP, e duas perguntas de qualificação: qual serviço ([serviços]) e com que urgência a pessoa precisa dele. Inclua uma mensagem de sucesso curta dizendo que ligaremos dentro do horário comercial.
5. Mostre-me o rascunho completo e a campanha à qual ele será anexado. Crie-o somente depois da minha aprovação.

Depois, diga como puxar os envios diariamente para que todo lead receba uma ligação no mesmo dia.

SiteAltera após sua aprovação

Crie páginas de localização alinhadas aos seus perfis do Google Business Profile

Uma página otimizada para SEO por unidade da sua empresa no seu site hospedado, com nome, endereço, telefone e horários copiados exatamente do Business Profile e do schema LocalBusiness.

Quando usarQuando o endereço, o telefone ou os horários do seu site não correspondem ao seu Google Business Profile, ou quando você tem várias unidades sem páginas próprias.

Crie uma página de unidade no meu site hospedado para cada um dos nossos locais do Google Business Profile, para que o site e as fichas do Maps digam exatamente a mesma coisa.

1. Liste todos os locais do Business Profile e leia nome, endereço, telefone, horários, categorias, serviços e link do Maps de cada um.
2. Leia o guia de SEO e o guia de design do site. Use /locations/[slug-da-cidade] como padrão de URL.
3. Para cada unidade, redija: H1 com a marca mais o bairro, uma introdução de 100 a 150 palavras exclusiva daquela unidade (sem texto copiado e colado entre as páginas), a lista de serviços, os horários de funcionamento, um link de telefone para ligar com um clique, um link de rota para o Maps e o JSON-LD LocalBusiness vinculado ao @id da Organization do site. Nome, endereço e telefone devem corresponder à ficha caractere por caractere.
4. Adicione uma página de índice /locations com links para todas elas.

Mostre-me uma página de unidade completa e uma tabela-resumo das demais (URL, título, descrição, origem do NAP) e aguarde minha aprovação. Depois que eu aprovar, escreva as páginas e envie capturas de tela mobile de duas delas.

Em seguida, proponha, mas não aplique, a atualização do campo de site de cada ficha para a nova página correspondente. Vou aprovar isso separadamente.

SiteAltera após sua aprovação

Reescreva a seção acima da dobra da minha landing page hospedada para visitantes vindos de anúncios

Uma análise crítica, baseada em captura de tela, da primeira tela da sua landing page e uma reescrita pronta para aplicar de título, subtítulo e CTA, com prévia antes de publicar.

Quando usarQuando as pessoas clicam no seu anúncio do Google, mas saem da sua landing page sem converter, e você suspeita que a primeira tela não é convincente.

Minha landing page [caminho da página, ex.: /teklif] está hospedada no meu servidor do Opus Growth, e minha campanha do Google Ads [nome da campanha] envia tráfego para ela.

1. Tire uma captura de tela da página e leia o arquivo de origem dela.
2. Puxe os termos de pesquisa que converteram nos últimos 30 dias e os títulos de RSA da campanha. Isso mostra o que os visitantes realmente pesquisaram e o que meus anúncios prometeram.
3. Analise apenas a primeira tela que um visitante mobile vê. Verifique o título, o subtítulo, o botão de call-to-action, os sinais de confiança (avaliações, anos de mercado, garantias) e qualquer coisa que distraia da única ação que eu quero.

Depois, escreva um novo título (máx. 10 palavras), um subtítulo (máx. 20 palavras) e o texto do botão (máx. 4 palavras). Baseie-os nos principais termos de pesquisa e mantenha o tom da minha marca. Mostre as alterações exatas de texto no arquivo como um diff de antes e depois. Aguarde minha aprovação antes de editar qualquer coisa e confirme com uma nova captura de tela depois.

SiteAltera após sua aprovação

Audite plugins do WordPress e a versão do PHP em busca de lentidão

Uma lista plugin por plugin de manter, atualizar ou desativar, com um plano de testes cuidadoso, um de cada vez.

Quando usarQuando seu site WordPress parece lento e você acumulou plugins ao longo dos anos sem saber quais podem ser removidos com segurança.

Meu site WordPress [site] acumulou muitos plugins ao longo dos anos. Acho que alguns deles o deixam lento.

1. Leia a visão geral do site para obter a versão do WordPress, a versão do PHP, o tema e a quantidade de plugins. Sinalize uma versão do PHP abaixo da 8.1 como um problema de velocidade e segurança para minha hospedagem corrigir.
2. Liste todos os plugins com seu status e as atualizações disponíveis. Agrupe-os nestas categorias: necessários para leads (formulários, rastreamento de ligações, SEO), função duplicada (por exemplo, dois plugins de cache ou dois de SEO), inativos, desatualizados e provavelmente pesados no front-end (sliders, complementos extras de construtores de página, widgets de chat, feeds de redes sociais).
3. Verifique o wordpress_performance para não recomendar a remoção do plugin de cache ativo.
4. Execute o core_web_vitals na página inicial e em [URL da página do serviço principal] para mobile como referência.
5. Dê-me uma tabela com estas colunas: plugin, categoria, status, atualização disponível e recomendação (manter, atualizar, desativar ou excluir), com um motivo de uma linha para cada um.

Nunca mexa em plugins de formulário, rastreamento de ligações ou segurança. Para as desativações, proponha uma ordem de um plugin por vez. Mostre cada ação como uma prévia e aguarde minha aprovação. Após cada alteração aprovada, limpe o cache e teste novamente antes de passar para a próxima.

SiteAltera após sua aprovação

Audite o rastreamento de compras do WooCommerce no GA4, Google Ads e GTM

Compara os pedidos diários do WooCommerce com as compras do GA4 e as conversões do Google Ads ao longo de 14 dias, mapeia todas as origens de tags e identifica rastreamento de compras duplicado ou ausente antes de propor correções com prévia.

Quando usarQuando os pedidos do WooCommerce, as compras do GA4 e as conversões do Google Ads não batem e você suspeita de rastreamento de compras duplicado ou ausente.

Verifique se [site WordPress] está informando as compras corretamente ao GA4 e à [conta do Google Ads].

1. Comparação diária, últimos 14 dias completos:
   - WooCommerce: percorra as páginas de wordpress_woo_orders até passar dos pedidos com mais de 14 dias. Conte apenas pedidos concluídos (completed) e em processamento (processing) por dia. Avise se os pedidos acabarem antes do 14º dia e trate separadamente qualquer pedido que pareça ser de teste (meu próprio nome, total 0).
   - GA4: execute ga4_report com a dimensão "date" e dimension2 "event", e considere apenas a contagem do evento purchase. Não use o total de conversões, pois ele soma todos os eventos-chave.
   - Google Ads: execute google_ads_query na ação de conversão de compra, segmentada por segments.date e segments.conversion_action_name, para que outras ações não inflem o número. Observe que o Google Ads informa as conversões pela data do clique, então os dias mais recentes ainda podem ser preenchidos.
   - Anote os fusos horários da loja, da propriedade do GA4 e da conta do Ads, se forem diferentes, pois isso desloca pedidos entre os dias.
2. Configurações:
   - Confirme com ga4_list_conversions que purchase é um evento-chave.
   - Com list_conversion_actions e get_conversion_settings, confirme que a ação de compra do Ads está ativada, incluída em conversões (principal), tem dados registrados, e verifique o tipo de contagem. MANY_PER_CLICK em uma ação de compra é uma fonte comum de contagem em excesso.
3. Inventário de tags:
   - Use wordpress_tracking para listar todos os lugares onde uma tag do GA4 ou do GTM é disparada (plugins, snippets do WPCode, código de cabeçalho/rodapé, opções do tema). Leia qualquer snippet suspeito com wordpress_snippet e qualquer opção do tema indicada por ele com wordpress_option.
   - Use wordpress_list_plugins para encontrar plugins que enviam dados de compra por conta própria (por exemplo GTM4WP, WooCommerce Google Analytics, Site Kit, PixelYourSite).
   - No GTM, liste as tags e os acionadores do workspace do contêiner publicado e sinalize toda tag que envia purchase ao GA4 ou uma conversão do Google Ads, com o ID/rótulo da conversão e as condições do acionador. Use gtm_workspace_status para ver se alguma alteração de compra está sem publicar.
   - O modo de consentimento não pode ser lido como uma configuração única. Informe o que o inventário de tags mostrar (um plugin de consentimento, configurações de consentimento nas tags do GTM, um snippet de consentimento) e diga claramente se não for possível saber.

Entregue:
- Uma tabela diária com estas colunas: data, pedidos, compras no GA4, conversões no Google Ads, diferença % do GA4 vs pedidos, diferença % do Ads vs pedidos.
- Uma lista numerada de achados, cada um ligado à evidência que o sustenta.

Use estes limites apenas como indicadores e depois confirme a causa pelo inventário:
- Mais de 10% acima dos pedidos: procure duas origens enviando a mesma compra (um plugin mais uma tag do GTM, dois contêineres), transaction_id ausente, contagem MANY_PER_CLICK ou um acionador da página de agradecimento que dispara ao recarregar.
- Mais de 25% abaixo dos pedidos: procure uma tag ausente ou não publicada, uma condição de acionador que não captura a URL da página de agradecimento, bloqueio por consentimento ou um gateway de pagamento que não retorna à página de agradecimento. Se os dados do pedido não mostrarem a forma de pagamento, pergunte quais gateways usamos.

Propor correções indicando a tag, o acionador, o snippet ou o plugin exato a alterar. Não faça nenhuma alteração até eu aprovar a prévia de cada uma.

SiteSomente leitura

A gestão pode confiar nos nossos números de conversão? Auditoria de Google Ads e GA4

Uma auditoria somente leitura de cada ação de conversão do Google Ads e de cada evento-chave do GA4. Ela sinaliza os problemas por gravidade, estima o quanto as conversões e o CPA reportados podem estar errados e termina com um veredito em linguagem simples para a gestão.

Quando usarQuando a gestão perguntar se as conversões e o CPA reportados são confiáveis, ou quando você suspeitar de ações de conversão duplicadas ou inativas.

Preciso dizer à gestão se os dados de conversão de [conta do Google Ads] são confiáveis. Analise os últimos 30 dias. Isto é somente leitura, então não altere nada.

1. Monte uma tabela com todas as ações de conversão, com estas colunas: nome, origem (tag do site, importação do GA4, ligação, upload etc., conforme o tipo da ação), categoria, status, principal ou secundária, contagem (todas ou uma), janela de atribuição por clique, modelo de atribuição e conversões nos últimos 30 dias. Para principal ou secundária, use o indicador "incluída em Conversões", não o indicador legado primary_for_goal. Mostre também quais categorias de conversão são otimizáveis no nível da meta.
2. Adicione uma coluna "data da última conversão". Execute uma consulta GAQL somente leitura na conta para os últimos 90 dias, segmentada por ação de conversão e data, com todas as conversões como métrica. Para cada ação, pegue a data mais recente com valor diferente de zero. Se uma ação não tiver nada em 90 dias, escreva "nenhuma em 90 dias".
3. Ao lado da tabela, liste os eventos-chave do GA4 com o método de contagem. Adicione a contagem de 30 dias de cada evento a partir de um relatório do GA4 detalhado por evento.
4. Traga o gasto das campanhas nos últimos 30 dias para saber quais campanhas estavam gastando enquanto cada ação estava inativa.

Sinalize cada problema com um nível de gravidade:
- Crítico: uma ação principal com zero conversões em 30 dias enquanto as campanhas gastaram dinheiro. O mesmo formulário ou a mesma compra contados por duas ações principais (por exemplo, uma tag do Google Ads mais uma importação do GA4).
- Alerta: ações de lead contadas como "todas". Uma ação principal pausada ou removida. Janelas de atribuição diferentes entre ações semelhantes.
- Informativo: ações secundárias sem conversões em 90 dias.

Para estimar o exagero ou a subestimação, compare as conversões principais do Ads com as contagens dos eventos-chave correspondentes do GA4 nos mesmos 30 dias. Onde duas ações principais rastreiam o mesmo formulário ou a mesma compra, mostre qual seria o total de conversões e o CPA se apenas uma delas contasse. Apresente o resultado como uma faixa, não como um número exato, e declare suas premissas. Atribuição, janelas de atribuição e consentimento fazem com que Ads e GA4 nunca coincidam exatamente, e a contagem duplicada não pode ser medida diretamente.

Termine com um único parágrafo para a gestão que responda a três perguntas. Podemos confiar nas conversões e no CPA reportados? Quanto eles estão errados, aproximadamente, como uma faixa estimada? O que precisa ser corrigido primeiro?

Liste as correções propostas separadamente e indique a ferramenta que aplicaria cada uma. Indique qualquer correção que só possa ser feita na interface do Google Ads, como pausar ou remover uma ação de conversão. Vou aprovar as correções uma a uma. Para cada correção aprovada, mostre primeiro a prévia com confirm=false e aguarde meu sinal verde antes de aplicar qualquer coisa.

SiteSomente leitura

Marque os eventos certos do GA4 como eventos-chave e vincule o GA4 ao Google Ads

Uma lista curta de eventos de negócio que devem contar como eventos-chave, uma verificação do vínculo entre GA4 e Ads e alterações propostas para aprovação.

Quando usarQuando você suspeita que o GA4 está contando os eventos errados como conversões, ou não tem certeza de que o GA4 e o Google Ads estão corretamente vinculados.

Analise a propriedade do GA4 [nome da propriedade do GA4] para o site [URL do site].

1. Extraia o total de eventos por nome de evento dos últimos 28 dias e liste os eventos-chave atualmente marcados.
2. Identifique eventos que representam resultados reais de negócio, mas não são eventos-chave. Exemplos típicos são generate_lead, form_submit, purchase, eventos de clique em telefone ou WhatsApp e confirmações de agendamento. Ignore ruído de engajamento como scroll, page_view e user_engagement.
3. Sinalize eventos-chave que não deveriam ser eventos-chave, por exemplo um evento genérico de clique que inflaria a contagem de conversões.
4. Verifique se esta propriedade está vinculada à conta do Google Ads [conta do Google Ads].

Entregue uma tabela com estas colunas: nome do evento, contagem em 28 dias, atualmente é evento-chave (sim/não), recomendação (adicionar, remover ou manter) e um motivo em uma linha. Adicione uma nota curta para a gestão explicando quais resultados poderemos reportar depois dessas alterações.

Não marque nenhum evento nem crie nenhum vínculo ainda. Mostre exatamente o que você criaria e aguarde minha aprovação. Observe que remover eventos-chave não é possível por esta conexão, então liste-os para eu tratar manualmente no GA4.

SiteAltera após sua aprovação

Rastreie envios de formulário bem-sucedidos como evento-chave do GA4 pelo GTM

Um acionador do GTM e uma tag de evento do GA4 com prévia, que disparam apenas em envios bem-sucedidos, publicados e marcados como evento-chave após a sua aprovação.

Quando usarQuando os leads do seu formulário de contato estão sendo contados a mais porque o GA4 registra cada clique no botão em vez de envios realmente bem-sucedidos.

Quero que o GA4 conte um lead somente quando o formulário de contato de [site] for enviado com sucesso, e não a cada clique no botão de enviar.

1. Verifique onde o GTM e o GA4 disparam no site e confirme que existe exatamente um contêiner do GTM e nenhuma tag duplicada do GA4.
2. Obtenha o ID de medição do GA4 e liste os eventos-chave existentes.
3. Liste as tags, os acionadores e as variáveis do GTM. Diga se já existe uma configuração de rastreamento de formulário e se ela está funcionando ou quebrada.
4. Proponha a configuração: um acionador que dispare somente em caso de sucesso (a página de agradecimento [URL da página de agradecimento], se tivermos uma; caso contrário, o evento de sucesso do formulário), as variáveis integradas necessárias e uma tag de evento do GA4 chamada generate_lead com um parâmetro form_id.
5. Crie tudo em um workspace e depois me mostre o status do workspace com todas as alterações pendentes. Não publique até eu aprovar.
6. Depois de publicar, marque generate_lead como evento-chave no GA4.

Me explique como verificar o evento no GA4 em até 24 horas.

SiteSomente leitura

Encontre títulos e seções que um modelo de página repete no lugar errado

Rastreia o site, agrupa as páginas por modelo e idioma e identifica títulos compartilhados que citam o produto, a plataforma ou a cidade errada, textos sem tradução em páginas traduzidas e títulos que copiam o H1.

Quando usarQuando você suspeita que um modelo de página compartilhado está colocando o nome do produto, da plataforma ou da cidade errada nos títulos, ou deixando texto em inglês em páginas traduzidas.

Faça uma auditoria em [URL do site] em busca de textos que vêm de um modelo de página compartilhado e estão errados em algumas das páginas que o usam. Casos típicos são uma tabela comparativa com o título de um produto que aparece em todas as páginas de produto, um título de seção que cita a plataforma errada ou texto em inglês deixado em páginas traduzidas.

1. Inicie um rastreamento do site com seo_site_crawl para [domínio] e reúna títulos duplicados, descrições duplicadas e páginas sem H1. Agrupe as URLs afetadas por modelo, ou seja, pelo padrão de caminho compartilhado, como /product/, /blog/ ou /solutions/, e por prefixo de idioma.
2. Escolha até [número de páginas, ex.: 5] páginas de cada modelo e de cada idioma e leia a estrutura delas com site_read_url e outline=true: título, meta descrição, canonical e a árvore completa de títulos.
3. Compare os títulos H2 e H3 entre páginas do mesmo modelo. Um título idêntico em todas as páginas, mas que cita um produto, plataforma, cidade ou concorrente específico, é suspeito. Confira-o com o tema da própria página, extraído do H1 e da URL, e marque como errado quando os dois divergirem.
4. Verifique em cada versão que não esteja em inglês se há títulos ou descrições ainda escritos em inglês e, em todas as páginas, títulos que repetem o H1 palavra por palavra.

Entregue uma tabela por modelo com estas colunas: texto do título, páginas em que aparece, o tema que ele deveria citar em cada página, veredito (correto, tema errado, sem tradução, cópia do H1) e a correção escrita como o novo título exato para cada idioma afetado. Termine com uma nota curta para o desenvolvedor: qual modelo provavelmente contém o texto fixo e que o título deve ser construído a partir dos dados da própria página, e não de uma string fixa no código.

Somente leitura. Não altere nada no site.

Estes prompts funcionam melhor quando seu assistente de IA está conectado às suas contas com o Opus Growth.

Conecte suas contas grátis