ECサイトのSEO対策15選｜商品ページとカテゴリページの改善方法【2026年版】

ECサイトの担当者の方から、「商品は増えているのに、広告と指名検索以外からの売上が伸びない」という相談が増えています。ECサイトのSEOは、商品説明を長く書き直す作業ではありません。カテゴリと商品のどちらでキーワードを受けるか、絞り込みやバリエーションで生成されるURLをどう扱うか、価格や在庫の表示と構造化データをどう一致させるかという、サイト構造と商品情報の設計が中心になる領域です。本記事では、ECサイト内で実施すべき15の施策を、優先順位、担当の分け方、既存売上を落とさない実装手順、KPIまで含めて整理しました。読み終えたときに、自社サイトのどのページから直すべきかが具体的に見えるはずです。

この記事でわかること

• ECサイト内SEOの優先順位の決め方
• カテゴリページと商品ページのキーワード分担
• 絞り込み・バリエーション・在庫切れURLの整理方法
• 15施策の担当分け（運用・開発・外部）
• 既存売上を落とさない変更手順とKPI

ECサイト内のSEO対策はどの順番で進めますか？

商品説明、カテゴリ、システムのどれから直すべきかは、多くの担当者が最初に迷う点です。結論から言えば、まず「検索エンジンが商品を見つけられない・誤解する問題」を直し、その後に「検索需要へ応える改善」へ進みます。具体的には、誤ったnoindexやrobots.txtによるブロック、重要商品の孤立、価格と在庫の不一致、購入できないページの大量インデックスを先に解消し、次にカテゴリ設計と商品情報の充実へ着手する順番です。

なお、本記事が扱うのはECサイト内のページと機能に限定した対策です。キーワード選定の調査手順、記事コンテンツの制作、被リンク獲得、モール内SEO、カゴ落ち対策などのCROは対象外で、それぞれ別記事で扱います。まず、症状から最初に確認すべき場所を早見表で示します。

症状	最初の確認先	主な担当
商品名で検索しても出ない	商品ページのindex状態	運用・SEO
カテゴリ経由の流入が少ない	カテゴリ設計と固有情報	SEO・MD
URL数が商品数より大幅に多い	絞り込み・並べ替えURL	SEO・開発
新商品がなかなか検索に出ない	内部リンクとサイトマップ	開発・SEO
検索結果の価格・在庫が実際と違う	商品マスタと構造化データ	商品管理・開発

※「主な担当」は一般的な分担例です。自社の体制に読み替えてください。

先に直す問題

インデックスと商品情報の事故は、他の施策の効果を打ち消します。次の項目に該当があれば、カテゴリや商品説明の改善より先に対処してください。

最優先で解消する問題

• 誤ったnoindexの設定（重要ページが検索対象外になっている）
• robots.txtによる重要ページ・重要リソースのブロック
• どのページからもリンクされていない重要商品（孤立ページ）
• 画面表示・商品マスタ・構造化データ間の価格と在庫の不一致
• 購入不能なページ（販売終了・空カテゴリ）の大量インデックス

次に直す問題

土台の事故がなければ、検索需要への適合を上げる改善へ進みます。カテゴリと検索意図の不一致、商品情報の不足、絞り込みURLの無制限な生成、表示速度とモバイル操作性が対象です。この順序の理由は単純で、見つけてもらえない状態で情報を充実させても評価される機会がなく、逆に見つかる状態を先に作れば、以降の改善が計測に乗るためです。

改善前に取得するデータ

着手前に、現状を数字で保存します。改善の効果測定と、万一の切り戻し判断の両方に使うためです。

着手前に取得するデータ

• Search Consoleのページ別クリック・表示回数・クエリ
• 自然検索経由の売上・商品閲覧・カート追加・購入（GA4等）
• サーバーログまたはクローラーによるクロールデータ
• 商品数、index可能URL数、サイトマップ送信URL数
• URL別の内部リンクと被リンク

優先順位の全体像はSEO内部対策の全体像も参考になります。ここからは、EC固有の論点に絞って進めます。

商品ページとカテゴリページはどのキーワードを受け持ちますか？

同じキーワードを商品ページとカテゴリページの両方で狙うと、サイト内で評価が分散します。分担の原則はシンプルです。商品名・型番・固有仕様の検索は商品ページ、商品群・用途・条件で比較したい検索はカテゴリページ（または条件別の商品集合ページ）で受けます。

分担の対応を表で整理します。この表の空欄が埋まらないキーワードは、受け皿ページの新設か対策の見送りを検討する対象です。

キーワードの型	例	受け持つページ	購入段階
商品群×属性・用途	メンズ スニーカー／オフィスチェア 腰痛対策	カテゴリページ	比較検討
商品群×スペック	ノートパソコン 16GB	カテゴリまたは条件別集合ページ	比較検討
ブランド×商品群	ブランド名 バッグ	ブランドページ	比較検討
固有商品×型番・仕様	商品名 型番／商品名 サイズ	商品ページ	購入直前
固有商品×購入条件	商品名 在庫／商品名 送料	商品ページ	購入直前
条件×商品群	1万円以下 オフィスチェア／翌日配送 ギフト	条件別集合ページ	購入直前

※キーワードの調査手順は別記事（SEOキーワードの選び方）を参照してください。

カテゴリページが受け持つキーワード

基本形は「商品群 × 用途・属性・悩み・季節・価格帯」です。「敏感肌 化粧水」「お中元 お菓子」のように、複数商品を比較したい意図のキーワードが該当します。検索ボリュームがあるからといって、在庫が続かない条件や他カテゴリと意図が重なる条件でカテゴリを増やすのは避けてください。

商品ページが受け持つキーワード

基本形は「固有商品 × 型番・仕様・色・サイズ・購入条件」です。「ブランド名 商品名」「商品名 価格」「商品名 送料」のように、その商品に決めかけている検索が該当します。この層の受け皿は商品説明の文章量ではなく、仕様・価格・在庫・配送・返品といった購入条件の明確さです。

ブランドページと条件別集合ページが受け持つキーワード

「ブランド名 通販」のような指名×商品群の検索はブランドページ、「幅60cm以下 収納棚」のような具体条件の検索は、後述する絞り込みURLのうち恒久ページ化した条件別集合ページで受けます。どのページで受けるか迷う場合の調査手順はSEOキーワードの選び方にまとめています。

カテゴリページは何を改善すれば検索流入と商品発見につながりますか？

商品一覧が並ぶだけのカテゴリページは、検索エンジンにも購入者にも「何のページか」が伝わりません。改善の柱は、検索意図に合う商品集合、固有のtitleとH1、選択を助ける情報、クロール可能な商品リンクの4点です。ここから施策1〜4として説明します。

施策1：インデックスさせるカテゴリを商品数と検索意図で選ぶ

すべてのカテゴリを検索流入の受け皿にする必要はありません。index対象は次の条件を満たすカテゴリに絞ります。

index対象カテゴリの条件

• 商品が継続して存在する（在庫が切れてもすぐ空にならない）
• 他カテゴリと異なる検索意図を持つ
• 固有の説明と選択基準を提示できる
• 一時的なセール・特集だけの条件ではない

施策2：title、H1、導入文をカテゴリ固有にする

「カテゴリ名 | サイト名」の機械生成だけでは、類似カテゴリとの違いが伝わりません。商品群・主な用途・選択条件を自然な文でtitleと導入文に含め、titleとH1の主題を一致させます。キーワードを羅列した不自然な文章は、読者にも検索エンジンにもマイナスです。

施策3：選び方と比較軸を一覧の前後に配置する

購入判断を変える条件（サイズ、用途、素材、互換性、納期など)を、商品一覧の前後に短く示します。商品カードと同じ情報を長文で繰り返す必要はありません。条件別の下位カテゴリがあるなら、その分岐をここでリンクします。

施策4：全商品へクロール可能なリンクを設ける

サイト内検索でしか到達できない商品は、検索エンジンからも発見されません。メニューからカテゴリ、サブカテゴリ、商品へ<a href>のリンクでたどれる構造を確認してください。JavaScriptのクリックイベントだけで遷移するリンクは、後述するレンダリング確認の対象です。カテゴリ構造の設計はGoogleのECサイト構造の公式ドキュメントが一次情報になります。

商品ページにはどの情報を掲載すれば検索と購入判断に使えますか？

メーカー説明の転載だけの商品ページは、同じ説明文を持つ他店と区別されません。改善の中心は文字数ではなく、購入条件と商品適合性を判定できる情報項目です。施策5〜8として整理します。まず必須項目を一覧にします。

項目	確認する内容	情報の起点
商品名・型番・ブランド	title・H1・パンくず・商品マスタで一致	商品マスタ
固有の説明	用途・選択条件を自社の言葉で追加	運用担当
仕様表	寸法・素材・重量・対応条件と非対応条件	商品マスタ・メーカー公式
価格	税込表示・追加費用の明示	商品マスタ
在庫・納期	在庫状態・発送目安・配送対象地域	在庫システム
送料・返品	送料条件・返品可否・期間・送料負担	運用ポリシー
画像・動画	色・サイズ感・利用場面・同梱物	制作・運用
レビュー	実在する投稿のみ・件数と評価の一致	レビュー基盤

※法令上の表示事項（特定商取引法に基づく表記等）は法務確認を前提としてください。

施策5：商品名、型番、ブランド、固有説明を一致させる

title、H1、パンくず、商品マスタの名称がページごとにばらつくと、検索エンジンは同一商品の判定に迷います。名称を整合させたうえで、メーカー説明の複製ではなく、自社で確認できる用途と選択条件を1〜2段落追加してください。同一商品が複数URLで表示される場合は、先に正規URLを決めます。

施策6：仕様、用途、互換性、サイズを表で示す

仕様は文章より表が確実です。型番、素材、寸法、重量、内容量、対象年齢など商品に必要な属性を使い、対応機種と非対応条件を分けて示します。仕様値の根拠は商品マスタまたはメーカー公式情報で確認し、推測で埋めないでください。

施策7：価格、在庫、送料、納期、返品条件を見える位置に置く

購入直前の検索者が確認するのはこの5点です。税込価格と追加費用、在庫状態、発送目安、返品の可否・期間・方法・送料負担を、スクロールせずに確認できる位置へ置きます。セール価格を比較対象価格と並べる場合は、二重価格表示の要件確認が必要です。商品ページ、カート、商品マスタ、構造化データの値は常に一致させます。

施策8：画像、動画、レビューを商品選択に使える内容にする

画像altは「写っている商品と状態」を説明します。色、サイズ感、利用場面、同梱物を画像で確認できる構成が理想です。レビューは実在する投稿だけを表示し、依頼や編集を行う場合はステルスマーケティング規制の確認が前提になります。評価の集計値を表示する場合は、画面上の評価・件数と一致させてください。

絞り込み、ページネーション、商品バリエーションのURLはどう整理しますか？

ECサイトのSEOで最も事故が起きやすいのがこの領域です。絞り込みと並べ替えの組み合わせはURLを無限に生成し、クロールを浪費させます。一方で、一括のnoindexやcanonicalは検索需要のあるページごと消してしまいます。原則は「検索価値がある組み合わせだけを恒久URLとして残し、それ以外はクロールとindexを制御する」です。判定の目安を表にします。

URLタイプ	例	index方針	理由
カテゴリ・サブカテゴリ	/chairs/office/	index	検索需要の主な受け皿
検索需要のある絞り込み	幅60cm以下の収納棚	恒久ページ化してindex	条件検索の受け皿になる
並べ替え・表示件数	?sort=price&view=100	indexさせない	内容が重複し検索価値がない
複数条件の自由な組み合わせ	?color=red&size=m&sale=1	原則indexさせない	組み合わせ爆発の主因
セッション・追跡パラメータ	?sid=…	生成させない	重複と浪費のみ
ページネーション	/chairs/?page=2	クロール可能に保つ	商品発見の経路

※判定は目安です。変更前に必ず現状の流入・被リンク・canonical選択を確認してください。

施策9：階層とURLをページの役割に合わせる

恒久的で人が読めるURLを使い、セッションID・現在時刻・追跡値を内部リンクへ含めないのが基本です。内部リンク、canonical、サイトマップでURL表記を統一します。URL設計の一次情報はGoogleのECサイトのURL構造ドキュメントです。

施策10：絞り込みと並べ替えURLのindex対象を限定する

検索需要・商品数・固有内容・継続性の4条件を満たす組み合わせだけをindex候補にし、価格順・新着順・表示件数・自由な複数条件は検索流入の受け皿にしません。パラメータは`key=value`形式と順序を統一します。制御方法の選択（canonical・noindex・クロール制御のどれを使うか）は挙動が異なるため、canonicalの安全な設定とnoindexの判断方法を確認してから決めてください。特に、robots.txtでブロックしたURLに置いたnoindexはGoogleが読めない場合があるため、併用の設計は現行挙動の検証が前提です。

施策11：ページネーションと無限スクロールをクロール可能にする

一覧の2ページ目以降が存在しないことにされると、そこに載る商品の発見が遅れます。各ページに固有URLを用意し、次ページを<a href>で順にリンクします。`#`以降だけが変わるURLへの依存は避け、無限スクロールを使う場合もリンクで到達できるページ分割版を用意してください。

施策12：色とサイズ等の商品バリエーションを関連付ける

バリエーションごとにURLを分けるかどうかは、検索意図（色名やサイズで検索されるか）と運用負荷で判断します。分ける場合は、URL、canonical、商品マスタ、ProductGroupとProductの設計をそろえ、存在しない組み合わせをindex可能なURLとして生成しないようにします。canonicalを全バリエーションへ一括変更する前には、必ず現状の流入を確認してください。

施策13：在庫切れと販売終了ページを状態別に処理する

在庫状態によって正解が変わります。一時的な在庫切れはページを維持して入荷予定と代替商品を示す、再入荷しないが代替がある場合は意図が同じか確認して案内する、完全終了で代替がない場合は流入・被リンク・保存要件を確認したうえで404または410を検討する、という分岐です。意図の異なるページやトップページへの一括リダイレクトは避けてください。価格と在庫の表示は、構造化データと商品フィードにも同期させます。

ここまでのURL整理は、既存流入を持つページに触れるため影響が大きい領域です。自社のURL状況を第三者の視点で確認したい場合は、診断もご利用いただけます。

内部リンクで優先商品とカテゴリをどう伝えますか？

パンくずと関連商品だけでは、サイト内の相対的な重要度は伝わりません。施策14として、カテゴリ階層・パンくず・関連商品・代替商品・人気商品を、検索意図と事業優先度に合わせて設計します。

施策14：カテゴリ、パンくず、関連商品を一つの階層へそろえる

基本構造は次の通りです。トップから重要カテゴリへ、カテゴリからサブカテゴリと商品へ、商品から上位カテゴリ・関連商品・代替商品へリンクし、パンくずの画面表示とBreadcrumbListを一致させます。全ページから全商品へリンクするのではなく、関係性とユーザーの選択を優先してください。孤立商品はクロールデータで定期的に検出します。構造を図にすると次の通りです。

アンカーテキストや階層設計の詳細は内部リンクの最適化で解説しています。

商品の構造化データはどこまで実装しますか？

施策15は構造化データです。Productを入れれば順位が上がるという性質のものではなく、商品情報の理解と検索結果での対象表示（価格・在庫・評価の表示など）を補助する実装と捉えてください。

施策15：Product、Offer、ProductGroup、BreadcrumbListを表示内容と一致させる

原則はひとつ、「実際にページへ表示されている情報だけをマークアップする」です。商品名・画像・説明・SKU・ブランドを商品マスタと合わせ、価格・通貨・在庫状態・URLを画面表示と合わせます。バリエーションを持つ商品は、バリエーション商品の構造化データの適用条件を確認してからProductGroupとProductを設計してください。返品・配送のポリシーは、実際の運用と一致する場合だけ追加します。実装後はリッチリザルトテスト、URL検査、Search Consoleで検証し、エラーを監視します。本文にない評価や自作レビューを入れる行為は、表示対象外やペナルティのリスクだけを増やします。マークアップの具体的な書き方は商品構造化データの実装を参照してください。

モバイル表示とJavaScriptはどこを確認しますか？

表示速度のスコア改善だけを追うのは得策ではありません。確認すべきは「商品の発見・購入判断・操作が、モバイルとレンダリング後のHTMLで成立しているか」です。

商品画像とファーストビューを軽くする

適切な画像形式と表示サイズを使い、主画像の過度な遅延読込を避けます。ファーストビューで商品名・価格・在庫・購入条件を確認できる状態が基準です。

追加読込後の商品にもURLとリンクを用意する

「もっと見る」の先にある商品が、レンダリング前のHTMLに存在しないケースは頻出です。Googlebotが操作しなくても商品へ到達できる構造か、レンダリング前後のHTMLとリンクを比較して確認してください。

バリエーション選択とカート操作の応答を確認する

色とサイズの選択でURL・価格・在庫・画像が矛盾しないか、レイアウトの移動や長い処理が購入操作を妨げていないかを実機で確認します。指標の見方と改善手順は表示速度と操作性の改善にまとめています。PageSpeed Insightsの点数そのものをKPIにしないでください。

対話型AIで商品が最終候補に残るには何をページ内に示しますか？

AI OverviewやAIモードの普及で、商品検索も対話型に変わりつつあります。重要なのは、AIに一度言及されることではなく、条件を追加された後の最終回答で候補に残ることです。

「商品名＋おすすめ」だけをCVキーワードにしない

対話型AIでは、「おすすめのオフィスチェア」の後に、利用目的、予算、サイズ、配送日、返品可否といった条件が追加されながら候補が絞られます。広い「おすすめ」クエリでの露出だけでは、最後の比較に残れず顧客接点を確保できません。

最終候補を絞る商品条件を本文と仕様表に出す

AIが条件判定に使えるのは、ページ上に検証可能な事実として書かれた情報です。対話で追加されやすい条件と、対応する商品情報を整理します。

対話で追加される条件	判定に使われる情報	記載場所
用途に合うか	向いている用途・向かない用途	商品説明・仕様表
サイズ・互換性	寸法・対応機種・非対応条件	仕様表
予算内か	税込価格・追加費用	価格表示
いつ届くか	在庫・発送日・到着目安	在庫・配送表示
失敗したら返せるか	返品・交換条件	返品ポリシー表示
保証はあるか	保証・サポート・問い合わせ先	サポート表示

※条件は代表例です。自社商品で実際に多い問い合わせから優先してください。

AI回答から公式商品ページへ進む理由を残す

AIの回答が要約を返しても、現在の価格と在庫、色とサイズの選択、詳細な仕様と画像、送料と到着日の計算、購入手続は公式ページでしか完結しません。この「ページでしか確認できない情報」を正確に保つことが、AI経由の来訪を購入へつなぐ設計です。AI検索の表示と観測の詳細はAI検索での表示と観測で扱っています。なお、AI表示・推薦・引用は制御も保証もできない前提で情報整備に徹してください。

15施策を自社対応と開発対応へどう分けますか？

施策の内容が分かっても、誰がやるかが決まらないと進みません。大枠は、商品情報とカテゴリ説明は運用で改善しやすく、URL生成・canonical・noindex・JavaScript・構造化データは開発とSEOの共同検証が必要、という分担です。

施策	主担当	関与	実装負荷
施策1〜3 カテゴリ選定・固有情報	SEO・MD	運用	低〜中
施策4 商品リンク構造	開発	SEO	中
施策5〜8 商品情報・画像・レビュー	運用・商品管理	法務	低〜中
施策9〜12 URL・canonical・バリエーション	開発・SEO	—	高
施策13 在庫切れ・販売終了処理	運用・開発	商品管理	中
施策14 内部リンク	開発・SEO	MD	中
施策15 構造化データ	開発	商品管理・SEO	中〜高

※担当区分は一般例です。EC基盤の制約（個別canonical設定の可否など）で変わります。

運用担当者が着手しやすい施策

商品名・固有説明・仕様表・画像alt、カテゴリ導入文と選択軸、送料・納期・返品・在庫の表示確認、関連商品と代替商品の選定は、システム改修なしで進められる範囲です。

開発担当者との検証が必要な施策

URL生成とパラメータ制御、canonical・noindex・robots.txt、ページネーションと無限スクロール、商品バリエーション、構造化データ、JavaScriptレンダリングは、設定ミスが売上に直結するため、必ず開発とSEOの両方で検証してから反映します。

外部診断が向いているケース

URL数がSKU数を大幅に上回っている、indexとcanonicalの状態を社内で説明できない、リニューアルやEC基盤移行を控えている、複数部署の仕様が衝突している、変更後の検証と切り戻しを設計できない、といった状況では外部の診断が選択肢になります。外注判断の基準はSEOを外注する判断基準も参考にしてください。

ECサイト内SEOの変更を安全に実装する手順は何ですか？

URL、canonical、noindex、リダイレクトに触れる変更は、失敗すると既存売上を直接失います。手順は「現状保存 → 影響URLの抽出 → ステージング検証 → 限定公開 → 本番監視 → 切り戻し」の順で固定します。全体の流れは次の図の通りです。

変更前に現状を保存する

URL一覧・index状態・canonical・robots.txt・サイトマップ、ページ別の流入・売上・被リンク・内部リンク、商品マスタ・画面表示・構造化データ、クロール結果とサーバーログを保存します。切り戻しの可否は、この保存の精度で決まります。

ステージングで受入条件を検証する

重要URLが200を返す、canonicalとnoindexが設計どおり、商品リンクをクロールできる、価格・在庫・構造化データが一致する、モバイル表示と購入操作が崩れない、の5条件を受入基準にします。

本番反映を限定し、監視する

全体一括ではなく、カテゴリまたはテンプレート単位で段階的に反映します。監視対象はクロールエラー、index、クリック、売上、カート追加です。技術エラーによる急落と、順位の短期変動は分けて判断してください。

切り戻し条件と方法を決める

重要URLの消失、意図しないnoindexまたはcanonical、商品リンクの断絶、価格と在庫の不一致、購入操作の障害のいずれかが発生したら、原因調査より先に旧設定へ戻します。旧テンプレート・旧canonical・旧robots設定を復元できる状態で保持し、URL変更を伴う場合は新旧URLの対応表を保存しておきます。

ECサイト内SEOの成果はどのKPIで測りますか？

順位だけを見ていると、クロールの浪費や在庫切れページへの流入といった問題を見落とします。KPIは「クロール・index → 検索流入 → 購入行動」の3段階でつなげて測ります。

段階	主な指標	データ源
クロール・index	重要商品の発見率／index可能URLとindex済みURL／絞り込みURLのクロール比率	クロールデータ・Search Console
検索流入	カテゴリ別の非指名クリック／商品別の指名・非指名クエリ／リッチリザルトの有効項目とエラー	Search Console
購入行動	商品閲覧からカート追加までの率／自然検索経由の購入数と売上／在庫切れ到達率	GA4等・ECバックエンド
事業指標	カテゴリ別売上と粗利／新規顧客比率・返品率	ECバックエンド・CRM

※季節性の影響が大きい業種は前年同期比を基本にしてください。

計測の実務では、「順位が上がったか」より「検索 → 商品発見 → 購入条件の確認 → カート追加」のどの段階で離脱しているかを見る姿勢が大切です。順位上昇と売上の因果を単独で断定せず、期間・対象URL・他要因を並べて評価してください。

ECサイトのSEO対策に関するよくある質問

本文を読んだ後に残りやすい実装判断を、短く確認できる形でまとめました。

Q. 商品説明は何文字書けばSEOに強くなりますか？

A. 文字数の基準はありません。購入判断に必要な仕様、用途、適合条件、価格、在庫、配送、返品を過不足なく示すことが優先です。

Q. 絞り込みページはすべてnoindexにすべきですか？

Q. 在庫切れ商品はすぐ削除しますか？

Q. 商品構造化データを入れると順位が上がりますか？

Q. 商品ページとカテゴリページが同じキーワードで競合したらどうしますか？

Q. ECサイト内のSEOは自社だけで対応できますか？

Q. AI検索向けに特別な商品ページを作る必要がありますか？

ECサイト内のSEO対策を実行へ移すためのまとめ

ECサイトのSEO対策について、優先順位、キーワード分担、ページ別の施策、URL整理、担当分け、安全な実装手順、KPIまでを整理しました。要点を振り返ります。

本記事の要点

• 先に直すのはindex事故・孤立商品・価格在庫の不一致
• キーワードは商品ページとカテゴリページで役割分担する
• 絞り込みURLは検索価値の有無で残す対象を判定する
• URL・canonical・noindexの変更は現状保存と切り戻しをセットにする
• 成果はクロール→流入→購入行動の3段階でつないで測る

次の一歩は、商品数とURL数、ページ種別ごとのテンプレート、主要カテゴリと売上商品、Search Consoleとアクセス解析の権限、商品マスタの更新方法、EC基盤と開発体制の6点を1枚に棚卸しすることです。URLの挙動を把握でき、運用と開発の担当者がそろい、変更前後を検証できる体制なら、自社対応で十分に進められます。URL生成が不明、index問題が大きい、基盤移行を控えている、部署間の仕様調整が必要という状況なら、第三者の診断を挟む方が安全です。当社では、サイト構造と商品ページの現状を踏まえて、優先順位のついた改善案をご提案しています。