Ecwid SEOガイド

要点 — Ecwid（現在の「Ecwid by Lightspeed」）はShopifyやBigCommerceのような完全なstore platformではなく、既存サイトへ組み込む小さなstore widgetです。JavaScript製のため、SEO向け機能の多くはInstant Site、公式WordPress plugin、公式Wix appの3構成だけで自動的に有効になります。それ以外ではSEO実装を自分で補います。

「Ecwid SEO」の意味

Ecwidは「E-commerce widget」の略です。Shopifyのようにstore全体をhostするのではなく、WordPress blog、Wix、Squarespace、独自HTMLなど既存pageへsnippetを貼り、catalog、cart、checkoutをpage内に描画します。

Ecwidには独自builderのInstant Siteもあり、サイト全体としても使えます。「他社site上のwidget」か「site全体」かでSEO挙動が大きく異なる点を常に区別します。

「Ecwid SEO」とは、Ecwidで動くstoreの商品／category pageを発見、crawl、index、順位付けさせる通常のSEO作業です。

すべてを左右する一つの条件

storeはJavaScriptで読み込まれます。GoogleはJavaScriptを読めるため、それ自体は問題ではありませんが、実際のcrawlable pageを見せる追加処理が必要です。Ecwidが自動処理するのは次の3構成だけです。

• Instant Site（Ecwid独自builder）
• 公式WordPress plugin
• 公式Wix app

この3構成では商品／category pageのplain HTML copy、clean URL、sitemapが自動提供されます。独自HTML、Squarespace、Weeblyなどでは#!を含むURLのJavaScript widgetが基本で、sitemapとclean URLを自分で用意します。

制御できること／できないこと

意外に思われやすい点は次の通りです。

• Free planではSEO編集不可。 titleとmeta descriptionを編集するにはVenture、Business、Unlimitedのpaid planが必要です。
• image alt textは商品名が既定ですが上書き可能。 imageごとにcustom alt textを設定し、gallery写真のcaptionとして表示できます。
• native blogなし。 SEO記事は別のblogで公開し、storeへlinkします。

最も多い誤解

正反対の2つの説はいずれも誤りです。“Ecwid handles all SEO automatically, so there’s nothing to do.” (翻訳) 「EcwidがSEOをすべて自動処理するので作業は不要」はInstant Site／WordPress／Wixに限られます。“Ecwid uses those weird #! links so Google can’t find it at all.” (翻訳) 「奇妙なhashbang linkなのでGoogleは発見できない」も誤りで、Googleはcrawlできます。ただし理想的ではないため「Clean Store URLs」を有効にします。

正確なURL形式、static HTML rendering、canonical／hreflang、商品名変更によるduplicate URLまで必要ならAdvancedタブへ進んでください。

要点 — Ecwidは既定ではhosted siteでなくJavaScript storefront widgetです。clean URL、crawlable static HTML、自動sitemap／robots.txtはInstant Site、WordPress plugin、Wix appに限定されます。それ以外はhashbang URL（/#!/product-name/p/123456）、SSR fallbackのないclient rendering、DIY sitemapが既定で、developerがStorefront SDKとstatic-code endpointを接続します。canonical／hreflangはAPI fieldにありますがstatic rendering時だけ出力され、no-code multilingual Instant Siteはhreflangを自動linkしません。structured dataは自動ですが編集不可で、Instant Site／WordPressはJSON-LD+Microdata、それ以外はMicrodataのみです。Free planではmeta tagを編集できず、embedded widgetでは301を作れないとの報告があり、native blogもありません。

Widgetかsiteかがすべてを決める

Ecwidは固定的なSEO挙動を持つShopify／BigCommerce型のhosted platformではありません。「E-commerce widget」（Lightspeedによる買収後はEcwid by Lightspeed）として既存pageへ埋め込み、catalog、cart、checkoutをclient-sideでrenderします。一方、hosted builderのInstant Siteならsite全体にもなります。

診断前に必ず「Instant Site／WordPress／Wix経路か、それ以外へのembedded widgetか」を確認します。Ecwidが宣伝するSEO機能のほぼすべては前者に限定されます。hostに関係なく挙動が概ね一定のShopify／WooCommerceと違い、Ecwidはhostにより形が変わります。

自動処理（Instant Site + WordPress + Wix）： crawler向けstatic HTML、clean URL、自動sitemap、Instant Siteの自動robots.txt、完全なJSON-LD structured data、canonical tag。

自分で処理（custom／他builder）： server rewrite ruleによるclean URL、sitemap生成、Storefront SDKによるstatic rendering、canonical／hreflang tagが配信されない可能性への対処。

EcwidにSEOが弱い評判がある理由

Ecwid自身は理由を、“Search engines do not always index dynamic websites well. To ensure they index Ecwid stores, we use special technology. If you sell with Ecwid Instant site or use WordPress or Wix plugin, Ecwid creates a static HTML copy for every product and category page in your store, then gives this copy to a search engine.” (翻訳) 「検索エンジンはdynamic websiteを常に適切にindexするとは限らない。Instant SiteまたはWordPress／Wix pluginでは、全商品／category pageのstatic HTML copyを作って検索エンジンへ渡す」と説明しています。(EcwidのSEO対応)

対策は3integration限定です。他はserver-rendered fallbackのないclient-side JS widgetです。developer資料も、“If your website is based on Wix or WordPress site builders, use our official integrations… These integrations have static store pages enabled out of the box. And if you build a storefront on another CMS or a custom website, use our Storefront SDK and Static code endpoints to set up static pages for your website.” (翻訳) 「Wix／WordPressは公式integrationを使えばstatic store pageが標準で有効。他CMS／custom websiteではStorefront SDKとStatic code endpointで設定する」としています。(Static store pages)

したがってSquarespace、Weebly、Webflow、custom pageへwidgetだけを埋め込みstatic layerを作らない構成では、現在もclient renderingの問題が残ります。base embedは実際にclient-renderedです。

<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>

これがstorefront全体です（storefront widgetのdynamic loading）。商品をcrawlerが見られるかはJavaScript renderingに依存します。これは JavaScript SEO の問題であり、static HTMLが重要な理由です。

URL structure — 最も微妙で重要な事実

EcwidのURL形式はintegration方法だけで決まります。資料は*“Ecwid generates different URL formats based on your website’s setup and the features you have enabled.”* (翻訳) 「website setupと有効な機能に応じて異なるURL形式を生成する」と説明しています。(better URLによるcustom website SEO)

hashbang（/#!/）形式は現在も既定で、古い名残ではありません。Instant Site／native WordPress／Wix以外ではClean Store URLsを明示的に有効化します。custom siteでは*“you must have: Access to its server rewrite rules [and] HTML code of the store page”* (翻訳) 「server rewrite ruleとstore pageのHTML codeへのaccess」が必要で、Apache .htaccess、Nginx server block、IIS URL rewrite moduleを使います。(Enable Clean Store URLs on a custom website)

Instant Site、WordPress、Wixでは*“SEO-friendly URLs automatically.”* (翻訳) 「SEO-friendly URLを自動提供」します。商品／categoryのcustom slugをUIで設定できるのは新Instant SiteまたはWordPressで、他builderはREST APIを使います。(Ecwid site／storeのSEO改善)

#以後のfragmentはbrowserからserverへ送られないため、server log、crawler／tool互換性、link equity統合、social previewに摩擦が生じます。Googleは#! URLをrenderできますが新規導入を推奨していません。「crawlできる」で済ませずClean Store URLsを有効にします。

Crawlabilityとrendering — static store page

Instant Site、WordPress、Wixでは商品／category pageのpre-rendered static HTML copyをcrawlerへ返し、人にはlive JS widgetへ切り替えます。これによりcleanにcrawlできます。

他ではdeveloperが実装します。REST endpoint（storefront.ecwid.com/product-page/{storeId}/{productId}/static-codeとcategory／home版）からpre-rendered HTMLを取得してvisible containerへ挿入し、load後にStorefront SDK（ec.storefront.staticPages.*、StaticPageLoader.switchToDynamicMode()）でlive widgetへ渡します。(Static store pages) 未実装ならcrawlerが見られるのはclient-side widgetのrender結果だけです。

実務上、Squarespace、Webflow、Weebly、hand-built pageへ置いただけのEcwid widgetは、既定ではhashbang URLとSSR fallbackのないpure client-side JavaScriptです。非WordPress／Wix／Instant Site embedでSEO評価が悪い理由は現在もここにあります。

Sitemapとrobots.txt

自動生成もintegration限定です。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”* (翻訳) 「sitemap.xmlを自動生成し、新page／商品を早くindexできるがGoogleへの手動送信は必要」と説明し、Venture、Business、Unlimitedで提供します。(EcwidのSEO対応) Instant Siteではrobots.txtから内部送信されますが、Search Consoleへの送信も有効です。(Submitting a sitemap to Google)

custom websiteは*“you can generate a sitemap for your store pages by using a third-party service.”* (翻訳) 「third-party serviceでstore pageのsitemapを生成できる」というDIY経路です。WordPress v5.5+ pluginは自動生成し、旧版はYoast等が必要です。Wix sitemapはsite pageだけで*“and not the store pages with your products, categories, etc.”* (翻訳) 「商品／category等のstore pageは含まない」ため、Wix + Ecwidの商品発見はstatic-rendering経路へ依存します。

robots.txtもInstant SiteではEcwidが管理し、商品／categoryはindexable、visitor固有のcart／search resultは除外します。既存siteへのembedではhost CMS／hosting accountが所有し、Ecwid側に管理対象はありません。widgetの置き場所でownerが変わります。

Canonical tagとduplicate content

static-page REST responseはcanonicalUrl（“Canonical URL for this page” (翻訳) 「このpageのcanonical URL」）をhtmlCode、metaDescriptionHtml、ogTagsHtml、jsonLDHtml、hrefLangHtmlとともに返します。(商品page用static code) static renderingが動くInstant Site／WordPress／Wixでは自動処理されます。static／SSR layerなしのcustom JS embedではcrawlerへcanonical tagが配信されない場合があります。

より深刻なのは商品名変更です。titleからURLを作るため、商品titleを変えると新URLができ、旧URLは自動redirectされず、1商品に2つのlive URLが残ります。Instant Siteはmanual 301を追加できますが、embedded widgetではredirectを作れないとの報告があります。Style Factoryも*“can’t create redirects,”* (翻訳) 「redirectを作れない」とし、URL変更時にはredirectが必要だと指摘します。(Style Factory) 公開前にURLを決め、可能ならrename前に301を設定します。基礎は canonicalization を参照してください。

Structured data

Ecwidは全integrationでschema.org markupを自動生成しますが、“Ecwid uses Schema.org vocabulary to annotate product information and adds structured data to all store pages automatically. For Ecwid Instant Site and stores on WordPress sites, structured data is generated using JSON-LD and Microdata markup. For all the other websites, only the Microdata format is used. As of now, it’s impossible to edit or remove the structured data.” (翻訳) 「全store pageへ自動追加し、Instant Site／WordPressはJSON-LDとMicrodata、他はMicrodataのみで、編集／削除不可」と説明しています。(EcwidのSEO対応)

実務上、schema customizationやFAQ／Video markup追加はできず、形式もintegrationで異なります。Microdataは古くerror-proneですがGoogleは読めます。widgetでもrich resultは可能ですが、native integrationのmarkup品質が高く、どちらも編集不可です。 “a widget can’t do rich results” (翻訳) 「widgetではrich resultを出せない」という説は誤りです。

Meta tag、alt text、plan制限

custom title、meta description、slugはVenture、Business、Unlimitedが必要で、free-plan merchantはmeta tagを一切編集できません。 best practiceではなくhard limitとして最初に確認します。

image alt textは商品名が既定ですが、商品／variation imageごとに最大125文字のcustom textを設定できます（Catalog → Products → image → Actions → Edit alt text）。Instant SiteではWebsite → Edit Site → Product → Product Details → Image galleryからcaption表示も可能です。(image alt textとvisible description) 「変更不可」とする古いthird-party reviewは現在は誤りです。商品名で十分な場合もありますが、image SEO とaccessibilityのため説明的にできます。

Multilingualとinternational SEO

Instant Siteのno-code multilingual機能はclassic hreflangではありません。各languageは固有subpathを持ち、“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.” (翻訳) 「各翻訳版はlanguage code付きsubpathを持つ独立siteとして扱われ、個別最適化が必要」と説明されます。(Creating a multilingual site)

no-code資料にhreflangの自動linkはありません。一方APIのstatic-code endpointはinternationalPages parameterを受け、hrefLangHtmlを返します。(商品page用static code) つまりmerchantだけで使うmultilingual Instant Siteではlanguage間hreflangが自動生成されない可能性が高く、wrong locale問題を避けるにはdeveloperがinternationalPagesを使うか手動annotationを追加します。hreflang の一般指針も参照してください。

Ecwidがしないこと

• Native blogなし。 Style Factoryは*“There’s no built-in blogging engine. For content marketing or SEO blogging, you’ll need to host your blog separately (on WordPress, for example) and link to it.”* (翻訳) 「built-in blogはなく、別hostしてlinkする必要がある」と説明します。Instant Siteのworkaroundもproduct categoryをpostに使う不自然な方法です。contentが重要なら別blogを使います。
• non-Instant-Site embedのredirect toolは限定的。 widget版はredirect不可との報告があります。
• structured dataは編集不可。 一方image alt textは現在編集できます。

Ecwidと他platformの比較

弱点はembed先でSEO挙動が変わること、native blogがないこと、widget版にredirectがないこと、free tierのSEO編集lockです。一方、全構成でstructured dataを自動提供し、HTTPS／mobile renderingは問題なく、Instant Site／WordPress／Wixのstatic-renderingはJavaScript crawlabilityを実際に解決します。

Ecwidは既存siteへ安価にstoreを追加する用途に優れます。WordPress、Wix、Instant SiteならSEO baselineは堅実です。他builder／custom siteへembedしSEOを重視するなら、static page、clean URL、DIY sitemap、hreflangを実装するか、Shopify、BigCommerce、WooCommerce、Magento、PrestaShopなど用途に合うplatformを検討します。

AI要約

Advanced版の要点です。

• Ecwidはhosted siteでなくembeddable JavaScript widgetが既定です。 既存WordPress、Wix、Squarespace、custom pageへstorefrontを貼ります。独自builderのInstant Siteならsite全体にもなります。
• SEO向け自動処理は3integration限定： Instant Site、WordPress plugin、Wix appはstatic HTML、clean URL、自動sitemap、Instant Siteのrobots.txtを得ます。
• custom embedのURL既定はhashbang /#!/product-name/p/123456です。Clean Store URLsには他環境でserver rewrite ruleが必要です。
• Static renderingは3native integrationだけが標準です。custom siteではStorefront SDK + static-code REST endpointを接続します。
• Sitemap／robots.txtは主にInstant Siteとmodern WordPressが自動処理し、custom siteはDIYです。Wix sitemapはEcwid商品pageを除外します。
• Canonical／hreflang API field（canonicalUrl、hrefLangHtml）はstatic rendering時に出力され、no-code multilingual機能はhreflangを自動linkしません。
• Structured dataは自動・編集不可： Instant Site／WordPressはJSON-LD+Microdata、他はMicrodataのみです。
• 商品renameはredirectなしの新URLを作ります。 Instant Siteはmanual redirect、embedded widgetはredirect不可との報告があります。
• Free planはmeta tag編集不可、native blogなし。 image alt textは現在imageごとに上書きできます。custom embedでSEOが重要ならdeveloper実装を行うか、用途に合うplatformを使います。

公式ドキュメント

Ecwid／LightspeedとGoogleの一次資料です。

Ecwid / Lightspeed

• EcwidのSEO対応 — static copy、clean URL、sitemap、robots.txt、structured data、ALT tagの概要。
• image alt textとvisible description — imageごとのalt text上書き方法。
• Ecwid site／storeのSEO改善 — meta tag、custom slug、301、sitemap、SSL、plan制限。
• Submitting a sitemap to Google — Instant Site／own website、WordPress、Wixの違い。
• Ecwid Instant Siteのmultilingual site作成 — language別subpathとSEO。
• Lightspeed eComのSEO対応 — Lightspeed eComがEcwidであることを確認できるmirror。

Ecwid developer docs

• Static store pages — 標準static renderingの範囲とStorefront SDK swap。
• 商品page用static code — canonicalUrl、hrefLangHtml、internationalPages。
• better URLによるcustom website SEO — 3段階のURL比較。
• Enable Clean Store URLs on a custom website — server rewrite rule要件。
• storefront widgetのdynamic loading — base embed code。

Google

• Deprecating our AJAX crawling scheme — #! URLをrenderできるが新規導入を推奨しない2015年の説明。
• Structured data intro — MicrodataよりJSON-LDを推奨する理由。

情報源からの引用

Ecwid／Lightspeed、Google、Ecwid固有の知見を提供したpractitionerの記名発言です。deep link対応pageは引用箇所へ直接linkします。

Google — hashbang／AJAX crawling（deep-link確認済み）

• “In short: We are no longer recommending the AJAX crawling proposal we made back in 2009.” (翻訳) 「要するに、2009年に提案したAJAX crawling方式はもう推奨していません。」— Google Search Central Blog、2015年10月14日。現在も#!をrenderできますが新規導入は非推奨です。 引用箇所へ

Ecwid developer docs — URL structureとstatic page（deep-link確認済み）

• “When you add an Ecwid store to a custom website, it creates dynamic pages for the catalog” (翻訳) 「custom websiteへEcwid storeを追加するとcatalogのdynamic pageを作る」— hashbang URLが既定となるsetupです。 引用箇所へ
• “To enable Clean Store URLs on a custom website, you must have:” (翻訳) 「custom websiteでClean Store URLsを有効にするには必要条件がある」— server rewrite ruleとstore page HTMLへのaccessです。 引用箇所へ
• “If your website is based on Wix or WordPress site builders, use our official integrations” (翻訳) 「Wix／WordPress builderなら公式integrationを使う」— 標準static renderingの範囲を示します。 引用箇所へ

Ecwid support docs — SEO概要（support.ecwid.comは自動取得を遮断するためrendered pageで確認。最終利用前にlive pageで再確認） 引用先は#:~:text= fragmentで自動確認できないためlive pageで確認します。

• “Search engines do not always index dynamic websites well. To ensure they index Ecwid stores, we use special technology.” (翻訳) 「dynamic websiteを常に適切にindexするとは限らないため特別な技術を使う」— EcwidのSEO対応。
• “Ecwid uses Schema.org vocabulary to annotate product information and adds structured data to all store pages automatically… For all the other websites, only the Microdata format is used. As of now, it’s impossible to edit or remove the structured data.” (翻訳) 「全store pageへ自動追加し、その他のwebsiteはMicrodataのみ、編集／削除不可」— 同記事。
• “Ecwid automatically generates a sitemap.xml file… You still need to submit a sitemap to Google manually.” (翻訳) 「sitemap.xmlを自動生成するがGoogleへ手動送信が必要」— 同記事。

Practitioner — Ecwid固有の知見（Style Factoryからのrelay。sourceで再確認）

• “you can’t create redirects in the widget (embedded) version of Ecwid either, which is not ideal at all because if you change a URL, a redirect is necessary to tell Google where the new page lives.” (翻訳) 「embedded widget版ではredirectを作れず、URL変更時に新pageをGoogleへ伝えられないため望ましくない。」出典
• “Changing alt text (the description of images that search engines and screen readers see) isn’t possible, though — you’re stuck with whatever Ecwid generates for you automatically.” (翻訳) 「alt textを変更できず自動生成値に固定される。」出典 — 現在は古い情報： Ecwid公式は最大125文字のcustom alt textを案内しています。現行資料
• “There’s no built-in blogging engine. For content marketing or SEO blogging, you’ll need to host your blog separately (on WordPress, for example) and link to it.” (翻訳) 「built-in blogはなく、別hostしてlinkする必要がある。」出典

Ecwid SEO checklist

impact順です。最初の質問「どのintegrationか」がlistの半分を決めます。

まずsetupを特定

• Instant Site、WordPress plugin、Wix app、custom／other embedのどれか確認する。以下はすべてここで分岐します。

High impact

• Clean Store URLsを有効化。 Instant Site／WordPress／Wixは自動、custom siteはserver rewrite rule（.htaccess／nginx／IIS）とJS flagを追加し、hashbang /#!/を残さない。
• Crawlerへreal HTMLを返す。 custom embedはStorefront SDK + static-code endpointを接続するかnative integrationへ移す。
• Sitemapを作成・送信。 Instant Site／modern WordPressは自動、custom siteはthird-party generatorを使いGSCとBingへ送信。Wix sitemapはEcwid商品を除外します。
• rename前にredirectを計画。 Instant Siteはtitle変更前にredirectを設定し、redirect不可のembedded widgetではrenameを避ける。

標準setup

• title／meta description編集が必要ならVenture／Business／Unlimited planを使う。
• homepage、主要商品、主要categoryのtitle／descriptionを書く。
• 自動生成structured dataをGoogle Rich Results Testで確認する。
• 商品／category pageにcanonical tagがあるか確認する。
• contentが重要ならWordPress等にreal blogを用意する。

International（multilingualのみ）

• language版間にhreflangがあるか確認する。no-code Instant Siteは自動追加しないためinternationalPagesまたは手動annotationを使う。
• Ecwidは各版を別siteとして扱うためtitle／descriptionも個別最適化する。

Storefront ownership framework

Ecwid auditでは4種類の出力についてownerを決めます。

1. Host page： Wix、WordPress、custom、Instant Siteの周囲route。
2. Store route： crawlerへ公開するcleanな商品／category URL。
3. Search signal： canonical、metadata、structured data、internal link。
4. Discovery file： sitemapとrobots ruleを公開するsystem。

hostとstoreが同じ責任を主張すると重複／signal conflictが生じ、どちらも持たないと商品URLがsitemapから消えるかmarkupなしで出荷されます。設定変更前に各出力のownerを1つ記録します。

Ecwid SEO cheat sheet

Integration別の自動処理

URL形式

Plan制限（on-page SEO）

• Free plan：title／meta descriptionを編集不可。
• Venture／Business／Unlimited：custom title、description、slug、sitemap。

重要なAPI field（static-code endpoint）

• canonicalUrl — canonical tag
• hrefLangHtml — hreflang tag（internationalPages parameterが必要）
• jsonLDHtml／metaDescriptionHtml／ogTagsHtml — その他のhead要素

避けること

• custom embedでhashbang /#!/を残さずClean Store URLsを有効化する。
• redirectがないembedded widgetで商品renameをしない。
• Wix sitemapにEcwid商品が含まれると想定しない。
• no-code multilingual機能がhreflangを追加すると想定しない。
• structured dataは編集できない。一方、既定が不十分なら現在はimageごとにcustom alt textを設定できます。

Ecwid URL variantを比較する

疑わしい商品／category variantをurls.txtへexportし、statusと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

出力を商品別にgroup化します。各public variantは一貫して統合するか明確に異なる目的を持つべきで、status codeだけからpreferred URLを推測しません。

Ecwid SEO用tool

• Google Search Console — sitemap送信、URL Inspectionによるrender確認、Page Indexingでhashbang／duplicate URLを監視。
• Bing Webmaster Tools — 2つ目のsitemap送信とcrawl visibility。
• Google Rich Results Test／Schema Markup Validator — 編集不可な自動structured data、特にcustom embedのMicrodataをvalidate。
• GSC URL Inspectionの「View crawled page」 — crawlerがreal HTMLとempty JS shellのどちらを得るか確認。
• Screaming Frog／Ahrefs Site Audit（JS rendering有効）— hashbang、rename重複、missing canonical、JSなしでblankになるpageを検出。
• XML sitemap generator — custom siteでEcwidが作らないsitemapを生成。
• Server rewrite tool — Apache .htaccess、Nginx config、IIS URL RewriteでClean Store URLsを有効化。

時間を使う価値のある資料

関連するsite内記事

• JavaScript SEO — Ecwid client-side widgetのrendering問題。
• Canonicalization — canonicalUrlとrename duplicate URLの仕組み。
• hreflang — no-code multilingual Instant Siteが追加しないもの。

Ecwid／Lightspeed公式

• EcwidのSEO対応 と Ecwid site／storeのSEO改善 — 中心となるhelp記事。
• Static store pages — custom siteでcrawlable HTMLを提供するdeveloper経路。

業界資料

• Ecwid review：長所、短所、価格、代替案（Style Factory） — widgetのredirect不可、native blogなしの出典。alt-text固定の指摘は現在古い情報です。
• image alt textとvisible description — custom alt textとgallery caption。
• Ecwid Review (ecommerce-platforms.com) — renameによるduplicate URL risk。
• Ecwid Review 2026 (Tooltester) — native platformよりSEOが弱いという独立review。
• Ecwid by Lightspeed Ecommerce Shopping Cart — WordPress.org plugin page — 20 000+ active installationの公式plugin。
• 全Ecwid store向け新Clean URL（Ecwid blog） — hashbang問題とClean Store URLsの経緯。

Ecwidで実際に起きる誤り

共通原因は、integrationを確認せずEcwidを通常のhosted platformとして扱うことです。

Custom siteへwidgetを埋め込みClean Store URLsを有効化しない

誤りの理由： non-native embedの既定はhashbang（/#!/product-name/p/123456）で、#以後はserverへ届かずlink equity統合、server log、tool互換性に摩擦が生じます。代わりに： 初日にURL形式を確認し、/#!/があればserver accessを得て.htaccess／nginx／IISでClean Store URLsを有効化します。「Googleがcrawlできる」だけで放置しません。

Squarespace／Webflow／Weeblyへbase embed codeだけを置く

誤りの理由： developerがStorefront SDKとstatic-code endpointを接続しなければpure client-side JavaScriptで、crawlerはwidgetのrender結果しか見られません。代わりに： static-pages実装（Storefront SDK + static-code endpoint）を行うか、標準static renderingがあるInstant Site、WordPress plugin、Wix appへ移します。

Redirectを準備せず商品titleをrenameする

誤りの理由： titleから新URLが作られ、旧URLもliveのままで自動redirectされません。代わりに： 公開前にtitle／URLを決めます。Instant Siteでrenameするなら保存前にmanual 301を追加し、redirect不可と報告されるembedded widgetでは公開済み商品のrenameを避けます。

Wix sitemapがEcwid商品を含むと思う

誤りの理由： Wix sitemapはsite pageだけでEcwidの商品／category pageを含みません。代わりに： Wix側のsitemapだけでauditせず、Ecwid static-rendering経路とGoogle Search Console coverageで商品発見を確認します。

Free planでtitle／descriptionを編集できると思う

誤りの理由： free planではmeta-tag編集が完全に無効で、setting欠落ではなくplan制限です。代わりに： on-page title／description作業を約束する前にVenture、Business、Unlimitedのどれか確認します。

No-code multilingual Instant Siteがhreflangを追加すると思う

誤りの理由： 各翻訳版は固有subpathを持ちますが、no-code flowはlanguage版間をhreflangで自動linkしません。wrong localeがrankする問題を招きます。代わりに： internationalが重要ならstatic-code endpointのinternationalPagesをdeveloperが設定するか、hreflang annotationを手動追加します。

Ecwid SEOでよくあるissue

Ecwid storeで実際に見える症状から原因を引けるように整理します。

商品pageがGSCの「Discovered — currently not indexed」に残る

原因： custom site／他builderにStorefront SDK static-pages layerがなく、GoogleがSSR fallbackなしのclient-side JS widgetをrenderできない場合があります。修正： Search Console URL Inspectionの「View crawled page」で受信内容を確認します。near-empty shellならmeta tagでなくstatic-code integrationを構築するかInstant Site／WordPress／Wixへ移します。

同一商品に2つのlive URLが表示される

原因： renameにより新title由来URLができ、旧URLをredirectしません。修正： 旧URLが通常200で解決するか確認し、Instant Siteでは旧→新へmanual 301を追加します。redirect不可のembedded widgetではtitleを戻すか分裂を受け入れ、今後のrenameを防ぎます。

Clean URLでなくhashbang URLがGoogle indexに出る

原因： hashbang版のindex後にClean Store URLsを有効化し、旧/#!/を新clean pathへredirect／canonicalizeしていません。修正： 両形式の解決を確認し、hashbang→cleanへredirectまたはcanonicalを追加してSearch Consoleへsitemapを再送信します。数週間後に Google Index Checker で再確認します。

Rich Results Testでstructured dataがない／invalidになる

原因： custom embedでは古くerror-proneなMicrodataだけを返すか、test時にwidget renderingが完了していません。修正： Google Rich Results Testまたは Schema Validator で直接確認します。自動markupは編集できないため、本当に壊れていればJSON-LD + Microdataを提供するInstant Site／WordPress／Wixへの移行が現実的です。

Wix storeのsitemapに商品／category pageがない

原因： Wix sitemapはsite pageだけを対象とし、Ecwid store pageを含まない正常仕様です。修正： Wix sitemapで商品coverageを探さず、Search Console coverageからEcwid static-rendering経路で発見されているか確認します。

Meta title／description fieldを保存できない

原因： Ecwid free planはon-page SEO field編集を全面的に遮断します。修正： Ecwid adminでplanを確認します。title／description編集にはVenture、Business、Unlimitedが必要で、free planにworkaroundはありません。

このstoreに適用するEcwid SEO経路

EcwidのSEO挙動は一定でなくintegration方法でほぼ分岐します。他を診断する前にここへ回答します。

Ecwid SEO作業用AI prompt

この記事が扱う診断／draft作業用のcopy-paste promptです。指定inputを貼り、実行前にAI出力を記事内容へ照合してください。既知情報の整理を助けますが、自分での検証に代わりません。

1. 商品pageが実際に使うURL形式を診断する

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. Static-code API responseのcanonical／hreflang fieldを確認する

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. Renameでduplicate URLを作った商品を検出する

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. Plan制限を踏まえて商品batchのmeta title／descriptionをdraftする

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.

理解度test：Ecwid SEO

EcwidのSEO挙動に関する5問です。回答を選び、結果を確認してください。

変更履歴