ECサイトのSEO担当者が行う仕事｜社内で必要な役割と進め方
目次
ECサイトのSEO担当者は、キーワードを選んで記事を書く人だけではありません。商品、カテゴリ、記事、技術設定の課題を見つけ、事業の優先順位へ合わせ、制作や開発へつなぎ、公開後の結果を確認する役割です。
商品数が多いサイトでは、一人で全ページを直すことはできません。商品担当、カスタマーサポート、制作、開発、分析をつなぐ進行役として、改善が続く仕組みを整えます。
事業目標をSEOへ落とし込む
売上を増やすという目標だけでは、対象ページを決められません。継続販売する商品群、新規顧客へ届けたいカテゴリ、問い合わせを減らしたいテーマなどへ分解します。
在庫、利益、販売期間を商品担当に確認し、検索需要だけで優先順位を決めないことが重要です。
現状を調査する
Search Console、アクセス解析、サイト内検索、問い合わせ、URL一覧などから課題を探します。主要ページがインデックスされているか、検索語句と入口が合っているか、流入後に商品を見られているかを確認します。
ツールの警告を並べるだけでなく、影響するページと事業上の重要度を調べます。
改善の優先順位を決める
誤ったnoindexや5xxなど前提を壊す問題、主要ページの情報不足、記事企画の順に整理します。対象URL数、売上との関係、修正工数、再発性を基準にします。
一件ずつ直すよりテンプレートや登録ルールを修正できる問題は、開発担当と仕組みで解決します。
商品担当と連携する
商品名、仕様、素材、サイズ、在庫、販売終了の判断は商品担当の情報が必要です。SEO担当者が推測で説明を書かず、確認元と更新責任を決めます。
検索語句や問い合わせから見つけた顧客の用途を共有すると、商品説明やカテゴリ分類の改善にもつながります。
制作担当と連携する
ページの目的、想定読者、必要情報、案内先を構成へ落とし込みます。メインキーワードだけを渡すと、一般論や語句の羅列になりやすいため、検索意図と記事のゴールを説明します。
公開前には事実、表記、リンク、titleタグ、見出しを確認します。
開発担当と連携する
「SEOを改善する」では実装内容が伝わりません。対象URL、現在の状態、期待するHTMLや応答、発生条件、確認方法を要件として書きます。
テンプレート変更は、通常商品、在庫切れ、バリエーション、販売終了など状態別にテストします。
公開後に検証する
公開直後は表示、HTML、リンク、商品情報を確認します。その後、クロールとインデックス、検索語句、表示回数、クリックを見ます。売上や購入はアクセス解析やECシステムで確認します。
変更日と内容を記録し、複数の大きな施策を同時に行わないようにします。
定例業務を設計する
日次では重大なエラーや公開事故、週次では重要ページの変化、月次では検索パフォーマンスと改善施策を確認するなど、問題の速度に合わせます。
会議資料を作ることが目的にならないよう、各数値から次に何を調べるかを決めます。
必要な知識
検索の基本、商品とカテゴリの構造、HTMLの基礎、Search Console、アクセス解析、文章編集が役立ちます。すべてを一人で専門家レベルにする必要はありません。
分からない技術は開発担当、専門表現は監修者へ相談し、正確な判断を進められることが重要です。
引き継げる運用にする
キーワード表、ページ役割、変更履歴、確認手順、テンプレート仕様を文書化します。担当者の記憶だけにすると、異動で改善が止まります。
なぜその設定にしたか、例外は何かも残すと、将来のサイト改修で誤って戻されにくくなります。
一週間の仕事を具体化する
たとえば月曜日にSearch Consoleと障害通知を確認し、火曜日に商品担当から新商品と終売商品の情報を受け取り、水曜日に改善要件を制作・開発へ渡します。公開日はHTMLと画面を確認し、週末に変更履歴を更新します。毎週すべてを行う必要はありませんが、確認と実行を分離しないことが大切です。
緊急対応と通常改善も分けます。主要カテゴリがnoindexになった事故は即時対応し、記事タイトルの見直しは定例の優先度評価へ回します。どちらも同じタスク表へ入れると、細かな改善に重大事故が埋もれます。
依頼票に書く項目
開発や制作へ依頼するときは、対象URL、現状、期待する状態、理由、対象外、確認方法、希望時期を書きます。たとえば「在庫復活後もnoindexが残るため、公開中かつ販売可能になった時点でrobots metaをindex可能な状態へ戻す」と具体化します。
記事制作では、想定読者、検索時の状況、解消する疑問、紹介可能な商品、根拠資料、確認担当を渡します。キーワードだけを渡すより、自然で事業に合う原稿を作りやすくなります。
SEO担当者が決めてはいけないこと
検索需要があるという理由だけで、未確認の効能、対応していない用途、在庫のないカテゴリを打ち出してはいけません。医療、安全、金融など影響の大きい説明は、適切な専門家や法務担当へ確認します。
販売終了ページを残すか、新しいカテゴリを作るかも、検索データだけでは決められません。商品方針、顧客対応、システム負荷を関係者と検討します。SEO担当者の価値は、独断で決めることではなく、必要な判断材料を集めて意思決定を進めることにあります。
不確実な点は推測で埋めず、確認待ちとして明示します。公開を急ぐ場合も、事実がそろった範囲に内容を限定してください。
検索エンジンの仕様についても、古い知識を断定せずGoogleの公式情報を確認します。変更される可能性がある数値は一般的な目安として扱います。
判断に使った公式資料と確認日を残しておくと、将来の見直しで前提が変わったかを確認できます。
担当者を評価する視点
記事本数や順位だけで評価すると、重大な設定事故の予防、商品データの整備、部門調整が見えません。完了した改善、再発防止、検証の品質、社内へ残した知識も評価します。
検索結果は担当者だけで制御できないため、保証できない結果を個人目標にしすぎないことが大切です。一方で、調査や実装が止まった理由を説明し、次の行動を示す責任はあります。
事業成果と運用品質の両方を見ると、短期の順位変動に振り回されにくくなります。
よくある間違い
- SEO担当者だけで商品情報を決める
- 調査レポートを作って実装を追わない
- 記事本数や順位だけを評価する
- 開発要件を抽象的な言葉で伝える
- 変更履歴を残さず同じ問題を繰り返す
担当者のチェック項目
- 事業目標と対象ページを結び付けたか
- 商品事実の確認担当を決めたか
- 改善案を実装可能な要件へ変えたか
- 公開直後と中期の確認を分けたか
- 数値変化後の行動を決めたか
- 判断基準と履歴を共有したか
まとめ
ECサイトのSEO担当者は、事業、商品、制作、技術、データをつなぎ、改善を実行まで進める役割です。一人で全作業を抱えるのではなく、必要な担当者へ正確に依頼します。
まず主要カテゴリ一つを対象に、調査、優先順位、要件、公開、検証の流れを作ってください。その手順を文書化すると、商品数が増えても引き継げるSEO運用になります。
