Audit avant mise en ligne

Ton site Next.js passé au peigne fin avant le grand jour.

Le prompt

# Mission : audit complet et correction pré-mise en ligne Tu es un expert senior en Next.js/React, SEO technique, sécurité web, accessibilité et performance. Tu as accès au code de ce projet. Ta mission : faire le tour complet du site avant sa mise en ligne, **corriger directement** ce qui doit l'être, **améliorer** ce qui peut l'être, puis me remettre un rapport clair. Je ne te donne volontairement aucun détail sur le site : c'est à toi de tout déterminer à partir du code. --- ## Règles de travail 1. **Explore avant de toucher.** Ne modifie rien tant que la phase 1 n'est pas terminée. 2. **Respecte l'existant.** Suis les conventions du projet (TypeScript ou JS, structure des dossiers, style, librairies déjà présentes). N'ajoute une dépendance que si c'est vraiment nécessaire, et justifie-le. 3. **N'invente jamais de contenu factuel** (adresse, téléphone, prix, avis, noms, horaires, URL de réseaux sociaux). Si une info manque, utilise un placeholder clair du type `TODO: À COMPLÉTER` et liste-le dans le rapport. 4. **Ne casse rien.** Après tes modifications, le projet doit passer le lint, la vérification de types et le build sans erreur. 5. **Demande avant toute action risquée ou irréversible** : suppression de fichiers ou de pages, changement d'URL existante, migration de router, mise à jour majeure de dépendance, modification de la logique métier. 6. **Rédige le contenu SEO dans la langue du site** (titres, descriptions, texte de la page 404, etc.). --- ## Phase 1 — Exploration et compréhension du site Détermine et note : - **Stack** : version de Next.js et React (`package.json`), App Router (`app/`) ou Pages Router (`pages/`), TypeScript ou non, librairie de style, CMS ou source de données, mode de rendu (SSG, SSR, ISR, export statique), hébergement probable (Vercel, Netlify, Docker, autre — cherche les fichiers de config). - **Langue(s)** : contenu des pages, attribut `lang`, présence d'i18n (next-intl, next-i18next, routes `[locale]`, etc.). - **Type de site** : vitrine, e-commerce, blog, SaaS, portfolio, landing page, application, site local/commerce de proximité, etc. - **Public cible et région**, si déductible. - **URL de production** : cherche dans les variables d'environnement (`NEXT_PUBLIC_SITE_URL`, `SITE_URL`, `VERCEL_URL`, `.env.example`), la config, les métadonnées existantes. Si introuvable, centralise-la dans une seule constante/variable d'environnement avec un placeholder et signale-le. - **Inventaire des routes** : toutes les pages statiques et dynamiques, routes API, middleware, redirections existantes. - **Formulaires, intégrations tierces, iframes, scripts externes** (analytics, chat, cartes, vidéos, paiement). Présente-moi un **résumé court** de ce que tu as compris (5 à 10 lignes) avant de passer à la phase 2. --- ## Phase 2 — Audit et corrections Utilise les API natives de la version de Next.js détectée (par exemple `metadata` / `generateMetadata`, `app/sitemap.ts`, `app/robots.ts`, `not-found.tsx` pour l'App Router ; `next/head`, `next-sitemap` ou équivalent, `pages/404.tsx` pour le Pages Router). ### 1. SEO on-page - `title` et `meta description` uniques et pertinents pour **chaque** page (titres ~50-60 caractères, descriptions ~140-160), avec un `title.template` global si applicable. - `metadataBase` défini, URL **canonique** sur chaque page, gestion des paramètres d'URL et des doublons (avec/sans slash final, www/non-www). - Attribut `lang` correct sur `<html>` ; balises **hreflang** (`alternates.languages`) si le site est multilingue, avec `x-default`. - Open Graph complet (title, description, url, siteName, locale, type, image 1200×630) et Twitter Card. Crée une image OG par défaut (`opengraph-image`) si absente. - Hiérarchie des titres : un seul `<h1>` par page, `h2`/`h3` logiques. - Images : `next/image`, attributs `alt` descriptifs (vides si purement décoratives), dimensions, formats modernes, `priority` sur l'image principale au-dessus de la ligne de flottaison. - Liens internes : `next/link`, textes d'ancre explicites, aucun lien cassé ; liens externes avec `rel="noopener noreferrer"` si `target="_blank"`. - Pages à ne pas indexer (admin, merci, panier, compte, staging, pages de test) : `noindex` approprié. - URLs propres, lisibles, cohérentes. ### 2. Données structurées (JSON-LD) - Ajoute les schémas adaptés au type de site détecté : `Organization` ou `LocalBusiness`, `WebSite`, `BreadcrumbList`, et selon le cas `Article`/`BlogPosting`, `Product`/`Offer`, `FAQPage`, `Service`, `SoftwareApplication`, `Event`, etc. - Utilise uniquement des informations réellement présentes dans le site ; sinon placeholders `TODO`. - JSON-LD valide, injecté proprement. ### 3. Sitemap - `sitemap.xml` dynamique incluant **toutes** les pages indexables, y compris les routes dynamiques (articles, produits…), avec `lastModified` et, si multilingue, les alternates. - Exclure les pages en `noindex`, les routes API et les pages privées. - Si le volume est important, découpe en plusieurs sitemaps. ### 4. robots.txt - Généré proprement, autorisant l'indexation du site public, bloquant les zones privées (`/api/`, `/admin/`, etc.), et pointant vers le sitemap avec l'URL absolue. - Prévois de bloquer toute indexation hors production (preview/staging) via variable d'environnement. - Prends une position explicite et commentée sur les robots d'IA (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot…) : par défaut, autorise-les pour la visibilité, et indique dans le rapport comment les bloquer si je le souhaite. ### 5. llms.txt - Crée `/llms.txt` (dans `public/` ou via une route) selon la convention llms.txt : titre H1 avec le nom du site, résumé en citation, puis sections listant les pages importantes avec lien absolu et courte description. - Optionnel si pertinent : `/llms-full.txt` avec le contenu texte principal. - Contenu dans la langue du site, fidèle au contenu réel. ### 6. Pages d'erreur - Page **404** personnalisée (`not-found.tsx` ou `pages/404.tsx`) : dans la langue du site, cohérente avec le design, avec lien vers l'accueil et vers les sections principales, et qui renvoie bien un vrai statut HTTP 404. - Gestion des erreurs : `error.tsx` et `global-error.tsx` (App Router) ou `pages/500.tsx` / `_error` (Pages Router), sans exposer de détails techniques. - Les routes dynamiques avec une ressource inexistante doivent appeler `notFound()` (ou renvoyer `notFound: true`) au lieu d'afficher une page vide. ### 7. Sécurité - **En-têtes HTTP** dans `next.config` (`headers()`) ou le middleware : `Content-Security-Policy` adaptée aux scripts et services réellement utilisés, `Strict-Transport-Security`, `X-Content-Type-Options: nosniff`, `Referrer-Policy`, `Permissions-Policy`, protection contre le clickjacking (`frame-ancestors` dans la CSP et/ou `X-Frame-Options`). Teste que la CSP ne casse rien (analytics, polices, images, iframes). - `poweredByHeader: false`. - **Secrets** : aucune clé ou secret dans le code ni dans une variable `NEXT_PUBLIC_*` ; `.env*` présents dans `.gitignore` ; un `.env.example` à jour. - **Routes API / Server Actions** : validation des entrées (avec la librairie déjà utilisée, sinon Zod), vérification d'authentification/autorisation, gestion des erreurs sans fuite d'informations, méthodes HTTP restreintes, limitation de débit ou anti-spam sur les formulaires (honeypot, captcha si déjà prévu). - Recherche les usages de `dangerouslySetInnerHTML`, `eval`, redirections ouvertes, injections possibles. - Lance `npm audit` (ou l'équivalent du gestionnaire de paquets) et signale les vulnérabilités ; corrige celles qui ne nécessitent pas de mise à jour majeure. - Retire les `console.log` de debug, les pages et routes de test, les commentaires sensibles. - Ajoute `/.well-known/security.txt` avec un contact placeholder. - Vérifie les cookies (`Secure`, `HttpOnly`, `SameSite`) s'il y en a. ### 8. Iframes et contenus tiers - Chaque `<iframe>` : attribut `title` descriptif, `loading="lazy"`, `sandbox` le plus restrictif possible, `allow` limité au nécessaire, `referrerpolicy` adapté. - Utilise les versions respectueuses de la vie privée quand elles existent (ex. `youtube-nocookie.com`), ou une façade cliquable pour les intégrations lourdes. - Domaines des iframes cohérents avec la directive `frame-src` de la CSP. - Scripts tiers chargés via `next/script` avec la bonne stratégie (`afterInteractive`, `lazyOnload`). ### 9. Performance (Core Web Vitals) - Polices via `next/font`, sans décalage de mise en page. - Images optimisées, dimensions réservées (CLS). - Composants lourds chargés dynamiquement si pertinent ; évite les `"use client"` inutiles. - Vérifie la taille des bundles au build et signale les pages trop lourdes. - Mise en cache et revalidation cohérentes avec la nature du contenu. ### 10. Accessibilité - Contrastes suffisants, navigation clavier, focus visible, lien « aller au contenu ». - Labels sur tous les champs de formulaire, boutons avec texte ou `aria-label`. - Landmarks sémantiques (`header`, `nav`, `main`, `footer`). ### 11. Fichiers et éléments de finition - Favicons complets (`icon`, `apple-icon`), `manifest` web, `theme-color`. - Redirections nécessaires (www/non-www, anciennes URLs si repérées) en 301. - Mentions légales / politique de confidentialité / bannière cookies : signale si absentes alors que le site collecte des données ou utilise des traceurs (sans rédiger de texte juridique). - Vérifie que les variables d'environnement de production sont documentées. --- ## Phase 3 — Vérification 1. Lance le lint, la vérification de types et `build`. Corrige toute erreur introduite. 2. Si possible, démarre le site en mode production et vérifie : `/sitemap.xml`, `/robots.txt`, `/llms.txt`, une URL inexistante (statut 404), les en-têtes HTTP de réponse, l'absence d'erreurs dans la console. 3. Valide le JSON-LD et les balises meta générées dans le HTML rendu. --- ## Phase 4 — Rapport final Remets-moi un rapport structuré ainsi : 1. **Résumé du site** : ce que tu as déterminé (stack, langue, type, cible). 2. **Corrections effectuées** : par catégorie, avec les fichiers modifiés ou créés. 3. **Améliorations apportées.** 4. **À compléter par moi** : tous les `TODO` et placeholders (URL de production, coordonnées, image OG, contact sécurité, etc.). 5. **Points nécessitant ma décision** : ce que tu n'as pas fait par prudence, avec ta recommandation. 6. **Checklist de mise en ligne** : actions hors code (Google Search Console, Bing Webmaster Tools, soumission du sitemap, variables d'environnement de production, DNS/HTTPS, analytics, test sur mobile, tests PageSpeed Insights et Rich Results). 7. **Score indicatif** avant/après par catégorie (SEO, sécurité, performance, accessibilité) sur 10. Commence maintenant par la phase 1.

Prêt

D’autres prompts

Audit des dépendancesL’inventaire des vulnérabilités, les mises à jour sûres appliquées et testées, et le détail du risque pour celles qui pourraient casser.Code Fichier d’avancementCe que la conversation a décidé, réglé et laissé en plan, résumé dans un AVANCEMENT.md qu’une nouvelle IA peut reprendre.Code Correction d’orthographeOrthographe, grammaire et typographie corrigées sans toucher au style ni à la structure. Les fautes voulues sont gardées telles quelles.Écriture