Un scraper Python orienté SEO est un script qui récupère le code HTML d’une page web, en isole les balises structurantes (titres, méta-descriptions, paragraphes) et en extrait les termes récurrents pour alimenter une analyse de contenu. La brique de base repose sur une requête HTTP suivie d’un parsing du DOM, mais l’intérêt réside dans ce qu’on fait des données une fois collectées.
Sélecteurs CSS et XPath : cibler les balises SEO utiles en Python
La plupart des concurrents décrivent l’installation de Beautiful Soup ou de Scrapy. Le point rarement abordé concerne le choix du sélecteur lui-même et son impact sur la maintenabilité du scraper.
A voir aussi : Stratégie SEO : comprendre ses enjeux et applications
Un sélecteur CSS comme h1, h2, h3 suffit pour extraire la hiérarchie de titres d’une page. En revanche, récupérer le contenu principal (et non les barres latérales, les footers ou les menus) demande un ciblage plus fin. XPath permet de filtrer par position dans l’arbre DOM, par exemple en ne gardant que les paragraphes contenus dans une balise article ou main.
Traiter les sélecteurs comme de la configuration plutôt que du code figé est un principe qui gagne du terrain dans les guides récents. L’idée : stocker les sélecteurs dans un fichier JSON ou YAML séparé du script. Si la structure HTML du site cible change, la mise à jour se fait sans toucher au code Python.
A lire également : Apprendre le SEO : qui devrait le faire ? Pourquoi est-ce important ?
En pratique, un dictionnaire Python de ce type centralise la logique d’extraction :
"title": "h1::text"pour le titre principal de la page"headings": "article h2, article h3"pour les sous-titres du contenu éditorial, en excluant ceux des widgets"meta_description": "meta[name='description']::attr(content)"pour la balise meta description"body_text": "article p::text"pour le texte brut des paragraphes, filtré au conteneur principal
Cette approche rend le scraper réutilisable d’un site à l’autre en changeant uniquement le fichier de configuration.
Extraction de mots-clés avec Python : TF-IDF plutôt que comptage brut
Compter les occurrences d’un mot dans une page ne produit qu’une liste de termes fréquents, dominée par des mots vides (articles, prépositions). Pour un usage SEO, la pondération TF-IDF apporte une information bien plus exploitable.
TF-IDF (Term Frequency – Inverse Document Frequency) mesure l’importance d’un terme dans un document par rapport à un corpus. Un mot présent sur toutes les pages du corpus voit son score chuter. Un mot spécifique à quelques pages voit son score monter. Appliqué au scraping SEO, le corpus est l’ensemble des pages scrapées sur un même site ou sur les concurrents d’une requête donnée.
Implémentation avec scikit-learn
Le module TfidfVectorizer de scikit-learn prend en entrée une liste de textes bruts et retourne une matrice de scores. Chaque ligne correspond à un document, chaque colonne à un terme. Trier les colonnes par score décroissant pour un document donné donne les mots-clés les plus discriminants de cette page.
Deux paramètres méritent un réglage pour un contexte SEO. Le premier, max_df, exclut les termes présents dans une proportion trop large du corpus (typiquement le nom du site, les mentions légales). Le second, ngram_range=(1,2), permet de capturer des expressions de deux mots, souvent plus pertinentes qu’un mot isolé pour identifier une intention de recherche.
Respecter le rythme de collecte et les contraintes légales du scraping
Un scraper Python qui envoie des centaines de requêtes par seconde se fait bloquer rapidement. Au-delà du blocage technique, le cadre juridique du web scraping en Europe impose des obligations documentées.
Les guides juridiques récents (notamment ceux de Leto Legal et Eproxies) décrivent des pratiques opérationnelles concrètes : cartographier les champs de données collectés, définir une base légale au sens du RGPD, documenter la finalité de la collecte et conserver des logs d’audit. Scraper du contenu public à des fins d’analyse SEO entre dans le cadre de l’intérêt légitime, à condition de ne pas collecter de données personnelles et de respecter le fichier robots.txt.
Adapter le rythme des requêtes
Randomiser le délai entre deux requêtes (par exemple entre une et trois secondes) réduit le risque de détection. Les guides de 2026 insistent sur un point : traiter un blocage comme un signal d’arrêt, pas comme un obstacle à contourner à tout prix. Si un site retourne un code 429 (Too Many Requests), le scraper doit suspendre la collecte, pas multiplier les proxys.
Structurer la sortie du scraper pour l’analyse SEO
Extraire des données ne sert à rien si la sortie est un fichier texte brut inexploitable. Exporter les résultats en JSON structuré avec validation de schéma permet de détecter immédiatement les pages où un titre manque, où la meta description est vide ou où le contenu principal est anormalement court.
Un schéma de sortie adapté à l’analyse SEO contient au minimum :
- L’URL de la page scrapée
- Le titre H1 et la liste ordonnée des H2/H3
- La meta description extraite
- Le texte brut du contenu principal (sans navigation ni footer)
- Les cinq à dix termes avec le score TF-IDF le plus élevé pour cette page
Une tendance récente consiste à utiliser un modèle de langage pour transformer la page nettoyée en extraction structurée JSON, avec relance automatique si le schéma de validation échoue. Cette approche hybride (scraping classique puis traitement par IA) simplifie l’extraction sur des sites dont la structure HTML est imprévisible.
Le scraper le plus utile n’est pas celui qui collecte le plus de pages, mais celui dont la sortie alimente directement un tableur ou un script d’analyse sans nettoyage manuel. Privilegier l’outil le plus léger qui retourne les données attendues reste le principe de conception le plus fiable : requests et Beautiful Soup avant Scrapy, Scrapy avant Playwright, Playwright uniquement si le rendu JavaScript est indispensable.
