SEO technique Symfony : les 15 optimisations qui changent tout

Symfony est un excellent framework pour bâtir un SaaS ou un site à fort contenu, mais il ne fait pas le SEO technique à ta place. J'ai travaillé sur une trentaine de projets Symfony depuis 2014, et je vois toujours les mêmes lacunes côté SEO : sitemaps absents, balises canoniques incohérentes, schema.org inexistant, rendu JavaScript opaque pour les robots. Cet article liste 15 optimisations concrètes, classées par impact, avec les bundles et patterns Symfony correspondants.

1 à 4 : les fondations structurelles

Les URLs doivent refléter la hiérarchie du site, utiliser des tirets, pas d'accents, pas de paramètres inutiles. Dans Symfony, le composant Routing facilite cela avec les attributs PHP 8. Je crée systématiquement une route nommée par entité métier, avec un paramètre {slug} plutôt qu'{id}. Pour générer ces slugs, j'utilise par défaut le Slugger natif Symfony (Symfony\Component\String\Slugger\AsciiSlugger) — pas de dépendance supplémentaire à maintenir.

La canonical est à produire dans le layout Twig de base, avec une logique simple : URL absolue, sans paramètre de tracking, jamais vide. J'utilise un service CanonicalResolver injecté dans le layout qui calcule l'URL canonique à partir de la requête courante.

Le sitemap XML s'automatise très bien. Sur les projets que je maintiens, j'écris souvent une commande console maison qui balaye les entités publiées et génère un fichier statique : zéro dépendance, code complètement sous contrôle. Pour des projets plus volumineux ou avec besoins d'événements personnalisés, le bundle presta/sitemap-bundle est une excellente alternative qui expose une route dynamique.

Le robots.txt doit exister, et interdire explicitement les zones administratives. Je le sers via une route Symfony qui lit un template Twig, pour pouvoir le faire varier par environnement (préproduction en Disallow: /, production en Allow: / ciblé).

5 et 6 : métadonnées et données structurées

Chaque page doit avoir un title et une description uniques. Je pose un bloc Twig dans le layout, et chaque template le surcharge. Pour les pages générées dynamiquement (fiches produit, articles), les métadonnées viennent de la base, avec un fallback si l'auteur a oublié.

Schema.org en JSON-LD est un levier sous-exploité. Un bon balisage Article, Organization, BreadcrumbList, FAQPage, LocalBusiness, HowTo déclenche des rich snippets dans les résultats Google. D'expérience, un article de blog correctement balisé obtient un CTR sensiblement supérieur sur ses requêtes. Côté outillage, j'utilise selon les projets soit la bibliothèque spatie/schema-org appelée depuis un TwigExtension, soit du JSON-LD écrit directement dans les templates Twig (plus de contrôle, moins de dépendance).

7 à 9 : redirections, pagination, multilingue

Une migration de site sans table de redirection 301 est la meilleure façon de détruire son SEO. Je stocke les redirections dans une entité Doctrine, et j'écris un RequestEventSubscriber qui intercepte les 404 et redirige au besoin. Pour les gros volumes, je les externalise au niveau Nginx pour éviter de charger la stack PHP.

La pagination mérite une attention particulière. Depuis 2019, Google ne suit plus rel="next/prev" mais les liens internes restent critiques. J'évite la pagination infinie pure pour les listes longues : je préfère une pagination classique bien balisée, avec pages numérotées et URLs indexables.

Le hreflang est obligatoire sur un site multilingue. Erreur fréquente : déclarer fr et en en oubliant x-default. Résultat : Google choisit mal la version à servir. Je génère les balises via un service dédié qui parcourt les langues disponibles pour la route courante.

10 à 12 : performance servie

Le cache HTTP Symfony (reverse proxy natif ou Varnish) est une arme redoutable pour le SEO. Une page mise en cache sert en quelques dizaines de millisecondes, ce qui libère le TTFB et améliore le LCP. Les ESI permettent de mettre en cache la page entière tout en rafraîchissant un fragment personnalisé (le header utilisateur, par exemple).

Brotli au niveau Nginx économise 15 à 25 % de poids par rapport à gzip. Sur un HTML de 80 Ko, c'est directement 15 Ko en moins à transférer.

Le srcset sur les images sert la bonne résolution selon le device. Sur mobile 4G, c'est la différence entre un LCP de 1,5 s et un LCP de 3,5 s. liip/imagine-bundle gère ça correctement avec une config de filtres multi-tailles.

13 à 15 : cerise sur le gâteau

Open Graph et Twitter Cards améliorent l'affichage des partages sociaux, ce qui fait cliquer. Un fil d'Ariane structuré avec BreadcrumbList apparaît dans les résultats Google à la place de l'URL brute. Enfin, brancher Google Search Console et consulter les rapports hebdomadaires permet de détecter rapidement les erreurs d'exploration et les opportunités.

Ma philosophie en matière de bundles : si un composant natif Symfony existe, je le prends ; sinon je cherche un bundle communautaire éprouvé ; sinon je code maison. Voici les briques que je mobilise au quotidien sur les projets SEO.

• Génération du sitemap : commande console maison (lecture des entités publiées, écriture d'un fichier statique). Alternative selon les projets : presta/sitemap-bundle pour une route dynamique avec événements personnalisés.
• Slugs propres et stables : Symfony\Component\String\Slugger\AsciiSlugger natif. Aucune dépendance supplémentaire à maintenir.
• Images responsives et filtres multi-tailles : liip/imagine-bundle.
• Génération JSON-LD côté PHP : spatie/schema-org appelé depuis un TwigExtension sur les projets complexes ; sinon écriture directe dans les templates Twig pour rester sans dépendance.
• Cache HTTP et ESI : composant HttpCache natif Symfony, ou Varnish en reverse proxy pour les forts trafics.