Scraping Shopify vs WooCommerce : différences et méthodes

Shopify et WooCommerce dominent le marché du e-commerce en 2026 — à eux deux, ils équipent plus de la moitié des boutiques en ligne dans le monde (entre 50 et 65 % selon les sources). Leur domination est telle que si tu veux scraper une boutique concurrente, il y a 3 chances sur 4 que ce soit l'un des deux. Et pourtant, scraper l'un et scraper l'autre sont deux métiers radicalement différents.

Shopify est un SaaS hébergé propriétaire, fermé en apparence mais techniquement ouvert par choix d'architecture. WooCommerce est un plugin open-source pour WordPress, "libre" par nature mais en réalité bien plus pénible à scraper. Ce paradoxe, on l'explique ici en détail, avec les méthodes concrètes pour chacune des deux plateformes, les outils adaptés, les pièges à éviter, et les cas particuliers à connaître. Si tu veux comprendre le scraping e-commerce au niveau technique, le contraste Shopify vs WooCommerce est la meilleure leçon que tu puisses te donner.

Deux architectures, deux philosophies de scraping

La différence fondamentale ne vient pas du scraping lui-même. Elle vient de comment chaque plateforme stocke et expose ses données produit. Cette différence architecturale change tout sur la méthode à employer.

Shopify : un SaaS centralisé avec une API publique par défaut

Shopify est un logiciel hébergé (Software as a Service). Quand un commerçant crée une boutique Shopify, son catalogue est stocké dans les bases de données de Shopify, pas sur son propre serveur. L'affichage de la boutique est généré côté Shopify et servi au visiteur via un thème.

Conséquence directe : toutes les boutiques Shopify partagent la même structure sous-jacente. Que tu regardes une boutique de chemises en lin ou une boutique de pièces auto, les endpoints, les champs, les formats de données sont identiques. Cette uniformité, c'est ce qui rend Shopify exceptionnellement facile à scraper à l'échelle.

Et surtout, Shopify a pris une décision d'architecture fondamentale : exposer publiquement un endpoint JSON pour le catalogue de chaque boutique. Cet endpoint, c'est /products.json, accessible à l'adresse https://nomdelaboutique.com/products.json. Toute boutique Shopify le propose par défaut. Le propriétaire peut techniquement le désactiver, mais la quasi-totalité des boutiques ne le font pas (souvent sans même savoir qu'il existe).

WooCommerce : un plugin WordPress hébergé localement, mille variantes

WooCommerce est le contraire exact. C'est un plugin open-source pour WordPress, installé sur un hébergement que le commerçant choisit lui-même (OVH, O2Switch, Kinsta, un VPS personnel...). Le catalogue est stocké dans la base de données WordPress du site, et les pages produits sont générées côté serveur par WordPress + le thème choisi.

Conséquence : deux boutiques WooCommerce peuvent avoir des structures HTML complètement différentes. Le thème détermine comment les données produit sont affichées, quels sélecteurs CSS les entourent, où se trouvent les variantes dans le DOM, comment les images sont chargées. Il existe littéralement des milliers de thèmes WordPress compatibles WooCommerce, chacun avec sa propre structure.

Il n'existe pas d'équivalent public à /products.json pour WooCommerce. L'API REST WooCommerce existe bien (endpoint /wp-json/wc/v3/products), mais elle est authentifiée par défaut : impossible de l'interroger sur la boutique d'un concurrent sans avoir un token d'API fourni par le propriétaire. Pour extraire le catalogue d'une boutique WooCommerce tierce, tu es obligé de passer par le parsing HTML des pages publiques.

Scraper Shopify : la méthode /products.json

Concrètement, voici comment on scrape une boutique Shopify en 2026. C'est d'une simplicité désarmante.

L'URL magique

Tu prends le nom de domaine de la boutique cible et tu ajoutes /products.json. Exemple :

https://exempleshop.com/products.json

Dans 95 % des cas, tu obtiens en retour un fichier JSON avec les 30 premiers produits de la boutique, formatés de manière structurée. Tu peux ensuite utiliser deux paramètres de query string pour contrôler la pagination :

• ?limit=250 — récupère jusqu'à 250 produits par requête (maximum autorisé par Shopify)
• ?page=N — permet de paginer à travers tout le catalogue

Pour aspirer un catalogue de 500 produits, deux requêtes suffisent :

https://exempleshop.com/products.json?limit=250&page=1
https://exempleshop.com/products.json?limit=250&page=2

Temps total d'exécution : quelques secondes. Proxies nécessaires : aucun. JavaScript à exécuter : aucun. Captchas à résoudre : aucun. C'est de loin la méthode la plus simple qui existe dans tout l'univers du scraping e-commerce.

Ce que tu obtiens dans le JSON

Le JSON Shopify est remarquablement riche. Pour chaque produit, tu récupères :

• Titre, description HTML complète, handle (slug), tags, type de produit, date de création et de mise à jour
• Variantes avec leur prix, prix comparé, SKU, stock (disponible/indisponible), poids, options
• Images avec leurs URLs haute résolution, positions, alt text quand disponible
• Options produit (taille, couleur, etc.) avec leurs valeurs possibles
• Vendor (marque)

Ce que tu n'obtiens pas via /products.json : les meta title et meta description SEO (qui sont dans les templates Liquid du thème), les avis clients (qui dépendent des apps installées comme Yotpo, Judge.me), les schémas JSON-LD complets, les niveaux de stock précis (seulement disponible/indisponible), et surtout les collections auxquelles chaque produit appartient. C'est une limite souvent sous-estimée : /products.json te donne les tags de chaque produit, mais pas le mapping produit ↔ collection. Pour reconstituer la structure du catalogue (quelle collection mère, quelles sous-collections, quel produit dans chacune), tu dois aussi scraper /collections.json puis chaque collection individuellement via /collections/{handle}/products.json. C'est faisable mais ça multiplie les requêtes et la complexité — tu passes de "2 requêtes pour 500 produits" à "2 + N requêtes" (N étant le nombre de collections).

C'est exactement ce type de complexité que les outils SaaS spécialisés comme Kaatalog gèrent automatiquement : le scraper aspire à la fois les produits ET la structure de collections de la boutique cible, en combinant /products.json, /collections.json et les pages HTML si nécessaire. Tu récupères un catalogue complet avec son arborescence, pas juste une liste de fiches à plat.

Les outils qui exploitent /products.json

La plupart des "scrapers Shopify" gratuits ou freemium que tu trouves en ligne ne font qu'appeler cet endpoint et formater le résultat :

• Shopify-scraper.fr — gratuit, interface web, export CSV en un clic
• ShopScraper — extension Chrome, gratuit jusqu'à 160 produits
• eScraper Shopify — payant, plus complet (ajoute les meta et schemas)
• Apify Shopify Scraper — payant à l'usage, supporte la pagination et l'export multiple
• Kaatalog — combine scraping Shopify + réécriture SEO automatique par IA + import direct dans ta propre boutique

Ces outils sont gratuits ou peu chers parce que leur "magie" est en fait triviale : ils sont juste un wrapper autour d'un endpoint public que Shopify a décidé d'ouvrir. Aucun mérite technique particulier.

Scraper WooCommerce : le HTML parsing obligé

Pour WooCommerce, la fête est finie. Tu dois te retrousser les manches et faire du vrai scraping HTML, avec toute la complexité qui va avec.

L'approche : parcourir la boutique page par page

Le workflow classique :

1. Partir de la page boutique (généralement /boutique ou /shop) qui liste les produits avec pagination
2. Extraire les liens vers chaque fiche produit (typiquement des balises <a> avec une classe .woocommerce-loop-product__link ou équivalent selon le thème)
3. Visiter chaque fiche produit une par une pour récupérer les données complètes (titre, description, prix, variantes, images, attributs)
4. Parser le HTML de chaque page avec des sélecteurs CSS adaptés au thème utilisé

Cette approche demande une requête HTTP par produit — contre une requête tous les 250 produits pour Shopify. Pour un catalogue de 500 produits, tu passes de 2 requêtes à 500 requêtes, soit une multiplication par 250.

Le problème de la variabilité des thèmes

C'est la difficulté principale. WooCommerce a des classes CSS standardisées (.product, .price, .woocommerce-product-gallery__image, etc.) mais chaque thème les surcharge à sa manière. Certains thèmes "storefront" premium (Astra, OceanWP, Flatsome, Shoptimizer, Porto) modifient profondément la structure DOM, ajoutent leurs propres classes, réorganisent les variantes, changent les formats de prix.

Concrètement, un scraper WooCommerce qui marche sur un thème ne marche pas forcément sur un autre. Tu dois soit :

1. Utiliser un scraper qui s'adapte dynamiquement (détection automatique des classes standard WooCommerce) — c'est ce que font les meilleurs outils SaaS
2. Écrire un script sur mesure pour le thème spécifique de la boutique cible
3. Utiliser un scraper générique avec configuration manuelle des sélecteurs (Octoparse, ParseHub)

Les outils qui fonctionnent bien sur WooCommerce

Contrairement à Shopify, où beaucoup d'outils se ressemblent, les bons outils WooCommerce se comptent sur les doigts d'une main :

• eScraper WooCommerce — le plus complet, détection auto de la structure, support des thèmes courants
• Apify jupri/woocommerce — scraper communautaire, 5 étoiles sur la marketplace Apify
• HasData — service payant avec API, gère les thèmes complexes et les protections
• ParseHub — configurable, bon pour des cas spécifiques
• ScrapingBee Woo API — API-first, gère le rendu JavaScript si nécessaire
• WooCommerce Scraper Extractor — extension Chrome gratuite, suffit pour des petits catalogues simples

Les scrapers qui ne marchent que sur Shopify (ShopScraper, Shopify-scraper.fr) ne marchent absolument pas sur WooCommerce — c'est une erreur fréquente de débutant que de les essayer.

Pourquoi les protections sont plus imprévisibles

WooCommerce étant self-hosted, le niveau de protection dépend entièrement de l'hébergeur et des plugins installés. Certaines boutiques WooCommerce hébergées sur du cloud dédié (Kinsta, WP Engine) ont Cloudflare en frontal et bloquent agressivement les crawlers. D'autres, hébergées sur du mutualisé bas de gamme, n'ont aucune protection et sont trivialement scrapables. Tu ne sais jamais à l'avance à quoi tu as affaire — c'est de l'artisanat.

En résumé, scraper WooCommerce demande de résoudre simultanément trois problèmes que Shopify n'a pas : la variabilité des thèmes (sélecteurs CSS), la gestion du rendering JavaScript, et les protections hébergeur-dépendantes. C'est gérable manuellement sur une boutique cible, mais ça ne scale pas si tu veux scraper 3 ou 4 concurrents différents. C'est pour cette raison que les outils comme Kaatalog qui détectent automatiquement le CMS cible et s'adaptent à la structure de chaque boutique WooCommerce (quel que soit le thème) apportent un vrai gain de temps : tu n'as pas à diagnostiquer le thème, configurer les sélecteurs ou gérer les protections — l'outil fait cette ingénierie pour toi.

Comparatif pratique : ce que tu obtiens et à quelle vitesse

Le tableau qui suit résume les différences opérationnelles concrètes entre les deux plateformes pour un scraping type "catalogue produit".

La lecture de ce tableau est sans appel : Shopify est plus simple, plus rapide, plus fiable et plus prévisible que WooCommerce sur presque tous les critères.

Quelle plateforme est "plus facile" à scraper en pratique ?

Réponse courte : Shopify, sans hésitation. Et ce n'est pas une question de compétence technique — c'est une question d'architecture.

Quelques chiffres concrets pour illustrer :

• Temps total pour aspirer un catalogue de 500 produits : ~20 secondes sur Shopify, 10 à 20 minutes sur WooCommerce
• Taux de réussite sur un scraping "à froid" (sans configuration préalable) : ~95 % sur Shopify, ~60-70 % sur WooCommerce (les thèmes exotiques font chuter le taux)
• Maintenance nécessaire pour garder le scraper fonctionnel : quasi-nulle sur Shopify (l'endpoint ne change pas), régulière sur WooCommerce (nouveaux thèmes, mises à jour de plugins)
• Risque de se faire bloquer : faible sur Shopify (Shopify accepte l'endpoint public comme un usage légitime), variable sur WooCommerce (dépend de l'hébergeur)

Cette asymétrie est tellement marquée que, dans la pratique, si tu as le choix entre scraper une boutique Shopify et une boutique WooCommerce de qualité équivalente, choisis systématiquement la boutique Shopify. C'est un conseil qu'on donne dans le guide de lancement en 3 jours : quand tu identifies ta boutique source à scraper, prioriser Shopify accélère tout le workflow.

Le casse-tête de l'import cross-platform

Il y a un aspect que les guides de scraping oublient systématiquement : scraper et importer ne ciblent pas forcément la même plateforme. Tu peux très bien scraper un concurrent sur WooCommerce pour alimenter ta propre boutique Shopify, ou l'inverse. Et dans ce cas, les formats de données ne sont absolument pas compatibles.

Le format CSV de Shopify a ses propres colonnes obligatoires (Handle, Title, Body (HTML), Vendor, Type, Tags, Variant Price, Variant SKU, Image Src...), et les noms ne correspondent à rien de ce que WooCommerce exporte. Le CSV WooCommerce, lui, utilise des conventions WordPress (post_title, post_content, regular_price, _sku...) qui ne collent pas du tout avec Shopify. Convertir l'un dans l'autre manuellement est un exercice pénible, surtout sur les variantes et les images — c'est là que 80 % des erreurs d'import se produisent.

Trois options pour gérer ce problème :

1. Conversion manuelle via un tableur — faisable pour 20 produits, suicidaire pour 300. Tu passes des heures à renommer des colonnes, reformater des variantes, réécrire des chemins d'images. Et la moindre erreur casse tout l'import.
2. Utiliser un outil de mapping CSV dédié — des outils comme Matrixify (Shopify) ou WP All Import (WooCommerce) permettent de mapper des colonnes sources vers le format cible. C'est la solution intermédiaire, documentée en détail dans CSV import Shopify : le guide pas à pas.
3. Utiliser un outil intégré qui gère la conversion pour toi — Kaatalog scrape la boutique source quel que soit son CMS (Shopify ou WooCommerce), normalise les données dans un format unifié interne, et te laisse choisir la sortie : export en CSV format Shopify, export en CSV format WooCommerce, ou publication directe via l'API Admin de ta boutique cible. Tu scrapes un concurrent WooCommerce et tu veux un CSV Shopify ? C'est un clic. Tu scrapes une boutique Shopify et tu veux importer dans WooCommerce ? Même workflow. Ça fonctionne dans tous les sens, sans mapper une seule colonne toi-même. Et si tu préfères bypasser le CSV complètement, l'intégration API publie directement dans ta boutique — scraping et import en un seul workflow.

L'import cross-platform est un cas qui paraît marginal sur le papier mais qui est en réalité très fréquent : beaucoup d'e-commerçants démarrent sur Shopify (simplicité de setup) et scrapent des concurrents qui sont sur WooCommerce (parce que WooCommerce domine en volume de sites). Le chemin inverse existe aussi quand un commerçant WooCommerce veut s'inspirer d'un concurrent Shopify mieux structuré.

Cas particuliers à connaître

Les boutiques Shopify qui ont désactivé /products.json

C'est rare mais ça existe. Certaines grosses boutiques Shopify (Gymshark, Allbirds, Fashion Nova historiquement) ont explicitement désactivé leur endpoint /products.json via une règle dans leur thème Liquid ou via leur hébergeur frontal. Si tu tombes sur un cas comme ça, tu as deux options :

1. Scraper le sitemap Shopify (/sitemap.xml) qui liste tous les produits avec leurs URLs, puis visiter chaque page produit en HTML parsing
2. Basculer sur une approche type WooCommerce — parcours complet en parsing HTML, avec les mêmes contraintes (variabilité du thème, rendering JS, etc.)

Dans ce cas, Shopify perd son avantage de vitesse et devient aussi pénible que WooCommerce.

Les boutiques WooCommerce avec la REST API publique

Rarement, un développeur WooCommerce ouvre délibérément son API REST /wp-json/wc/v3/products sans authentification. Quand ça arrive (c'est surtout le cas sur des petites boutiques mal configurées), tu obtiens l'équivalent Shopify : un endpoint JSON propre qui retourne le catalogue en une requête. Toujours tester https://nomdelaboutique.com/wp-json/wc/v3/products?per_page=100 avant de lancer un scraping HTML — ça peut te faire gagner des heures.

Les boutiques hybrides avec frontend découplé (headless)

De plus en plus de boutiques e-commerce tournent en architecture headless : un frontend React/Next.js qui charge ses données via une API, et un backend Shopify ou WooCommerce qui ne sert qu'à stocker les produits. Dans ce cas, la page que tu scrapes est peut-être générée côté client par du JavaScript, et le parsing HTML classique ne donne rien. Tu dois utiliser un scraper capable de rendre le JavaScript (Playwright, Puppeteer, Browser automation) ou trouver directement l'API backend appelée par le frontend (souvent visible dans l'onglet Network des DevTools).

La voie simple pour les deux : les outils intégrés qui détectent le CMS

Si tu ne veux pas te soucier de la différence technique entre Shopify et WooCommerce, la solution pragmatique est d'utiliser un outil qui détecte automatiquement le CMS cible et bascule entre les deux méthodes pour toi. C'est ce que font les meilleurs SaaS spécialisés e-commerce.

Kaatalog, par exemple, détecte automatiquement si la boutique cible est sur Shopify ou WooCommerce, applique la bonne méthode (/products.json ou HTML parsing), gère les protections anti-bot, et fournit un catalogue structuré uniforme quel que soit le CMS source. L'intérêt, c'est que tu n'as pas besoin de connaître la différence technique pour scraper proprement — et si tu veux scraper plusieurs concurrents sur des plateformes différentes, tu utilises le même workflow. Kaatalog ajoute par-dessus la réécriture SEO automatique par IA et l'import direct dans ta boutique cible, ce qui transforme la chaîne "scraping → catalogue publié" en un seul workflow. Les 50 premiers crédits sont offerts à l'inscription, sans carte bancaire.

Pour des outils plus bas-niveau qui gèrent aussi les deux plateformes, les alternatives sont Apify, Bright Data et ScrapingBee — plus orientés développeurs, plus flexibles, mais sans la couche réécriture et import.

En résumé

Le paradoxe Shopify / WooCommerce est parfait : Shopify, SaaS propriétaire, est le plus ouvert au scraping grâce à son endpoint /products.json par défaut. WooCommerce, plugin open-source, est en pratique le plus pénible à scraper parce que ses données ne sont accessibles qu'à travers un HTML qui varie d'un thème à l'autre. Pour 500 produits, Shopify c'est 2 requêtes et 30 secondes, WooCommerce c'est 500 requêtes et 10 à 20 minutes.

Trois conseils opérationnels pour choisir ton approche :

1. Teste toujours /products.json en premier quand tu abordes une nouvelle boutique. Si elle est sur Shopify, tu gagnes un ordre de grandeur sur tout le workflow.
2. Identifie le CMS avant le scraping (Wappalyzer, BuiltWith, test manuel). Ça prend 30 secondes et ça t'évite de partir dans la mauvaise direction.
3. Privilégie les outils qui gèrent les deux plateformes si tu fais du scraping multi-concurrents ou de la veille régulière — la double compétence (JSON endpoint + HTML parsing) t'évite d'avoir à jongler entre plusieurs outils.

Le scraping e-commerce, c'est autant d'architecture que de technique. Comprendre pourquoi Shopify et WooCommerce demandent des méthodes différentes, c'est la base pour choisir le bon outil et éviter les heures perdues sur la mauvaise approche. Pour approfondir les techniques de scraping en général et les 4 approches classiques (manuelle, no-code, scripts, SaaS), consulte le guide complet du scraping e-commerce. Et pour le volet juridique qui s'applique aux deux plateformes à l'identique, voir Est-ce légal de scraper une boutique e-commerce ? Ce que dit la loi.