こんにちは、株式会社インディバースの河合です。
前回、データベースSEOメディアを立ち上げた際の体験談について記事を書きました。
おかげさまで、多くの反響をいただきまして、ご相談を多くいただきました。ありがとうございます。
さて、以前の記事では
- データベース型SEOサイトと、オウンドメディア（記事型メディア）の組み合わせがよい
という話をしたのですが、あまり詳しく書けませんでした。
そこで今回は、データベース型SEOメディアと、オウンドメディアの掛け合わせについて解説していきたいと思います。
※なお、今回の記事はエンジニア用語とマーケティング用語がかなり入っているので、ぜひ社内展開してエンジニアチームとマーケティングチームで一緒に読んでいただけると嬉しいです。
目次
なぜこの記事を書いたのか
当社が運営しているインディバースフリーランスは、フリーランスエージェントのアフィリエイトサイトです。このサービスの競合は、
- フリーランスエージェントのアグリゲーションサイト
- アフィリエイトメディア
- 事業会社のデータベースSEO型サイト
がメインです。
さて、ずっと記事型のメディアを運営していたのですが、どうしても競合に勝てないな、、、と思いまして、原因について考えていたところ、
- 競合のアグリゲーションメディアが獲得しているキーワードのカバレッジがDBで多かった
- 競合のアグリゲーションメディアが運営しているサイトの中でも、クエリによっては記事型で取りに行っていた
ということに気づきまして、「これっておそらく戦略的にデータベースメディアと記事型メディアを出し分けているのでは？」と思いました。
そのうち調査していく中で、「このクエリはデータベースサイト型の出現頻度が多い」「このクエリはデータベース型サイトの出現頻度が少ない」ということに気づきました。
例を挙げるとこんな感じです。
| よく取れるクエリ | |
| データベースSEO型メディア （動的生成を前提としたカタログサイト） | 例）AWS フリーランス 例）AWS 単価 |
| 記事型メディア （ライターが記事を手動で作成するタイプの一般的なメディア） | 例）フリーランスエージェント おすすめ 例）レバテック 評判 |
そして強いメディアであればあるほど、
- データベースでとりにいくクエリはデータベースで注力している
- 記事型でとりにいくクエリは記事型で注力している
- 場合によっては二面で同じキーワードで出ている
ということに気づきました。
ということで当社は、アグリゲーション型のデータベースSEOメディアと、コラム型のデータベースSEOメディアを開始しました。
その中で、実際にやってみて、
- データベース型SEOメディアと、コラム型メディアを組み合わせると、とれるキーワードの種類が増えてよい
- ページ品質の評価がデータベース型SEOメディアと記事型SEOメディアだと異なるので、出し分けられると強い
- ただし、技術選定などはSEOコンサルや開発だけでは難しく、両軸でわかっている人ではないと推進が難しそう
- 何かしらデータベース型SEOメディアと、記事型メディア運用の論点を整理するためのドキュメントがあったほうがよいな
ということに気づきまして、これについて実際にマーケ、PdM、エンジニアを一人でやってみて思ったことについて記載していきたいと思います。
河合大施策として、データベース型メディアと記事型メディアを両方やりたいなぁと思っているんだけど、これどうやって議論進めていこうかなぁと悩まれている方がいらっしゃいましたら、ぜひ社内で展開いただけると嬉しいです！
データベース型SEOメディアと、記事型メディアの定義を確認
データベース型SEOメディアと、記事型メディアですが、以下のように定義します。
- データベース型SEOメディア:大量の商品, 求人, 店舗などのデータを、動的に集計したページを生成したメディア。
- 記事型メディア: 人間が一つ一つ記事を書いていくようなメディア。
| 定義 | 技術 | |
|---|---|---|
| データベース型SEOメディア | 大量の商品, 求人, 店舗などのデータを、動的に集計したページを生成したメディア。 例）Amazon / 食べログ | Rails / PHP / NodeJSなど、バックエンドフレームワークで作成された大規模サイトを想定 |
| 記事型メディア | 人間が一つ一つ記事を書いていくようなメディア。例）このインディバースのオウンドメディア | WordPressなどのCMSで構築されることが多い。 |
データベース型SEOとオウンドメディアの強み、弱みの整理
あらためて、データベースSEOメディアを運営する中で、コラム記事と連携することで以下のような利点が得られます。
| データベース型メディア | コラム型メディア | |
| コンテンツ量 | ◎ ・データ量が多様で多ければ、自動的にコンテンツを生成することができる | △ ・手動で作るため、予算的にカバーできないケースがある |
| 柔軟性 | × ・特定の一覧ページにアイテム数がない場合は、記事が作れない ・データ量が少ないと、低品質コンテンツになるため制御がきかない ・特定のキーワード軸で横展開するような構造に必然的になるので、かけるキーワードに制限が出てくる | ◎ ・キーワードに合わせて、手動でコンテンツを変えることができる ・かけるクエリの幅も広がる |
| フレッシュネスの担保 （コンテンツの鮮度） | ◎ ・新規でアイテムが増えれば、テンプレートに自動更新可能な要素をおいておくことで、フレッシュネスを担保できる | △ ・手動更新のための人的リソースが一定かかる |
| コンテンツの原価構造 | ◯ ・求人数が担保できれば、動的にコンテンツが生成されるため、システムの人件費のみになる ※ただしアグリゲーションメディア以外の場合は別 | × ・鮮度が落ちるため、コンテンツのリライトに一定の原価がかかり続ける ・ロングテールキーワードだと、投資しても損益分岐を超えられないためかけない ※参入する競合性に依存 |
| イニシャルコスト | × ・エンジニア/PMなどの開発リソース、事業開発などによるアライアンスが必要なケースが多く、イニシャルでのコストがかかる | ◯ ・オウンドメディア構築、記事作成費用のみ |
コンテンツ量
データベース型メディアに関しては、登録されているアイテム数（例：求人/ECサイトの商品)が多ければ多いほど、多くの対策ページを作成することができます。
例えば、レストランの比較メディアを運営しているとします。
「吉祥寺 レストラン」のような、「$駅名 レストラン」というクエリについては、それぞれ記事型と異なり、駅名に属するデータが多くあればあるほど、自動で地域のレストランページが生成されます。そのため、データ量がある程度あれば、価値のあるコンテンツを複数作成することが可能です。
一方で、コラム型ページでは、すべての記事を手動で作成する必要があります。記事を作成するためには、複数の記事を人件費を払って多く書く必要があります。
コンテンツの柔軟性
データベース型メディアに関しては、記事単体のコンテンツに対して、細かい柔軟性を持たせることはできません。
例えば、「吉祥寺 レストラン」 というキーワードで、コンテンツをつくりたい時に
- 吉祥寺のレストランが1件もない場合→コンテンツがないので表示できない（できるが低品質になるので出さない方がよい）
- 吉祥寺 レストラン というキーワードで上位表示されているクエリがほとんど手動更新しないと追加できない情報がある→修正不可能
というネックがあります。
一方で、記事型の場合は人間が手動で文字を入れることができるので、非常に柔軟にコンテンツを作ることができます。
また、例えば「$地域 レストラン」というキーワード以外にも、「レストラン 選び方」のようなキーワードで記事を書きたい時は、データベース型メディアだとそのカテゴリごとのテンプレートが決まっているため、融通が効きません。
コンテンツのフレッシュネスの担保
データベース型メディアでは、動的生成する部分についてはコンテンツを自動で更新しやすいです。
例えば、レストランの比較メディアの場合、
- レートの数
- 口コミの数
- 空席情報
など、毎日変わるデータが更新されます。
一方で、記事型メディアの場合だと、ここの更新が全て手動になります。更新するには、フレッシュネスが求められるような内容を先に定義しておいて、ライターチームにアサインする工数や人件費などが定常的にかかってきます。
コンテンツの原価構造
データベース型SEOの場合、求人数が担保できれば、動的にコンテンツが生成されるため、システムの開発者の人件費のみになります。もちろん入稿など、手動で行わないといけないサービスであれば追加でお金はかかりますが、微々たるものでしょう。
一方で、記事型メディアの場合だと、
- 記事の構成を作成するメンバーの人件費
- 記事を書く人の人件費
- リライトを行う人の人件費
など、さまざまな原価がかかってきます。
特に、検索ボリュームが少ないキーワードの場合、記事の損益分岐を突破することが非常に難しくなります。
イニシャルコスト
データベース型SEOの場合、外注する場合は
- エンジニア/PMの開発費：500万円〜
- SEOコンサルタントの費用: 50-100万円
など、そもそもの開発費に膨大な金額がかかります。
一方で、記事型のメディアだと、
- オウンドメディアの初期構築：10-30万円
- ドメイン/サーバーの費用: 1万円
と、かなりコストが低くなります。
データベース型SEOとオウンドメディアを組み合わせると強い
さて、この強み・弱みを合わせることによって、どうなるでしょう。
以下のテーブルをご確認ください。
| データベース型メディア | コラム型メディア | 両方運用 | |
| コンテンツ量 | ◎ ・データ量が多様で多ければ、自動的にコンテンツを生成することができる | △ ・手動で作るため、予算的にカバーできないケースがある | ◎ ・手動で作って網羅できないクエリはデータベース型メディアで置き換えられる |
| 柔軟性 | × ・特定の一覧ページにアイテム数がない場合は、記事が作れない ・データ量が少ないと、低品質コンテンツになるため制御がきかない ・特定のキーワード軸で横展開するような構造に必然的になるので、かけるキーワードに制限が出てくる | ◎ ・キーワードに合わせて、手動でコンテンツを変えることができる ・かけるクエリの幅も広がる | ◎ ・データ量が足りないクエリ/データベース型SEOで対応できないクエリは記事型で対応できる |
| フレッシュネスの担保 （コンテンツの鮮度） | ◎ ・新規でアイテムが増えれば、テンプレートに自動更新可能な要素をおいておくことで、フレッシュネスを担保できる | △ ・手動更新のための人的リソースが一定かかる | ◎ データベース型メディアのデータをオウンドメディアに取り込むことによって、フレッシュネスを担保できる |
| コンテンツの原価構造 | ◯ ・求人数が担保できれば、動的にコンテンツが生成されるため、システムの人件費のみになる ※ただしアグリゲーションメディア以外の場合は別 | × ・鮮度が落ちるため、コンテンツのリライトに一定の原価がかかり続ける ※参入する競合性に依存 | ◎ ・フレッシュネスを維持できるため原価が減る |
| イニシャルコスト | × ・エンジニア/PMなどの開発リソース、事業開発などによるアライアンスが必要なケースが多く、イニシャルでのコストがかかる | ◯ ・オウンドメディア構築、記事作成費用のみ | × ・データベース型SEOメディアとオウンドメディアでの負担がある |
データベース型SEOとオウンドメディアを組み合わせる方針
以下の観点が重要かと思います。
1. データベースSEOと記事型クエリでどのクエリをとるか決める
初期設計のタイミングで、データベースSEOで取るクエリと記事型で取るクエリを決めておきましょう。
これが決まらないと、データベースSEO型メディアの仕様がなかなか決められません。
例えばある程度記事型で取るクエリが多い場合は、技術選定で記事型でかける体制を優先しなければなりませんし、逆に記事型で取るクエリが少ない場合は、データベース型SEOの中に一部簡単な記事編集機能を入れるだけで済みます。
いずれにしても、キーワード戦略に応じて
- データベース型SEOサイトの技術選定
- オウンドメディアコラム型サイトの技術選定
が変わります。
とはいえ、最初の段階で全部クエリが見れるわけではないので、個人的にはWebアプリケーションとWordPressをあわせたような形の構成をおすすめします。その方が後から変更しようと思った時に柔軟だからです。
ちなみに以下のスプレッドシートは、当社のアフィサーチを開発する前に、ざっくりとサイトマップでどのキーワードを狙うかまとめた資料です。
クライアント納品するものの場合はもっと細かく見ますが、最低でもこれくらいはサイト立ち上げの際に言語化できているといろいろと見えてくると思います。
2. データベースに入れるデータの取得戦略を決める
データベースSEOサイトを運営する上で、どういうデータをDBの中に入れる必要があるか決めましょう。
またそのデータを誰がどこから取得するのか、そして誰がそのデータをどうやって入れるかも明確に決めておくことが重要です。
大きく分けると、以下があると思います。
- 外部サイトからデータを取得するクローラーを書く
- 外部サイトとアライアンスを結び、データの提携を行う（CSVをもらう等）
- ユーザーに投稿を行ってもらうことで、コンテンツ量を増やす
- 社内でリサーチャーチームを入れて、手動で入れていく
| 留意事項 | 参考データベース型サイト | |
| 外部サイトからデータを取得するクローラーを書く | ・外部サイトへのクローラーの利用規約などの確認が必要 ・外部サイトへの許可をもらう必要がある | |
| 外部サイトとアライアンスを結び、 データの提携を行う（CSVをもらう等） | ・外部サイトへのアライアンスを行うリソースが必要。 ・相手にとって提携する旨みを初期段階で作れるか検討が必要 | 多くの求人アグリゲーションメディア |
| ユーザーに投稿を行ってもらうことで、 コンテンツ量を増やす | ・ユーザーが投稿をしてくれるようなインセンティブ構造が必要 ・投稿がないとユーザーが投稿してくれないという、「鶏と卵問題」の解決方法を考える必要がある | 食べログ |
| 社内でリサーチャーチームを入れて、手動で入れていく | ・すでにデータのアセットがある場合は問題なし ・ない場合は、データをどういうふうに集めてくるのか、人件費はどうするのかなど予算策定が必要 | マイベスト 多くの求人サイト |
3. ページクオリティが高いページを作れるか判断する
対象としているキーワードと、データベースに入れるデータを照らし合わせて、「ページクオリティが高いページを作れるか判断する」ことが重要となります。
ここである程度。以下が見えると良いです。
- データ量が少ないことによる低品質コンテンツ化
- データ量が少ないことによる重複ページ過多になるリスク
低品質コンテンツについては、例えば、レストランのレビューサイトを運営していて、「レストラン 吉祥寺」で対策するとします。
この場合、最低でも競合は10件はコンテンツを並べているのであれば、これに相当するようなアイテム数がデータとして確保できている必要があります。
例）「レストラン 吉祥寺」で表示させたい場合の競合のレストラン件数
| 吉祥寺のレストラン件数 | |
|---|---|
| 自社 | 5 |
| 他社A 検索順位1位 | 10 |
| 他社B 他社A 検索順位2位 | 25 |
| 他社C 検索順位3位 | 10 |
初期のタイミングで、対象とするページが価値をもたらせるかどうかは、自社のデータベースを照らし合わせて対応します。
もう一つ、重複ページについてです。
例えば「レストラン 吉祥寺 デート」というキーワードで対策するとします。
もしデータベース上で、吉祥寺のレストランがあまり件数がなく、件数を稼ぐために「レストラン 吉祥寺 デート」とほぼ同じデータを出力すると、中身がほとんど同じの重複ページ扱いになってしまいます。
ロングテールキーワードで対策する場合、よく起こる問題となるので、ここは注意が必要です。
※エンジニアとしてのコメント：上の設計書がBiz側である程度できたら、エンジニア側でSQLでデータベースを叩いてみて、だいたいどれくらい件数が取れるかみてみるのがおすすめです。
4. 技術選定を行う
上記のキーワード戦略やデータ取得計画をもとに、技術選定を行います。データベースSEO型メディアにオウンドメディアを構築する際の技術選定です。後述します。
データベースSEO型サイトの技術選定
データベースSEO型サイトの技術選定としては、以下の通りです。
- Webアプリケーションで構築する（PHP, Ruby, Javaなど）
- WordPressで構築する
1. Webアプリケーションで構築する（PHP, Ruby, Javaなど）
もっとも一般的な技術構成です。柔軟性の高いWebフレームワークを利用して、Webアプリケーションの構築を行います。
メリットとしては、ほぼ全てのカスタマイズが用意に行えること。特にあとから大幅な仕様変更する余地を残しておくのであれば、Webアプリケーションとして構築するのがおすすめです。
例えば運営当初はただSEOで集客できればいいや、と思っていたけど、途中からログイン/新規登録が必要になった、というケースがある場合、後述するWordPressなどで実装しようとすると厳しいです。
よっぽどの理由がない限りは、まずは選択肢1を選ぶのが良いと思います。
2. WordPressで構築する
もっともミニマムで、低予算で構築する方法です。
仕様もほぼFixしていて、あとから変わる可能性が低い。ただアイテムが一覧表示されていればOK。ここから変わる必要がない。こういう場合はWordPressが最適な技術構成となると思います。
実装イメージとしては、適当なテーマに子テーマを配置し、
- single-restaurant.php
- archive-restaurants.php
などを追加します。また、カスタム投稿タイプなどで「レストラン」などを追加し、WordPress内でデータを入れていくような形です。
ちなみにWordPressでデータベースサイトを運営しているメディアは少なさそうに見えますが、わりと結構あります。当社の過去のお客様でもいました。（WordPressのDBとAPIだけはバックエンドとして利用、フロントはNextJSみたいなケースです）
この技術構成は、やはりあとで解説しますが、運用するBizサイド側のUX、柔軟性が非常に高く、エンジニアの工数がかからずともBiz側でわりといい感じに修正がきくというのは強いです。
ただ一方で、
- ユーザー登録機能入れたいんだよね
- 登録したら、別の送客先にも一括登録できるようにしたいなぁ
など、WordPressでやろうとすると難易度が高くなったり保守しづらくなる要件が増えてくる場合がありそうな場合は、あまり推奨できません。
※エンジニア視点：多分ここをBizの人間が最初の段階でイメージできません。何ができて何ができないのかは、CTOポジションの人に相談でしたほうがいいでしょう。
WordPressでは「できる」と「できない」の間に、「できるけど疲れる」があります。（できるけど壊れやすくなる / できるけど脆弱 / できるけど遅い / できるけどテストに時間がかかるとか）
今後の戦略から逆算した上で、SEOと技術がわかる人に相談するのがおすすめです。
オウンドメディア側の技術選定
オウンドメディア側の技術選定は、大きく分けて2つあります。
- データベース型SEOサイトを運営しているWebアプリケーションの一部に自社独自のCMSを開発する
- データベース型SEOサイトを運営しているWebアプリケーションに記事型ページのみヘッドレスCMSを利用する
- WordPressを別サーバーに設置し、サブドメイン / サブディレクトリでオウンドメディアを運営する
アプローチ1: データベース型SEOサイトを運営しているWebアプリケーションの一部に自社独自のCMSを開発する
データベース型SEOサイトの管理画面の裏側に、オウンドメディアの機能を新しく新規実装し、管理画面上でコンテンツを入稿できるような体制を構築する方法です。
メリットとしては、まずデータベース型SEOサイトのデータを記事型コンテンツでも再利用しやすいことが挙げられます。
例えば、オウンドメディアの中で先述したレストランデータを一覧で表示したい、という場合に、すでに存在するデータベースをそのままとってこれるという点で、便利です。
また、動的生成する箇所の価値が非常にSEO的に多かったり、単純に似たようなテンプレートでコンテンツを作るのではなく、個別にカスタマイズしたページが多い場合などには、この構成にしておくと柔軟性が効いて良いです。
デメリットとしては、一定エンジニアの工数をオウンドメディアに割かないといけないことと、またそれに応じてBiz側の改善スピードが遅くなることです。
エンジニアチームの場合、基本新規機能やバグ改善などに、優先的なリソース配分が行われます。Bizサイトの方であれば経験あるかもしれませんが、オウンドメディアの簡単な修正などは、作業が簡単だったとしても、「手の空いた時間にやろうぜ」タスクになります。「来月は新機能A」「今週は新機能B」「毎月バッファ持っている工数はこれ」「ごめん、今週バッファなかったわ」みたいになります。つまり「時間があったらやる（＝時間ないからやらない）」になります。
結局は対応してくれなくなるケースが多いです。オウンドメディアのタスク修正は、おそらく他のどの機能よりも後回しにされるので、根気強くBizチームでエンジニアとコミュニケーションする必要が出てきます。
また、エンジニアはプロダクト開発の専門家であり、SEOの専門家ではないことがほとんどです。そのため、Bizチームやマーケチームが細かく技術仕様書を定義する必要がありますが、そもそもBizやマーケチームも技術の専門家ではないため、ここでミスコミュニケーションが生じやすいです。誰がQA（品質保証）するの？もあいまいになりやすいです。
例えばよくあるのが、SPA(Single Page Application)で実装しているコンテンツで、静的キャッシングをしないままリリースしてしまって、SEO対策が全くできていないままリリースしてしまうなどです。（これはめちゃくちゃありますが、守備範囲としてどっちがSEOの門番をやるのか、責任があいまいになるケースが多いです）
こういうチームの場合、見えない「調整コスト」や、「手戻りコスト」、「機会損失コスト」などを加味すると、チーム全体で相当工数を奪われることになります。
この選択肢を取る場合、以下の条件の人材がいる場合は機能する印象です。
- エンジニアチームにSEOが詳しい人がいること
- マーケチームにエンジニアリングが詳しい人がいること
- PdMなどがどちらの知識も持っていること
- チームにSEOの品質を担保する責任があるような、品質評価番長がいること
- 代理店に依頼する場合、外注先がSEOのみではなくプロダクト開発の知識を持っていること
- 長期的にメンテナンスフェーズで、インハウスで運用する / 外注するかなどが意思決定できていること
※エンジニア視点。この「SEOという非機能要件」に関心を持っているエンジニアは少なく、どちらかというとパフォーマンス改善やセキュリティ観点, UI, UXなど、エンジニアとしてのキャリアにわかりやすく直結しやすいようなものに目がいきやすいためだと思っています。エンジニアはSEOができても転職で年収そんなにあがりずらいだろうし。「エンジニアにSEOなどの知識を身につけて欲しい」と思っていても、評価されるKPIがBizとは異なるケースが多いので、Bizがエンジニアリングを学んだ方がスムーズに進むことが多いと思います。
アプローチ②：ヘッドレスCMSを利用する
既存システムに 外部のヘッドレスCMS（例：microCMS） を組み合わせる方法。記事作成やアセット管理は外部CMSに任せ、その他のデータ構造や表示制御はアプリケーション側で実装します。
メリット
- コンテンツ作成・編集機能をゼロから開発する必要がない
- エンジニア工数を削減できる
- データ構造の設計や変換も比較的容易
デメリット
- 最終的な公開にはエンジニアの補足作業が必要
- ビズ側とエンジニア側のコミュニケーションコストは発生
- 単体テストなどはアプリケーション側で個別対応する必要があり、テスト網羅性に課題が残る
個人的にはこの構成はそこまで旨味がないように感じるため、あまり推奨しません。（すいません、これは僕が知らないだけなので、よい事例があったらぜひ教えてください。）
アプローチ③：WordPressを別サーバーに設置し、サブドメイン / サブディレクトリでオウンドメディアを運営する
データベースSEO型メディアとアプリケーションとは切り離して別サーバーにWordPressを立て、サブドメイン / サブディレクトリでオウンドメディアを運営する方法です。サブドメインの場合はDNSの設定のみで問題ありませんが、サブディレクトリで運営する場合はnginxなどを利用して、リバースプロキシを挟まないといけないため、実装難易度が高めです。サーバーサイド、フロントエンドチームのみならず、インフラチームの支援も必要になるケースが多々あります。
メリットとしては、まずエンジニアがSEOのことを考えなくてもデフォルトでSEO要件の実装が簡単にできることです。
- マーケ側（Biz側）だけで運営可能なため、エンジニアの工数を奪わなくてもいい
- 初期構築後はエンジニア工数がほぼ不要
です。例えば、
- Sitemap構築
- JSON-LDの指定（構造化マークアップ）
- Google Analytics4 / Google Search Consoleの設定
- コンテンツの入稿
- 投稿者の認証/認可の管理
この辺も、とりあえずWordPressをたてればやってくれます。Bizがググれば、知識がなくてもなんとかなります。
ちなみにデータベースSEOサイトを自分でつくると、この辺は全部要件定義とコーディングが必要になります。
そして要件定義 / 最終的なQAをやるのも全部Bizチームになります。SEOに詳しくないエンジニアに丸投げでここを任せる場合、問題が起こるケースが多いです。（SEOの知識が強く求められるため）
例えば、WordPressを使わない場合、こういう面倒くささがあります。フルスクラッチで社内システムでCMSを構築し、それを外部ライターさんに社内システムの中で入稿してもらいたいとします。その場合、まず認可・認証システムをつくらないといけません。例えば、もともとエンジニアチームのみが入ることを想定していて、ユーザーの機密データが閲覧できるようになっていたとします。でも外部で業務委託しているライターさんにコンテンツの入稿のみ頼みたいとしたら？そのために認可機能を作らないといけません。記事を書く機能のように見えて、セキュリティ要件などもそうだし、考慮する内容が多いのです。
あと、地味に便利な点ですが、「多くの人が使い慣れたWordPressのエディタで入稿できる点」です。
独自CMSを作成して、管理画面で記事を入稿できることを考えてみてください。だいたいの場合、管理画面って事業に直結しないから、デザイナーの工数が使われず、エンジニアがUIから適当に作ることが多いです。となると、エディタのUXがかなりしんどくなります。（管理画面ちゃんとメンテされない問題）
- あの〜画像がアップロードできないんですけど….
- リビジョンが消えてしまいました….これもとに戻せないですか….
- あの〜…入稿方法がわからないのですが….
- すいません、1時間書いた記事が消えました…なんとかしてください…
- すいません、なんか動きません…
みたいな問い合わせが増えます。でも、前述したようにそこに工数は割けません。
その結果、ライターチームのエディタのオンボーディングコストなどが上がってしまいます。
エディタのUXに投資できないと、コンテンツの投稿スピードも落ちますし、市場からライターやディレクターを調達しても、入稿コストが高くて案件としては見送られやすくなります。採用の調達コストも跳ね上がります。
特にオウンドメディアの初期はディレクターが1名とかでいいのですが、規模が伸びてきたら大変です。管理画面に流し込む仕事とかは、規模が増えると大変になります。
こういうことを、WordPressを採用していれば特に考える必要はありません。
さて、デメリットですが、サブディレクトリに設置する場合は、リバースプロキシの設定などインフラ知識が必要が必要になります。サブドメインで置く場合はたいして問題はありません。問題はサブディレクトリです。
サブディレクトリの方がサイトパワーの恩恵は受けやすいのですが、ここの設定はかなり骨が折れます。インフラチームが強くないと、サイトが表示されなくなったりするリスクがありますので、そこが怖かったらいったんはサブドメインでもいいかな、と思います。
あとはデータベースSEO型メディアとは異なるデータベースを利用するため、もし連携を行いたい場合は、データベースSEO型メディアにAPI（データの窓口みたいなもの）を生やして、さらにWordPress側でAPIへのリクエストを行うショートコードを設定する、みたいな対応が必要になります。
※なお、2025年現在にエンジニアにWordPressを採用したいというと、「そんなレガシーでメンテしづらいCMSを技術選定しているなんて終わっている」と言われるケースが多いです。自分もエンジニアなので、わかります。単体テスト書けないし、プラグインやCMSに依存するWordPress, PHPのバージョン管理とかだるいし、、、、遅いし、、、、でも、エンジニアチームのSEOの知識がなかったりするとBizが成果を出せなくなりますし、エンジニアチームのリソースに依存してBizが動けない方が事業的にはリスクではないかなと思い、WordPressを推奨するケースが多いです。もちろん、一定の工数をオウンドメディアに割けますと確約できたり、SEOに強いエンジニアの方がQAまで含めて全部対応してくださるような頼もしいチームの場合は、そのチームの技術選定を尊重したほうが良いと思っています。
フェーズ別の技術選定指針
データベースSEO型メディアにオウンドメディアを組み込む場合、どの技術選定が最適かは 「狙うクエリの種類」 と 「事業フェーズ（リソース状況）」 によって変わります。
- 既存DBの情報を活かして「もうちょっとで上位表示できそうな差分」を埋めたい場合
- 既存DBでは対応できない異なる検索意図のクエリの差分を埋めたい場合
- 事業立ち上げ初期（リソース制約が大きい）場合
| シチュエーション | 推奨方針 | 実装イメージ |
| 1. 既存DBの情報を活かして「もうちょっとで上位表示できそうな差分」を埋めたい場合 | データベース型SEOサイトを運営しているWebアプリケーションの一部に自社独自のCMSを開発する | ・Restaurantテーブルに「restaurant_detail_id」を追加 ・RestaurantDetailテーブルを作成 ・RestaurantDetailの中に、詳細な説明を追加できるようにし、管理画面で編集可能にする |
| 2. 既存DBでは対応できない異なる検索意図のクエリの差分を埋めたい場合 | WordPressを別サーバーで構築 | ・https://restraurant.jp 配下に https://restraurant.jp/blogを設置 ・リバースプロキシを指定してWordPressをホスティング。 ・技術的に大変であれば、サブドメインで運用 (https://blog.restraurant.jp ) |
| 3. 事業立ち上げ初期（リソース制約が大きい）場合 | WordPressを別サーバーで構築 | ・https://restraurant.jp 配下に https://restraurant.jp/blogを設置 ・リバースプロキシを指定してWordPressをホスティング。 ・技術的に大変であれば、サブドメインで運用 (https://blog.restraurant.jp ) |
1. 既存DBの情報を活かして「もうちょっとで上位表示できそうな差分」を埋めたい場合
すでに上位表示されている特定のクエリの結果に対して、商品情報や補足テキストを追加したい場合。
例えばですが、
- レストランの詳細ページに対して、レストランを運営している方のレストラン紹介を記事のように入れたい
みたいなケースです。
つまり主なコンテンツがデータベース上にあって、補完的にテキストデータを載せたい、みたいなケースが多い場合。
ここでいうと、「アプローチ1: データベース型SEOサイトを運営しているWebアプリケーションの一部に自社独自のCMSを開発する」が最適です。既存のテーブルに、テキストを入れられる編集フィールドを追加してもらって、編集という形です。
データベースにフィールド、もしくはhas one のテーブルで新規テーブルをつけてassociation をつけて管理するだけなので、技術的負債がなければ1週間もあれば実装できるでしょう。
2. 既存DBでは対応できない異なる検索意図のクエリが多い場合
既存DBでは対応できない異なる検索意図のクエリが多い場合です。例えばですが、
- 「吉祥寺 レストラン おすすめ」は、どうも記事型ではないと上位表示させづらそうだ。レストランのアイテムを一覧表示しているだけだと上がりきらない。特に絶対とりたいクエリについては手動でもいいからとりたい」
こういうケースが多い場合です。
推奨アプローチとしては、WordPressを別サーバーで構築です。
3. 事業立ち上げ初期（リソース制約が大きい）場合
たとえばですが、
- 今のエンジニアチームは、公開しているマイルストーンの達成が重要なので、当分オウンドメディアのリソースはさけなさそう
という場合も、WordPress一択です。
理由は前述しましたが、オウンドメディア系の改善試作は永遠に対応されなくなる可能性があります。
事業インパクトは大きいのですが、事業インパクトが小さく見えるからです。
一方でWordPressを選定すると、この辺がBizで完結します。
自社でのデータベース型SEOメディアと、記事型メディアの活用事例
当社では、データベースSEOとオウンドメディアを掛け合わせた運用を実際に行っています。ここでは「独自性のあるコンテンツづくり」と「更新性の担保」に関する具体的な事例をご紹介します。
Media Analyticsにおける、データベース型SEOメディアと記事型メディアの活用事例
ざっくりとコンテンツをわけるとこんな感じになります。
| メディアカテゴリ | URL | 対象としているクエリ |
|---|---|---|
| データベース型SEOメディア アフィリエイト案件一覧ページ | https://media-analytics.jp/affisearch/ | ・「$案件名 アフィリエイト」 ・「$商材カテゴリ アフィリエイト」 |
| 記事型メディア ブログページ | https://blog.media-analytics.jp | ・「リファラーとは」 ・「コンバージョン リファラ」 ・「アフィリエイト おすすめ」 ・「特別単価」 |
データベース型SEOメディアで、アフィリエイト案件を探しているユーザーを広く集め、オウンドメディアではノウハウ系の記事や定義系の記事を書いています。
データベース型メディアでは、確かに多くのユーザーを獲得可能ですが、テンプレートが異なるキーワードの記事を入れることはできません。そういう時に、そっちは記事型メディアでコンテンツを入れるという意思決定をしています。
インディバースフリーランスにおけるデータベースSEOメディアと記事型メディアの活用事例
| URL | 対策しているキーワード | |
|---|---|---|
| データベース型SEOメディア インディバースフリーランス | https://freelance.indieverse.co.jp | ・$職種 フリーランス リモート ・$職種 フリーランス など |
| 記事型メディア インディバースフリーランスブログ | https://freelance.indieverse.co.jp/media | ・$フリーランスエージェント名 評判 など |
インディバースフリーランスのデータベース型SEOメディアでは、求人系のクエリをとりいにき、記事型メディアではアフィリエイトサイトがよく取りに行くようなキーワードを獲得しにいっています。
やってみると気づくのですが、同じドメインでも、
- データベース型SEOメディアの一覧ページ
- 記事型メディアのコラム記事
- ツール
これらはそれぞれ異なるページ評価がされている印象があります。ですので、
「このクエリは、データベース型SEOのPQ評価されると勝てないから、あえて記事型のほうでとりにいってみるか」
とやってみると、データベースではとれなかったものがコラムでとれたりするケースが多いです。
最後に
ということで、結論です
- データベース型SEOメディアと、記事型SEOメディアを両刀使いできると強い
- ただし、この全体設計や実装面は、全体が見れる人がいないと調整が難しい
当社では、データベース型SEOサイトの運営やオウンドメディア構築から記事制作まで、上のテーマに関してはなんでも対応できるかと思います。壁打ちや雑談レベルでも全く問題ないので、ぜひ気になったらご連絡くださいませ！
