Sur le site
[nom du serveur] de mon serveur d'hébergement Opus Growth, crée un site d'annonces statique et rapide pour mon agence immobilière
[nom de l'agence], qui génère chaque annonce à partir d'un seul fichier JSON. Agence :
[ville, quartiers où je travaille, vente ou location]. Numéro de ma licence d'agent immobilier (Taşınmaz Ticareti Yetki Belgesi) :
[n° de licence]. Annonces : [pour chaque annonce : n° d'annonce, titre, quartier, secteur, nombre de pièces, surface brute et nette en mètres carrés, étage, année de construction, chauffage, charges, situation du titre de propriété, prix, date de l'annonce, une description de deux paragraphes, quatre caractéristiques clés, liens des photos et le niveau de localisation que le propriétaire a accepté de montrer]. Contact :
[téléphone],
[numéro WhatsApp],
[e-mail],
[adresse de l'agence]. Domaine :
[domaine].
Pages : accueil (un formulaire de recherche par quartier, pièces et prix maximum, annonces à la une, guide des quartiers, FAQ), annonces (/ilanlar/ : filtres, nombre de résultats, grille d'annonces, FAQ des annonces), une page par annonce (/ilanlar/
[quartier-secteur-a-vendre-pieces-type]/), à propos (/hakkimizda/ : les étapes de l'achat et la licence), contact (/iletisim/, sans formulaire), confidentialité (/gizlilik/) et 404.html.
Style : immobilier éditorial et chaleureux. Un fond sable clair, du texte encre, un seul accent foncé comme le vert pin (texte blanc sur les boutons), une serif Fontshare pour les titres et les prix (par exemple Sentient 500) et une sans-serif pour le texte courant (par exemple Ranade 400). Des cartes d'annonce avec une photo 4:3, un grand prix en serif et de petites étiquettes pour les pièces, les mètres carrés et l'étage. La photo de la carte zoome légèrement au survol. Aucune bibliothèque de carte, aucune iframe Google Maps, aucune bibliothèque de galerie ou de slider n'est chargée.
Source unique et génération :
1. Toutes les données des annonces se trouvent dans `assets/ilanlar.json`. Écris un petit `ilan-build.mjs` et exécute-le avec site_run_command via `node ilan-build.mjs` : (a) il génère `ilanlar/
[slug]/index.html` pour chaque annonce à partir du modèle `_src/ilan.tpl`, (b) il injecte toutes les cartes entre `<!-- ilanlar:start --><!-- ilanlar:end -->` dans `ilanlar/index.html` et celles à la une entre `<!-- one-cikan:start --><!-- one-cikan:end -->` sur la page d'accueil, (c) il écrit le schema ItemList de la page des annonces entre `<!-- ilan-ld:start --><!-- ilan-ld:end -->`. Utilise dans le modèle des espaces réservés comme `
[[FIYAT]]`, pas `{{...}}`. Ordre : ilan-build, chrome-stamp, build Tailwind, seo-stamp. Ajouter une annonce ou retirer une annonce vendue doit se résumer à modifier le JSON et à relancer cet ordre ; quand la page d'une annonce vendue est supprimée, redirige son URL vers /ilanlar/ avec site_redirects.
2. Les cartes sont du HTML statique généré côté serveur : chaque annonce est donc visible avec JS désactivé et pour les moteurs de recherche. Chaque carte porte les attributs data-ilce, data-oda, data-fiyat, data-m2 et data-tarih pour le filtre ; les noms de classes des composants ne doivent pas entrer en conflit avec les utilitaires Tailwind (utilise un préfixe comme lcard).
Règles du filtre :
1. Le filtre est un vrai formulaire avec action="/ilanlar/" et method="get" : des selects avec libellés pour le quartier, les pièces, le prix minimum, le prix maximum et l'ordre de tri, plus un bouton « Filtrer ». Avec JS désactivé, le formulaire remplit l'URL mais la liste ne change pas ; dis-le en une phrase dans `<noscript>`.
2. `ilan-filtre.js` se charge avec defer sur /ilanlar/ uniquement : au chargement, il lit ?ilce=&oda=&min=&max=&sira= avec URLSearchParams (en n'acceptant que des valeurs présentes dans les selects), masque et affiche les cartes avec hidden, réordonne le DOM pour le tri et met à jour l'URL avec history.replaceState à chaque changement. La liste filtrée peut être partagée par lien et l'historique du bouton retour ne se remplit pas.
3. Annonce le nombre de résultats dans une phrase role="status" (« 2 annonces sur 6 correspondent à vos filtres »). Sans résultat, affiche un message d'état vide et un lien « Effacer les filtres ». Le bloc de filtres est dans le premier écran, donc le JS ne doit rien y ajouter ni y masquer ; seules les cartes changent, sinon on obtient un décalage de mise en page (CLS).
4. Sur la page des annonces, la photo de la première carte n'est pas lazy et les autres le sont ; les titres des cartes sont des h2 sur cette page et des h3 sous le h2 « Annonces à la une » sur la page d'accueil.
Page d'annonce :
1. Le premier paragraphe résume l'annonce en une phrase : secteur, quartier, pièces, mètres carrés, année de construction et prix. Puis la bande de photos : des figures qui défilent horizontalement avec CSS scroll-snap sans JS, avec dessous des vignettes qui sont des liens d'ancre vers chaque photo. `galeri.js` (pages d'annonce uniquement) intercepte les clics sur les vignettes, fait défiler uniquement la bande sans faire sauter la page, et marque la vignette de la photo visible avec aria-current="true" via un IntersectionObserver. La première photo est l'élément LCP de la page : fetchpriority="high", pas lazy.
2. Un bloc de prix sticky dans la colonne de droite : le prix, une liste de faits (dl : prix, n° d'annonce, pièces, surface brute et nette, étage, année de construction, chauffage, charges, titre de propriété, date de l'annonce), un lien WhatsApp avec un message prérempli qui inclut le numéro d'annonce, le téléphone et le numéro de licence. La réglementation turque attend le numéro de licence sur les annonces immobilières ; mets-le aussi dans le pied de page.
3. Localisation : ne publie pas l'adresse complète. Utilise une image de carte statique locale qui montre l'emplacement approximatif au niveau accepté par le propriétaire (en général le secteur) et indique dessous que l'adresse complète est communiquée lors de la visite. Si tu construis la carte à partir de tuiles OpenStreetMap, respecte la politique d'usage des tuiles (une fois par annonce, quelques tuiles, aucun téléchargement en masse) : récupère les tuiles avec site_fetch dans `_src/harita/`, installe sharp avec site_run_command et background=true (`npm i -D sharp`), puis utilise un petit script pour assembler les tuiles, recadrer autour du centre, marquer la zone approximative avec un cercle semi-transparent et enregistrer des fichiers WebP de 480 et 768 pixels. Si le recadrage dépasse la zone des tuiles, une bande noire apparait au bord ; récupère au moins 5x3 tuiles autour du centre. Écris la mention « © OpenStreetMap contributors » à la fois dans l'image et sous forme de lien dessous. La carte se charge en lazy et aucun script de carte externe n'entre dans la page.
Schema : sur la page d'annonce, RealEstateListing (url, name, description, datePosted, un tableau image, offers avec une Offer : price, priceCurrency "TRY", availability et le @id de l'entreprise comme seller) avec un Apartment ou SingleFamilyResidence comme mainEntity (numberOfRooms, numberOfBedrooms, numberOfBathroomsTotal, floorSize en QuantitativeValue avec unitCode "MTK", yearBuilt, et une address avec uniquement quartier, province et pays). Google n'affiche pas de résultat enrichi dédié pour ces types ; l'objectif est que les moteurs de recherche et d'IA lisent correctement le prix, le nombre de pièces et la localisation. CollectionPage et ItemList sur la page des annonces, businessType "RealEstateAgent" dans seo-stamp pour l'agence, BreadcrumbList sur chaque page interne. Prends le prix, les mètres carrés, les charges et les informations du titre uniquement dans la déclaration écrite du propriétaire ; laisse de côté, à la fois dans le JSON et dans le schema, tout ce que tu ne sais pas.
Mise en place et pièges connus (chacun a couté des points lors des mesures de la démo, n'en saute aucun) :
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 ne l'appelle avec confirm=true qu'après mon accord. Puis lis site_design_guide et site_seo_guide. Avant d'écrire du code, consigne la direction de design (typographie, couleurs, grille, élément signature, langage de mouvement et bibliothèques qui ne seront PAS chargées) dans un court fichier ART.md hors de assets et montre-le-moi.
2. Compile Tailwind, ne le charge pas depuis le CDN. Installe-le avec site_run_command et background=true (`npm i -D tailwindcss@3`) et fais suivre d'un site_command_status. Les chemins content de `tailwind.config.js` doivent couvrir tous les fichiers HTML, les modèles `_src` et tout fichier JS qui écrit des classes. `_src/tw.css` contient la ligne `@import "../assets/app.css";` plus 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`. Retire le script cdn.tailwindcss.com et le tailwind.config inline de chaque page et ne lie que `/assets/site.css`. Recompile après chaque modification du HTML.
3. Héberge toi-même les polices. Lis le CSS de la famille Fontshare choisie, télécharge le woff2 de chaque graisse séparément avec site_fetch dans `assets/fonts/` et écris les règles @font-face avec `font-display: swap` dans `assets/app.css`, qui est l'endroit où design-check cherche une police personnalisée. Vérifie le nom font-family dans le CSS téléchargé et assure-toi que la famille possède les lettres turques ı, İ, ş et ğ (Tanker n'a pas de ı). Précharge TOUTES les graisses utilisées dans le premier écran avec `<link rel="preload" as="font" type="font/woff2" crossorigin>`, placé avant la ligne de la feuille de style ; si cela fait plus de trois fichiers, utilise moins de graisses. Dans la démo, une seule graisse de texte non préchargée a fait monter le LCP mobile à 2,6 secondes et fait tomber Performance à 97. La plupart des polices Fontshare n'ont pas le signe ₺, donc écris les prix avec « TL ».
4. Fais du menu et du pied de page du HTML statique. Ne charge pas chrome.js, motion.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 injecte `_src/header.tpl` et `_src/footer.tpl` entre les marqueurs `<!-- nav:start --><!-- nav:end -->` et `<!-- footer:start --><!-- footer:end -->` sur chaque page, en ajoutant aria-current="page" au lien actif. Utilise des espaces réservés comme `
[[NAV]]` au lieu de `{{...}}` et ne donne pas aux modèles l'extension .html, sinon design-check et seo-check les traitent comme des pages inachevées. Construis le menu mobile avec un `<details>` sans JS. Garde le nom de l'entreprise, l'adresse et le téléphone en texte brut dans le pied de page, et donne aux liens du pied de page et du fil d'Ariane une hauteur d'au moins 44 pixels.
5. Convertis les images pendant leur récupération avec site_fetch : écris la même image en fichiers distincts avec resize="480x", "800x" et "1200x", image_format="webp", quality=60 (site_fetch ne recadre pas, donc demande la source au ratio dont tu as besoin). Donne à chaque `<img>` srcset, sizes ainsi que width et height conformes au vrai ratio. L'image qui est l'élément LCP de la page reçoit fetchpriority="high" et n'est pas lazy ; toutes les autres images reçoivent loading="lazy" decoding="async". Si une image remplit le premier écran mobile, sers un recadrage plus petit au mobile avec `<picture>`.
6. Ajoute `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` à chaque page et crée une apple-touch-icon de 180 pixels à partir du logo avec site_fetch et resize="180x180". Sans lien favicon, le navigateur demande /favicon.ico, enregistre un 404 et Best Practices tombe à 96.
7. Règles du validateur HTML : commence chaque document par un `<!DOCTYPE html>` en majuscules ; chaque espace dans le texte visible d'un lien tel: doit être un ` `, y compris celui après un préfixe comme « Appelez : 0212... » ; n'utilise pas style="" ; donne un type à chaque bouton ; mets aria-label uniquement sur les landmarks, les formulaires ou les éléments interactifs (sur un ul ou un div sans rôle, c'était une erreur) ; ne donne jamais le même nom à deux landmarks ; ne laisse aucun espace en fin de ligne.
8. Ne saute pas de niveaux de titre : sur une page de liste, des titres de cartes en h3 juste après le h1 ont fait tomber Accessibility à 98. Quand tu réutilises une carte, définis son niveau de titre par page (h2 sur une page de liste, h3 dans une section h2).
9. Nomme l'attribut de mouvement data-reveal (design-check ne reconnait le mouvement que sous ce nom). Le JS ne donne l'état initial masqué qu'aux blocs situés sous l'écran à l'ouverture de la page, et ne masque jamais le contenu du premier écran ; utilise transform, car un fondu par opacity fait baisser l'audit de contraste. Mets l'attribut sur le bloc qui enveloppe un titre et sa description, pas sur le titre seul ; dans la démo, un titre en attente glissait par-dessus le paragraphe suivant. Avec prefers-reduced-motion: reduce, rien n'est masqué et les animations sont désactivées.
SEO, AEO et GEO :
1. Utilise des URL de type répertoire avec une barre oblique finale. Remplis le bloc seo de site.config.js et exécute `node seo-stamp.mjs`. Écris le schema propre à chaque page dans des blocs `<script type="application/ld+json">` séparés, reliés au graphe de base par @id. N'imbrique pas BreadcrumbList dans @graph ; garde-le dans son propre bloc, ce qui est la seule façon pour seo-check de le voir.
2. Titres de 60 caractères maximum (seo-check signale comme erreur tout ce qui fait moins de 25 ou plus de 65), descriptions de 130 à 158 caractères, un seul h1 par page et au moins 150 mots de contenu principal sur chaque page. Les pages contact, confidentialité et liste ont tendance à rester courtes ; ajoute des informations propres à la page, pas du remplissage.
3. Le premier paragraphe de chaque page répond directement à la question de la page. Écris des FAQ propres à chaque page avec `<details>` et balise-les en FAQPage. Affiche l'éditeur et une date « Dernière mise à jour » dans un élément `<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 une liste des pages importantes.
5. Aucune invention : n'écris ni avis, ni notes, ni récompenses, ni nombre de clients, ni certificats, ni horaires d'ouverture, ni coordonnées, ni prix sans me demander. Laisse totalement hors du schema tout champ que tu ne connais pas.
Contrôles (dans l'ordre ; ne dis pas « terminé » avant que tous soient passés) :
1. Avec site_run_command, exécute `node chrome-stamp.mjs`, le build 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. Affiche chaque page avec site_preview, view="mobile" et view="desktop". site_preview capture la page avec le mouvement désactivé (reduced-motion) ; si du contenu manque dans cette capture, l'état statique est cassé. Dans les captures pleine page, des éléments fixes comme une barre sticky peuvent apparaitre au milieu de la page et les images lazy plus bas peuvent être vides ; ne les compte pas comme des erreurs, 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 (objectif 99 à 100) et Accessibility, Best Practices et SEO à 100 ; sur desktop, les quatre à 100. Pour une page qui n'atteint pas ces seuils, utilise resources=true pour trouver le fichier qui la retarde, corrige-le et mesure à nouveau. Puis lance seo_audit sur la page d'accueil avec strategy="mobile" et runs=2. Aucune adresse extérieure à ton propre domaine ne doit rester dans la liste des requêtes réseau.
4. Aucun défilement horizontal à 360, 390, 768 et 1440 pixels de large, zones tactiles d'au moins 44 pixels, aucune erreur dans la console.
Vérification de l'interaction : site_preview ne peut pas manipuler le filtre. Indique-moi comment vérifier que l'ouverture de /ilanlar/?ilce=
[quartier]&oda=3%2B1 n'affiche que les annonces correspondantes et remplit le formulaire, que le changement d'un select met à jour la barre d'adresse, que le message d'état vide apparait quand rien ne correspond, que toutes les annonces s'affichent avec JavaScript désactivé, et que le clic sur une vignette d'une page d'annonce fait défiler uniquement la bande de photos sans faire sauter la page.
Après la publication : prévisualise la règle `/assets/* Cache-Control: public, max-age=31536000, immutable` avec site_headers et applique-la une fois que j'aurai approuvé ; à partir de là, versionne le nom de fichier à chaque modification du CSS ou du JS (site-v2.css, etc.). Soumets sitemap.xml avec gsc_submit_sitemap et vérifie la page d'accueil avec gsc_url_inspect. À la fin, donne-moi : un tableau des scores page par page (page, quatre scores mobile, quatre scores desktop, LCP, CLS), le résultat de chaque contrôle et la liste des correctifs appliqués.
