不動産ブログはHugoとWordPressのどっち？837記事の実測で分かった自動化・SEO・運用コスト

「不動産ブログを始めたいが、HugoとWordPressのどちらを選べばよいか分からない」「記事更新に時間を取られず、検索流入や問い合わせを生む仕組みを作りたい」と悩んでいないでしょうか。

先に結論を示すと、選び方は次のとおりです。

• 記事生成・検査・公開をコードで自動化したいならHugo
• 非技術者が管理画面から共同編集したいならWordPress
• 物件検索や会員機能が中心なら、CMSだけでなくシステム全体で判断する

管理画面から記事を書けるWordPressは、初心者や複数人での編集に向いています。一方、HugoはMarkdownファイルから静的HTMLを生成する仕組みで、記事生成から公開までをプログラムで動かしやすいのが特徴です。

ただし、**「Hugoなら必ず高速」「WordPressなら必ず手間がかかる」**という単純な話ではありません。運営者の技術力、更新者の人数、物件検索機能の有無、保守体制によって適解は変わります。

この記事では、一般的な機能比較に加え、Hiroが運用する「AI × 不動産 自動ブログ」のリポジトリと実測ログを使い、次の点を明らかにします。

• 不動産ブログにおけるHugoとWordPressの仕組みの違い
• 自動投稿、SEO、保守、収益導線から見た判断基準
• 無人運用へ近づける具体的な構築手順
• 導入後に追うべきKPI
• HugoやWordPressが適さないケース

読了後には、自社の不動産ブログでどちらを採用すべきか判断し、最初の検証記事を公開するところまで進められるはずです。

この記事の検証範囲

スペック表だけを並べるのではなく、実際のHugoリポジトリに存在する記事数、Hugoのバージョン、ビルドコマンド、終了コードを確認しています。ただし、WordPress側で同一コンテンツを使った速度比較は実施していません。そのため、掲載するビルド時間はHugoの運用確認値であり、両CMSの性能を直接比較するベンチマークではありません。

HugoとWordPressの全体像

Hugoは「記事ファイルをHTMLへ変換する工場」

Hugoは、Go言語で作られた静的サイトジェネレーターです。静的サイトジェネレーターとは、Markdownなどの原稿から公開用HTMLをまとめて作るプログラムを指します。

例えば、次のような原稿を保存します。

---
title: "新宿区の中古マンション売却相場"
date: 2026-07-21
categories:
  - 不動産マーケティング
---

新宿区で中古マンションを売却するときは……

Hugoがこのファイルを読み、テーマや共通レイアウトを組み合わせてWebページを生成します。Hugo公式ドキュメントでも、Markdownを標準的なコンテンツ形式として扱い、HTMLへレンダリングすると説明されています。Hugo公式：Content formats

公開後に閲覧者へ配信されるのは、原則として生成済みのHTML、CSS、画像です。公開サーバーに編集画面や記事データベースを置かない構成を選べます。

この性質は、次のような自動化と相性が良好です。

1. SEOトピックをリストから選ぶ
2. AIやテンプレートでMarkdown原稿を作る
3. 表記、リンク、画像、出典をプログラムで検査する
4. GitHubへ保存する
5. Cloudflare Pagesなどが自動公開する
6. アクセスデータから次の改善対象を選ぶ

原稿をファイルとして扱えるため、記事数が増えても同じ検査ルールを適用しやすい点が強みです。

WordPressは「編集画面とデータベースを備えたCMS」

WordPressはCMS、つまり記事の作成、保存、公開、権限管理をブラウザ上で行う管理システムです。記事本文や設定は、MySQLまたはMariaDBなどのデータベースに保存されます。WordPress公式：FAQ Installation

ブロックエディターでは、見出し、画像、動画、表などを画面上で配置できます。HTMLやGitの知識がない営業担当者でも更新しやすい設計です。WordPress公式：Block Editor

また、編集者、投稿者、寄稿者などの権限を割り当てられます。営業担当者が下書きを作り、宅建士や責任者が確認して公開する運用を組みやすい点は、WordPressの大きな強みです。WordPress公式：Roles and Capabilities

仕組みの違いを比較

30秒で分かる選定フロー

次の順番で判断すると、CMS名だけで迷い続けずに済みます。

1. 物件検索、会員登録、お気に入り機能が必要か
   • 必要ならWordPressのプラグイン、外部サービス、個別開発を含めて比較する
2. 非技術者が複数人で記事を更新するか
   • 更新するならWordPressが有力
3. 記事生成から公開までコードで自動化したいか
   • 自動化したいならHugoが有力
4. Git、コマンド、ビルド障害へ対応できる人がいるか
   • いなければWordPressか、保守会社付きの構成を検討する
5. 問い合わせを外部フォームで代替できるか
   • 代替できるならHugoでも構築しやすい

重要なのは、「どちらが高性能か」ではなく、誰が、何を、どの頻度で更新するかです。

不動産ブログではどちらを選ぶべきか

Hugoが向くケース

次の条件が多いなら、Hugoを優先候補にできます。

• 地域情報、売却ノウハウ、相続、賃貸経営などの記事を大量に蓄積したい
• PythonやAIを使って下書き、校正、内部リンク設定を自動化したい
• GitHub上で記事の変更履歴を残したい
• 更新担当者が少なく、管理画面を必要としない
• 資料請求や相談受付は外部フォームで処理できる
• 公開サーバーの保守範囲を小さくしたい

例えば、「東京都23区×マンション売却」の地域記事を作る場合、区名、対象読者、関連ページを構造化データから差し込み、同じ品質検査を全原稿へ適用できます。

ただし、自治体情報や相場データを機械的に量産すると、古い数字や類似ページが増える危険があります。自動化する対象は公開作業だけではありません。

少なくとも、次の項目まで検査対象に含める必要があります。

• 出典URL
• 出典の確認日
• データの基準日
• 類似記事との重複率
• 更新期限
• 公開停止条件
• 人間による確認が必要なリスク区分

WordPressが向くケース

次の条件が多い場合は、WordPressが扱いやすいでしょう。

• 営業担当者や外部ライターがブラウザから直接投稿する
• 承認権限を細かく分けたい
• 物件検索、会員登録、コメント、複雑なフォームを短期間で追加したい
• コードを使わずにページデザインを変更したい
• 障害対応や更新を任せられる保守会社がいる

WordPressにもREST APIとApplication Passwordsがあり、外部プログラムから投稿できます。Application Passwordsは、対話型ログインではなくAPI連携に使う、個別に取り消し可能な認証情報です。WordPress公式：Application Passwords

したがって、**「WordPressでは無人化できない」**という評価も正確ではありません。AIが下書きを作成し、REST APIで予約投稿し、SNSへ連携する構成は可能です。

一方、本体、テーマ、プラグインの更新とバックアップは継続業務になります。WordPress公式も、未使用プラグインの削除、各ソフトウェアの更新、バックアップ、監視を推奨しています。WordPress公式：Hardening WordPress

どちらも単体では向かないケース

HugoかWordPressかを決める前に、別の選択肢を検討した方がよいケースもあります。

• 物件在庫を基幹システムとリアルタイム連携したい
• 会員ごとに非公開物件を出し分けたい
• 査定、追客、契約管理まで一つのシステムで処理したい
• 営業担当者ごとに顧客情報を管理したい
• 法令上の保存要件や厳格な監査ログが必要

この場合は、CMS選定ではなく、SaaS、CRM、物件データベース、認証基盤を含めたシステム設計が必要です。ブログ部分だけをHugoまたはWordPressに分離する構成も検討できます。

Hiroの実行ログ：3サイト・837記事をHugoで検証

Hiroの「AI × 不動産 自動ブログ」は、次の経路で動く構成です。

トピック一覧
  ↓
PythonからAI CLIを実行
  ↓
Markdown生成・品質検査
  ↓
Git commit / push
  ↓
Cloudflare PagesがHugoをビルド
  ↓
3つのブログへ公開

記事数の実測結果

2026年7月21日に、各サイトのcontent/posts直下にあるMarkdownファイルを数えた結果は次のとおりです。

直前のGitコミット2cc5eafには、「3サイト・836記事」という記録が残っていました。一方、今回の作業ツリーを再計測すると837件でした。

この1件の差は、運用実績を記事へ掲載するときに、過去の説明文を流用するのではなく、公開直前に数字を再計測すべき理由を示しています。

記事数は、次のPowerShellで再確認できます。

$sites = @(
  "sites/ai-tech",
  "sites/business",
  "sites/real-estate"
)

foreach ($site in $sites) {
  $count = @(
    Get-ChildItem `
      -LiteralPath "$site/content/posts" `
      -File `
      -Filter "*.md"
  ).Count

  "$site`t$count"
}

この集計はcontent/posts直下のMarkdownファイル数です。下書き、別ディレクトリの記事、生成済みHTMLのページ数を含む指標ではありません。

Hugoのビルド実測結果

同じWindows環境でHugo v0.163.3 extendedを使い、次の条件で3サイトをビルドしました。

hugo --source <各サイトのディレクトリ> --renderToMemory --quiet

--renderToMemoryは、公開物をディスクへ書き出さず、メモリ上でビルドを確認するためのオプションです。

2026年7月21日の再計測結果は次のとおりです。

3サイトとも終了コードは0でした。これは、計測時点の作業ツリーをHugoがエラー終了せずに処理できたことを示します。

ただし、この結果には次の限界があります。

• 各サイト1回だけの計測である
• ウォームアップ回と本計測回を分けていない
• CPU、メモリ、ストレージ使用率を固定していない
• CDNへのデプロイ時間を含んでいない
• WordPressとの同一条件比較ではない
• 終了コード0だけでは、リンク切れや本文の正確性まで保証できない

記事数と時間も単純には比例していません。テーマ処理、画像、タグ、キャッシュ、ストレージ状態などが影響するため、**「Hugoなら何記事でも数秒で処理できる」**と一般化することはできません。

この運用では、記事生成の入口をPythonへ集約し、カテゴリによって保存先を振り分けています。さらに、GitHubへのコミットとプッシュ、Cloudflare Pagesでの公開を自動化しています。人間が毎回管理画面へログインする工程はありません。

それでも、収益が自動的に発生する保証はありません。自動化できるのは、生成、検査、公開、計測、改善候補の抽出です。検索需要、記事の信頼性、商品との適合、問い合わせ品質が低ければ、記事数だけ増えても収益にはつながりません。

自動化できる不動産ブログの作り方

1. 収益までの導線を1本に絞る

最初に、記事を読んだ人へ何をしてほしいか決めます。

例えば、次のいずれかを選びます。

• 売却査定を相談してもらう
• 賃貸管理について問い合わせてもらう
• メール講座へ登録してもらう
• 不動産業務マニュアルを購入してもらう
• 提携サービスの紹介ページを見てもらう

「アクセスを集める」だけでは、自動化資産の成否を判定できません。記事、CTA、遷移先、成約地点を一本の経路として記録します。

記事
→ CTA
→ サービス説明
→ フォーム
→ 問い合わせ

2. 更新者と必要機能を書き出す

次のチェックリストに回答してください。

• 記事を書く人はコードやGitを扱えるか
• ブラウザ上の承認画面が必要か
• 物件データをリアルタイム検索するか
• 会員ログインやお気に入り機能が必要か
• 問い合わせは外部フォームで代替できるか
• 本体やプラグインを毎月点検できるか
• AI記事の誤情報を検出するルールがあるか
• ビルドや公開に失敗したときの担当者が決まっているか

静的記事と外部フォームが中心ならHugo、非技術者による共同編集や動的機能が中心ならWordPressが有力です。

3. 10記事で小さく検証する

最初から数百記事を生成せず、検索意図が異なる10記事を用意します。

ここでの「10記事」は、Hiroが初期検証に使う推奨単位です。検索順位や問い合わせ数を保証する件数ではありません。

例えば、次のように構成します。

1. 「横浜市 マンション 売却」の地域記事
2. 「専任媒介 一般媒介 違い」の比較記事
3. 「空室対策 内見」の悩み解決記事
4. 「不動産査定 必要書類」の手順記事
5. 自社サービスの事例記事
6. よくある失敗の記事
7. 費用や期間を説明する記事
8. 初心者向け用語解説
9. 地域固有の相談事例
10. サービス選定のチェックリスト

各記事には、最低でも次の情報を持たせます。

target_reader: "横浜市でマンション売却を検討している所有者"
source_date: "2026-07-21"
review_due: "2026-10-21"
primary_cta: "売却相談"
risk_level: "medium"

4. 公開工程を自動化する

Hugoなら、Markdown保存後に検査、ビルド、Gitへの保存、公開確認を実行します。

原稿生成
→ 表記検査
→ 出典検査
→ リンク検査
→ Hugoビルド
→ Gitへ保存
→ 公開
→ URL確認

WordPressなら、APIで下書き投稿し、画像、カテゴリ、公開日時を設定します。

最初から自動公開にはせず、下書き状態で送信して次の点を確認してください。

• 認証エラーがないか
• アイキャッチ画像が欠落していないか
• カテゴリが正しいか
• 同じ記事が二重投稿されていないか
• 予約日時とタイムゾーンが正しいか
• CTAや内部リンクが壊れていないか

5. 停止条件を設定する

完全自動化には、「動かす条件」だけでなく「止める条件」が必要です。

• 出典URLがない相場記事は公開しない
• 出典の確認日がない記事は公開しない
• 画像が取得できなければ下書きへ戻す
• 同じタイトルやslugがあれば処理を停止する
• ビルド終了コードが0以外なら公開しない
• リンク検査で重大エラーがあれば公開しない
• 1日の投稿上限を超えたら翌日に回す
• 法律、税務、融資条件を含む記事には更新期限を設定する
• 高リスク記事は人間の承認があるまで公開しない

投稿上限は、サーバー性能だけでなく編集体制から決めます。大量投稿できる設定値を、そのまま適切な公開数だと考えないでください。

6. CTAと計測タグを設置する

記事ごとに主要CTAを一つ設定し、次のイベントを計測します。

検索表示
→ 記事クリック
→ CTAクリック
→ 商品・相談ページ到達
→ 問い合わせ・購入

表示回数だけでは、収益導線の詰まりを発見できません。記事ごとに、CTAクリック以降を追える状態にします。

計測イベントには、少なくとも次の項目を持たせます。

event_name
article_id
article_category
cta_id
landing_page
timestamp

個人情報や広告計測に関わる設定は、利用する解析サービスの規約と自社のプライバシーポリシーを確認したうえで実装してください。

7. 週次で改善候補を自動抽出する

週次レポートでは、次の記事を優先的に抽出します。

• 検索表示は多いがクリック率が低い
• 読まれているがCTAが押されていない
• CTAは押されているが問い合わせにつながらない
• 公開後もインデックスされていない
• 更新期限を過ぎている
• 内部リンクの入口が少ない
• 同じ検索意図の記事と競合している

人間が介在しない運用を目指すなら、データ取得、優先順位付け、タイトル案の生成、再ビルドまで自動化できます。

ただし、不動産の価格、制度、法令に関わる記述には誤認リスクがあります。公開停止ルールや専門家確認の対象を、あらかじめ定義してください。

専門家目線のチェックポイント

SEOはCMS名よりページ品質で判断する

Hugoを使っただけで検索順位が上がるわけではありません。WordPressも、キャッシュやCDNを適切に設定すれば高速化できます。

確認する項目は次のとおりです。

• 検索意図に合う回答が冒頭にあるか
• 地域名だけを差し替えた重複記事になっていないか
• 実例、調査条件、更新日が記載されているか
• 一次情報へのリンクがあるか
• 関連記事への内部リンクがあるか
• 画像の代替テキストが内容を説明しているか
• スマートフォンでCTAが見つけやすいか
• 古い物件情報を残す場合に更新履歴が分かるか
• 著者や監修者の経験範囲が明示されているか

保守コストは「月額料金」ではなく作業時間で見る

Hugoでも、テーマ更新、ビルド環境、GitHub連携が壊れる可能性があります。WordPressでも、保守込みのマネージドサービスを選べば、運営者の作業を減らせます。

比較するときは、次の式で見積もります。

月間運用コスト
＝ サーバー・サービス料金
＋ 定期更新時間 × 担当者の時間単価
＋ 障害対応時間 × 担当者の時間単価
＋ 品質確認時間 × 確認者の時間単価

例えば、月額料金が安くても、障害対応に毎月5時間かかる構成は、必ずしも低コストではありません。

金額を試算する場合は、自社の契約料金と作業記録を使ってください。この記事では、環境差の大きい一般的な月額相場を断定しません。

「無人化」と「無責任な公開」を分ける

不動産ブログでは、誤った税率、法律、融資条件、物件情報が読者の判断へ影響する可能性があります。記事生成を無人化しても、公開責任まで消えるわけではありません。

次のように、リスクで処理を分ける方法があります。

• 低リスク：用語集、掃除、内見準備などは自動検査後に公開
• 中リスク：地域情報や相場は出典日と更新期限を必須化
• 高リスク：法令、税務、融資、投資判断に関わる内容は公開前確認へ送る

収益が発生する可能性はありますが、成果を保証する仕組みではありません。本記事は一般的な情報提供であり、個別の投資、法律、税務に関する助言ではありません。

一次情報と視覚証拠の読み方

この記事に掲載している画像は、構成やKPIを理解しやすくするための概念図です。実際のターミナル画面や解析画面のスクリーンショットではありません。

実測値を判断するときは、画像の見栄えではなく、次の情報を一組で確認してください。

• 計測日時
• 対象リポジトリまたはコミット
• Hugoのバージョン
• 実行コマンド
• 対象ディレクトリ
• 記事数の数え方
• 終了コード
• 計測回数
• 計測に含まれない工程

公開用の視覚証拠を追加する場合は、次の3点が有効です。

1. HugoとWordPressの公開フロー比較図
   Hugoは「Markdown→ビルド→CDN」、WordPressは「管理画面→DB→PHP→閲覧者」と描きます。

2. 実行ログのスクリーンショット
   837件の記事数集計と、3サイトすべての終了コードが0になった結果を掲載します。日時、Hugoバージョン、実行コマンドも同じ画面に残します。

3. 検索から収益までのファネル図
   表示回数、検索クリック、CTAクリック、問い合わせ、購入を矢印で結び、どこで離脱したか分かるようにします。

機密情報、ローカルパス、APIキー、顧客名がスクリーンショットへ入らないよう、公開前にマスキングしてください。マスキング後も、検証に必要な日時、コマンド、件数、終了コードは残します。

よくある失敗と対策

Hugoを選んだが記事を編集できない

原因：更新担当者がMarkdown、Git、コマンド操作を使えない。

対策：外部CMSや投稿フォームを追加します。非技術者が多い場合はWordPressも再検討してください。システムの速さより、更新が止まらない運用を優先します。

WordPressのプラグインを増やしすぎる

原因：SEO、フォーム、画像圧縮、キャッシュなどのプラグインを、役割の重複を確認せずに追加する。

対策：各プラグインの目的、管理者、更新日、代替手段、削除条件を一覧化します。更新前にはバックアップを取り、可能であればステージング環境で動作を確認します。

記事数を成果として扱ってしまう

原因：自動生成できた件数だけを記録し、検索流入やCTAを見ていない。

対策：公開数は稼働確認の指標に限定し、検索クリック、CTAクリック、問い合わせまで追います。837記事という実績も、収益性を直接示す数値ではありません。

古い不動産情報が自動公開される

原因：生成日、出典の基準日、更新期限を分けて管理していない。

対策：記事のfront matterやカスタムフィールドへsource_dateとreview_dueを保存します。期限を過ぎた記事は、自動更新または非公開候補へ送ります。

自動投稿が重複する

原因：途中で処理が失敗し、再実行時に同じ記事を投稿する。

対策：トピックIDやslugを一意キーにし、「存在確認→生成→保存」の順に処理します。WordPress APIでも、送信前に既存記事を検索してください。

ビルド成功だけで公開品質を保証してしまう

原因：Hugoの終了コード0を、本文の正確性やリンクの正常性まで保証する結果として扱う。

対策：ビルド検査とは別に、リンク、画像、出典、重複、禁止表現、更新期限を検査します。公開後には、実際のURLへアクセスする監視も追加します。

成果を測るKPI

比較には同じ期間と条件を使います。例えば、「公開後28日間」の数字を記事ごとに比べるなど、集計条件を固定してください。

収益額を見る場合も、広告、相談、商品販売、アフィリエイトなどの経路を分けなければ、改善点を特定できません。

今日から取るべき行動

Hugoは、Markdown、Git、Python、Cloudflare Pagesなどを組み合わせ、記事生成から公開までを自動化したい運営者に向いています。

WordPressは、非技術者による共同編集、権限管理、動的機能を早く導入したい組織に向いています。

今日できる具体的なアクションは、次の3つです。

1. 自社ブログの収益導線を「記事→CTA→成約地点」の一行で書く
2. 必要機能と更新者をチェックリストへ記入する
3. HugoまたはWordPressで10記事だけ公開し、28日間のKPIを記録する

迷っている場合は、まず次の一文を完成させてください。

私たちは、［誰が］記事を更新し、
［どの機能］を使って、
読者を［成約地点］へ案内する。

この一文に「複数の営業担当者」「管理画面」「物件検索」が入るなら、WordPressが有力です。

「Python」「Git」「定型記事」「外部フォーム」が入るなら、Hugoを検証する価値があります。

自動化資産は、記事を大量に作るプログラムではありません。需要のあるテーマを選び、根拠を検査し、公開し、反応を測り、改善する循環まで止まらず動く状態です。

機械が公開作業を引き受ければ、人は戦略や高リスク情報の確認へ時間を使えます。

本気で自動化できる仕組みを構築したい方へ

「仕組みの違いは分かった。しかし、記事生成、品質検査、公開、収益導線をどう接続すればよいか分からない」

そんな方に向けて、実際に手を動かしながら構築できる実践マニュアルを用意しています。

毎回ログインして投稿する運用から抜け出し、作業していない時間にも記事が蓄積され、検索流入と商品導線を検証できる仕組みへ移行してみませんか。

収益を保証するものではありませんが、手作業を記録可能な自動処理へ置き換えることで、測定し、改善できる運用資産として育てられます。

次の休日を調査と設定だけで終わらせたくない方は、目的に合うマニュアルをこちらから選んでください。

👉 本気で自動化・不労所得を構築したい方向けの実践マニュアルを見る