売却や移行に強いメディアサイトは、どう設計すればいい？

結論（Conclusion）

売却や移行のオプションを残すには「不可逆な結合」を避ける。 コアのルールはこれ。

• コンテンツを ファイル資産 にする（Markdown + frontmatter）
• URL構造を早期に固定し、途中で変えない
• 画像/メタ/タグを規格化する
• いつか移行する前提でcanonical/redirectを設計する

背景（Explanation）

ポータブルにできない理由の多くは2つ。

• コンテンツがDBや独自ビルダーに閉じる
• SEOが乗った後でURLを変える

ポータブル設計は“後でやる”ではなく、最初からの規律。

実務手順（Practical Guide）

手順1：コンテンツを資産として分離する

• 記事はMarkdown + frontmatter
• テンプレ/表示ロジックと分離
• エクスポートが簡単

手順2：URL設計を固定する

例：

• /ja/<slug>/
• /en/<slug>/

判断基準：

• URLを変えるなら「評価のリセット」を前提にし、redirectを完璧に用意する。

手順3：frontmatter/メタを統一する

最低限：

• title
• description
• date/updated
• tags
• image

手順4：画像置き場と命名を規格化

• パスを固定（例：/public/thumbs/...）
• slugベースの命名

手順5：canonical/alternateを必ず出す

• canonicalの表記を統一
• 多言語ならhreflang

手順6：redirect戦略を先に決める

• 旧→新のマッピングファイルを持つ
• 内部リンクを壊れにくくする（システム跨ぎのハードコードを避ける）

失敗パターン（Pitfalls）

• 伸びてからslugを変える
• URL正規化（スラッシュ/大小/パラメータ）が混ざる
• CMSのDBに閉じてエクスポート不能
• 移行時にredirect計画がない

チェックリスト（Checklist）

• [ ] 記事がMarkdown + frontmatterで管理されている
• [ ] URL構造が固定され、文書化されている
• [ ] canonicalの表記が統一
• [ ] 多言語ならhreflangが揃っている
• [ ] frontmatterスキーマが統一
• [ ] 画像パス/命名が統一
• [ ] 旧→新redirectの方針がある
• [ ] 内部リンク戦略が壊れにくい（ハードコード回避）
• [ ] sitemapがcanonical/正規化と一致
• [ ] 移行テスト（エクスポート/インポート）の段取りがある

FAQ

Q1. 最初からWordPressにした方がいい？

あり。ただし静的サイトは早く安く始められる。その場合でも、コンテンツ資産化とURL固定を守れば移行可能性は残る。

Q2. 一番取り返しがつかない失敗は？

SEOが乗った後にURL構造を変えること。URLは“永久”として扱うのが基本。

Q3. 買い手は何を見る？

コンテンツが取り出せるか、URLが安定しているか、運用が複雑でないか（独自CMSロックインがないか）を重視する。

内部リンク（Internal links）

• 親記事（Hub）：インデックス（Indexing）：まずはここから
• 関連記事：
  • Next.js多言語のcanonical/hreflang落とし穴
  • Google Search Consoleの登録手順（Next.js + Vercel）
  • GTM/GA4の最低限イベント設計

参考（一次情報）

• Google Search documentation: https://developers.google.com/search

免責

売却の可否は買い手と実行次第。