brandvm/webflow-audit

Webflow audit : un site en ligne, modifié par petits pas vérifiés

Un site en ligne a des visiteurs, un classement (rankings) et du travail non publié d'autres personnes. Rien ici n'est construit à neuf : chaque modification part d’une mesure, est déployée seule et peut être annulée.

Les règles communes s’appliquent (webflow-build › rules.md : pas de commit, push, release ou changement DNS sans un OK explicite ; pas d’identifiants dans le chat ; Designer en premier ; les scripts dans le repo). Leurs scripts de vérification (pnpm wf:*) effectuent les mesures ; pointez stagingUrl dans webflow-build.config.json vers le domaine de staging et utilisez --live pour ce que voient les visiteurs.

Tags : [Claude] Claude le fait · [Claude checks] Claude vérifie et rapporte · [Person] une personne le fait ; Claude peut le suivre, jamais le revendiquer.

Deux règles par-dessus toutes les autres :

• Une publication est globale. Publier envoie tout ce qui est en attente sur le site, y compris les modifications inachevées d'autres personnes. Ne publiez jamais sur le domaine en ligne tant que la personne n'a pas tapé le mot publish pour ce lot. Un seul « publish » couvre un lot, jamais le suivant.
• Lisez avant d'écrire. L'audit n'écrit rien dans Webflow.

Les documents

Dans le dossier docs/handoff/ du dépôt, tenus à jour au fil du travail :

Fichier	Contient
AUDIT.md	Le rapport d'audit : ce qui a été mesuré, avec chiffres et dates
STATUS.md	Le suivi : chaque demande, dans les mots du client, avec son état
DECISIONS.md	Chaque décision, qui l'a prise, quand, et ce qu'elle signifie
ROLLBACK.md	Le point de rollback et, mot pour mot, l’intégralité du code personnalisé tel qu’il était
MANUAL-TODO.md	Les étapes qu’une personne peut seule réaliser dans le Designer

1. Audit en lecture seule

Rien n'est écrit dans Webflow à cette étape. Exécutez-la dans cet ordre : les deux premières sont celles qui peuvent être sautées et ne peuvent pas être rattrapées plus tard, car elles décrivent le site avant tout changement.

• [Claude] Baselines visuelles, avec le bruit de fond. pnpm wf:baseline save --live sur chaque page clé à quatre largeurs, puis compare immédiatement sans aucune modification. Ce qui diffère entre deux exécutions intactes (images vidéo, sliders, images lazy) est le bruit de fond ; notez-le par page. Gardez les images de baseline hors de git (elles sont volumineuses) : .webflow-build/ est ignoré pour cette raison.
• [Claude] Plan de titres de chaque page clé (pnpm wf:outline --live), sauvegardé dans AUDIT.md.
• [Claude] Vitesse : pnpm wf:perf --live, mobile et desktop, la médiane de 5 runs avec son intervalle, pour chaque page clé (pas seulement la Home).
• [Claude] Accessibilité : pnpm wf:a11y --live --all-widths.
• [Claude] Liens et redirections : pnpm wf:links --live --external ; la liste des redirections depuis les paramètres du site (exportez-la en CSV) ; le sitemap. Avec les URLs que Search Console signale comme non trouvées, pnpm wf:redirects test --live --file <export> : quelles anciennes URLs sont en 404, bouclent, chaînent ou atterrissent sur la page d'accueil.
• [Claude] HTML publié : pnpm wf:html --live (noms de champs par défaut, liens en lieu et place de boutons, classes qu'aucune feuille de style ne définit).
• [Claude] SEO et schémas : pnpm wf:seo --live --canonical : par page, le titre, la description, le canonique, l’image Open Graph, l’état d’indexation et tout JSON‑LD (se parse-t-il ; une citation dans un champ CMS le casse-t-elle) ; et à l’échelle du site, les titres et descriptions en double, la page 404, le fichier robots.txt. Les plans de titres comparés à webflow-launch › headings.md.
• [Claude] Suivi : pnpm wf:tracking --live : quelles balises se chargent où, les pages vues comptées deux fois, ce qui s’exécute avant le choix des cookies et après Reject, gclid et UTM à travers les redirections. Les requêtes de données sont bloquées, donc l’audit n’envoie rien vers les comptes du client.
• [Claude] Domaine : pnpm wf:domain : certificat, date de renouvellement du domaine, registrar et hébergeur DNS, les redirections http et www.
• [Claude] Inventaire, lu via le connecteur : pages et dossiers ; collections CMS avec types de champs et nombre d’éléments ; composants ; polices et comment elles se chargent ; chaque morceau de code personnalisé (head et footer du site, code de chaque page, chaque Embed) et chaque script tiers, avec leur utilité (wf:tracking liste les services que les pages chargent) ; interactions (et quelles pages en dépendent) ; formulaires (et où ils envoient).
• [Claude] Rapport dans AUDIT.md : les constats sous forme de points courts avec des chiffres, chacun marqué mesuré ou lu depuis le code, trié par ce qu’il apporterait et ce qu’il pourrait casser. Une affirmation qui n’a pas été mesurée le mentionne. Barrière : la personne reçoit le rapport.

2. Suivi, dès le premier jour

• [Claude] Rédiger STATUS.md à partir du brief et de la checklist du client, dans ses propres mots, une ligne par demande : demande, état (pas commencé, en cours, en staging, en ligne, abandonné et pourquoi), lot, date. Sur des sites précédents, des demandes ont été perdues parce que le suivi arrivait tard et était rédigé dans des mots différents de la liste du client.
• [Person] Confirme que rien ne manque. Barrière.
• [Claude] Chaque rapport ultérieur coche le suivi et donne le compte : « 9 sur 14 en ligne, 2 en staging, 3 en attente d’une décision ».

3. Décisions, une à la fois

• [Claude] Poser une décision à la fois, chacune avec ce qu’elle signifie en mots simples : ce qui change pour les visiteurs, ce que ça coûte, ce qui pourrait mal tourner, et la recommandation.
• [Claude] Enregistrer chaque décision dans DECISIONS.md quand elle est prise.
• Seul le nouveau contenu destiné au client (texte, images, maquette modifiée) est soumis à l’approbation du client. La tuyauterie (comment un script se charge, où vit le CSS) relève de l’équipe.

4. Point de rollback, avant la première écriture

• [Claude] Un tag git sur le commit qui correspond à ce qui est en ligne.
• [Claude] ROLLBACK.md contient, mot pour mot, chaque morceau de code personnalisé tel qu’il est maintenant : code head et footer du site, code de chaque page, chaque Embed.
• [Person] Une sauvegarde Webflow (Paramètres du site › Sauvegardes), nommée avec la date ; et une protection de branche sur la branche par défaut du dépôt.
• [Claude checks] Les étapes de rollback sont écrites et chacune est réalisable : restaurer les blocs de code, repointez le chargeur vers l’ancienne release, restaurer la sauvegarde. Barrière : confirmé par la personne.

5. Publication de parité (quand la tuyauterie change)

Migrer un site vers le template change la manière dont son code est délivré. Ce changement part en premier, seul, sans rien que le visiteur puisse voir.

• [Claude] Porter le comportement existant tel quel. Pas de réécritures ni d’améliorations dans cette étape : ce sont des lots ultérieurs, chacun mesuré.
• [Claude checks] Parité sur chaque page clé à quatre largeurs : styles calculés et géométrie par rapport aux baselines (pnpm wf:baseline compare, différences uniquement dans le bruit de fond).
• [Claude checks] Parité du temps de chargement aussi (pnpm wf:film) : une page stable peut correspondre alors que la première seconde saute. Comparez le chargement, pas seulement la fin.
• Ensuite, suivez les étapes de lot ci-dessous, comme n’importe quel autre lot.

6. Lots, du moins risqué d’abord

Organisez le travail de manière à ce que les gains les plus sûrs et les plus certains passent en premier, et que chaque lot puisse être jugé individuellement. Un lot = un changement qu’une personne pourrait décrire en une phrase. Pour chacun :

1. Préparer dans le dépôt (pnpm check && pnpm build && pnpm test) ; dire ce qui changera dans Webflow et ce qu’un visiteur remarquera.
2. Appliquer dans Webflow après le feu vert. Puis dire : « rechargez le Designer », et ce qui n’est pas publié.
3. Publier uniquement en staging.
4. Vérifier en staging : la vérification du lot lui-même, plus baseline compare, html et la console sur les pages concernées, à quatre largeurs.
5. Demander ce qui d’autre partirait en ligne. [Person] vérifie le site pour d’autres modifications en attente (les leurs ou celles d’un collègue). Claude ne peut pas voir qui a changé quoi ; le dire et attendre.
6. La personne tape « publish ». Ensuite, publier sur le domaine en ligne.
7. Vérifier la production avec --live : les mêmes vérifications, et le numéro du lot (vitesse, erreurs, liens) mesuré à nouveau.
8. Cocher le suivi et la checklist du client ; noter le résultat dans AUDIT.md à côté du constat.

• Les modifications d’éléments CMS (une faute de frappe, un nouvel élément) peuvent partir directement en ligne : publier un élément ne publie pas le site. Les modifications de page et de site passent toujours par les huit étapes.
• Webflow limite la fréquence de publication d’un site : regroupez les vérifications pour qu’un lot nécessite une publication en staging et une en ligne.

7. Ne garder que les gains mesurés

• [Claude checks] Avant et après sont tous deux des médianes du même nombre de runs. Une différence dans l’intervalle est du bruit.
• [Claude] Un changement qui ne fait pas bouger son chiffre, ou qui en fait bouger un autre dans le mauvais sens, est annulé, et le suivi le mentionne. Aucun changement ne reste sur la foi de ce qu’il aurait dû faire.

8. Clôture

• [Claude] Rapport avant/après : chaque demande du suivi avec son résultat en chiffres ; ce qui a été abandonné et pourquoi ; ce qui reste.
• [Claude] ROLLBACK.md mis à jour vers le nouvel état ; l’ancien tag conservé.
• [Claude] Leçons proposées au template (webflow-build › rules.md › Contributing).

Petits travaux (une correction unique sur un site en ligne)

Un lien cassé, un carrousel qui s’arrête, un formulaire qui n’envoie pas. La même attention, en cinq étapes :

1. Reproduire le problème, sur le site en ligne, et dire exactement quand il se produit (page, largeur, navigateur, étapes).
2. Corriger à l’endroit le plus petit possible. Lire GOTCHAS.md et les leçons d’abord : c’est déjà arrivé.
3. Test de régression là où le dépôt a des tests pour cette zone, afin que cela ne revienne pas inaperçu.
4. Staging, sur desktop et largeur téléphone ; pnpm wf:html et la console sur la page.
5. Stop. Signaler ce qui était faux, ce qui a changé et comment cela a été vérifié, et attendre l’approbation avant tout push, tag ou publication. Conserver le tag de release précédent pour pouvoir y repointez le chargeur. Une publication en ligne nécessite toujours le mot « publish », après que la personne a vérifié ce qui est en attente.