Tickets dev.
25 tickets en 4 paniers. Filtre par panier ou criticité, recherche libre, statut local, copy Linear-ready. Pour l'équipe dev OfficeRiders.
Aucun ticket ne correspond aux filtres en cours.
- Description
Construire un mapping exhaustif URL par URL des routes app.officeriders.com vers leur équivalent www.officeriders.com, à appliquer au moment de la bascule (301 permanent, pas 302/307).
PourquoiÀ la fusion plateforme de février-mars 2026, des milliers de liens OfficeRiders n'ont pas été redirigés (call du 27 mai). Sans plan complet pour la migration fin juin, on reproduit la perte.
Critères d'acceptation- Mapping URL exhaustif, basé sur le crawl Roalink + l'inventaire GSC app. (en attente d'accès)
- 100 % des URLs app.* recensées ont une cible www.* déterminée (ou un 410 explicite)
- Validé conjointement avec OfficeRiders avant la bascule
- Appliqué en 301 au moment de la migration
URLs concernéesCadrage post-call OfficeRiders 2026-05-27 Plan de redirections app.* → www.* avant la bascule fin juin Critique avant la migration Critique [ROA-A1] Plan de redirections app.* → www.* avant la bascule fin juin Panier: A · Critique avant la migration Criticité: Critique Produit cible: WebApp (Marketplace) Source: Cadrage post-call OfficeRiders 2026-05-27 ## Description Construire un mapping exhaustif URL par URL des routes app.officeriders.com vers leur équivalent www.officeriders.com, à appliquer au moment de la bascule (301 permanent, pas 302/307). ## Pourquoi À la fusion plateforme de février-mars 2026, des milliers de liens OfficeRiders n'ont pas été redirigés (call du 27 mai). Sans plan complet pour la migration fin juin, on reproduit la perte. ## Critères d'acceptation - [ ] Mapping URL exhaustif, basé sur le crawl Roalink + l'inventaire GSC app. (en attente d'accès) - [ ] 100 % des URLs app.* recensées ont une cible www.* déterminée (ou un 410 explicite) - [ ] Validé conjointement avec OfficeRiders avant la bascule - [ ] Appliqué en 301 au moment de la migration ## URLs concernées - app.officeriders.com/*app.officeriders.com/*
- Description
Sitemap unique, à jour, généré depuis la base, listant uniquement les URLs canoniques servies en 200. Soumis à Search Console après la migration.
PourquoiLe sitemap actuel pointe vers un bucket S3 supprimé (NoSuchBucket). Le nouveau sitemap post-fusion doit être généré dynamiquement depuis la source de vérité des pages servies en 200.
Critères d'acceptation- GET /sitemap.xml → 200, Content-Type XML, 0 redirection
- Schéma sitemaps.org valide (xmllint ok)
- 100 % d'un échantillon de 20 <loc> aléatoires répondent 200
- Aucune référence à *.s3.amazonaws.com dans robots.txt ni dans la chaîne sitemap
- Soumis et 'Réussite' dans GSC → Sitemaps
URLs concernéeswww.officeriders.com/sitemap.xmlwww.officeriders.com/blog/sitemap_index.xml
Constat actuel (à supprimer après migration)Bloc A specs + audit Équipe Roalink Sitemap www.officeriders.com post-migration Critique avant la migration Haute [ROA-A2] Sitemap www.officeriders.com post-migration Panier: A · Critique avant la migration Criticité: Haute Produit cible: Plateforme Source: Bloc A specs + audit Équipe Roalink ## Description Sitemap unique, à jour, généré depuis la base, listant uniquement les URLs canoniques servies en 200. Soumis à Search Console après la migration. ## Pourquoi Le sitemap actuel pointe vers un bucket S3 supprimé (NoSuchBucket). Le nouveau sitemap post-fusion doit être généré dynamiquement depuis la source de vérité des pages servies en 200. ## Critères d'acceptation - [ ] GET /sitemap.xml → 200, Content-Type XML, 0 redirection - [ ] Schéma sitemaps.org valide (xmllint ok) - [ ] 100 % d'un échantillon de 20 <loc> aléatoires répondent 200 - [ ] Aucune référence à *.s3.amazonaws.com dans robots.txt ni dans la chaîne sitemap - [ ] Soumis et 'Réussite' dans GSC → Sitemaps ## URLs concernées - www.officeriders.com/sitemap.xml - www.officeriders.com/blog/sitemap_index.xmlcurl -sI https://www.officeriders.com/sitemap.xml # → 302 location: https://officeriders-storage-prod.s3.amazonaws.com/... curl -s https://officeriders-storage-prod.s3.amazonaws.com/officeriders/sitemap/sitemap.xml # → <Error><Code>NoSuchBucket</Code> ...</Error> - Description
Définir le robots.txt unique post-fusion : déclare le sitemap valide, bloque les routes privées (ex /open-space?), pas de référence S3.
PourquoiAujourd'hui pas de robots.txt sur app.* et celui de www. déclare le sitemap mort. Post-fusion, un seul robots.txt sur www., qui déclare le bon sitemap et bloque les routes non-publiques.
Critères d'acceptation- Un seul robots.txt sur www.officeriders.com
- Directive Sitemap: pointe vers /sitemap.xml (résolution 200)
- Routes non-publiques bloquées (à valider avec OfficeRiders : /open-space?, etc.)
- Pas de blocage involontaire sur les routes publiques
URLs concernéesAudit Équipe Roalink ticket #8 Robots.txt cohérent post-migration Critique avant la migration Haute [ROA-A3] Robots.txt cohérent post-migration Panier: A · Critique avant la migration Criticité: Haute Produit cible: Plateforme Source: Audit Équipe Roalink ticket #8 ## Description Définir le robots.txt unique post-fusion : déclare le sitemap valide, bloque les routes privées (ex /open-space?), pas de référence S3. ## Pourquoi Aujourd'hui pas de robots.txt sur app.* et celui de www. déclare le sitemap mort. Post-fusion, un seul robots.txt sur www., qui déclare le bon sitemap et bloque les routes non-publiques. ## Critères d'acceptation - [ ] Un seul robots.txt sur www.officeriders.com - [ ] Directive Sitemap: pointe vers /sitemap.xml (résolution 200) - [ ] Routes non-publiques bloquées (à valider avec OfficeRiders : /open-space?, etc.) - [ ] Pas de blocage involontaire sur les routes publiques ## URLs concernées - www.officeriders.com/robots.txtwww.officeriders.com/robots.txt
- Description
Cataloguer les chemins legacy morts depuis la fusion plateforme de février-mars 2026. Pour chacun : 301 si une cible équivalente existe sur www., 410 sinon.
Pourquoi~40 % des requêtes Googlebot retournent 404 sur des chemins legacy (/rooms/, /salles/, /articles/, /glossaire/, /france/, /guides/, /blog/wp-content/uploads/, etc.). En 404, Google continue de revisiter. En 410 (Gone), il arrête.
Critères d'acceptation- Liste exhaustive des préfixes legacy 404 (extraite du sheet 404_crawl_stats)
- Décision URL par URL : 301 vers cible www. ou 410 Gone
- Implémentation côté serveur (middleware Next.js ou config edge)
- Vérification : Googlebot reçoit le bon code de réponse
URLs concernées/edit-*/fr/s/*/fr/es*/blog/wp-content/uploads/*/salles/*/rooms/*/articles/*/enjeux/*/france/*/glossaire/*/ressources/*/guides/*
Données sources Crawl Googlebot · 404 983 lignes · table filtrable + CSVAudit Équipe Roalink ticket #12 Plan 410 sur les chemins legacy morts Critique avant la migration Haute [ROA-A4] Plan 410 sur les chemins legacy morts Panier: A · Critique avant la migration Criticité: Haute Produit cible: Plateforme Source: Audit Équipe Roalink ticket #12 ## Description Cataloguer les chemins legacy morts depuis la fusion plateforme de février-mars 2026. Pour chacun : 301 si une cible équivalente existe sur www., 410 sinon. ## Pourquoi ~40 % des requêtes Googlebot retournent 404 sur des chemins legacy (/rooms/, /salles/, /articles/, /glossaire/, /france/, /guides/, /blog/wp-content/uploads/, etc.). En 404, Google continue de revisiter. En 410 (Gone), il arrête. ## Critères d'acceptation - [ ] Liste exhaustive des préfixes legacy 404 (extraite du sheet 404_crawl_stats) - [ ] Décision URL par URL : 301 vers cible www. ou 410 Gone - [ ] Implémentation côté serveur (middleware Next.js ou config edge) - [ ] Vérification : Googlebot reçoit le bon code de réponse ## URLs concernées - /edit-* - /fr/s/* - /fr/es* - /blog/wp-content/uploads/* - /salles/* - /rooms/* - /articles/* - /enjeux/* - /france/* - /glossaire/* - /ressources/* - /guides/* - Description
Remplacer le 307 par un 301 permanent, ou servir directement le contenu à la racine et gérer la langue via hreflang. Vérifier qu'aucun edge/CDN ne réécrit le 301 en 307/302.
PourquoiAujourd'hui / redirige en 307 (temporaire) vers /fr. Google interprète / comme canonique et laisse /fr hors index (verdict 'Duplicate, Google chose different canonical than user'). Bloc majeur de récupération.
Critères d'acceptation- GET / (UA Googlebot, sans cookie) → 301 vers /fr OU 200
- Plus aucune réponse 307 sur la racine
- Chaîne de redirection ≤ 1 saut, sans boucle, vers une URL 200
- Comportement stable indépendamment de l'Accept-Language
URLs concernéeswww.officeriders.com/
Constat actuelBloc A specs A2 + audit Équipe Roalink ticket #14 Racine / : passer le 307 en 301 (ou servir directement en 200) Correctifs www. à pousser dès que possible Haute [ROA-B1] Racine / : passer le 307 en 301 (ou servir directement en 200) Panier: B · Correctifs www. à pousser dès que possible Criticité: Haute Produit cible: Landing Page Source: Bloc A specs A2 + audit Équipe Roalink ticket #14 ## Description Remplacer le 307 par un 301 permanent, ou servir directement le contenu à la racine et gérer la langue via hreflang. Vérifier qu'aucun edge/CDN ne réécrit le 301 en 307/302. ## Pourquoi Aujourd'hui / redirige en 307 (temporaire) vers /fr. Google interprète / comme canonique et laisse /fr hors index (verdict 'Duplicate, Google chose different canonical than user'). Bloc majeur de récupération. ## Critères d'acceptation - [ ] GET / (UA Googlebot, sans cookie) → 301 vers /fr OU 200 - [ ] Plus aucune réponse 307 sur la racine - [ ] Chaîne de redirection ≤ 1 saut, sans boucle, vers une URL 200 - [ ] Comportement stable indépendamment de l'Accept-Language ## URLs concernées - www.officeriders.com/curl -sI https://www.officeriders.com/ | grep -i '^HTTP\|^location' # → HTTP/2 307 # → location: /fr - Description
Servir un <link rel='canonical'> auto-référent absolu sur /fr (https://www.officeriders.com/fr), cohérent en http(s)/www/casse/trailing slash avec l'URL réellement servie en 200.
PourquoiURL Inspection : /fr a un canonical Google différent du canonical déclaré. La home FR n'est pas indexée. Cohérence canonical/hreflang à restaurer.
Critères d'acceptation- /fr sert un canonical auto-référent absolu
- Aucune autre page ne déclare canonical vers /fr si elle n'en est pas variante
- Hreflang FR/EN réciproque, ne pointe pas vers du 404
- Verdict URL Inspection passe à 'canonique user = canonique Google'
- /fr n'est ni en noindex ni bloqué par robots.txt
URLs concernéesBloc A specs A3 Canonical /fr auto-référent Correctifs www. à pousser dès que possible Haute [ROA-B2] Canonical /fr auto-référent Panier: B · Correctifs www. à pousser dès que possible Criticité: Haute Produit cible: Landing Page Source: Bloc A specs A3 ## Description Servir un <link rel='canonical'> auto-référent absolu sur /fr (https://www.officeriders.com/fr), cohérent en http(s)/www/casse/trailing slash avec l'URL réellement servie en 200. ## Pourquoi URL Inspection : /fr a un canonical Google différent du canonical déclaré. La home FR n'est pas indexée. Cohérence canonical/hreflang à restaurer. ## Critères d'acceptation - [ ] /fr sert un canonical auto-référent absolu - [ ] Aucune autre page ne déclare canonical vers /fr si elle n'en est pas variante - [ ] Hreflang FR/EN réciproque, ne pointe pas vers du 404 - [ ] Verdict URL Inspection passe à 'canonique user = canonique Google' - [ ] /fr n'est ni en noindex ni bloqué par robots.txt ## URLs concernées - www.officeriders.com/frwww.officeriders.com/fr
- Description
Choisir l'URL canonique unique (recommandé : garder le slug FR sur l'arbo /fr). L'URL canonique sert 200 avec canonical auto-référent, l'autre URL redirige en 301 (pas 307). Étendre l'audit à tous les couples FR/EN du site.
PourquoiPage survivante à fort trafic (2 532 clics / 16 mois). Canonical vers /fr/become-a-host qui redirige 307 vers /fr/devenir-hote. Signal contradictoire. Pattern à risque sur tous les couples FR/EN.
Critères d'acceptation- URL canonique unique choisie pour ce couple
- Canonical → 200, link canonical auto-référent absolu
- Autre URL → 301 (pas 307), pas de boucle
- Audit étendu : tous les couples FR/EN (for-business, solutions, partners, contact, careers, help, etc.)
URLs concernéeswww.officeriders.com/fr/devenir-hotewww.officeriders.com/fr/become-a-host
Constat actuelBloc A specs A4 Boucle canonical /fr/devenir-hote ↔ /fr/become-a-host Correctifs www. à pousser dès que possible Haute [ROA-B3] Boucle canonical /fr/devenir-hote ↔ /fr/become-a-host Panier: B · Correctifs www. à pousser dès que possible Criticité: Haute Produit cible: Landing Page Source: Bloc A specs A4 ## Description Choisir l'URL canonique unique (recommandé : garder le slug FR sur l'arbo /fr). L'URL canonique sert 200 avec canonical auto-référent, l'autre URL redirige en 301 (pas 307). Étendre l'audit à tous les couples FR/EN du site. ## Pourquoi Page survivante à fort trafic (2 532 clics / 16 mois). Canonical vers /fr/become-a-host qui redirige 307 vers /fr/devenir-hote. Signal contradictoire. Pattern à risque sur tous les couples FR/EN. ## Critères d'acceptation - [ ] URL canonique unique choisie pour ce couple - [ ] Canonical → 200, link canonical auto-référent absolu - [ ] Autre URL → 301 (pas 307), pas de boucle - [ ] Audit étendu : tous les couples FR/EN (for-business, solutions, partners, contact, careers, help, etc.) ## URLs concernées - www.officeriders.com/fr/devenir-hote - www.officeriders.com/fr/become-a-hostcurl -s https://www.officeriders.com/fr/devenir-hote | grep -i 'rel="canonical"' # → <link rel="canonical" href="https://www.officeriders.com/fr/become-a-host"/> curl -sI https://www.officeriders.com/fr/become-a-host | grep -i '^HTTP\|^location' # → HTTP/2 307 location: /fr/devenir-hote - Description
Revue de toutes les redirections 302 du site (sheet 302_crawl_stats de l'audit Équipe Roalink). Pour chacune : 301 si la cible est OK, 410 si la cible est elle-même morte.
Pourquoi~17 % des requêtes Googlebot passent par des 302 (temporaires). Google revisite indéfiniment. Cumulé avec les 404 du panier A4, plus de la moitié du budget crawl est gaspillé.
Critères d'acceptation- Liste complète des 302 actuels (extraite de la donnée crawl)
- Décision URL par URL : 301 ou 410
- Implémentation côté serveur
- Vérification : Googlebot ne voit plus de 302 sur les chemins traités
Données sources Crawl Googlebot · 302 983 lignes · table filtrable + CSVAudit Équipe Roalink ticket #13 Plan 302 → 301 sur les redirections legacy Correctifs www. à pousser dès que possible Haute [ROA-B4] Plan 302 → 301 sur les redirections legacy Panier: B · Correctifs www. à pousser dès que possible Criticité: Haute Produit cible: Plateforme Source: Audit Équipe Roalink ticket #13 ## Description Revue de toutes les redirections 302 du site (sheet 302_crawl_stats de l'audit Équipe Roalink). Pour chacune : 301 si la cible est OK, 410 si la cible est elle-même morte. ## Pourquoi ~17 % des requêtes Googlebot passent par des 302 (temporaires). Google revisite indéfiniment. Cumulé avec les 404 du panier A4, plus de la moitié du budget crawl est gaspillé. ## Critères d'acceptation - [ ] Liste complète des 302 actuels (extraite de la donnée crawl) - [ ] Décision URL par URL : 301 ou 410 - [ ] Implémentation côté serveur - [ ] Vérification : Googlebot ne voit plus de 302 sur les chemins traités - Description
Le serveur doit retourner 404 (ou redirect vers /404) quand une route blog n'existe pas.
PourquoiLes URLs introuvables dans /fr/blog/espaces/ ou /en/blog/espaces/ retournent 200 alors qu'elles sont logiquement 404. Google les indexe à tort.
Critères d'acceptation- Aucune page blog inexistante ne retourne 200
- Comportement vérifié sur les URLs citées dans l'audit
URLs concernéesAudit Équipe Roalink ticket #1 Soft 404 sur le blog Correctifs www. à pousser dès que possible Moyenne [ROA-B5] Soft 404 sur le blog Panier: B · Correctifs www. à pousser dès que possible Criticité: Moyenne Produit cible: Landing Page Source: Audit Équipe Roalink ticket #1 ## Description Le serveur doit retourner 404 (ou redirect vers /404) quand une route blog n'existe pas. ## Pourquoi Les URLs introuvables dans /fr/blog/espaces/ ou /en/blog/espaces/ retournent 200 alors qu'elles sont logiquement 404. Google les indexe à tort. ## Critères d'acceptation - [ ] Aucune page blog inexistante ne retourne 200 - [ ] Comportement vérifié sur les URLs citées dans l'audit ## URLs concernées - www.officeriders.com/en/blog/espaces/espaces-travail-usages-bien-etre-productivite - www.officeriders.com/en/blog/espaces/choisir-espace-coworking-entreprisewww.officeriders.com/en/blog/espaces/espaces-travail-usages-bien-etre-productivitewww.officeriders.com/en/blog/espaces/choisir-espace-coworking-entreprise
- Description
Sur chaque article blog FR : n'inclure le hreflang EN que si l'article EN existe et répond 200. Inverse aussi.
PourquoiLes articles blog FR déclarent un hreflang vers la version EN, mais cette dernière n'existe pas. Les hreflang doivent toujours pointer vers une URL 200.
Critères d'acceptationAudit Équipe Roalink ticket #2 Hreflang blog : retirer les liens vers articles EN inexistants Correctifs www. à pousser dès que possible Moyenne [ROA-B6] Hreflang blog : retirer les liens vers articles EN inexistants Panier: B · Correctifs www. à pousser dès que possible Criticité: Moyenne Produit cible: Landing Page Source: Audit Équipe Roalink ticket #2 ## Description Sur chaque article blog FR : n'inclure le hreflang EN que si l'article EN existe et répond 200. Inverse aussi. ## Pourquoi Les articles blog FR déclarent un hreflang vers la version EN, mais cette dernière n'existe pas. Les hreflang doivent toujours pointer vers une URL 200. ## Critères d'acceptation - [ ] Aucun lien hreflang vers une URL 404 - [ ] Vérification automatisée sur l'ensemble du corpus blog- Aucun lien hreflang vers une URL 404
- Vérification automatisée sur l'ensemble du corpus blog
- Description
Choisir un slug canonique pour chaque article ayant plusieurs URLs. Les autres redirigent en 301 vers le canonique.
PourquoiUn même article (ex 'rituels-entreprise-travail-hybride') est servi sous /fr/blog/moments/... et /fr/blog/travailler-differemment/..., les deux self-canonical. Duplication.
Critères d'acceptationAudit Équipe Roalink ticket #15 Article blog accessible sous plusieurs URLs Correctifs www. à pousser dès que possible Basse [ROA-B7] Article blog accessible sous plusieurs URLs Panier: B · Correctifs www. à pousser dès que possible Criticité: Basse Produit cible: Landing Page Source: Audit Équipe Roalink ticket #15 ## Description Choisir un slug canonique pour chaque article ayant plusieurs URLs. Les autres redirigent en 301 vers le canonique. ## Pourquoi Un même article (ex 'rituels-entreprise-travail-hybride') est servi sous /fr/blog/moments/... et /fr/blog/travailler-differemment/..., les deux self-canonical. Duplication. ## Critères d'acceptation - [ ] Un article = une URL canonique unique - [ ] Variantes legacy → 301 vers le canonique- Un article = une URL canonique unique
- Variantes legacy → 301 vers le canonique
- Description
Convertir le rendu en mailto: standard.
PourquoiL'email du privacy policy est rendu comme un lien hypertexte au lieu d'un mailto. Fix HTML ponctuel, sans impact architectural.
Critères d'acceptation- Aucun lien contenant @ sur la page (qui ne soit pas un mailto:)
URLs concernéesAudit Équipe Roalink ticket #16 mailto rendu comme lien normal sur /en/privacy-policy Correctifs www. à pousser dès que possible Basse [ROA-B8] mailto rendu comme lien normal sur /en/privacy-policy Panier: B · Correctifs www. à pousser dès que possible Criticité: Basse Produit cible: Landing Page Source: Audit Équipe Roalink ticket #16 ## Description Convertir le rendu en mailto: standard. ## Pourquoi L'email du privacy policy est rendu comme un lien hypertexte au lieu d'un mailto. Fix HTML ponctuel, sans impact architectural. ## Critères d'acceptation - [ ] Aucun lien contenant @ sur la page (qui ne soit pas un mailto:) ## URLs concernées - www.officeriders.com/en/privacy-policywww.officeriders.com/en/privacy-policy
- Description
Supprimer toute mention « ex Worklib » / « (ex Worklib) » dans les <title>, les H1 et les métadonnées générées par les templates. Vérifier qu'aucune chaîne legacy ne subsiste au rendu.
PourquoiLes balises title et les H1 affichent encore « OfficeRiders (ex Worklib) ». Ça divise le signal d'entité : Google et les moteurs IA ne savent pas quelle marque faire autorité. Consolider sur OfficeRiders renforce la marque en SEO comme dans les citations IA.
Critères d'acceptationAnalyse GSC initiale · consolidation d'entité Retirer « ex Worklib » des titres et H1 Correctifs www. à pousser dès que possible Moyenne [ROA-B9] Retirer « ex Worklib » des titres et H1 Panier: B · Correctifs www. à pousser dès que possible Criticité: Moyenne Produit cible: Plateforme Source: Analyse GSC initiale · consolidation d'entité ## Description Supprimer toute mention « ex Worklib » / « (ex Worklib) » dans les <title>, les H1 et les métadonnées générées par les templates. Vérifier qu'aucune chaîne legacy ne subsiste au rendu. ## Pourquoi Les balises title et les H1 affichent encore « OfficeRiders (ex Worklib) ». Ça divise le signal d'entité : Google et les moteurs IA ne savent pas quelle marque faire autorité. Consolider sur OfficeRiders renforce la marque en SEO comme dans les citations IA. ## Critères d'acceptation - [ ] Aucune occurrence de « Worklib » dans les <title> et H1 des pages servies - [ ] Métadonnées (og:title, etc.) cohérentes sur « OfficeRiders » - [ ] Vérifié sur un échantillon de pages clés (home, devenir-hôte, pages locales)- Aucune occurrence de « Worklib » dans les <title> et H1 des pages servies
- Métadonnées (og:title, etc.) cohérentes sur « OfficeRiders »
- Vérifié sur un échantillon de pages clés (home, devenir-hôte, pages locales)
- Description
À revérifier post-migration : si les welcome pages survivent côté www., corriger le baseURL.
Pourquoiapp./welcome, app./en/welcome, app./nl/welcome déclarent leur baseURL en localhost. Bug de build hérité de Worklib. Sera résolu par la fusion (app. disparaît). À ne pas pousser maintenant.
Critères d'acceptation- Post-migration : aucune page welcome ne référence localhost
Données sources Canonicalisations accidentelles 5 lignes · table filtrable + CSVAudit Équipe Roalink ticket #3 Welcome pages app./welcome (localhost baseURL) À garder pour après la migration Moyenne [ROA-C1] Welcome pages app./welcome (localhost baseURL) Panier: C · À garder pour après la migration Criticité: Moyenne Produit cible: WebApp (Marketplace) Source: Audit Équipe Roalink ticket #3 ## Description À revérifier post-migration : si les welcome pages survivent côté www., corriger le baseURL. ## Pourquoi app./welcome, app./en/welcome, app./nl/welcome déclarent leur baseURL en localhost. Bug de build hérité de Worklib. Sera résolu par la fusion (app. disparaît). À ne pas pousser maintenant. ## Critères d'acceptation - [ ] Post-migration : aucune page welcome ne référence localhost - Description
Sera obsolète à la fusion. Post-migration, vérifier que A2 couvre ce cas et qu'aucun sitemap ne subsiste sur app.*.
Pourquoiapp./sitemap.xml retourne 404. Sera obsolète à la fusion (un seul sitemap sur www. post-migration, cf. ticket A2).
Critères d'acceptationAudit Équipe Roalink ticket #7 Sitemap app.officeriders.com (404) À garder pour après la migration Moyenne [ROA-C2] Sitemap app.officeriders.com (404) Panier: C · À garder pour après la migration Criticité: Moyenne Produit cible: WebApp (Marketplace) Source: Audit Équipe Roalink ticket #7 ## Description Sera obsolète à la fusion. Post-migration, vérifier que A2 couvre ce cas et qu'aucun sitemap ne subsiste sur app.*. ## Pourquoi app./sitemap.xml retourne 404. Sera obsolète à la fusion (un seul sitemap sur www. post-migration, cf. ticket A2). ## Critères d'acceptation - [ ] Post-migration : A2 livré, aucun sitemap servi sur app.officeriders.com- Post-migration : A2 livré, aucun sitemap servi sur app.officeriders.com
- Description
Sera obsolète à la fusion. Post-migration, vérifier que A3 couvre ce cas et qu'aucun robots.txt résiduel ne subsiste sur app.*.
Pourquoiapp. n'a pas de robots.txt. Obsolète à la fusion (cf. ticket A3).
Critères d'acceptationAudit Équipe Roalink ticket #8 Robots.txt manquant sur app. À garder pour après la migration Moyenne [ROA-C3] Robots.txt manquant sur app. Panier: C · À garder pour après la migration Criticité: Moyenne Produit cible: WebApp (Marketplace) Source: Audit Équipe Roalink ticket #8 ## Description Sera obsolète à la fusion. Post-migration, vérifier que A3 couvre ce cas et qu'aucun robots.txt résiduel ne subsiste sur app.*. ## Pourquoi app. n'a pas de robots.txt. Obsolète à la fusion (cf. ticket A3). ## Critères d'acceptation - [ ] Post-migration : A3 livré, aucun robots.txt servi sur app.officeriders.com- Post-migration : A3 livré, aucun robots.txt servi sur app.officeriders.com
- Description
Post-migration : si le pattern persiste côté www., 404 (ou redirect vers le slug canonique) quand le slug ne matche pas la route canonique.
PourquoiLa route accepte n'importe quel slug derrière l'ID, ce qui ouvre une expansion infinie d'URLs servies en 200. Le canonical limite les dégâts mais c'est un risque crawl budget. À revérifier sur le pattern post-fusion.
Critères d'acceptationAudit Équipe Roalink ticket #6 Routing par ID app./building/{id}-* accepte n'importe quel slug À garder pour après la migration Haute [ROA-C4] Routing par ID app./building/{id}-* accepte n'importe quel slug Panier: C · À garder pour après la migration Criticité: Haute Produit cible: WebApp (Marketplace) Source: Audit Équipe Roalink ticket #6 ## Description Post-migration : si le pattern persiste côté www., 404 (ou redirect vers le slug canonique) quand le slug ne matche pas la route canonique. ## Pourquoi La route accepte n'importe quel slug derrière l'ID, ce qui ouvre une expansion infinie d'URLs servies en 200. Le canonical limite les dégâts mais c'est un risque crawl budget. À revérifier sur le pattern post-fusion. ## Critères d'acceptation - [ ] Post-migration : les pages ne résolvent que sur leur slug canonique - [ ] Slugs non canoniques → 301 vers canonique ou 404- Post-migration : les pages ne résolvent que sur leur slug canonique
- Slugs non canoniques → 301 vers canonique ou 404
- Description
Post-migration : ajouter x-default sur les pages building si le pattern persiste.
PourquoiPas pénalisant en FR-FR mais bon à avoir. À revérifier post-migration.
Critères d'acceptation- Post-migration : x-default présent sur toutes les pages building
Données sources x-default manquant sur app. 27 lignes · table filtrable + CSVAudit Équipe Roalink ticket #4 x-default hreflang manquant sur app./building/... À garder pour après la migration Basse [ROA-C5] x-default hreflang manquant sur app./building/... Panier: C · À garder pour après la migration Criticité: Basse Produit cible: WebApp (Marketplace) Source: Audit Équipe Roalink ticket #4 ## Description Post-migration : ajouter x-default sur les pages building si le pattern persiste. ## Pourquoi Pas pénalisant en FR-FR mais bon à avoir. À revérifier post-migration. ## Critères d'acceptation - [ ] Post-migration : x-default présent sur toutes les pages building - Description
Post-migration : ajouter le hreflang fr sur toutes les pages explore qui survivent.
PourquoiLes pages explore ne déclarent que x-default, pas de hreflang fr. À grande échelle. À revérifier post-migration : si les URLs survivent côté www., corriger.
Critères d'acceptation- Post-migration : 100 % des pages explore ont un hreflang fr cohérent
Données sources Hreflang FR manquant sur app. 601 lignes · table filtrable + CSVAudit Équipe Roalink ticket #5 Hreflang FR manquant sur 601 URLs app./explore/ À garder pour après la migration Haute [ROA-C6] Hreflang FR manquant sur 601 URLs app./explore/ Panier: C · À garder pour après la migration Criticité: Haute Produit cible: WebApp (Marketplace) Source: Audit Équipe Roalink ticket #5 ## Description Post-migration : ajouter le hreflang fr sur toutes les pages explore qui survivent. ## Pourquoi Les pages explore ne déclarent que x-default, pas de hreflang fr. À grande échelle. À revérifier post-migration : si les URLs survivent côté www., corriger. ## Critères d'acceptation - [ ] Post-migration : 100 % des pages explore ont un hreflang fr cohérent - Description
Corriger la génération de ces liens (variable d'URL non initialisée) pour qu'ils pointent vers les bonnes pages. À revérifier post-migration : si les pages concernées survivent côté www., appliquer le correctif.
PourquoiDes liens du footer (privacy / terms sur les welcome pages app.) contiennent « undefined » dans l'URL et renvoient 404. Variable JS non initialisée au rendu : le défaut apparaît sur chaque page qui affiche ce footer.
Critères d'acceptationAudit Équipe Roalink ticket #11 Liens avec « undefined » dans le slug (footer) À garder pour après la migration Moyenne [ROA-C7] Liens avec « undefined » dans le slug (footer) Panier: C · À garder pour après la migration Criticité: Moyenne Produit cible: WebApp (Marketplace) Source: Audit Équipe Roalink ticket #11 ## Description Corriger la génération de ces liens (variable d'URL non initialisée) pour qu'ils pointent vers les bonnes pages. À revérifier post-migration : si les pages concernées survivent côté www., appliquer le correctif. ## Pourquoi Des liens du footer (privacy / terms sur les welcome pages app.) contiennent « undefined » dans l'URL et renvoient 404. Variable JS non initialisée au rendu : le défaut apparaît sur chaque page qui affiche ce footer. ## Critères d'acceptation - [ ] Aucun lien contenant « undefined » dans le slug sur le site servi - [ ] Les liens footer privacy / terms pointent vers des URLs 200- Aucun lien contenant « undefined » dans le slug sur le site servi
- Les liens footer privacy / terms pointent vers des URLs 200
- Description
Baliser espaces (workspace), avis, tarifs avec Schema.org. Couverture progressive.
PourquoiEnrichit l'apparence dans les résultats et aide Google + moteurs IA à comprendre le contenu. À programmer une fois la base technique stable.
Critères d'acceptationBloc B (proposition Équipe Roalink) Données structurées Schema.org sur pages espace Améliorations post stabilisation Moyenne [ROA-D1] Données structurées Schema.org sur pages espace Panier: D · Améliorations post stabilisation Criticité: Moyenne Produit cible: WebApp (Marketplace) Source: Bloc B (proposition Équipe Roalink) ## Description Baliser espaces (workspace), avis, tarifs avec Schema.org. Couverture progressive. ## Pourquoi Enrichit l'apparence dans les résultats et aide Google + moteurs IA à comprendre le contenu. À programmer une fois la base technique stable. ## Critères d'acceptation - [ ] Schema validé via Rich Results Test - [ ] Couverture progressive sur les pages workspace- Schema validé via Rich Results Test
- Couverture progressive sur les pages workspace
- Description
Audit page par page. Pour les zones sans dispo : afficher des espaces à proximité plutôt qu'une page vide.
PourquoiUne marketplace n'est indexée que si chaque page a une vraie valeur. Traiter les pages fines (peu de contenu), le contenu dupliqué entre pages similaires, et les zones où il n'y a pas de stock.
Critères d'acceptationBloc B (proposition Équipe Roalink) Architecture SEO marketplace : pages fines, contenu dupliqué, zones sans disponibilité Améliorations post stabilisation Moyenne [ROA-D2] Architecture SEO marketplace : pages fines, contenu dupliqué, zones sans disponibilité Panier: D · Améliorations post stabilisation Criticité: Moyenne Produit cible: WebApp (Marketplace) Source: Bloc B (proposition Équipe Roalink) ## Description Audit page par page. Pour les zones sans dispo : afficher des espaces à proximité plutôt qu'une page vide. ## Pourquoi Une marketplace n'est indexée que si chaque page a une vraie valeur. Traiter les pages fines (peu de contenu), le contenu dupliqué entre pages similaires, et les zones où il n'y a pas de stock. ## Critères d'acceptation - [ ] À définir au démarrage Bloc D : seuils 'page fine', règles de cluster, fallback zones sans stock- À définir au démarrage Bloc D : seuils 'page fine', règles de cluster, fallback zones sans stock
- Description
Audit du maillage actuel, propositions de liens, implémentation.
PourquoiDistribuer l'autorité vers les pages stratégiques. Cluster topique.
Critères d'acceptationProposition Équipe Roalink (internal links) Maillage interne et autorité topique Améliorations post stabilisation Moyenne [ROA-D3] Maillage interne et autorité topique Panier: D · Améliorations post stabilisation Criticité: Moyenne Produit cible: Plateforme Source: Proposition Équipe Roalink (internal links) ## Description Audit du maillage actuel, propositions de liens, implémentation. ## Pourquoi Distribuer l'autorité vers les pages stratégiques. Cluster topique. ## Critères d'acceptation - [ ] À définir au démarrage Bloc D : pages sources, cibles de maillage, KPI pages stratégiques- À définir au démarrage Bloc D : pages sources, cibles de maillage, KPI pages stratégiques
- Description
Audit performance. Optimisations ciblées.
PourquoiVitesse = signal de qualité et de conversion.
Critères d'acceptationProposition Équipe Roalink (performance fine tuning) Performance et Core Web Vitals Améliorations post stabilisation Moyenne [ROA-D4] Performance et Core Web Vitals Panier: D · Améliorations post stabilisation Criticité: Moyenne Produit cible: Plateforme Source: Proposition Équipe Roalink (performance fine tuning) ## Description Audit performance. Optimisations ciblées. ## Pourquoi Vitesse = signal de qualité et de conversion. ## Critères d'acceptation - [ ] LCP, FID/INP, CLS dans les seuils 'good' sur 90 % des pages stratégiques- LCP, FID/INP, CLS dans les seuils 'good' sur 90 % des pages stratégiques
- Description
Exploration, cadrage, POC. À programmer une fois la base stable.
PourquoiRendre le site consommable par les agents IA. Web MCP comme standard émergent.
Critères d'acceptationProposition Équipe Roalink (forward-looking) Préparation IA / Web MCP Améliorations post stabilisation Basse [ROA-D5] Préparation IA / Web MCP Panier: D · Améliorations post stabilisation Criticité: Basse Produit cible: Plateforme Source: Proposition Équipe Roalink (forward-looking) ## Description Exploration, cadrage, POC. À programmer une fois la base stable. ## Pourquoi Rendre le site consommable par les agents IA. Web MCP comme standard émergent. ## Critères d'acceptation - [ ] À définir au cadrage POC : compatibilité llms.txt, format Web MCP, scope agents IA visés- À définir au cadrage POC : compatibilité llms.txt, format Web MCP, scope agents IA visés