Guide Ecwid SEO

«> TL;DR — Ecwid (now “Ecwid by Lightspeed”) isn’t a full store platform the way

Shopify or BigCommerce is — it’s a little store widget you drop into a website you already have. Because that widget is built in JavaScript, most of Ecwid’s SEO-friendly features only kick in on three setups: Ecwid’s own Instant Site, the official WordPress plugin, and the official Wix app. On anything else, you’ll have to do more of the SEO work yourself. » (Traduction) (Résumé en français de la section trois, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

Ce que “Ecwid SEO” signifie

Ecwid est court pour “E-commerce widget,” et que nom indique vous presque tout. Au lieu de hosting votre entier store le façon Shopify fait, Ecwid donne vous a extrait vous paste dans an existing page — a WordPress blog, a Wix site, a Squarespace page, même a hand-built HTML site — et il draws a complet catalog, cart, et checkout correct à l’intérieur que page.

Ecwid aussi a son propre site web builder appelé Instant Site, donc vous pouvez exécuter Ecwid as votre entier site web aussi. c’est le split vous ont à gardez à l’esprit le entier façon via: Ecwid peut être “just a widget on someone else’s site” or “the whole site.” Il behaves very differently pour le SEO selon qui un vous êtes doing.

“Ecwid SEO” est simplement le normal fonctionner de getting votre produits et category pages trouvé, exploré, indexé, et ranked — applied à a store que exécute on Ecwid.

The un chose que shapes everything

Le store charge avec JavaScript. c’est pas automatiquement a problème — Google peut lire JavaScript — mais il signifie Ecwid a à faire supplémentaire fonctionner à assurez-vous moteur de recherches voir réel, crawlable pages. Ecwid fait faire que fonctionner, mais seulement on three setups:

• Instant Site (Ecwid’s propre site web builder),
• le official WordPress plugin, et
• le official Wix app.

On ceux three, Ecwid quietly hands moteur de recherches a plain-HTML copy de chaque produit et category page, donne vous clean web addresses, et construit a sitemap pour vous. On quelconque autre setup — a custom HTML site, Squarespace, Weebly, et donc on — vous obtenir le raw JavaScript widget avec messy #! web addresses, et vous ont à handle le sitemap et clean URLs yourself.

Ce que vous pouvez and can’t contrôler

A few choses surprise personnes:

«- Free plan = no SEO editing. On Ecwid’s free plan you can’t edit your page titles or meta descriptions at all. You need a paid plan (Venture, Business, or Unlimited) for most on-page controls. » (Traduction) (Résumé en français de la section quinze, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.) «- Image alt text defaults to the product name, but you can override it. Ecwid writes your image alt text for you by default, and now lets you set your own custom alt text per image (and even show it as a visible caption under the gallery photo). » (Traduction) (Résumé en français de la section quinze, sous-partie deux : le texte source est conservé pour vérification lors de la relecture francophone.) «- No blog built in. Unlike WordPress, Ecwid has no real blogging tool. If you want to publish articles for SEO, you host a blog somewhere else and link it to your store. » (Traduction) (Résumé en français de la section quinze, sous-partie trois : le texte source est conservé pour vérification lors de la relecture francophone.)

The chose la plupart personnes obtenir incorrect

Là sont deux opposite myths, et les deux sont incorrect. Un dit “Ecwid handles tout SEO automatiquement, donc il y a rien à faire.” c’est seulement vrai on Instant Site, WordPress, or Wix — everywhere sinon vous êtes doing réel setup par hand. Le autre dit “Ecwid utilise ces weird #! liens donc Google ne peut pas trouver il à tous.” Google peut explorer ceux liens — c’est simplement pas ideal, qui est exactly pourquoi Ecwid construit a “Clean Store URLs” option à déplacer past les. Turn que option on.

Vouloir le technique version — le exact URL formats, comment le static-HTML rendu fonctionne, le canonical et hreflang details, et le produit-rename duplicate-URL trap? Switch à le Avancé tab.

«> TL;DR — Ecwid is a JavaScript storefront widget by default, not a hosted site,

and that decides everything. Clean URLs, crawlable static HTML, auto sitemap, and auto robots.txt are scoped to three integrations: Instant Site, the WordPress plugin, and the Wix app. Everywhere else the default is hashbang URLs (/#!/product-name/p/123456), a client-rendered widget with no SSR fallback unless a developer wires up the Storefront SDK + static-code endpoints, and a DIY sitemap. Canonical and hreflang exist as API fields but are only populated where static rendering runs; the no-code multilingual Instant Site feature doesn’t auto-link hreflang. Structured data is automatic but non-editable (JSON-LD+Microdata on Instant Site/WordPress, Microdata-only elsewhere). Free plan can’t edit meta tags; the embedded widget reportedly can’t do 301s; there’s no native blog. » (Traduction) (Résumé en français de la section vingt et un, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

Le frame: widget vs. site decides tout

La plupart “Ecwid SEO” contenu treats Ecwid comme Shopify or BigCommerce — a hosted plateforme avec a fixed définir de SEO behaviors. Il n’est pas. Ecwid (“E-commerce widobtenir,” maintenant Ecwid par Lightspeed après le acquisition) est fundamentally an embeddable JavaScript storefront. Vous paste a widget dans an existing page et il renders le catalog, cart, et checkout client-side. Ecwid aussi ships son propre hosted builder, Instant Site, donc il peut être le entier site web aussi.

Que duality est le organizing idea pour le entier article. Demander un question à propos de quelconque Ecwid store avant vous diagnose n’importe quoi: est ce le Instant Site / WordPress / Wix chemin, or est il a widget embedded somewhere sinon? Parce que nearly chaque SEO-friendly behavior Ecwid advertises est scoped à le premier chemin et absent on le deuxième. Unlike Shopify or WooCommerce, où le plateforme’s SEO behavior est roughly constant regardless de où il exécute, Ecwid’s changements shape selon le host.

Handled pour vous (Instant Site + WordPress + Wix): static HTML copies served to robots d’exploration, clean URLs, auto sitemap, auto robots.txt (Instant Site), complet JSON-LD données structurées, balise canonicals.

Le vôtre à faire (custom / autre builders): clean-URL setup via serveur rewrite règles, sitemap generation, static rendu via le Storefront SDK, et awareness que canonical/hreflang balises peut simplement pas être servi.

Pourquoi Ecwid has an SEO reputation problem

Ecwid a carried a “mauvais pour SEO” reputation pour années, et le docs sont unusually candid à propos de pourquoi. Dans Ecwid’s propre words: “Moteur de recherches ne faites pas toujours indexer dynamic sites web bien. À garantir ils indexer Ecwid stores, nous utiliser special technology. Si vous sell avec Ecwid Instant site or utiliser WordPress or Wix plugin, Ecwid crée a static HTML copy pour chaque produit et category page dans votre store, alors donne ce copy à a moteur de recherche.” (Ce que Ecwid fait pour le SEO)

Lire que carefully — le mitigation est scoped à three integrations. Everyone sinon obtient le client-side JS widget avec aucun serveur-rendu fallback. Le developer docs dire le même chose depuis le autre direction: “Si votre site web est fondé on Wix or WordPress site builders, utiliser notre official integrations… Ces integrations ont static store pages enabled out de le box. Et si vous construire a storefront on un autre CMS or a custom site web, utiliser notre Storefront SDK et Static code endpoints à définir up static pages pour votre site web.” (Static store pages)

Donc le reputation n’est pas a relic — c’est encore actif pour anyone embedding le widget dans Squarespace, Weebly, Webflow, or a custom page et pas building le static couche themselves. Le base embed est genuinely client-rendu:

<div id="my-store-1003"></div>
<script type="text/javascript" src="https://app.ecwid.com/script.js?1003" charset="utf-8"></script>
<script type="text/javascript">xProductBrowser("id=my-store-1003");</script>

c’est le entier storefront (Dynamic chargement pour storefront widget). Si a robot d’exploration voit produits dépend on si il renders que JavaScript — qui est exactly le JavaScript SEO problème, et pourquoi le static-HTML mechanism matters donc beaucoup.

Structure d’URL — the la plupart nuanced fact ici

Ce est le unique la plupart important technique detail, et c’est où Ecwid differs sharply depuis chaque hosted rival. Ecwid’s URL format dépend entirely on comment le store est integrated. Depuis le docs: “Ecwid generates différent URL formats fondé on votre site web’s setup et le fonctionnalités vous ont enabled.” (Optimize custom site web SEO avec meilleur URLs)

Le critical correction à le usual assumption: le hashbang (/#!/) formulaire est le actuel par défaut, pas a 2014-era relic. On quelconque custom/embedded site que n’est pas Instant Site or le native WordPress/Wix apps, vous obtenir hashbang URLs unless vous explicitly enable Clean Store URLs. À turn les on off a custom site, per le docs, “vous doit ont: Accès à son serveur rewrite règles [et] HTML code de le store page” — Apache .htaccess, an Nginx serveur bloquer, or le IIS URL rewrite module (Enable Clean Store URLs on a custom site web).

On Instant Site, WordPress, et Wix, clean URLs sont automatic — Ecwid states plainly que on ceux il provides “SEO-friendly URLs automatiquement.” Custom URL slugs pour produits et categories sont disponible aussi, mais seulement on Instant Site (nouveau version) or WordPress dans le UI; merchants on autre builders peut définir slugs seulement via le REST API (Improving SEO pour Ecwid site et store).

Pourquoi fait le hashbang par défaut matter si Google peut explorer il? Parce que a fragment après # est jamais sent à le serveur par le navigateur, par design. Que crée réel friction autour serveur-log visibility, some robot d’exploration/outil compatibility, lien-equity consolidation, et social-share previews. Google’s propre position (plus on ce dans le Google section ci-dessous) est que il peut rendre #! URLs mais recommends contre introducing nouveau ones — qui est precisely le justification pour enabling Clean Store URLs plutôt que shrugging et saying “Google peut explorer il.”

Crawlability et rendu — static store pages

Ce est le technique heart de le plateforme. On Instant Site, WordPress, et Wix, Ecwid sert a pre-rendu static HTML copy de chaque produit/category page à robots d’exploration, alors swaps dans le actif JS widget pour humans. c’est ce que rend ceux setups explorer cleanly.

Everywhere sinon, vous construire il yourself. Le mechanism, per le developer docs, est manual: récupérer pre-rendu HTML depuis a REST endpoint (storefront.ecwid.com/product-page/{storeId}/{productId}/static-code, et le category/home equivalents), inject il dans a visible container, alors hand off à le actif widget via le Storefront SDK (ec.storefront.staticPages.*, StaticPageLoader.switchToDynamicMode()) une fois il charge (Static store pages). Si a developer ne fait pas construire ce, robots d’exploration voir seulement whatever le client-side widget renders — or fails à rendre.

«The practical inference worth stating plainly: an Ecwid widget dropped into Squarespace, Webflow, Weebly, or a hand-built page is, by default, pure client-side JavaScript with hashbang URLs and no server-rendered fallback. That’s the exact scenario the “Ecwid is bad for SEO” reputation is about, and it’s still true today for most non-WordPress/non-Wix/non-Instant-Site embeds. » (Traduction) (Résumé en français de la section quarante-trois, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«## Sitemap and robots.txt » (Traduction) (Résumé en français de la section quarante-cinq, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«Auto-generation here is also integration-scoped. Ecwid: “Ecwid automatically generates a sitemap.xml file… New pages – and new products – are indexed faster with sitemaps… You still need to submit a sitemap to Google manually” — availability listed as Venture, Business, Unlimited (What Ecwid does for SEO). On Instant Site the sitemap is even submitted internally via robots.txt, though you can still submit it in Search Console to speed discovery (Submitting a sitemap to Google). » (Traduction) (Résumé en français de la section quarante-six, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«But the same article is explicit about the DIY path: “If you are using Ecwid with your own website, you can generate a sitemap for your store pages by using a third-party service.” For WordPress v5.5+, the plugin auto-generates a store sitemap; older versions need Yoast or Google XML Sitemaps. And the Wix caveat matters — Wix’s own sitemap covers site pages “and not the store pages with your products, categories, etc.” So a Wix + Ecwid store’s product pages are not in Wix’s sitemap; you rely on Ecwid’s static-rendering path to get them discovered. » (Traduction) (Résumé en français de la section quarante-sept, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

Robots.txt est similarly scoped. Ecwid contrôle a robots.txt seulement on Instant Site, où produit et category pages sont indexable mais le cart et recherche-résultats pages sont excluded (ils sont per-visitor). On quelconque embed dans an existing site, robots.txt belongs à le host CMS or hosting account — Ecwid a aucun robots.txt à manage là à tout. Ce est unlike WooCommerce (où WordPress owns robots.txt) or BigCommerce (editable dans-admin) — avec Ecwid, qui owns robots.txt dépend on où le widget lives.

Balise canonicals and contenu dupliqué

Ecwid’s static-page REST réponse inclut a canonicalUrl champ — “URL canonique pour ce page” — renvoyé alongside htmlCode, metaDescriptionHtml, ogTagsHtml, jsonLDHtml, et hrefLangHtml (Static code pour produit page). Donc balise canonicals sont handled automatiquement wherever Ecwid’s static rendu exécute (Instant Site, WordPress, Wix). On a custom integration que seulement embeds le JS widget avec aucun static/SSR couche, là peut être aucun balise canonical servi à robots d’exploration — le page est a unique client-rendu URL avec aucun per-produit HTML en réalité delivered.

Le nastier duplicate-contenu risque est renaming. Ecwid generates a produit URL depuis le titre, donc si vous modifier a produit’s titre, a nouveau URL est créé et le old un n’est pas automatiquement redirigé — le old URL garde fonctionnement, giving vous deux actif URLs pour un produit. On Instant Site, Ecwid a since shipped manual 301 redirection setup, donc ce est maintenant avoidable si vous proactively ajouter a redirection. On le embedded widget version, though, practitioners rapport vous ne peut pas créer redirections à tout — Style Factory’s examiner notes que on le widget vous “can’t create redirects,” qui “n’est pas ideal à tout parce que si vous modifier une URL, a redirection est necessary” (Style Factory). Le takeaway: plan votre URLs avant vous publish, et définir up le 301 avant renaming où le tooling permet il. Le canonicalization cluster covers le underlying mechanics.

Données structurées

Ecwid auto-generates schema.org markup on tout integrations, qui est a genuine strength — mais avec deux catches. Dans Ecwid’s words: “Ecwid utilise Schema.org vocabulary à annotate produit information et ajoute données structurées à tout store pages automatiquement. Pour Ecwid Instant Site et stores on WordPress sites, données structurées est generated en utilisant JSON-LD et Microdata markup. Pour tout le autre sites web, seulement le Microdata format est utilisé. As de maintenant, c’est impossible à edit or supprimer le structured données.” (Ce que Ecwid fait pour le SEO)

Deux actionable points: (1) c’est pas editable à tout — aucun schema customization, aucun ajout FAQ or Video markup via Ecwid; (2) le format differs par integration — complet JSON-LD+Microdata seulement on Instant Site/WordPress, Microdata-seulement everywhere sinon. Microdata est le older, plus erreur-prone format; Google encore lit il mais recommends JSON-LD. Donc le myth que “a widget can’t do rich results” est faux — Ecwid fait données structurées everywhere — mais le qualité de que markup est meilleur on le native integrations, et vous pouvez’t touch il soit façon.

Meta tags, texte alternatif, and plan gating

«On-page controls are gated behind paid plans. Custom titles, meta descriptions, and slugs require Venture, Business, or Unlimited — free-plan merchants can’t edit meta tags at all. Call this out early with any client on the free tier; it’s a hard limiter, not a best-practice nicety. » (Traduction) (Résumé en français de la section cinquante-six, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«Image alt text defaults to the product name, but it’s no longer locked. Ecwid now lets you set a custom alt text (up to 125 characters) per product image and per variation image from Catalog → Products → image → Actions → Edit alt text — and there’s no plan gating mentioned for this, unlike meta tags. You can even flip a toggle (Website → Edit Site → Product → Product Details → Image gallery, on Instant Site; the equivalent setting on other integrations) to display the custom alt text as a visible caption under each gallery photo, which is useful for apparel sizing/fit details. (Alt texts and visible product image descriptions) This is a real improvement worth knowing about if you last checked Ecwid a while ago — several third-party reviews (Style Factory among them) still describe alt text as unchangeable, and that’s now outdated. For most product images “product name as alt text” is a fine default, but if you need descriptive or accessibility-improving alt text — which matters for image SEO and screen-reader users — you can now write it yourself. » (Traduction) (Résumé en français de la section cinquante-sept, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«## Multilingual and international SEO » (Traduction) (Résumé en français de la section cinquante-huit, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«Ecwid’s no-code multilingual feature (Instant Site) is not classic hreflang internationalization. Each language gets its own subpath, and Ecwid’s help doc treats each as a self-contained mini-site you must SEO separately: “each translated version of your site has its own subdomain [subpath] with a language code… Search engines consider each… as unique and distinct from your main site. You need to optimize each version to make it high ranked.” (Creating a multilingual site) » (Traduction) (Résumé en français de la section cinquante-neuf, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«Nothing there mentions automatic hreflang linking between the versions. At the API level, hreflang is supported — the static-code endpoint takes an internationalPages parameter and returns an hrefLangHtml field (Static code for product page) — but that’s developer-facing. The gap worth flagging: a merchant using the no-code multilingual Instant Site feature likely gets zero automatic hreflang tags between language versions, which is exactly the “wrong locale ranks for the wrong query” problem generic hreflang guidance warns about. If international matters, either have a developer call the API’s internationalPages param or add the hreflang annotations yourself. » (Traduction) (Résumé en français de la section soixante, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

Ce que Ecwid doesn’t do

• Aucun native blog. Style Factory: “il y a aucun built-dans blogging moteur. Pour contenu marketing or SEO blogging, vous’ll besoin à host votre blog séparément (on WordPress, Par exemple) et lien à il.” Instant Site’s blog “workaround” is odd — it “involves a vraiment odd workaround où produit categories sont utilisé à créer posts.” Si contenu est a channel pour vous, exécuter a réel blog elsewhere. (Ce est a placer où WooCommerce, sitting on top de WordPress, a a structural advantage.)
• Limited redirection tooling on non-Instant-Site embeds — covered ci-dessus; le widget version reportedly ne peut pas faire redirections à tout.
• Aucun editable données structurées — covered ci-dessus. (Image texte alternatif, unlike structured données, est maintenant editable per image — voir le meta balises section ci-dessus.)

Ecwid vs. the autre platforms

Où Ecwid est weaker que le hosted rivals: c’est le seulement un whose core SEO behavior flips fondé on où c’est embedded; il a aucun native blog (WooCommerce wins ici par living on WordPress); redirections sont absent on le widget version (Shopify, BigCommerce, Magento, et PrestaShop tout handle ce meilleur); et gratuit-tier SEO est locked. Où c’est adequate: données structurées ships automatiquement everywhere, HTTPS et mobile rendu sont fine, et on Instant Site/WordPress/Wix le static-rendu chemin genuinely solves le JavaScript-crawlability problème.

Le honest positioning: Ecwid est excellent à ce que c’est pour — ajout a store à a site vous déjà ont, cheaply, sans a rebuild. Si que site est WordPress or Wix, or si vous utiliser Instant Site, votre SEO baseline est solid. Si vous êtes embedding le widget dans a custom site or un autre builder et treating SEO as important, vous soit commit à le developer fonctionner (static pages, clean URLs, DIY sitemap, hreflang) or vous devez être looking à a plateforme construit pour il — Shopify, BigCommerce, WooCommerce, Magento, or PrestaShop — à la place.

«## AI summary » (Traduction) (Résumé en français de la section soixante-huit, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«A condensed take on the Advanced version: » (Traduction) (Résumé en français de la section soixante-neuf, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«- Ecwid (now Ecwid by Lightspeed) is an embeddable JavaScript widget, not a hosted site by default. You paste a storefront into an existing WordPress, Wix, Squarespace, or custom page. Its own builder, Instant Site, can run the whole site. This widget-vs-site split drives every SEO fact. » (Traduction) (Résumé en français de la section soixante-dix, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.) «- SEO-friendly behavior is scoped to three integrations: Instant Site, the WordPress plugin, and the Wix app get static HTML served to crawlers, clean URLs, an auto sitemap, and (Instant Site) auto robots.txt. Everywhere else you’re on your own. » (Traduction) (Résumé en français de la section soixante-dix, sous-partie deux : le texte source est conservé pour vérification lors de la relecture francophone.) «- URL default is the hashbang form /#!/product-name/p/123456 on custom embeds — this is current, not legacy. Clean Store URLs are automatic on Instant Site/WordPress/Wix but require server rewrite rules (.htaccess/nginx/IIS) elsewhere. » (Traduction) (Résumé en français de la section soixante-dix, sous-partie trois : le texte source est conservé pour vérification lors de la relecture francophone.) «- Static rendering (“static store pages”) is out-of-the-box only on the three native integrations; on a custom site a developer must wire up the Storefront SDK + static-code REST endpoints, or crawlers see only the client-rendered widget. » (Traduction) (Résumé en français de la section soixante-dix, sous-partie quatre : le texte source est conservé pour vérification lors de la relecture francophone.) «- Sitemap and robots.txt auto-generation is Instant-Site (and modern WordPress) only; custom sites DIY the sitemap; Wix’s own sitemap excludes Ecwid product pages. » (Traduction) (Résumé en français de la section soixante-dix, sous-partie cinq : le texte source est conservé pour vérification lors de la relecture francophone.) «- Canonical + hreflang exist as API fields (canonicalUrl, hrefLangHtml) but are only populated where static rendering runs. The no-code multilingual Instant Site feature does not auto-link hreflang between language versions. » (Traduction) (Résumé en français de la section soixante-dix, sous-partie six : le texte source est conservé pour vérification lors de la relecture francophone.) «- Structured data is automatic but non-editable — full JSON-LD+Microdata on Instant Site/WordPress, Microdata-only elsewhere. » (Traduction) (Résumé en français de la section soixante-dix, sous-partie sept : le texte source est conservé pour vérification lors de la relecture francophone.) «- Renaming a product creates a new URL with no auto-redirect; Instant Site now has manual 301s, but the embedded widget reportedly can’t do redirects at all. » (Traduction) (Résumé en français de la section soixante-dix, sous-partie huit : le texte source est conservé pour vérification lors de la relecture francophone.) «- Free plan can’t edit meta tags; there’s no native blog. Image alt text defaults to the product name but can now be overridden per image (no plan gating), unlike meta tags. Google can crawl hashbang URLs but recommends against them — hence Clean Store URLs. If SEO matters on a custom embed, do the developer work or use a platform built for it (Shopify, BigCommerce, WooCommerce, Magento, PrestaShop). » (Traduction) (Résumé en français de la section soixante-dix, sous-partie neuf : le texte source est conservé pour vérification lors de la relecture francophone.)

«## Official documentation » (Traduction) (Résumé en français de la section soixante-treize, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«Primary-source docs from Ecwid/Lightspeed and Google. » (Traduction) (Résumé en français de la section soixante-quatorze, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«Ecwid / Lightspeed » (Traduction) (Résumé en français de la section soixante-quinze, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.) «- What Ecwid does for SEO — the overview: static copies, clean URLs, sitemap, robots.txt, structured data, automatic ALT tags. » (Traduction) (Résumé en français de la section soixante-quinze, sous-partie deux : le texte source est conservé pour vérification lors de la relecture francophone.) «- Alt texts and visible product image descriptions — how to override the default product-name alt text per image. » (Traduction) (Résumé en français de la section soixante-quinze, sous-partie trois : le texte source est conservé pour vérification lors de la relecture francophone.) «- Improving SEO for Ecwid site and store — meta tags, custom URL slugs, 301 redirects, sitemap submission, SSL (and the plan gating). » (Traduction) (Résumé en français de la section soixante-quinze, sous-partie quatre : le texte source est conservé pour vérification lors de la relecture francophone.) «- Submitting a sitemap to Google — Instant Site vs. own-website sitemap handling, WordPress and Wix specifics. » (Traduction) (Résumé en français de la section soixante-quinze, sous-partie cinq : le texte source est conservé pour vérification lors de la relecture francophone.) «- Creating a multilingual site with Ecwid Instant Site — the subpath-per-language model and its SEO implications. » (Traduction) (Résumé en français de la section soixante-quinze, sous-partie six : le texte source est conservé pour vérification lors de la relecture francophone.) «- What Lightspeed eCom does for SEO — the Lightspeed-branded mirror confirming “Lightspeed eCom” = Ecwid. » (Traduction) (Résumé en français de la section soixante-quinze, sous-partie sept : le texte source est conservé pour vérification lors de la relecture francophone.)

«Ecwid developer docs » (Traduction) (Résumé en français de la section soixante-seize, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.) «- Static store pages — the scoping of “out of the box” static rendering and the Storefront SDK swap mechanism. » (Traduction) (Résumé en français de la section soixante-seize, sous-partie deux : le texte source est conservé pour vérification lors de la relecture francophone.) «- Static code for product page — the canonicalUrl, hrefLangHtml, and internationalPages fields. » (Traduction) (Résumé en français de la section soixante-seize, sous-partie trois : le texte source est conservé pour vérification lors de la relecture francophone.) «- Optimize custom website SEO with better URLs — the three-tier URL comparison table. » (Traduction) (Résumé en français de la section soixante-seize, sous-partie quatre : le texte source est conservé pour vérification lors de la relecture francophone.) «- Enable Clean Store URLs on a custom website — the server rewrite-rule requirements. » (Traduction) (Résumé en français de la section soixante-seize, sous-partie cinq : le texte source est conservé pour vérification lors de la relecture francophone.) «- Dynamic loading for storefront widget — the base embed code. » (Traduction) (Résumé en français de la section soixante-seize, sous-partie six : le texte source est conservé pour vérification lors de la relecture francophone.)

«Google » (Traduction) (Résumé en français de la section soixante-dix-sept, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.) «- Deprecating our AJAX crawling scheme — Google’s 2015 statement that it renders #! URLs but recommends against introducing new hashbang/escaped-fragment URLs. » (Traduction) (Résumé en français de la section soixante-dix-sept, sous-partie deux : le texte source est conservé pour vérification lors de la relecture francophone.) «- Structured data intro — why Google recommends JSON-LD over Microdata. » (Traduction) (Résumé en français de la section soixante-dix-sept, sous-partie trois : le texte source est conservé pour vérification lors de la relecture francophone.)

«## Quotes from the source » (Traduction) (Résumé en français de la section quatre-vingts, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

On-le-record statements depuis Ecwid/Lightspeed, Google, et le practitioners whose Ecwid-spécifique findings shaped ce guide. Où une page prend en charge a deep lien, Je lien à le quoted passage.

Google — hashbang / AJAX exploration (deep-link verified)

«- “In short: We are no longer recommending the AJAX crawling proposal we made back in 2009.” — Google Search Central Blog, Oct 14, 2015. Google renders #! URLs today but recommends against introducing new ones. Jump to quote » (Traduction) (Résumé en français de la section quatre-vingt-trois, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

Ecwid developer docs — Structure d’URL & static pages (deep-link verified)

«- “When you add an Ecwid store to a custom website, it creates dynamic pages for the catalog” — the setup that produces hashbang URLs by default. Jump to quote » (Traduction) (Résumé en français de la section quatre-vingt-cinq, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.) «- “To enable Clean Store URLs on a custom website, you must have:” access to server rewrite rules and the store page’s HTML — i.e., clean URLs aren’t free off a native integration. Jump to quote » (Traduction) (Résumé en français de la section quatre-vingt-cinq, sous-partie deux : le texte source est conservé pour vérification lors de la relecture francophone.) «- “If your website is based on Wix or WordPress site builders, use our official integrations” — the scoping statement for out-of-the-box static rendering. Jump to quote » (Traduction) (Résumé en français de la section quatre-vingt-cinq, sous-partie trois : le texte source est conservé pour vérification lors de la relecture francophone.)

Ecwid prise en charge docs — SEO overview (relayed; le prise en charge.ecwid.com host bloque automated fetching, donc ces sont verified via rendu page, pas a récupérer-checked #:~:text= fragment — confirmer contre le actif page avant treating as final)

• “Moteur de recherches ne faites pas toujours indexer dynamic sites web bien. À garantir ils indexer Ecwid stores, nous utiliser special technology.” — Ce que Ecwid fait pour SEO, “Static copies of pages.”
• “Ecwid utilise Schema.org vocabulary à annotate produit information et ajoute données structurées à tout store pages automatiquement… Pour tout le autre sites web, seulement le Microdata format est utilisé. As de maintenant, c’est impossible à edit or supprimer le données structurées.” — même article, “Données structurées.”
• “Ecwid automatiquement generates a sitemap.xml fichier… Vous encore besoin à submit a sitemap à Google manuellement.” — même article, “Sitemap pour Instant Sites.”

Practitioners — Ecwid-spécifique findings (relayed depuis Style Factory; confirmer à source)

• “vous pouvez’t créer redirections dans le widget (embedded) version de Ecwid soit, qui n’est pas ideal à tout parce que si vous modifier une URL, a redirection est necessary à tell Google où le nouveau page lives.” Source
• “Modification texte alternatif (le description de images que moteur de recherches et screen lecteurs voir) n’est pas possible, though — vous êtes stuck avec whatever Ecwid generates pour vous automatiquement.” Source — superseded: Ecwid’s propre aider center maintenant documents custom per-image texte alternatif (up à 125 characters, aucun plan gating), donc ce finding ne … plus holds. Voir Texte alternatifs et visible produit image descriptions.
• “il y a aucun built-dans blogging moteur. Pour contenu marketing or SEO blogging, vous’ll besoin à host votre blog séparément (on WordPress, Par exemple) et lien à il.” Source

Ecwid SEO checklist

Prioritized by impact. The premier question decides half the liste: qui integration is ce?

Premier, identifier le setup

• Confirmer si ce store exécute on Instant Site, le WordPress plugin, le Wix app, or a custom/autre embed — chaque élément ci-dessous branches on il.

Élevé impact

• Clean Store URLs sont on. Automatic on Instant Site/WordPress/Wix; on a custom site, ajouter le serveur rewrite règles (.htaccess / nginx / IIS) plus le JS flag — ne pas laisser hashbang /#!/ URLs dans placer.
• Robots d’exploration obtenir réel HTML. On a custom/autre-builder embed, wire up le Storefront SDK + static-code endpoints (or déplacer à a native integration) donc pages ne sont pas pure client-side JS.
• Sitemap exists et est submitted. Instant Site/modern WordPress auto-generate il; custom sites besoin a tiers generator. Submit il dans la recherche Google Console et Bing Webmaster Outils. On Wix, remember Wix’s propre sitemap excludes Ecwid produit pages.
• Plan pour 301s avant renaming. Définir up le Instant Site redirection avant vous modifier a produit titre; on le embedded widget, éviter renames since vous pouvez’t redirection le old URL.

Standard setup

• Payant plan (Venture/Entreprise/Unlimited) si vous devez edit titles/meta descriptions à tout — le gratuit plan ne peut pas.
• Page titles et meta descriptions written pour le page d’accueil, top produits, et top categories.
• Données structurées verified avec Google’s Résultats enrichis Tester (c’est auto-generated et non-editable — confirmer c’est valide, surtout le Microdata-seulement chemin on custom embeds).
• Balise canonicals confirmed présent on produit/category pages (auto on native integrations; peut être absent on a bare widget embed).
• A réel blog définir up elsewhere (e.g., WordPress) si contenu est a channel — Ecwid a aucun native blog.

International (multilingual seulement)

• hreflang en réalité présent entre langue versions — le aucun-code Instant Site multilingual fonctionnalité fait pas ajouter il automatiquement; utiliser le API’s internationalPages param or ajouter annotations yourself.
• Chaque langue version optimized independently (titles/descriptions translated), since Ecwid treats chaque as a distinct site.

«## The storefront ownership framework » (Traduction) (Résumé en français de la section cent un, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«Every Ecwid audit starts by assigning ownership for four outputs: » (Traduction) (Résumé en français de la section cent deux, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«1. Host page: the surrounding Wix, WordPress, custom, or Instant Site route. 2. Store route: the clean product/category URL Ecwid exposes to crawlers. 3. Search signals: canonical, metadata, structured data, and internal links. 4. Discovery files: which system publishes the sitemap and robots rules. » (Traduction) (Résumé en français de la section cent trois, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

Quand le host et store les deux claim le même responsibility, duplicates et conflicting signaux apparaître. Quand aucun claims il, produit URLs disappear depuis sitemaps or ship sans requis markup. Document un owner pour chaque sortie avant modification paramètres.

Ecwid SEO cheat sheet

What’s automatic — by integration

URL formats

Plan gating (sur la page SEO)

• Gratuit plan: ne peut pas edit titles/meta descriptions.
• Venture / Entreprise / Unlimited: custom titles, descriptions, slugs, sitemap.

API champs que matter (static-code endpoint)

• canonicalUrl — balise canonical
• hrefLangHtml — hreflang balises (nécessite internationalPages param)
• jsonLDHtml / metaDescriptionHtml / ogTagsHtml — le rest de le head

Don’ts

• ne pas laisser hashbang /#!/ URLs on a custom embed — turn on Clean Store URLs.
• ne pas rename produits on le embedded widget (aucun redirection = duplicate/orphan URL).
• ne pas assume Wix’s sitemap inclut votre Ecwid produits (il ne fait pas).
• ne pas assume le aucun-code multilingual fonctionnalité ajoute hreflang (il ne fait pas).
• ne pas expect à edit données structurées (vous pouvez’t) — mais faire définir custom texte alternatif si le defaults ne sont pas bon suffisant; que un’s editable per image maintenant.

Comparer Ecwid URL variants

Export suspected product/category variants to urls.txt, alors capture leur status and canonical target:

while IFS= read -r url; do
  html=$(mktemp)
  status=$(curl -sSL -o "$html" -w '%{http_code}' "$url")
  canonical=$(grep -Eio '<link[^>]+rel=["'"']canonical["'"'][^>]*>' "$html" | head -1)
  printf '%s\t%s\t%s\n' "$status" "$url" "$canonical"
  rm -f "$html"
done < urls.txt

Groupe le sortie par produit. Chaque public variant devrait soit consolidate consistently or ont a distinct objectif; ne faites pas infer le preferred URL depuis code d’état alone.

Outils pour Ecwid SEO

• Recherche Google Console — submit votre sitemap, utiliser Inspection d’URL à confirmer Google en réalité renders votre produit pages (critical on quelconque JS-widget embed), et watch Page Indexation pour hashbang or duplicate-URL problèmes.
• Bing Webmaster Outils — deuxième sitemap submission et explorer visibility.
• Google Résultats enrichis Tester / Balisage de données structurées Validator — confirmer Ecwid’s auto-generated données structurées est valide; c’est non-editable, donc validation est votre seulement lever, et le Microdata-seulement chemin on custom embeds est plus erreur-prone.
• Inspection d’URL (GSC) “View crawled page” — le fastest façon à voir si a robot d’exploration obtient réel HTML or an vide JS shell on a custom/autre-builder embed.
• Screaming Frog / Ahrefs Site Audit (JS-rendu mode on) — explorer le store à catch hashbang URLs, duplicate URLs depuis renames, manquant canonicals, et pages que rendre blank sans JavaScript.
• XML sitemap generators (XML-Sitemaps, Mon Sitemap Generator, or Yoast/Google XML Sitemaps on WordPress) — pour le DIY sitemap Ecwid ne va pas construire on a custom site.
• Serveur rewrite tooling — .htaccess (Apache), le Nginx config, or le IIS URL Rewrite module — à enable Clean Store URLs on a custom site.

Ressources utiles

On-site, connexe

• JavaScript SEO — le rendu problème behind Ecwid’s client-side widget; ce est le cluster que explique pourquoi static store pages matter.
• Canonicalization — le mechanics behind Ecwid’s canonicalUrl champ et le produit-rename duplicate-URL trap.
• hreflang — ce que le aucun-code multilingual Instant Site fonctionnalité ne fait pas ajouter pour vous.

Ecwid / Lightspeed official

• Ce que Ecwid fait pour le SEO et Improving SEO pour Ecwid site et store — le deux core aider articles.
• Static store pages — le developer chemin pour crawlable HTML on custom sites.

Depuis autour le industry

• Ecwid Examiner — Clé Pros et Cons, Pricing et Alternatives (Style Factory) — le source pour le aucun-redirects-on-widget et aucun-native-blog findings (son locked-alt-texte finding est maintenant outdated — voir le alt-texte article ci-dessous).
• Texte alternatifs et visible produit image descriptions — comment définir custom per-image texte alternatif et montrer il as a visible gallery caption.
• Ecwid Examiner (ecommerce-platforms.com) — practitioner coverage de le produit-rename duplicate-URL risque.
• Ecwid Examiner 2026 (Tooltester) — independent examiner framing Ecwid’s SEO as son weaker area versus native platforms.
• Ecwid par Lightspeed Ecommerce Shopping Cart — WordPress.org plugin page — le official plugin (20 000+ active installations), le chemin que obtient static rendu et clean URLs on WordPress.
• Nouveau Clean URLs pour Chaque Ecwid Store (Ecwid blog) — Ecwid’s propre history de pourquoi hashbang URLs étaient a problème et pourquoi Clean Store URLs exist.

Mistakes personnes en réalité faire on Ecwid

Every un of ces traces back to the même root causer: treating Ecwid comme a normal hosted platform au lieu de checking qui integration it’s running on.

Embedding the widget on a custom site and jamais turning on Clean Store URLs

Pourquoi c’est incorrect: le par défaut on quelconque non-native embed est le hashbang formulaire (/#!/product-name/p/123456). Le fragment après # jamais reaches le serveur, qui crée friction pour lien-equity consolidation, serveur-log visibility, et some robot d’exploration/outil compatibility — le exact raison Ecwid construit Clean Store URLs dans le premier placer. Que faire à la place: vérifier l’URL format on day un. Si vous voir /#!/ dans a produit lien, obtenir serveur accès et enable Clean Store URLs (.htaccess/nginx/IIS) plutôt que assuming “Google peut explorer il, donc c’est fine.”

Dropping le base embed code dans Squarespace/Webflow/Weebly et appel il fait

Pourquoi c’est incorrect: que base embed est pure client-side JavaScript avec aucun serveur-rendu fallback unless a developer wires up le Storefront SDK et static-code endpoints. Robots d’exploration voir seulement whatever le widget renders — or fails à rendre. Ce est le spécifique scenario le “Ecwid est mauvais pour SEO” reputation est à propos de. Que faire à la place: soit commission le static-pages construire (Storefront SDK + static-code endpoints) or déplacer le store à Instant Site, le WordPress plugin, or le Wix app, où static rendu ships automatiquement.

Renaming a product title sans setting up a redirection premier

Pourquoi c’est incorrect: Ecwid generates le produit URL depuis le titre, donc a rename crée a brand-new URL pendant que le old un garde fonctionnement — deux actif URLs pour un produit, avec aucun automatic redirection. Que faire à la place: decide on a produit’s titre et URL avant vous publish il. Si vous doit rename on Instant Site, ajouter le manual 301 avant vous enregistrer le nouveau titre; on le embedded widget, éviter renaming publié produits à tout, since redirections reportedly ne sont pas disponible là.

Assuming Wix’s sitemap covers votre Ecwid products

Pourquoi c’est incorrect: Wix’s propre sitemap covers site pages, pas le store pages Ecwid generates — produit et category pages simplement ne sont pas dans il. Que faire à la place: ne pas audit sitemap coverage depuis le Wix side. Confirmer produit-page discovery via Ecwid’s propre static-rendu chemin et Recherche Google Console’s coverage rapport à la place.

Assuming le gratuit plan lets vous edit titles or descriptions

Pourquoi c’est incorrect: on Ecwid’s gratuit plan, meta-balise editing est switched off entirely — c’est pas a manquant paramètre, c’est a plan limitation. Temps spent hunting pour le champ est wasted. Que faire à la place: confirmer le plan (Venture, Entreprise, or Unlimited) avant promising a client sur la page titre/description fonctionner.

Assuming le aucun-code multilingual Instant Site fonctionnalité ajoute hreflang pour vous

Pourquoi c’est incorrect: chaque translated version obtient son propre subpath, mais Ecwid’s propre docs frame chaque as a séparé site vous doit optimize on son propre — rien dans que aucun-code flow auto-liens hreflang entre versions. Skipping ce invites le classic wrong-locale-se classe-pour-le-wrong-requête problème. Que faire à la place: si international matters, ont a developer populate le static-code endpoint’s internationalPages parameter, or ajouter le hreflang annotations par hand.

Courant Ecwid SEO problèmes

Symptom-first lookup pour problems que en réalité montrer up on Ecwid stores, grouped by ce que you’d notice premier.

Produit pages stuck on “Discovered — currently not indexed” dans GSC

Causer: le store est embedded on a custom site or un autre builder sans le Storefront SDK static-pages couche, donc Google est trying à rendre a client-side JS widget avec aucun serveur-rendu fallback et pas toujours succeeding. Corriger: ouvrir Search Console’s Inspection d’URL outil et utiliser “View crawled page” à voir ce que Google en réalité reçu. Si c’est a near-empty shell, le corriger est building le static-code integration (or moving à Instant Site/WordPress/Wix) — pas tweaking meta balises.

Two live URLs showing up pour the même product

Causer: le produit était renamed, qui generates a nouveau URL depuis le nouveau titre sans redirecting le old un. Corriger: vérifier si le old URL encore resolves (il généralement fait avec a 200). On Instant Site, ajouter le manual 301 depuis le old URL à le nouveau un. On le embedded widget où redirections reportedly ne sont pas disponible, revert le titre à arrêter le duplication, or accept le split et empêcher future renames.

Hashbang URLs showing up in Google’s index au lieu de clean URLs

Causer: Clean Store URLs était enabled après le hashbang version était déjà indexé, et le old /#!/ URLs étaient jamais redirigé or canonicalized à le nouveau clean paths. Corriger: confirmer les deux URL formulaires resolve, ajouter redirections or a balise canonical depuis le hashbang version à le clean un, et resubmit le sitemap dans Recherche Console. Recheck indexation status après a quelques weeks avec le Google Indexer Checker.

Résultats enrichis Tester montre aucun données structurées, or flags it as invalid

Causer: on a custom/autre-builder embed, Ecwid sert Microdata seulement (pas JSON-LD), qui est le older, plus erreur-prone format — or le widget simplement n’a pas finish rendu quand le tester exploré il. Corriger: exécuter lune page via Google’s Résultats enrichis Tester or le Schema Validator directement. Vous ne peut pas edit Ecwid’s auto-generated markup, donc si c’est genuinely broken le realistic corriger est moving à a native integration (Instant Site/WordPress/Wix) où JSON-LD + Microdata les deux ship.

Product/category pages manquant from le sitemap on a Wix store

Causer: Wix’s propre sitemap seulement covers site pages, pas le store pages Ecwid generates — ce est attendu behavior, pas a bug. Corriger: arrêter looking à Wix’s sitemap pour produit coverage. Confirmer ceux pages sont étant découvert via Ecwid’s static-rendu chemin via Search Console’s coverage rapport au lieu de via sitemap inclusion.

Meta title/description fields won’t enregistrer

Causer: le store est on Ecwid’s gratuit plan, qui bloque sur la page SEO champ editing entirely. Corriger: vérifier le plan tier dans le Ecwid admin. Editing titles et descriptions exige Venture, Entreprise, or Unlimited — il y a aucun workaround on gratuit.

Qui Ecwid SEO chemin s’applique to ce store?

Ecwid’s SEO behavior isn’t constant — it branches almost entirely on how the store is integrated. Réponse ce premier avant diagnosing anything sinon.

AI prompts pour Ecwid SEO fonctionner

Copy-paste prompts pour le spécifique diagnostic et drafting tasks ce article covers. Paste dans le entrée décrit, et vérifier le AI’s sortie contre le article avant acting on il — ces prompts aider vous organize ce que vous déjà know, ils ne pas remplacer verifying il yourself.

1. Diagnose qui URL format a product page is en réalité en utilisant

I'm checking an Ecwid product page's URL for SEO. Here's the URL:
[paste the product page URL]

Tell me: is this the default hashbang format (contains /#!/), the Clean Store URLs
format, or a custom-slug format? If it's the hashbang format, explain in plain
language what that means for how a browser and a search engine treat everything
after the # symbol.

2. Vérifier a static-code API réponse pour canonical and hreflang fields

Here's the JSON response from Ecwid's static-code endpoint for one of my product
pages:
[paste the raw JSON response]

Tell me whether the canonicalUrl field is populated and what it points to, whether
hrefLangHtml is present and non-empty, and list any of these fields that appear
empty or missing: canonicalUrl, hrefLangHtml, jsonLDHtml, metaDescriptionHtml,
ogTagsHtml.

3. Spot renamed produits creating duplicate URLs

Here's a CSV export of my Ecwid product titles and their current URLs:
[paste the CSV, or a list of "title, url" pairs]

Cross-reference this against my old product export if I have one, or just flag any
product whose URL doesn't match what its current title would generate (Ecwid builds
URLs from titles). List each mismatch as a likely renamed product that may have an
orphaned old URL still live.

4. Draft plan-gated meta titles et descriptions pour a batch de produits

I'm on an Ecwid paid plan and can edit meta titles and descriptions. Here's a list of
products with their name, category, and one key selling point:
[paste a list: "product name | category | selling point"]

Write a concise meta title and meta description for each product, written for a
shopper who's already searching for this kind of product by name. Front-load the
identifying details. Treat roughly 60 title characters and 155 description
characters only as display-preview heuristics, not Google limits, and flag anything
that should be checked in the intended language/script and on mobile.

Testez vos connaissances: Ecwid SEO

Five rapide questions on how SEO fonctionne on Ecwid. Pick an réponse pour chaque, alors vérifier.

Journal des modifications