Sur mon serveur d'hébergement Opus Growth
[nom du serveur], construis un site multipage pour
[nom de l'entreprise] qui ne charge aucun JavaScript et gère le mouvement et les transitions de page avec les fonctionnalités CSS natives du navigateur. Activité :
[ce que fait l'entreprise, pour qui], ville :
[ville, quartier]. Services ou produits :
[liste]. Réalisations : [pour chacune : nom, matériau ou périmètre, durée, problème résolu, lien de l'image]. Contact :
[e-mail],
[téléphone],
[numéro WhatsApp],
[adresse]. Domaine :
[domaine].
Pages : accueil (hero, réalisations récentes, méthode de travail, FAQ), réalisations (/isler/), à propos (/hakkimizda/), contact (/iletisim/, sans formulaire), confidentialité (/gizlilik/) et 404.html.
Style : éditorial et naturel. Une serif d'affichage (par exemple Zodiak) avec une police de texte sobre (par exemple Switzer), un fond ton lin, un seul accent foncé, beaucoup d'espace. Garde l'audace pour les cartes de réalisations.
Règles CSS modernes (amélioration progressive ; dans un navigateur sans prise en charge, la page doit être statique mais complète) :
1. Ne charge aucun fichier JavaScript ; ni GSAP, ni Lenis, ni Swiper. Le menu mobile fonctionne avec `<details>`.
2. Transitions de page (View Transitions entre pages de même origine) : écris `@media (prefers-reduced-motion: no-preference) { @view-transition { navigation: auto; } }` et garde une durée d'environ 0,35 s. Donne à la barre supérieure view-transition-name: site-header. Donne à l'image d'une carte de réalisation sur l'accueil et à la même image sur la page des réalisations le même view-transition-name unique, afin que l'image s'agrandisse jusqu'à sa place sur la nouvelle page. N'utilise chaque nom qu'une seule fois par page.
3. Animations pilotées par le scroll : une ligne de progression en haut qui grandit avec scaleX sur `animation-timeline: scroll(root)` (display:none par défaut, visible uniquement si la fonctionnalité est prise en charge) ; sur les cartes et les titres de section, `animation-timeline: view()` avec `animation-range: entry 0% entry 70%` en utilisant uniquement translateY ; sur l'image du hero, un léger zoom et décalage tant qu'elle est dans la vue. N'utilise pas opacity : des éléments estompés qui attendent sous l'écran échouent au contrôle de contraste de Lighthouse. Place toutes ces règles dans `@supports (animation-timeline: scroll())` et `prefers-reduced-motion: no-preference`.
4. Container queries : fais de la carte de réalisation un composant avec `container-type: inline-size`. Avec `@container (min-width: 34rem)`, l'image est au-dessus dans un conteneur étroit et à côté du texte dans un conteneur large. La même carte est étroite dans une grille de trois colonnes sur l'accueil et large dans une colonne unique sur la page des réalisations. Le cœur de Tailwind 3 n'a pas de classes de container queries ; écris ces règles en CSS pur dans app.css.
5. Le niveau de titre de la carte doit correspondre à la page où elle se trouve : sur la page des réalisations, place un h2 entre le h1 et les titres h3 des cartes. Quand cet h2 manquait dans la démo, Accessibility tombait à 98 sur heading-order.
6. Sur la page des réalisations, la première image de carte qui entre dans le premier écran n'est pas en lazy et reçoit fetchpriority="high".
Mise en place et pièges connus (chacun a fait baisser un score lors des mesures de la démo, ne les saute pas) :
1. Si un site est déjà en ligne sur le serveur, dis-le-moi d'abord, car l'installation écrase index.html et le dossier assets. Prévisualise scaffold_site avec confirm=false et appelle-le avec confirm=true après mon accord. Ensuite, lis site_design_guide et site_seo_guide. Avant d'écrire du code, mets la direction de design (typographie, couleur, grille, élément signature, langage de mouvement et bibliothèques qui ne seront PAS chargées) dans un court ART.md hors d'assets et montre-le-moi.
2. Compile Tailwind au lieu de le charger depuis le CDN. Installe-le avec site_run_command et background=true : `npm i -D tailwindcss@3`, puis enchaine avec site_command_status. Les chemins content de `tailwind.config.js` doivent couvrir tous les fichiers HTML, les gabarits et tout fichier JS qui écrit des noms de classes. `_src/tw.css` contient la ligne `@import "../assets/app.css";` et les trois lignes `@tailwind` ; compile-le en un seul fichier avec `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Supprime le script cdn.tailwindcss.com et le tailwind.config en ligne de chaque page, et ne lie que `/assets/site.css`. Recompile après chaque modification du HTML.
3. Héberge les polices toi-même. Lis le CSS des familles Fontshare choisies, télécharge le fichier woff2 de chaque graisse dans `assets/fonts/` avec site_fetch, et écris les règles @font-face avec `font-display: swap` dans `assets/app.css` ; design-check y cherche une police personnalisée. Vérifie le nom font-family dans le CSS téléchargé, car Fontshare peut renvoyer une autre famille quand une graisse n'existe pas. Précharge la police du titre du premier écran et la police de texte sur chaque page avec `<link rel="preload" as="font" type="font/woff2" crossorigin>` ; dans la démo, cela a supprimé le décalage de mise en page causé par l'échange de police (CLS 0,024 à 0). La plupart des polices Fontshare n'ont pas de glyphe ₺, écris donc "TL" pour les prix.
4. Fais du menu et du pied de page du HTML statique. Ne charge pas chrome.js ni site.config.js sur les pages. Écris un petit `chrome-stamp.mjs` qui lit la liste de navigation dans site.config.js et estampille `_src/header.tpl` et `_src/footer.tpl` entre les marqueurs `<!-- nav:start --><!-- nav:end -->` et `<!-- footer:start --><!-- footer:end -->` de chaque page, en ajoutant aria-current="page" au lien courant. Ne donne pas d'extension .html aux gabarits et utilise des espaces réservés comme `
[[NAV]]` à la place de `{{...}}`, sinon design-check et seo-check les lisent comme des pages inachevées. Construis le menu mobile sans JS avec `<details>`. Garde le nom de l'entreprise, l'adresse et le téléphone dans le pied de page en texte simple.
5. Convertis les images pendant le téléchargement avec site_fetch : écris la même photo dans des fichiers séparés avec resize="480x", "800x" et "1200x", image_format="webp", quality=65. Donne à chaque `<img>` srcset, sizes, width et height. L'image principale du premier écran reçoit fetchpriority="high" et n'est jamais en lazy ; les autres reçoivent loading="lazy" decoding="async". Si l'image principale remplit l'écran du téléphone, sers sur mobile un recadrage plus large et plus léger avec `<picture>` (dans la démo, le hero mobile est passé de 89 Ko à 43 Ko).
6. Crée un favicon PNG de 48 px à partir du logo avec site_fetch et ajoute `<link rel="icon">` à chaque page. Sans lui, le navigateur journalise une erreur 404 et Best Practices tombe à 96.
7. Règles du validateur HTML : commence chaque document par un `<!DOCTYPE html>` en majuscules (les fichiers de départ du kit l'écrivent en minuscules), utilise ` ` pour les espaces du texte visible des liens tel:, n'utilise jamais d'attribut style="", et donne à chaque bouton type="button".
SEO, AEO et GEO :
1. Utilise des URL de répertoire avec une barre oblique finale (/isler/, /hakkimizda/, /iletisim/, /gizlilik/). Remplis le bloc seo de site.config.js et exécute `node seo-stamp.mjs`. Écris le schema propre à chaque page (accueil WebPage et FAQPage ; réalisations CollectionPage avec un CreativeWork par pièce sous hasPart (avec material si connu) ; à propos AboutPage ; contact ContactPage ; BreadcrumbList sur les pages internes. Le sous-type LocalBusiness le plus précis dans site.config.js) dans des blocs `<script type="application/ld+json">` séparés et relie-le au graphe de base avec @id. N'enfouis pas BreadcrumbList dans un @graph ; donne-lui son propre bloc, car c'est la seule façon pour seo-check de le voir.
2. Titres de 48 à 60 caractères (seo-check signale comme erreur tout ce qui dépasse 65), descriptions de 145 à 158 caractères, un seul h1 par page. Chaque page doit avoir au moins 150 mots de contenu principal ; les pages contact et confidentialité ont tendance à rester en dessous.
3. Le premier paragraphe de chaque page répond directement à la question de la page. Écris une FAQ propre à la page avec `<details>` et balise-la en FAQPage. Affiche l'organisation éditrice et une date de « Dernière mise à jour » avec `<time>`.
4. Dans robots.txt, écris ta décision avec sa raison pour GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot et CCBot, et indique le sitemap. sitemap.xml porte de vraies dates lastmod. llms.txt contient un résumé exact du site en deux phrases et la liste des pages clés.
5. N'invente rien : pas d'avis, de notes, de récompenses, de nombre de clients, de certificats, d'horaires, de coordonnées ni de prix, sauf si je les fournis. Laisse les champs inconnus hors du schema.
Contrôles (dans l'ordre ; ne dis pas que c'est terminé tant qu'ils ne passent pas tous) :
1. Avec site_run_command, exécute `node chrome-stamp.mjs`, la compilation Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 erreur, 0 avertissement), `node design-check.mjs` (0 erreur ; justifie tout avertissement restant) et `npx html-validate "**/*.html"` (0 erreur).
2. Visualise chaque page avec site_preview, view="mobile" et view="desktop". site_preview capture la page avec le mouvement désactivé (reduced-motion) ; donc si du contenu manque sur cette image, l'état sans mouvement est cassé. Dans les captures pleine page, les images lazy plus bas peuvent apparaitre vides ; ce n'est pas une erreur, mais vérifie leurs chemins.
3. Lance core_web_vitals pour chaque page avec strategy="mobile" et strategy="desktop". Critères : sur mobile, Performance d'au moins 95 et Accessibility, Best Practices et SEO à 100 ; sur desktop, les quatre scores d'au moins 95. Sur une page qui échoue, utilise resources=true pour trouver le fichier qui la ralentit, corrige-le et mesure à nouveau. Lance ensuite seo_audit sur la page d'accueil avec strategy="mobile" et runs=2. La liste des requêtes réseau ne doit contenir aucun hôte autre que ton propre domaine.
4. Aucun défilement horizontal aux largeurs de 360, 390, 768 et 1440 px, zones tactiles d'au moins 44 px, aucune erreur de console.
Vérification de la prise en charge : site_preview capture avec le mouvement désactivé, il ne peut donc pas montrer les transitions. Explique-moi comment vérifier dans Chrome que l'image s'agrandit jusqu'à sa place quand je clique sur une réalisation depuis l'accueil, que la ligne du haut se remplit pendant que je fais défiler, que la carte change de disposition quand je réduis et élargis la fenêtre, et que la page s'ouvre complète dans un navigateur sans ces fonctionnalités.
Après la publication : prévisualise la règle `/assets/* Cache-Control: public, max-age=31536000, immutable` avec site_headers et applique-la après mon accord ; à partir de là, renomme les fichiers CSS ou JS quand ils changent (site-v2.css, etc.). Soumets sitemap.xml avec gsc_submit_sitemap et inspecte la page d'accueil avec gsc_url_inspect. Termine par un tableau de scores par page (page, quatre scores mobile, quatre scores desktop, LCP, CLS), les résultats des contrôles et la liste des corrections appliquées.
