ADR-0049 — Annuaires publics de boutiques et dossiers du haut du classement : des tranches, jamais des chiffres

Statut

Proposé · 2026-10-02

Piliers : growth-web, intelligence

Code : src/services/directories/, pages sous src/app/(marketing)/intelligence/directory et .../dossier, sitemaps sous src/app/sitemaps. Cadre de rendu : ADR 0047 (rendu par requete, CSP a nonce intacte, chargeurs en unstable_cache).

Contexte

La fiche d'une boutique (/intelligence/stores/[domain]) est noindex depuis juin 2026 : une page mince par boutique scannee gonflerait l'index. Il manque pourtant une surface d'acquisition organique honnete : « boutiques qui utilisent <app> », « boutiques <niche> en <pays> », et un dossier public pour les meilleures boutiques.

Décision

1. Annuaires par niche, pays, theme, application et niche x pays, au-dessus de l'admission du Store Spy (spyListingSql, whereOf) : pas de predicat maison. S'y ajoutent trois conditions propres a une page publique : lignes PUBLIC seulement, anti-jointure SQL sur IntelligenceSuppression (tombstone), et un releve de trafic ou de publicites qui ne compte que s'il est recent (90 et 30 jours).
2. Garde de contenu mince : un annuaire est indexable s'il liste au moins 12 boutiques dont au moins 8 portent 4 faits mesures sur 6. Sinon il reste servi (noindex, follow), sort des sitemaps, et n'est pas lie depuis l'index. Zero resultat, nom absent de l'index mis en cache, page au-dela de 10 : 404 sans requete. Les pages 2 et suivantes sont noindex, follow.
3. Dossiers pour les 500 premieres boutiques par trafic mesure et recent. Trafic et publicites sont affiches en tranches (une decade, une fourchette), avec source et periode ; jamais un chiffre exact de trafic, de CA, de croissance ou de depense. La tranche de trafic derive d'un champ payant (plan Pro) : c'est l'exception voulue de cette surface, et la seule. Les meilleures ventes viennent de la vue gratuite de la liste (redactHubStore(store, "free"), deux noms). La FAQ est generee par gabarits a partir des faits mesures ; une question dont le fait manque n'existe pas.
4. Retrait : le dossier relit la ligne vivante (tombstone, opt-out, listabilite) a chaque vue, hors cache ; les chunks de sitemap filtrent les tombstones a chaque fetch ; les chemins de retrait expirent le tag directories.
5. Sitemaps : un index /sitemaps/stores.xml et des chunks de 5 000 URLs au plus, lastmod = observed_at de la donnee ou absent. robots.txt nomme les deux sitemaps ; le proxy d'image signe du dossier est ouvert aux robots.
6. IndexNow : coupe tant que INDEXNOW_KEY n'est pas posee ; une soumission par 6 heures, 1 000 URLs par requete, 3 000 par jour, via guardedFetch. Declenche en fin du refresh froid quotidien : aucun cron nouveau.

Alternatives écartées

• Cle de cache par langue : les valeurs en cache (domaines, tranches, comptes, codes ISO) sont identiques dans les six langues ; la cle par langue aurait rejoue le meme balayage six fois. Les phrases se fabriquent au rendu.
• Table denormalisee ou colonnes generees (StoreSpyFacts) : necessite un changement de schema, hors de ce lot. Suivi : voir hub-store-query.ts.
• Dossier pour toute boutique : c'est exactement la page mince que la decision de juin 2026 refuse.
• Fiche /intelligence/stores/[domain] rendue indexable pour le haut du classement : deux URLs pour une boutique ; le dossier est une page distincte, a tranches, et la fiche garde son role de lecture complete.

Conséquences

• Chaque annuaire a froid coute un balayage des lignes listables (quelques dizaines de milliers, ~1,7 s d'apres hub-store-query.ts), une fois par heure et par entree.
• La fraicheur du catalogue public est de 24 h : si le balayage de vivacite cale, des annuaires et des dossiers sortent des sitemaps puis y reviennent.
• La region d'une boutique est son marche principal (pays du trafic, sinon premier marche declare), pas son siege.