Agence Blog Marketplace : construire un site éditorial headless pensé pour le SEO

1. Un média marketplace piloté depuis le CMS Dawap

Séparer la production éditoriale de la restitution publique

Le média devait publier des contenus spécialisés sur la création, la performance, les vendeurs et les technologies marketplace. Son rôle ne consistait pas seulement à empiler des articles. Il devait organiser ces contenus par catégories, donner une entrée lisible à chaque sujet et orienter le lecteur vers l’expertise Dawap correspondant à son besoin.

Les contenus ne sont pas stockés dans l’application publique. Le frontend appelle les routes du CMS Dawap avec l’identifiant du blog et une authentification porteuse. Les réponses JSON fournissent les catégories, les articles, les médias, les éléments de sommaire, les informations SEO et les liens commerciaux. Le site conserve ainsi une présentation propre sans recréer un second outil d’administration.

Cette architecture impose une règle produit importante : la qualité publique dépend du contrat entre CMS et frontend. Un titre SEO vide, un slug modifié, un média absent ou une catégorie inactive ne sont pas seulement des problèmes de contenu ; ils changent directement la page rendue. Les contrôleurs et les templates multiplient donc les contrôles de présence autour des images, des destinations commerciales et des réponses non trouvées.

Le résultat est un site éditorial spécialisé, relié au système de contenu de Dawap mais déployable comme une application distincte. Cette autonomie permet d’adapter ses gabarits, son domaine, son cache et son infrastructure au besoin du média sans imposer la même trajectoire au back-office qui alimente ses contenus.

2. Du premier écran au maintien des URLs sur 519 jours

Une trajectoire documentée du 10 mai 2023 au 9 octobre 2024

Le 10 mai 2023 pose le socle Symfony 6.1, les routes publiques et les premiers gabarits. L’accueil, la catégorie et l’article sont construits autour des réponses du CMS. Dès les premiers jours arrivent les ancres d’article, la commande de sitemap et les champs SEO des articles et catégories. Le référencement est donc intégré à la construction du produit, pas traité comme une campagne séparée.

La fin mai et le mois de juin renforcent l’exécution. Les lectures du CMS passent par le cache applicatif Redis, les vues sont optimisées, les ressources locales sont rationalisées et le comportement mobile est ajusté. Trois commandes permettent ensuite de rappeler l’accueil, les catégories et les articles avec un signal de rafraîchissement. Le cron complète ce dispositif en donnant une cadence au cache et au sitemap.

En juillet, le produit gagne des fonctions éditoriales structurantes : pagination des catégories, recherche textuelle, canonicals paginées, descriptions limitées à la première page, chapeau d’article et contenus complémentaires. Le 28 octobre 2023, le média quitte son sous-domaine Dawap pour agence-blog-marketplace.fr. Les URLs absolues, les serveurs Nginx, le sitemap et les tâches d’exploitation suivent cette bascule.

L’année 2024 ne constitue pas une nouvelle refonte fonctionnelle. Elle traite la mémoire du site : des URLs devenues introuvables après migration reçoivent des règles Nginx dédiées, puis le fichier robots et la déclaration du sitemap sont repris. Le dernier jalon, le 9 octobre 2024, ferme cette version par une correction de l’accueil. Cette chronologie raconte une construction, une mise en autonomie puis une phase de consolidation.

3. Séparer le CMS du frontend pour donner une identité propre au média

Un site autonome qui consomme les contenus au lieu de les dupliquer

Le choix structurant est visible dans l’absence d’entités éditoriales locales. L’application possède des briques partagées issues de son squelette technique, mais aucun modèle métier de catégorie ou d’article n’alimente ses pages publiques. Les contrôleurs construisent les URLs du CMS à partir de trois paramètres d’environnement : l’adresse de l’API, l’identifiant du blog et le jeton utilisé côté serveur.

Cette organisation évite une double saisie. Le titre, le chapeau, les descriptions SEO, les médias, le sommaire et les destinations de liens restent administrés dans un même système de contenu. Le frontend reçoit une représentation prête à restituer, puis garde la maîtrise de l’HTML, des URLs publiques, des styles, des images chargées et des appels vers les pages Dawap.

La séparation permet aussi de faire évoluer l’expérience sans modifier le CMS. Le site possède ses propres templates Twig pour l’accueil, la catégorie, l’article et la carte d’article. Les feuilles de style associées peuvent évoluer indépendamment du back-office. Inversement, le CMS peut enrichir un article avec un nouveau chapeau ou une nouvelle image mobile dès lors que le contrat JSON conserve les champs attendus.

Ce découplage ressemble à une architecture headless, avec une nuance importante : le frontend reste fortement lié à la forme actuelle des réponses. Il lit directement des clés comme collection.data, pagination_search, _rtoc_collection ou _rmedia_main. La séparation des déploiements existe ; la stabilité du contrat doit encore être protégée par des tests dédiés.

4. Trois parcours publics suffisent à couvrir le cycle de lecture

Découvrir, approfondir une catégorie, puis lire un article

Le frontend expose trois contrôleurs publics. La racine compose l’accueil. Une URL à un segment ouvre une catégorie. Une URL à deux segments ouvre un article dans le contexte de sa catégorie. Cette surface réduite donne une hiérarchie facile à comprendre : le lecteur part du média, resserre son intérêt, puis arrive sur un contenu précis.

La catégorie est toujours résolue avant l’article. Le contrôleur de détail appelle d’abord la route de catégorie du CMS et refuse le parcours lorsque celle-ci ne répond pas avec un statut valide. Il charge ensuite l’article par son slug, puis une collection de contenus « frères ». La catégorie n’est donc pas un simple décor dans l’URL ; elle intervient dans la navigation, le titre de contexte et les liens complémentaires.

La prévisualisation possède un chemin séparé. Lorsqu’un previewToken est présent, la lecture de l’article transmet ce jeton au CMS et utilise une clé de cache distincte. Les liens d’accueil et de catégorie conservent également ce paramètre lorsqu’ils mènent vers les articles. Un contenu futur peut ainsi être relu dans le frontend public sans remplacer la version normalement publiée.

La contrepartie de routes aussi courtes tient dans leur ordre et leur validation. Le contrôleur de catégorie accepte tout slug de premier niveau ; celui d’article accepte tout couple de segments. Le bon fonctionnement dépend donc de la réponse du CMS et des exceptions 404 construites côté frontend. Cette simplicité sert la lisibilité des URLs, mais appelle des tests de priorité si de nouvelles pages racines sont ajoutées.

5. Mettre Redis entre le lecteur et le CMS distant

Réutiliser les réponses sans figer la publication

Chaque parcours interroge le CMS avec le composant HTTP de Symfony. Les catégories de l’accueil, les articles d’une catégorie, le détail d’une catégorie, les pages d’articles et leurs contenus associés disposent de clés de cache distinctes. Redis est déclaré comme adaptateur du cache applicatif, ce qui permet aux processus PHP de partager les mêmes réponses plutôt que de répéter le même appel distant.

Les clés reprennent l’objet demandé. L’accueil utilise une entrée pour les catégories puis une entrée par identifiant de catégorie pour ses articles. La liste d’une catégorie inclut le slug et le numéro de page. L’article utilise son slug, tandis que les contenus complémentaires ajoutent un suffixe spécifique. La prévisualisation possède elle aussi sa propre entrée afin de ne pas contaminer le contenu public.

La recherche suit une règle différente. Le texte saisi est transformé en slug pour construire la clé et la réponse expire après vingt-quatre heures. Ce choix évite les caractères instables dans le cache tout en donnant une durée explicite à une requête potentiellement unique. La requête envoyée au CMS conserve le texte original et le contexte de catégorie.

Le cache protège la lecture courante, mais il ne constitue pas une copie locale durable du contenu. Si une entrée doit être recalculée et que l’API échoue, les contrôleurs interceptent largement les exceptions et retournent une valeur vide. La catégorie et l’article deviennent alors des 404 ; l’accueil ne possède pas la même garde avant de parcourir sa réponse. La prochaine version doit distinguer indisponibilité amont, contenu absent et donnée invalide.

6. Composer l’accueil à partir des catégories réellement publiables

Faire du CMS la source de l’ordre éditorial

L’accueil ne demande pas toutes les catégories. Son appel précise trois filtres : la catégorie doit posséder des articles, une position et un statut actif. Le frontend reçoit ainsi une sélection déjà gouvernée par le CMS. Pour chaque catégorie retenue, un second appel récupère ses articles et la vue n’affiche que les trois premiers sous son titre.

Cette composition donne à la page une logique de vitrine. Chaque bloc présente une catégorie, le nombre total d’articles publié transmis par le CMS, un lien vers la liste complète et trois cartes récentes. Le visiteur peut comprendre les territoires éditoriaux sans parcourir une grille indifférenciée de contenus.

Les cartes utilisent le slug de catégorie et le slug d’article pour former leur lien. Elles affichent la vignette lorsqu’elle existe, un titre, une date, un auteur fixe et, lorsqu’il est fourni, le chapeau. Les images déclarent leurs dimensions et le chargement différé, ce qui limite les déplacements de mise en page et évite de charger immédiatement tous les médias sous la ligne de flottaison.

Le choix de faire un appel par catégorie favorise une composition fine, mais augmente le nombre de dépendances lors d’un recalcul complet. Redis absorbe les visites ordinaires ; un préchauffage de l’accueil peut néanmoins déclencher plusieurs lectures du CMS. Une évolution naturelle consisterait à exposer un agrégat d’accueil versionné par l’API ou à paralléliser explicitement les appels avec une politique de repli par bloc.

7. Faire de la catégorie une vraie page de recherche éditoriale

Cinquante articles par page, une recherche textuelle et des URLs paginées

La page de catégorie charge au maximum cinquante articles par page. Le numéro demandé est intégré à la requête API et à la clé Redis. Le template utilise le nombre total de pages renvoyé par le CMS pour construire la navigation. La première page conserve une URL courte ; les suivantes ajoutent le paramètre page.

Les balises suivent cette structure. Une page supérieure à un reçoit une canonical contenant son numéro, un lien prev vers la page précédente et, lorsqu’elle existe, un lien next. La première page pointe vers son URL sans paramètre et annonce la page deux. Les descriptions courte et longue de la catégorie ne sont affichées que sur cette première page afin de ne pas répéter le même bloc éditorial sur toute la série.

Une recherche peut être lancée depuis le même écran avec le paramètre s. Le contrôleur transmet le texte et l’identifiant de catégorie au CMS, puis affiche la collection retournée. La navigation par pages disparaît pendant cette recherche. Le besoin est volontairement simple : retrouver des articles dans le périmètre courant, pas construire un moteur global avec facettes et suggestions.

Cette simplicité comporte deux limites visibles. La recherche n’ajoute pas de pagination dédiée dans le frontend et sa canonical ne conserve pas le terme saisi. Par ailleurs, la première page annonce systématiquement une page suivante à partir du template, même lorsqu’une seule page existe. Ces cas doivent être corrigés avant d’étendre l’indexation à des volumes éditoriaux beaucoup plus importants.

8. Transformer chaque article du CMS en page SEO complète

Métadonnées, canonical, partage social, sommaire et données structurées

Le détail reprend le titre SEO et la description SEO fournis par le CMS dans les balises principales. La canonical est reconstruite sur le domaine public à partir des deux slugs. Les blocs Twitter et Open Graph reçoivent le titre, la description, l’image principale lorsqu’elle existe, l’URL courante et le type article. Le contenu éditorial pilote donc les signaux sans demander une modification de template à chaque publication.

Le corps de l’article n’est pas un champ HTML unique posé sous un titre. Le CMS renvoie une collection de sommaire dont chaque élément possède un identifiant, une numérotation hiérarchique, un nom et un contenu. Le template réutilise l’identifiant pour l’ancre, affiche le sommaire en haut de page puis déroule chaque section avec son niveau de lecture. Cette structure rend les contenus longs navigables sans perdre leur organisation éditoriale.

Une donnée structurée Article est également produite. Elle reprend le titre SEO, la description, l’auteur, la date de publication et l’image principale. Ce balisage donne aux moteurs un objet éditorial identifiable. Dans cette version, il ne porte cependant pas de date de modification, d’entité éditrice détaillée ni de relation explicite vers la page principale : le socle existe, mais peut être aligné sur un schéma plus complet.

La page garde enfin la catégorie visible sous le titre, avec un lien de retour, et affiche la date publiée issue du CMS. Ce contexte évite que l’article ressemble à une page isolée. Pour une démarche comparable, la page données structurées JSON-LD permet de cadrer le contrat entre contenu, template et validation dans les outils des moteurs.

9. Relier la lecture éditoriale à la bonne expertise Dawap

Des liens commerciaux administrables plutôt qu’un CTA identique partout

Le header propose par défaut un lien vers le service de création de marketplace. Une catégorie ou un article peut toutefois remplacer cette destination lorsqu’il reçoit trois informations complètes du CMS : un identifiant, une URL et un texte de lien. Le même contrôle est appliqué au menu principal et au menu mobile.

Ce mécanisme transforme le maillage commercial en donnée éditoriale. Un article sur les connecteurs peut pointer vers une page d’intégration ; un contenu sur la création de plateforme peut conserver la page marketplace ; une catégorie orientée vendeurs peut utiliser une formulation propre à son intention. La décision ne demande pas une nouvelle condition codée pour chaque article.

Le détail charge aussi les articles apparentés depuis une route dédiée du CMS. Lorsqu’une réponse est disponible, le template affiche leurs vignettes, titres, dates et liens sous le contenu. Cette continuité aide le lecteur à approfondir un sujet avant de quitter le média. Elle renforce en même temps les relations internes entre articles d’une même famille.

Le dispositif reste gouverné depuis le CMS. Une destination résolue côté serveur, des liens vérifiés automatiquement et un marquage distinct entre lecture complémentaire et passage vers une page de service rendent ce maillage durable et mesurable.

10. Générer le sitemap depuis la même source que les pages

Parcourir articles et catégories sans maintenir une liste parallèle

La commande sitemap:generate commence par nettoyer le répertoire de sortie et fixe le domaine ainsi que le schéma depuis l’environnement. Elle ajoute la page d’accueil, puis parcourt les pages de résultats de l’API pour récupérer tous les articles rattachés à une catégorie active et tous les ensembles de catégories actives, positionnées et non vides.

Chaque article reçoit l’URL produite par sa catégorie et son slug. Chaque catégorie reçoit sa propre URL. La date updated_at renvoyée par le CMS devient le lastmod, tandis que la fréquence et la priorité sont déclarées dans le générateur. La fraîcheur du sitemap suit ainsi la donnée éditoriale au lieu de la date d’exécution de la commande.

Le générateur limite chaque fichier à mille URLs. Lorsqu’il atteint ce seuil ou la fin de la collection, il écrit un fichier numéroté, crée un nouvel ensemble puis produit à la fin un index qui référence chaque fragment. Le média peut donc augmenter son nombre d’articles sans dépasser la limite définie pour un document unique.

Le fichier robots publié sur le domaine annonce cet index et laisse les pages principales accessibles. Le système dépend cependant entièrement de la disponibilité et de la cohérence de l’API au moment du recalcul : il supprime les anciens fragments avant d’avoir terminé les nouveaux. Une génération atomique dans un répertoire temporaire, suivie d’un remplacement, protégerait mieux le sitemap servi en cas d’échec intermédiaire.

11. Donner une cadence au cache plutôt que d’attendre le premier lecteur

Trois commandes de rappel et quatre lignes de cron

Le projet contient trois commandes consacrées au cache public. cache:home:refresh rappelle la racine. cache:categories:refresh demande les catégories au CMS puis ouvre chacune de leurs URLs. cache:posts:refresh parcourt toutes les pages d’articles actifs et rappelle chaque détail. Toutes ajoutent ?cache=false à l’URL interne.

Les contrôleurs interprètent ce paramètre en passant une valeur de recalcul au composant de cache. L’objectif est de renouveler les réponses avant que le prochain visiteur ne supporte le coût de l’appel distant. Le dispositif ne duplique pas la logique de rendu dans une tâche : il exerce les mêmes contrôleurs et les mêmes templates que la navigation publique.

Le cron de production inscrit quatre cadences. Le sitemap est recalculé toutes les cinq minutes. L’accueil et les catégories sont rappelés toutes les heures. Les articles sont parcourus une fois par jour à dix-huit heures. Ces rythmes ne prétendent pas refléter chaque publication instantanément ; ils rendent explicite le compromis choisi entre fraîcheur et volume d’appels.

La mécanique reste perfectible. Le paramètre de rafraîchissement est compris directement par les contrôleurs publics et aucune restriction d’accès n’y apparaît. Les commandes n’examinent pas non plus le contenu des réponses rappelées. Une route interne signée, des verrous anti-concurrence, des métriques de succès et une invalidation déclenchée par webhook offriraient un fonctionnement plus sûr qu’un simple balayage périodique.

12. Passer d’un sous-domaine Dawap à une marque éditoriale autonome

Faire suivre configuration, canonicals, robots et URLs historiques

Le 28 octobre 2023, le site passe de agence-marketplace.dawap.fr à agence-blog-marketplace.fr. La modification traverse les fichiers Nginx, la composition de production, les tâches planifiées, le robots.txt et les canonicals des trois types de pages. Le serveur www redirige également vers la version sans préfixe en conservant le chemin demandé.

Cette bascule montre pourquoi un domaine ne doit jamais être traité comme une chaîne isolée dans un template. Il intervient dans les balises canoniques, les liens du sitemap, la configuration de certificat, les hôtes virtuels et les appels internes. Le projet a dû aligner tous ces points pour que le média soit cohérent sous sa nouvelle identité.

En octobre 2024, une seconde séquence traite les erreurs apparues après migration. La configuration Nginx finale contient soixante-douze blocs location = pour des chemins précis : anciennes catégories, articles tronqués, doublons de slugs ou URLs devenues sans destination. Ces règles évitent que les chemins concernés aboutissent directement au routeur puis à une 404.

La plupart de ces règles renvoient vers la page d’accueil, et non vers un contenu équivalent. C’est une protection technique minimale, pas une stratégie de migration optimale. La page migration et refonte SEO porte le prolongement naturel : inventorier les correspondances, rediriger vers la destination la plus proche et surveiller les anciennes URLs tant que les moteurs les explorent.

13. Travailler la performance dans le rendu, pas dans un score déclaré

Cache, ressources locales, images différées et variante mobile

Les évolutions de mai et juin 2023 portent concrètement sur le frontend. Les polices et styles utiles sont intégrés au projet, les scripts principaux sont chargés avec defer, les cartes d’articles déclarent une taille d’image et activent le chargement différé. Nginx attribue une durée de cache d’un an aux images, polices, CSS, JavaScript et vidéos servis comme fichiers statiques.

La page d’article utilise MobileDetect côté serveur. Lorsqu’un visiteur est identifié comme mobile et que le CMS fournit un média principal mobile, cette variante est choisie ; sinon l’image principale sert de repli. Le choix permet de donner au CMS la responsabilité de produire une ressource adaptée tout en évitant une image vide lorsque seule la version générale existe.

Redis agit sur un autre coût : le temps et la disponibilité de l’API de contenu. En conservant les catégories et articles déjà lus, le frontend réduit le nombre de requêtes nécessaires pour une visite ordinaire. Le cache statique Nginx, le chargement différé et le cache de données ne résolvent pas le même problème ; leur combinaison couvre réseau, médias et dépendance applicative.

Cache, ressources locales, dimensions d’images et chargement différé constituent des leviers observables. L’étape suivante consiste à leur associer des budgets, des mesures terrain et des alertes de régression grâce à l’accompagnement Performance et Core Web Vitals.

14. Construire des images pour deux lignes de code sans confondre packaging et qualité

Une CI de publication à compléter par une véritable barrière de tests

La configuration GitLab CI possède deux étapes : build et push. Quatre jobs construisent les variantes PHP et Nginx destinées aux lignes de développement et de production. Deux jobs supplémentaires récupèrent les images PHP intermédiaires, les renomment avec le tag de branche puis les publient dans le registre. Les jobs s’exécutent sur main et develop.

Les images de production embarquent PHP 8.1, les dépendances Composer, Redis, les extensions nécessaires et les fichiers de cron. L’image Nginx embarque les ressources publiques ainsi que la configuration de routage. La composition de production relie PHP, Nginx, Redis et les volumes de sitemap. Ces fichiers documentent un packaging ciblé ; ils ne prouvent pas à eux seuls une bascule ou une disponibilité continue.

La chaîne de livraison construit les images, mais elle doit encore intégrer une barrière de tests sur le contrat API, le rendu Twig, les canonicals et le générateur de sitemap. Le socle PHPUnit présent dans les dépendances permet d’ajouter ces scénarios sans redessiner toute l’architecture de livraison.

Les paramètres sensibles sont injectés par des variables protégées ou un gestionnaire d’accès propre à chaque environnement. Cette discipline complète les tests et les images reproductibles dans la qualité de livraison.

15. Ce que cette architecture change concrètement

Des bénéfices observables pour l’éditorial, la lecture, le référencement et l’exploitation

Le bilan opérationnel tient aux capacités livrées : une publication centralisée, trois parcours publics, un cache partagé, un ensemble SEO cohérent, un sitemap dynamique et une migration de domaine traitée dans l’infrastructure. Ces éléments donnent à l’équipe un média administrable et une base claire pour suivre ensuite audience, indexation et performance.

16. Les garanties à renforcer pour faire durer le média

Distinguer ce que le produit fait, ce qu’il tolère et ce qu’il ne mesure pas

La première frontière concerne la dépendance au CMS. Le frontend ne possède pas de contenu de secours structuré et intercepte les erreurs de façon très large. Une indisponibilité réseau, une réponse invalide et un contenu absent peuvent donc produire la même valeur nulle. L’article et la catégorie deviennent des 404 ; l’accueil peut échouer plus brutalement lorsqu’il tente de parcourir une réponse manquante.

La deuxième concerne l’indexation. Le sitemap suit correctement les objets publiables et leurs dates, mais sa génération efface les fichiers existants avant d’avoir validé le nouveau lot. Les canonicals paginées existent, tandis que la recherche et le lien next de première page demandent encore des règles plus fines. Les soixante-douze redirections protègent des chemins, mais leur destination générique ne restitue pas l’intention originale.

La troisième concerne la qualité logicielle. Les tests de contrat, de cache, de statuts d’erreur, de métadonnées et de validité XML constituent la suite naturelle de la chaîne CI qui construit déjà les images applicatives.

La quatrième concerne la mesure. Les optimisations d’accessibilité et de performance peuvent être reliées à des relevés avant/après afin de guider les décisions suivantes sur des signaux terrain.

17. Cinq paliers pour transformer le socle en média durablement observable

Sécuriser le contrat, la publication, les secrets, les migrations et la mesure

Le premier palier est contractuel. Des fixtures de réponses CMS doivent couvrir catégorie, liste paginée, article, prévisualisation, médias absents et contenus complémentaires. Les tests peuvent alors vérifier le rendu, les 404 légitimes et les erreurs amont sans appeler le service réel. Un schéma versionné éviterait qu’un changement de clé casse silencieusement le frontend.

Le deuxième est opérationnel. Un webhook de publication peut invalider uniquement la catégorie, l’article, l’accueil et le fragment de sitemap concernés. Le balayage planifié reste un filet de rattrapage, mais il ne porte plus seul la fraîcheur. Chaque tâche doit publier durée, nombre de pages rappelées, erreurs et dernier succès dans un outil de supervision.

Le troisième est sécuritaire. Les accès sont injectés par environnement, stockés dans un gestionnaire adapté et limités au strict périmètre du blog. Les images de base et les dépendances suivent également une politique de mise à jour. Le quatrième est SEO : rendre les redirections sémantiques, corriger les cas de pagination et enrichir le JSON-LD avec les relations éditoriales pertinentes.

Le cinquième est la mesure. Un tableau de bord peut suivre indexation, clics, pages actives, erreurs de sitemap, disponibilité du CMS, succès des préchauffages et Core Web Vitals réels. Chaque indicateur doit relier un événement technique à une décision. Cette discipline prolonge à la fois le monitoring et la non-régression et l’intégration API de CMS.