はてなブログからWordPressへ移行する完全手順｜SEOを落とさず引っ越すロードマップ

2025年8月21日2026年3月6日

「はてなブログからWordPressに移行したい」と思ったとき、最初にぶつかるのは“手順そのもの”よりも、失敗したらどうなるのかという不安ではないでしょうか。

たとえば、こんな声が多いです。

「移行した途端に検索順位やアクセスが落ちたらどうしよう…」
「独自ドメインの切り替えって何を触るの？ DNSとか怖い…」
「301リダイレクトってやらないとダメ？どこまで必要？」
「はてなの記事データは移せても、画像や装飾が崩れるって本当？」
「アドセンスやアフィリエイトリンクはそのまま使える？計測は？」
「記事数が多い… どこから手をつければいいか分からない」
「無料版（サブドメイン）からでも移行できる？現実的なやり方が知りたい」

WordPress移行は、やみくもに進めると「表示はできたけど、SEOと収益が崩れた」「どこが原因か分からない」状態になりがちです。
逆に言えば、正しい順番（ロードマップ）で進めれば、初心者でも落ち着いて移行できます。

この記事では、はてなブログ→WordPress移行を 準備〜移行〜公開後の監視まで一気通貫で整理し、失敗しやすいポイントを先回りして潰します。

読み終える頃には、次のことができる状態を目指します。

移行パターン（Pro/無料版、独自ドメイン有無）に応じて 最短ルートが分かる
URL設計・301・canonicalなど、SEOの重要ポイントを押さえられる
DNS/SSL/計測（Search Console・GA）を含めて、移行後の不安を減らすチェックができる
記事数が多くても、優先順位をつけて段階的に進められる

「失敗しない移行」のコツは、派手なテクニックではなく、基本を“順番どおり”に実行することです。
まずはロードマップに沿って、一歩ずつ進めていきましょう。

サイト引っ越し屋さん公式サイト

まず確認：あなたの移行パターンはどれ？（最短ルートが変わります）

はてなブログ→WordPress移行は、「今のブログの状態」で最短ルートが変わります。
先にここを整理すると、移行後に起きがちな アクセス減・リンク切れ・設定迷子 をかなり減らせます。

はてなブログPro＋独自ドメイン（王道・推奨）

結論：いちばんスムーズに移行しやすい勝ちパターンです。✨
理由はシンプルで、ドメイン（例：example.com）を自分で管理できるので、移行後もURL設計やSEO対策（301など）を組み立てやすいからです。

このパターンの特徴

✅ 独自ドメインを引き続き使える（資産性が高い）
✅ WordPressに切り替えても、ドメインを変えずに運用できる可能性が高い
✅ 設計次第で、検索評価を保ちやすい

初心者が最初に見るべきポイント

「今のURLの形」がどうなっているか
例）
- 日付入り：/2026/03/06/記事タイトル のような形
- entry系：/entry/記事タイトル のような形
「移行後にURLを同じ形に寄せられるか」
→ ここが寄せられるほど、後の作業が短くなります。

おすすめの判断

「将来もブログを育てたい」「収益化したい」「サイト設計を作り込みたい」なら
👉 Pro＋独自ドメインのままWordPressへが最適解になりやすいです。

はてな無料版（サブドメイン）の場合：できること／難しいこと

結論：移行はできるけど、“ドメインを引き継ぐ移行”が難しいため、SEO面の設計が変わります。
（例：〇〇.hatenablog.com → example.com のように、ドメインが別物になる）

できること

✅ 記事データを移して、WordPress側で記事として再構築する
✅ デザイン・機能・広告・計測などを自由に作れる

難しいこと（ここが落とし穴）

⚠️ 元のURL（サブドメイン）を、自分のWordPressへそのまま引き継ぐのは基本的にできない
⚠️ その結果、検索エンジン上では「別サイト」と見られやすく、移行直後は不安定になりがち

初心者向けの現実的な考え方

“引っ越し”というより、新しい家（独自ドメイン）に「引っ越して作り直す」イメージ
その代わり、WordPressで
- 記事の質を上げる
- 内部リンクを整理する
- カテゴリを再設計する
  など、伸びる土台を作れます。

こんな人は無料版→WPでもOK

「はてなでまず練習して、これから本気で育てたい」
「記事を整理し直したい（不要記事を捨てたい）」
「今はアクセスが少なめで、移行による変動リスクが小さい」

記事URLが「日付入り」か「カスタムURL」か

結論：URLの型が違うだけで、必要な作業がガラッと変わります。
移行を簡単にするコツは、まず “現在のURLの型”を把握することです。

代表的なURL型（例）

日付入り：/2026/03/06/記事タイトル
- 特徴：記事ごとに日付が関わる
- 影響：WordPress側でも近い形に寄せる設計が必要になりやすい
カスタムURL（スラッグ）：/article-name/ のような任意文字
- 特徴：WordPressの運用と相性が良い
- 影響：移行後のURLを揃えやすく、整理しやすい

ここだけ先にチェック（超重要）

直近の5記事くらいのURLを見て、型をメモする
- 日付が入っている？
- entry が入っている？
- 記事ごとにURLがバラバラ？
「揃えられる型」か「揃えにくい型」かで、移行方針が決まります。

初心者が迷ったときの判断軸

URLをなるべく変えたくない → 現行URLに近い設計でWordPress側を作る
URLを整理して強くしたい → 主要記事だけ優先して整備し、残りは段階的に最適化

複数人運営・複数ブログ・カテゴリ設計を変える予定があるか

結論：当てはまるほど、移行は「引っ越し」ではなく “サイト再設計プロジェクト” になります。
ここを甘く見ると、移行後に「記事はあるのに回らない」状態になりやすいです。

複雑になりやすいケース

複数人で投稿（投稿者・権限・運用ルールが必要）
複数ブログを統合（カテゴリが膨らみやすい）
カテゴリ設計を変える（内部リンクも再設計が必要）

この場合に先に決めること（おすすめ順）

ゴールの形：ブログ型？メディア型？（カテゴリ中心？タグ中心？）
カテゴリの骨組み：最大でも7〜10個程度に抑える
主要記事の役割：
- まとめ記事（入口）
- 比較記事（検討）
- レビュー記事（決定）
  を整理する
運用ルール（複数人の場合）：
- 投稿者名の扱い
- 記事チェック手順
- アイキャッチ／見出しルール

早見表：あなたの難易度はどれ？

スクロールできます

パターン	移行のしやすさ	SEOを守りやすさ	追加で増えがちな作業
Pro＋独自ドメイン／単独運営／カテゴリ現状維持	高い	高い	最小限の整形・設定
Pro＋独自ドメイン／カテゴリ再設計あり	中	中〜高	内部リンク再構築
無料版（サブドメイン）→独自ドメイン新設	中	中（立て直し型）	主要記事の優先整備
複数ブログ統合・複数人運営	低〜中	設計次第	ルール作り＋再設計

初心者向けの安全策

いきなり全部を完璧にしない
👉 まずは 「主要記事（よく読まれる記事）」から整える
設計変更をするなら
👉 カテゴリだけ先に決めて、タグは後から増やす（管理が楽）

サイト引っ越し屋さん公式サイト

WordPressへ移行する前に知っておくべきメリット・デメリット

はてなブログからWordPressへ移行すると、できることが増える一方で「自分で面倒を見る範囲」も広がります。
ここを理解してから移行すると、後悔や遠回りが減ります。

得られる自由度（デザイン／機能／収益化／資産性）

WordPressに移行する最大のメリットは、ひとことで言うと 「制限が減る」 ことです。
やりたいことが明確な人ほど、恩恵が大きくなります😊

1) デザインの自由度が上がる

テーマでサイト全体のデザインを一括変更できる
余白・見出し・CTA（ボタン）・導線などを、狙いどおりに作れる
企業サイト風／メディア風／ブログ風など、方向性を変えやすい

2) 機能を“足して伸ばせる”

プラグインや設定で、必要な機能を拡張できる
例）目次、関連記事、フォーム、会員機能、検索強化、表示高速化など
「記事を書く」だけでなく、サイトとしての完成度を上げられる

3) 収益化の選択肢が広がる

広告配置の自由度が高い（場所・表示条件・ABテストなど）
商品比較表、ランキング、レビュー導線などの作り込みがしやすい
“売れる導線設計” を自分で最適化しやすい

4) 資産性を高めやすい

独自ドメインで運用すれば、プラットフォーム依存が弱くなる
（将来の引っ越し・構成変更もしやすい）
カテゴリ設計や内部リンクを整理し、検索意図に合う構造を作りやすい

✅ まとめると、WordPressは「ブログ」だけでなく、“伸びるメディアの形” に育てやすいのが強みです。

増える運用コスト（保守・セキュリティ・更新作業）

WordPressのデメリットは、機能の自由と引き換えに 運用の責任が増える ことです。
ただし、最初から“必要最低限の仕組み”を入れれば、初心者でも十分回せます。

1) 費用が発生しやすいポイント

サーバー費用（WordPressを動かすための場所）
ドメイン費用（独自ドメインの場合の更新）
有料テーマ／有料プラグイン（必要なら）
外注費（移行代行や保守サポートを頼む場合）

※WordPress本体（WordPress.org）は基本的に無料ですが、運用環境には費用がかかります。

2) 作業（手間）が発生しやすいポイント

アップデート対応（WordPress本体・テーマ・プラグイン）
バックアップ管理（復元できる状態が大事）
セキュリティ対策（ログイン保護、不要機能の停止、脆弱性対応）
不具合対応（表示崩れ、プラグイン競合、速度低下など）

初心者がラクにするコツ（ここが重要）

いきなり“盛らない”
→ プラグインは必要最小限にして、増やすなら理由を明確に
自動化できるものは自動化
→ 自動バックアップ、更新通知、セキュリティの基本設定
「困った時に戻れる」状態を作る
→ 復元手順だけは早めに確認しておく

📌 目安として、移行後の運用は「週1の軽い点検」＋「月1のメンテ」で回る形を作るのが現実的です。

移行直後に順位が揺れる理由と、焦らないための目安

移行直後に検索順位やアクセスが揺れるのは、よくあることです。
原因が分かっていれば、必要以上に不安にならずに対処できます。

順位が揺れやすい主な理由

URLが変わった（または一部だけ変わった）
301リダイレクトが不十分／ミスがある
旧ページが一時的に404になっている
サイト構造（カテゴリ・内部リンク・パンくず）が変わった
表示速度やモバイル表示が変わった
検索エンジンが「新しいサイト構成」を再評価している

焦らないための“チェック順”
移行後は、順位よりもまず 「技術的に正しい状態か」 を確認するのが先です。

公開直後（当日〜数日）
- 404が大量発生していないか
- 主要記事に旧URLから正しく飛べるか（301）
- トップ・カテゴリ・人気記事が普通に閲覧できるか
1〜2週間
- Search Consoleで「インデックス」「エラー」「サイトマップ」を確認
- 重要ページが新環境で正しくクロールされているか
数週間〜数ヶ月（サイト規模で差が出ます）
- 大きな構造変更をした場合は、評価が落ち着くまで時間がかかりやすい
- 逆に、URL設計と301がきれいで、構造が素直なら早めに安定しやすい

やってはいけない焦り対応

移行直後に、大量の記事を削除・非公開にする
URLをさらに何度も変える
301の方針が固まらないまま、場当たり的に追加する

✅ まずは 「404を消す」「301を整える」「主要記事を優先して整形」。
これだけで回復の確率が上がります。

サイト引っ越し屋さん公式サイト

全体スケジュールと必要なもの（費用・時間・作業量の見積もり）

はてなブログ→WordPress移行は、ざっくり言うと

①準備 → ②WordPressの土台づくり → ③データ移行 → ④整形・SEO設定 → ⑤公開後チェック

の順で進みます。
先に「どこで時間とお金が増えるか」を把握しておくと、初心者でも迷いにくいです。

所要時間の目安（記事数別）

移行時間は 「記事数」×「整形の量（装飾・画像・埋め込み）」 で伸びます。
特に時間を食うのは、インポートよりも 移行後の整形（崩れ修正・リンク確認） です。

作業ボリュームのざっくり内訳

準備（棚卸し・バックアップ方針）…1〜2時間
WordPressセットアップ（サーバー・SSL・初期設定）…1〜2時間
エクスポート→インポート（記事データの移動）…30分〜2時間
整形（装飾、画像、内部リンク、埋め込みの修正）…ここが本番
SEO周り（URL・301・サチコ等）…1〜3時間
公開後チェック（404/表示/計測）…1〜2時間

記事数別の目安（初心者向け）

スクロールできます

記事数	最短（シンプル記事中心）	現実的（装飾や画像が多い）	つまずきポイント
〜30本	半日〜1日	1〜2日	見出し・囲み・画像の崩れ
31〜100本	1〜2日	3〜7日	内部リンク切れ・整形の量
101〜300本	2〜4日	1〜2週間	301設計・確認作業の増加
301本〜	1週間〜	2〜4週間	“全部完璧”にこだわると終わらない

初心者でも破綻しない進め方（おすすめ）

まずは 主要記事（アクセスが多い上位10〜30本）を最優先で整える
残りは「見た目は最低限 → あとで順番に整える」でOK
→ 最初から全部を完璧にしようとすると、ほぼ確実に挫折します😅

かかる費用（サーバー／ドメイン／テーマ／外注の選択肢）

費用は「どこまで自分でやるか」で大きく変わります。
ここでは初心者が判断しやすいように、最低ライン／標準／こだわりで分けます。

毎月・毎年かかる費用（固定費）

サーバー代：月額数百円〜数千円（契約期間やキャンペーンで変動）
ドメイン代：年額0円〜数千円
- サーバー特典で「ドメイン無料」になる場合もあり
- 自分で更新する場合は 更新費用がかかる（ここが盲点）
はてなブログPro（移行作業中だけ残す場合）：月額 or 年額
- 移行作業中は、旧サイト確認のために 1ヶ月だけ継続する人もいます

初期費用（最初だけ）

テーマ代（任意）
- 無料テーマ：0円
- 有料テーマ：1〜2万円前後が多い（買い切り型が主流）
必要に応じて：画像圧縮、バックアップ強化など（無料でも運用可）

予算別のイメージ（初心者向け）

スクロールできます

パターン	こんな人向け	初期費用の目安	毎月の目安
最低ライン（まず移行だけ）	とにかく早く引っ越したい	0〜数千円	サーバー代のみ
標準（失敗しにくい）	長く運営・収益化も視野	テーマ代が入ることも	サーバー＋ドメイン（無料特典なら抑えやすい）
こだわり（時短・安全）	時間を買いたい／不安が強い	外注費が上乗せ	固定費は上と同じ

外注の選択肢（どこまで任せるか）

外注は「何を含めるか」で価格が変わります。初心者が混乱しやすいので、まず分解します。

よくある依頼範囲

A：記事の取り込みだけ（インポート中心）
B：デザイン崩れの修正も含む（整形まで）
C：SEO移行も含む（301・サチコ・構造など）
D：丸投げ（設計・検証・保守込み）

考え方のコツ

“安さ”で選ぶと、結局 SEOや整形が手つかずで追加費用になりやすい
迷ったら、まずは 「主要記事だけC（SEOまで）」 を検討するとコスパが良いです

移行当日に避けたい時間帯（アクセスが多い時間の回避）

移行当日は、DNS反映や設定変更で一時的に表示が不安定になることがあります。
だからこそ、「アクセスが少ない時間」×「自分が落ち着いて作業できる時間」 を選ぶのが大事です。

基本ルール

アクセスが多い時間帯は避ける（特に新規訪問が増える時間）
平日の深夜〜早朝が選ばれやすい
作業後すぐに確認できるよう、寝る直前は避ける（ミスに気づけない）

実務的におすすめの時間帯

✅ 早朝（例：5:00〜9:00）
- アクセスが比較的少ない
- 作業後に日中の確認時間を確保しやすい
✅ 平日午前〜昼（例：10:00〜14:00）
- 自分が起きていて落ち着いて作業できる
- トラブル時にサポートへ連絡しやすい

避けたほうがいい時間帯（ありがち）

⚠️ 夜（例：19:00〜24:00）
- アクセスが増えやすい
- 焦って作業してミスが出やすい
⚠️ 金曜夜〜土日
- 直す時間が確保できないと詰みやすい
- サポート対応が遅い場合もある

移行当日の“安全運用”チェック

旧環境（はてな側）は即解約しない
→ 最低でも数日〜1〜2週間は残しておくと安心
作業前に「戻せる状態」だけ作る
- バックアップの確認
- WordPressのログイン確認
- SSL（https）で表示できるか確認
ピーク時間の見極めは自分のデータが最強
→ GA/サチコ、またはアクセス解析で「よく読まれる時間帯」を先に見ておくのがおすすめです

サイト引っ越し屋さん公式サイト

移行前チェックリスト（これをやると失敗が激減）

移行で一番多い失敗は、「移したつもりで、重要なものが抜けていた」パターンです。
作業に入る前に、次の4つだけでも整理しておくと安心度が一気に上がります。

バックアップ方針（何を・どこまで・どう戻すか）
URL構造の記録（301やURL再現の材料）
計測の棚卸し（移行後に数字が消えないように）
外部サービス連携の洗い出し（埋め込み・フォーム・SNSカード等）

バックアップ方針：記事・画像・計測・広告・CSS/埋め込みの控え

はてなブログのエクスポートは便利ですが、「全部が全部、同じ形で移る」とは限りません。
なので、“戻せる状態”を意識してバックアップを組みます。

1) 最低限これだけは守る（初心者の安全ライン）

記事本文のバックアップ（はてな側でエクスポート）
画像のバックアップ（別途）
コード類の控え（計測・広告・埋め込み・カスタムCSS）
移行前の状態がわかる記録（スクショでOK）

2) コピペ用：バックアップ実行チェック

以下を1つずつ☑していくと漏れが減ります。

☑ 記事データをエクスポート（ダウンロードできたファイルを保管）
☑ 画像をバックアップ（「よく使う画像」「アイキャッチ」「重要記事内の画像」から優先）
☑ サイドバー／ヘッダー／フッターの内容を控える（スクショ＋テキスト）
☑ カスタムCSSがあれば全文コピーして保存
☑ 埋め込み（script/iframe）を使っている記事があるか確認
☑ 広告・計測タグを控える（後述の棚卸しとセットで）

3) “戻せる”を強くする小ワザ

重要記事（アクセスが多い記事）だけでも、本文をテキストで別保存しておく
→ 移行時の装飾崩れがあっても復旧が早いです。
ブログ全体の見た目は、スクショで保存（トップ／カテゴリ／記事ページの3点）
→ 移行後の「何が変わった？」比較が楽になります。

現状のURL構造を記録（後で301設計に使う）

移行でSEOを守る鍵は、極端に言うと 「URLをできるだけ変えない」か「変えたら正しく案内する（301）」 です。
そのために、まずは現状のURLを“材料として”残します。

1) まず確認するのは「URLの型」

次のどれに近いかを把握してください（完璧に理解しなくてOK）。

日付が入る型（例：/2026/03/06/slug）
entryが入る型（例：/entry/slug）
記事ごとにバラバラ（例：一部だけカスタムURL）

ここが分かるだけで、移行後の方針が立ちやすくなります。

2) 記録しておくURLは「全部」じゃなくていい

初心者がやりがちなのが、最初から全URLを完璧に管理しようとして疲れることです。
おすすめは次の優先順位です。

優先度A（必ず）

検索流入が多い 上位ページ30〜100本
トップ／カテゴリ一覧／プロフィール／お問い合わせなどの重要ページ

優先度B（できれば）

被リンクが多い記事（他サイトから紹介されている記事）
SNSで伸びた記事（シェアされやすい記事）

3) 記録テンプレ（これがあると301設計が激ラク）

スプレッドシートに、最低これだけ作っておくと後工程が早くなります。

スクロールできます

旧URL	ページ種別	新URL案（仮）	優先度	メモ
（コピペ）	記事/固定/カテゴリ	（未定でOK）	A/B	旧URLの型・注意点

ポイントは、新URLは“仮”でOKなこと。
先に旧URLを集めるだけでも価値があります。

アクセス計測の棚卸し（GA/サチコ/広告タグ/イベント計測）

移行後に「アクセスがゼロになった！」と焦る原因の多くは、計測タグの入れ忘れです。
移行前に“今どれを使っているか”を棚卸ししておくと、再設定がスムーズです。

1) 棚卸しするもの（初心者向け・必要十分）

GA（Google Analytics）：計測ID／導入方法（直貼り or タグマネ）
Search Console：プロパティの種類（ドメイン or URLプレフィックス）
広告タグ：AdSense、ASPの計測タグ、クリック計測
イベント計測：ボタン・リンククリックのイベント（設定している場合）

2) 具体的な“控え方”（迷わない方式）

管理画面の設定画面（計測系）を開いて、次を保存します
- 計測IDやコンテナID（文字列をメモ）
- どこに入れているか（例：ヘッダーに貼っている／解析設定に入れている）
可能なら、ブラウザ表示のソースで「gtag」「GTM」「adsbygoogle」等を検索して
“入っていること”を確認（完璧じゃなくてOK）

3) ここだけ注意（後で詰まりやすい点）

計測タグは「記事内」ではなく、全ページ共通の場所に入れるのが基本
→ 移行後に「一部のページだけ計測されない」を防げます。
広告も同様に、どこで表示しているか（記事上／記事下／自動広告など）をメモ
→ WordPressで同じ導線を再現しやすくなります。

外部サービス連携（SNSカード、フォーム、ランキング、目次等）の洗い出し

移行で地味に時間を奪うのが、外部サービスの埋め込みや連携です。
これを先に洗い出しておくと、移行後の「表示されない…」が激減します。

1) 洗い出し対象（よくあるもの）

SNSカード（OGP／X（Twitter）カード等）
フォーム（問い合わせ、資料請求、予約）
ランキング・比較表（自作表、外部ツール、ASPのパーツ）
目次（はてな標準／自作コード／埋め込み）
埋め込み（YouTube、X投稿、Instagram、Amazon、Googleマップ等）
リンクカード（ブログカード的な表示）
コメント関連（外部コメント、通知系）

2) いちばん簡単な洗い出し手順（初心者向け）

まず アクセス上位10〜20記事 を開く
次の“見た目”があるかチェックしてメモ
- 変わった枠・ボタン・表・カード
- 予約フォームや問い合わせフォーム
- SNS投稿の埋め込み
次に、はてなブログの設定で
- サイドバー
- フッター
- HTML貼り付け欄
  をざっと確認（スクショでOK）

3) 記録テンプレ（外部連携の控え）

スクロールできます

種類	使っているサービス名	どこにある？（記事/全体）	必要情報	代替案
フォーム	例：Googleフォーム等	記事内/固定	URL/埋め込みコード	WPフォームに置換
SNS	例：X埋め込み	記事内	埋め込みの種類	ブロックで再埋め込み
表・ランキング	例：比較表	記事内	表の元データ	WPの表に再作成

コツ：代替案までメモしておくと、移行後の修正が“作業化”できます。

サイト引っ越し屋さん公式サイト

WordPress側の準備：最初に「土台」を作る

移行をスムーズにするコツは、先にWordPress側を「公開できる最低ライン」まで整えておくことです。
記事を流し込む前に土台が安定していると、あとで起きがちな 表示崩れ・URL迷子・計測漏れ を減らせます。

レンタルサーバー・独自ドメインを用意する

まずは「住所（ドメイン）」と「家（土地＝サーバー）」を用意します。ここで迷うと後工程が伸びるので、判断軸を固定しましょう。

1) 先に決めるべきは「ドメインを引き継ぐか」

はてなブログPro＋独自ドメインの場合
→ その独自ドメインを 継続利用 するのが王道（URLの連続性を作りやすい）
はてな無料版（サブドメイン）の場合
→ 新しく独自ドメインを取るのが一般的（別サイトとして立て直すイメージ）

2) サーバー選びで初心者が見るべきチェック項目

料金の細かい比較よりも、まずは「失敗しにくい機能」が揃っているかが重要です。

WordPressの簡単インストールがある
無料SSL（https）が使える
自動バックアップがある（復元できると安心）
WAFなどの基本セキュリティがある
サポートが分かりやすい（初心者はここで救われます）
できれば：ステージング（テスト環境）がある

3) 独自ドメイン周りで用意しておくもの

ドメインは「買って終わり」ではなく、移行では DNSの切り替え が発生します。

ドメインの管理画面にログインできること（登録メールも確認）
ネームサーバー／DNSレコードを編集できること
「wwwあり／なし」をどちらで統一するか決める
（後から変えると、余計なリダイレクトが増えて面倒です）

4) ここでやっておくと後がラクなこと

WordPress側で https表示ができる状態 を先に作る
ドメイン切り替え後に焦らないよう、最低限の“戻れる手段”を用意
- サーバーのバックアップ設定
- 管理画面（ログインURL）控え
- 初期設定のメモ（後で見返せる）

WordPressを新規インストールする

WordPressの入れ方は大きく2つ。初心者は基本的に「自動インストール」でOKです。

1) インストール方法の選び方

自動インストール（おすすめ）
管理画面の案内に沿って進めるだけ。失敗しにくい。
手動インストール
データベース作成やファイル配置などを自分で行う。慣れてからで十分。

2) つまずき防止の設定ポイント（最初に必ず意識）

インストール時にここをミスすると、後で“地味に困る”ポイントです。

管理者ユーザー名は 「admin」など単純なものを避ける
パスワードは強力に（使い回ししない）
可能なら最初から https（SSL） で進める
→ 後でhttp→httpsに直す作業が減ります

3) インストール直後に確認すること（3分でOK）

トップページが表示できる
管理画面にログインできる
404になっていない（URLが正しい）
変な警告が出ていない

最低限の初期設定（言語/パーマリンク/SSL/タイムゾーン）

ここは「移行の品質」に直結します。特に パーマリンク は後で変えるほどリスクが上がるので、先に固めます。

1) 言語・タイムゾーン（運用の基本）

言語：日本語
タイムゾーン：Asia/Tokyo
日付・時刻形式：見やすい形式に（あとで記事表示の印象が変わります）

2) パーマリンク（URL設計は“移行の核”）

パーマリンクは「記事の住所」です。移行では次の2択になります。

旧URLの形に“寄せる”（SEOの連続性を作りやすい）
WordPress標準で整える（運用しやすいが、旧URLとの差が出やすい）

初心者におすすめの考え方はこれです。

旧URLをほぼ再現できるなら → 寄せる
再現が難しい／整理し直したいなら → 主要記事だけ優先して整備（あとで段階的に最適化）

※ここを決めずに記事を入れると、後でURLがズレて修正が増えます。

3) SSL（https）とサイトURLの統一

サイトのURL（WordPressアドレス／サイトアドレス）が https になっているか確認
画像や外部埋め込みで http混在（混在コンテンツ） が出たら、移行後にまとめて修正する前提でOK
ただし、トップだけでもhttpsで安定表示できる状態にはしておくと安心です。

4) そのほか最低限の“整える設定”

不要な初期投稿・初期ページを整理（後で混乱しない）
パスワード・ユーザー権限の確認（複数人なら特に）
公開前なら「検索エンジンに見せない」設定の扱いに注意
→ テスト中にオンにする場合は、公開時に必ず戻す（戻し忘れが事故の原因）

移行作業に必要なプラグイン候補（入れすぎない）

プラグインは“便利”ですが、入れすぎると競合や速度低下の原因になります。
移行中は特に、役割が明確なものだけに絞るのが安全です。

1) 考え方：移行は「一時的に必要」なものが多い

インポート系：移行が終わったら 停止・削除候補
表示高速化系：サーバー機能と重複しやすいので慎重に
SEO系：複数入れると設定がぶつかりやすい（基本は1つ）

2) 最小構成の目安（用途別）

スクロールできます

区分	目的	目安
移行（インポート）	はてなMT形式などの取り込み	移行中だけ
リダイレクト	旧URL→新URLの案内（301管理）	必要なら導入
SEO	title/description、サイトマップ等	1つに絞る
セキュリティ	ログイン保護、基本防御	1つで十分
バックアップ	事故った時の復旧	サーバー側で足りなければ
画像最適化	画像の軽量化	後回しでもOK

3) 初心者が“入れすぎ”を防ぐルール

「目的が説明できないプラグインは入れない」
迷ったら、移行完了まで 新規追加を止める
追加したら、何を変えたかメモする
→ 不具合が出た時に戻しやすいです。

サイト引っ越し屋さん公式サイト

ダウンタイムを減らす“テスト環境”の作り方（2方式）

はてなブログ→WordPress移行でいう「ダウンタイム」は、ざっくり “切り替えの前後で、サイトが不安定に見える時間” のことです。

たとえば…

旧サイト（はてな）が表示される人と、新サイト（WordPress）が表示される人が混在する
画像やCSSが崩れる
一部ページが404になる
https（鍵マーク）が不安定になる

こうした揺れを最小化するために、「公開前に“本番に近い状態”で確認する」のがポイントです。
代表的な方法が、次の2つです。

方式A：クッション用WordPressを挟む（切替時間を短くする）

ここでいう「クッション」は、本番ドメインに切り替える前に、WordPress側を“ほぼ完成状態”にしておくやり方です。
切り替え当日の作業を減らせるので、結果的にサイトの不安定時間が短くなります。

ざっくり手順（初心者でも迷いにくい流れ）

サーバーにWordPressを用意（本番と同じテーマ・必須プラグインまで）
仮のURLでサイトを組み立てる
- 例：サーバーの「仮ドメイン」や「サブドメイン」など
記事をインポート→整形（見出し・画像・内部リンク）まで進める
公開前設定を整える（重要：検索エンジンに拾われないようにする）
切替当日、独自ドメインをWordPress側へ向ける（DNS変更）
最後にURLの最終調整（必要なら）→表示確認

目的は、切替当日に「サイト構築」ではなく、“切替と最終チェックだけ”にすることです。

向いている人／向かない人

向いている人

記事数が多い（100本以上など）／装飾が多い
切替当日にバタバタしたくない
複数人運営で確認工程が多い
失敗したくないので、手順を分割して落ち着いて進めたい

向かない人

記事数が少なく、作業が半日〜1日で終わりそう
仮URLでの調整（後述のURL書き換え）に不安が強い
“URLを1回も触りたくない”タイプ（→方式Bが合いやすい）

起こりがちなミス（URL書き換え・二重作業）

方式Aは便利ですが、初心者が詰まりやすいのはここです。

ミス1：仮URLのまま内部リンクや画像URLが残る

仮URLで記事を整形すると、本文内リンクが仮URLのまま残りがちです。
対策：
- まずは主要記事だけ先に整形（全部を完璧にしない）
- 切替後に「サイト内検索」で仮URLが残っていないか確認する
- 必要なら一括置換（ただし、実行前にバックアップ）

ミス2：二重作業になる（仮→本番の調整を2回やる）

仮URLで作り込みすぎると、切替後に再調整が発生します。
対策：
- 仮環境では「レイアウト・記事の崩れ修正・必須設定」まで
- “最終的な導線の細かいチューニング”は本番URLになってからにする

ミス3：仮URLが検索エンジンにインデックスされる（重複リスク）

仮サイトが見つかると、同じ内容が2つ存在する状態になりやすいです。
対策：
- 公開前は noindex（検索させない） の設定を必ず入れる
- 仮URLを公開している期間は、外部にリンクを貼らない

方式B：hostsで自分だけ先に確認する（本番URLのまま整備）

「hosts（ホストファイル）」は、あなたのPCだけに “このドメインはこのIP（サーバー）を見に行く” と教える仕組みです。
つまり、世の中はまだ「はてな」を見ているのに、自分だけ先に“本番ドメインでWordPressを確認できる”のが強みです。

ざっくり手順（考え方だけ押さえればOK）

WordPressをサーバーに用意（本番ドメインを設定）
新サーバーのIPアドレスを確認
自分のPCのhostsに、次のように一行追加
- 「本番ドメイン → 新サーバーIP」
ブラウザで本番ドメインを開き、WordPress側の表示を確認
問題がなければDNSを切替（一般公開）
hostsの設定を元に戻す（重要）

向いている人／向かない人

向いている人

本番URLのまま確認したい（URL問題を増やしたくない）
切替前に、表示崩れ・リンク・計測をしっかり点検したい
仮URLでの二重管理を避けたい
記事数が少〜中規模で、確認が現実的に回る

向かない人

PC操作（ファイル編集）が不安
スマホやタブレットでも同時に確認したい（端末ごとに設定が必要）
SSL証明書の準備が難しい環境（https確認が引っかかる場合がある）

注意点（複数端末での確認・戻し忘れ防止）

注意1：hostsは“その端末だけ”に効く

PCで見えても、スマホは見えません（スマホ側も同様の設定が必要）。
対策：
- 最低でも「PC（編集する端末）」＋「スマホ（一般ユーザー目線）」で確認したいなら、方式Aのほうがラクな場合もあります。

注意2：戻し忘れが事故の元

hostsを残したままだと、切替後の確認がややこしくなったり、旧サイトの状態確認ができなくなります。
対策（おすすめ）
- ✅ hostsを変更したら、デスクトップにメモを置く（「作業後に戻す」）
- ✅ ブラウザの別プロファイルで確認して、作業用と普段用を分ける
- ✅ 作業が終わったら、必ず「hostsを戻す→DNSキャッシュをクリア」の順で締める

注意3：https（鍵マーク）の確認は“準備次第”

hostsで本番ドメインにアクセスする場合でも、サーバー側にそのドメインのSSL証明書が入っていないと警告が出ることがあります。
対策：
- SSLが先に用意できる手段（DNS認証など）があるなら先に設定
- 難しければ、切替後にhttps最終確認でもOK（ただし切替当日にチェック時間を確保）

迷ったときの選び方（早見）

スクロールできます

観点	方式A（クッション）	方式B（hosts）
切替当日の作業量	少なめにしやすい	少なめにしやすい
URLの扱い	仮URL→本番で調整が出やすい	本番URLのまま確認できる
初心者のつまずき	URL置換・二重作業	hosts編集・戻し忘れ
複数端末での確認	しやすい	端末ごとに手間
おすすめタイプ	大規模・慎重派	URLを触りたくない派

サイト引っ越し屋さん公式サイト

はてなブログ側の準備：移行しやすい状態に整える

移行の成否は、WordPress側よりも先に 「はてな側をどれだけ整理できたか」 で決まりやすいです。
特に初心者は、最初にここを整えるだけで「移行後の修正地獄」をかなり避けられます。

記事データのエクスポート（MT形式）

はてなブログのエクスポートは、MT（Movable Type）形式のテキストファイルで書き出す方式です。
大事なポイントは次の3つです。

文字コードはUTF-8
編集モード（はてな記法／見たまま）に関係なく、本文はHTMLとして書き出される
書き出せるのは記事本文とコメントのテキスト（画像などは別）

失敗しにくいエクスポート手順（作業前の“型”）

移行期間は更新を止める日（凍結日）を決める
- 凍結日以降に記事を触ると「再エクスポート」が必要になりやすいです。
はてなブログ管理画面のエクスポートから MT形式で書き出す
ダウンロードしたファイルは、次のように保存（紛失防止）
- フォルダ名例：hatena_export_YYYYMMDD
- クラウドにもコピー（PC故障対策）
凍結日以降に修正したら、必ず「エクスポートしなおす」→再ダウンロード

事前にやっておくと“取り込みが安定する”整理

限定公開／下書きが混ざっていないか（移行後の公開事故を防ぐ）
予約投稿を使っている場合は、日時の扱いをどうするか決める
- 迷うなら、移行完了まで予約投稿は止めるのが安全です。
コメントを残すか決める（移行後に“誰のコメントか”の見え方が変わることがあります）

画像・添付ファイルは別管理（何を残し、何を移すか決める）

はてなのエクスポートは、画像や添付ファイルを含みません。
ここを決めずに進めると、移行後に「画像が抜けた」「表示が重い」「差し替えが終わらない」が起きやすいです。

まず決める：画像の移行方針は3択

スクロールできます

方針	何をする？	メリット	注意点
そのまま残す（外部参照）	画像URLははてな側のまま	最短で移行できる	将来の差し替えが面倒／表示速度・管理が不安定になりがち
WordPressへ移す（推奨）	WPのメディアに再アップロード	管理が一元化でき、資産性が高い	作業量が増える（優先順位が重要）
差し替える	画像自体を新調	記事品質が上がりやすい	工数が最も大きい

初心者におすすめは、「上位記事だけWPへ移す」→「残りは順次」 です。
いきなり全記事の画像を完璧にやろうとすると、だいたい止まります。

画像・添付の優先順位（これで迷いが減る）

優先度A（最初にやる）

検索流入が多い記事（上位20〜50本）
収益記事（レビュー・比較・ランキング）
アイキャッチ（一覧表示で目立つ）

優先度B（後でOK）

古い日記系・今後伸ばさない記事
参照されない装飾用画像（区切り線など）

“別管理”の具体的なメモ（作業が速くなる）

添付ファイル（PDF等）があるなら
- どの記事に、どのファイルが、どの目的で置かれているかを1行メモ
- 移行後は「WPに置く」「外部ストレージに置く」どちらかに統一すると管理が楽です。

記事内の要注意ポイント（目次コード／広告タグ／吹き出し等）

移行作業で時間を食うのは、本文の“中身”より 「記事内の仕掛け」 です。
以下は、初心者がつまずきやすい代表例です。

目次（TOC）

はてな側の目次は、WordPressに移すと…

見た目が崩れる
クリックしてもズレる
そもそも不要になる（WP側で自動生成する）

が起きがちです。

おすすめ対応

移行前：目次がある記事を把握（上位記事だけでOK）
移行後：WordPress側で 目次の方式を統一
- ブロックエディタの目次機能／目次プラグインなど
- 重要なのは「記事ごとに方式がバラバラにならない」ことです。

広告タグ・計測タグ

移行後に「広告が表示されない」「計測が取れない」は、だいたいここが原因です。

記事内に貼ったタグ（script/iframeなど）が、編集画面で崩れる
ブロックエディタでは、貼り付け場所（カスタムHTML等）を間違えると表示されない

おすすめ対応

はてな側で、記事内に広告タグを多用している場合
→ “どの記事に何が入っているか”だけでもメモ
WordPressでは、可能なら記事内ではなく
全ページ共通（テーマ／広告管理）に寄せると保守がラクです。

吹き出し・装飾ボックス

はてなで吹き出しや囲み枠を実現している場合、正体はだいたい次のどれかです。

記事内のHTML（class付きのdiv等）
カスタムCSS（デザイン設定のCSS）
外部サービスの埋め込み

移行すると、HTMLは残るけどCSSが消えて普通の文章になることが多いです。

おすすめ対応

移行前：吹き出しや囲みの“元のコード”と“CSS”を保存しておく
移行後：
- 続けるなら → WordPress側にCSSを移植（必要最小限）
- 乗り換えるなら → WPの吹き出しブロック／プラグインで統一

見出しタグのクセに注意（HTML編集・一括置換の考え方）

エクスポートされた本文はHTMLなので、見出しも <h2>〜</h2> のような形で入っていることが多いです。
ここでズレると、SEO面でも読みにくさの面でも損をします。

まず確認：見出しレベルが“ズレていないか”

初心者がやりがちな例はこれです。

最初の見出しが h3 から始まっている
見出しが太字（strong）になっているだけで、見出しタグではない
h2/h3/h4が記事ごとにバラバラ

チェックは上位記事だけでOK

アクセス上位の10記事を開いて
- 見出しの階層が自然か
- 目次が正しく拾うか
  を確認します。

直し方の基本方針（安全に進めるコツ）

見出し修正は、いきなり全記事に一括適用しないのが鉄則です。

まず10記事でルールを決める（例：本文の大見出しはh2、配下はh3）
そのルールで、上位記事を整える
問題がなければ、対象を増やす

一括置換をするなら“事故らない条件”を満たす

一括置換は強力ですが、雑にやると記事が壊れます。

やっていい条件（目安）

その記事（またはそのグループ）が
- h2を使っていない
- h3が実質的な最上位見出しになっている
  など、置換のルールが明確

やらない方がいい条件

記事ごとに構造がバラバラ
目次・装飾・吹き出しが複雑に混ざっている
置換後の確認時間を確保できない

迷ったら、「上位記事だけ手作業で整える」ほうが、結果的に早くて安全です。

サイト引っ越し屋さん公式サイト

記事データをWordPressへ取り込む（インポート工程）

インポート工程は、やること自体はシンプルです。
ただ、初心者がつまずきやすいのは 「取り込んだあとに何を確認すべきか」 と 「重複・公開事故をどう防ぐか」 の2点。

ここでは、安全に取り込むための手順に絞って解説します。

インポートツールの選択（Movable Type系インポーター）

はてなブログのエクスポートは MT形式（Movable Type形式） なので、WordPress側は基本的に「Movable Type と TypePad」のインポーターを使います。

選び方（迷ったらこの結論）

WordPress管理画面の ツール → インポート にある
「Movable Type と TypePad」 を使う
画面に「今すぐインストール」「インポーターをインストール」などが出たら、そのまま導入してOK

補足（初心者が安心できるポイント）

これは“移行専用”の道具なので、取り込みが終わったら 停止・削除しても問題ない ことが多いです
→ 使い終わった道具を片付けるイメージでOK

事前に1分だけ確認（トラブル予防）

MTファイルが テキスト（.txt） で用意できているか
ファイルが大きすぎてアップロードできない場合は
「アップロード上限」 が原因になりやすい
→ その場合は「分割して複数回インポート」か「サーバーの上限調整」で対応します（無理に一発でやらないのがコツ）

ファイル取り込み→投稿者割り当て→公開状態の確認

ここは流れ作業ですが、公開事故と重複を防ぐために「順番」を守るのが大事です。

1) 取り込み前のおすすめ状態（安全運転）

初心者は、まず “試し取り込み” を強くおすすめします。

10記事だけ（または小さめのMTファイル）で先に試す
問題がなければ本番ファイルを取り込む

こうすると、万一うまくいかなくても被害が小さく済みます。

2) 取り込み手順（基本の流れ）

ツール → インポート → Movable Type と TypePad を開く
MTファイルを選び、アップロードして実行
途中で出る設定（投稿者割り当て等）を選ぶ
インポート完了の表示を確認

3) 投稿者割り当て（後で直せるが、最初がラク）

インポート中に「この投稿者を誰として登録するか」を聞かれることがあります。ここで迷ったら次でOKです。

ひとり運営：自分のユーザーにすべて割り当て
複数人運営：まずは
“代表者1名に集約” → 後から必要分だけ振り分け
が安全（最初から完璧にやろうとしない）

※投稿者は後から変更できます。まずは「正しく記事が入ること」を優先しましょう。

4) 公開状態の確認（初心者はここが最重要）

インポート直後は、次のどちらの方針にするかを先に決めると事故が減ります。

方針A：いったん下書き（または非公開）で取り込む（おすすめ）

✅ 表示崩れ、リンク、見出し階層をチェックしてから公開できる
✅ 広告・計測・目次などの“仕掛け”を整えてから世に出せる

方針B：公開のまま取り込む（最短だが注意）

✅ すぐ移行を終わらせたい人向け
⚠️ 崩れた状態のまま公開される可能性がある
⚠️ “移行途中のページ”が検索やSNSで見られるリスクがある

初心者は基本的に、最初は 方針A が安心です。

5) 取り込み後の“最低限チェック”リスト（10分でOK）

インポートが終わったら、まずは次だけ確認してください。

✅ 記事数が想定と大きくズレていない
✅ 文字化けがない（本文・タイトル・カテゴリ名）
✅ 改行や箇条書きが極端に崩れていない
✅ 画像が「表示される／されない」の傾向が分かる
✅ 公開状態（公開・下書き）が意図どおりになっている

カテゴリ・タグ・コメントの扱いをどうするか

インポート後に「思っていたのと違う…」が出やすいのがここです。
最初に方針を決めておくと、後でサイト構造が崩れません。

1) カテゴリ（先に“骨組み”を固める）

カテゴリはSEOでも回遊でも効くので、移行時に整理しすぎると迷子になります。

初心者向けのおすすめ

いったん 現状のカテゴリをそのまま受け入れる
公開後に、上位記事から順に
カテゴリを統合・整理していく

特に記事数が多い場合、移行のタイミングでカテゴリを作り替えると
「内部リンク」「パンくず」「関連記事」まで影響して、手戻りが増えがちです。

2) タグ（“後から整える前提”がラク）

タグは、インポートで期待どおりに移らないケースもあります。
そのため、移行直後は次の考え方が現実的です。

タグは 最初は気にしすぎない
重要記事（上位記事）から
タグを付け直す／タグ設計を作る
で十分

おすすめの割り切り

カテゴリ＝サイトの柱（必須）
タグ＝補助（後で育てる）

この順にすると、運用が安定します。

3) コメント（残す／捨てるの判断基準）

コメントは「残したい気持ち」が出やすい一方で、移行後の運用負担にもなります。

残すのが向いているケース

コミュニティ性が高く、コメントが価値になっている
記事内容の補足としてコメントが役立っている

割り切って整理するケース

収益記事が中心で、コメント対応が負担になる
スパム対策やモデレーションを増やしたくない

初心者は、まずは “コメントは閉じる（新規を受けない）” という中間案もおすすめです。
過去ログは残しつつ、運用コストだけ下げられます。

サイト引っ越し屋さん公式サイト

移行後に崩れやすい部分の整形（ここで品質が決まる）

インポートが終わった直後は「記事が入っただけ」の状態です。
ここから整形（修正）をどれだけ丁寧にやれるかで、読みやすさ・滞在時間・CV（クリック）・SEO評価が大きく変わります。

最初に方針だけ決めておくと、作業が破綻しません。

優先順位：アクセス上位／収益記事（レビュー・比較）→その他
整形の順番：文章崩れ → 画像 → 内部リンク・埋め込み → アフィリンク・計測
完璧主義を捨てる：まず「致命傷（崩壊・リンク切れ）」だけ潰し、細部は後でOK

はてな記法／装飾／囲み／引用の崩れを直す手順

はてな→WPで崩れやすいのは、だいたい次の4カテゴリです。

装飾：太字・色・マーカー・ボックス
構造：見出し階層、箇条書き、表
引用・コード：引用ブロック、コードブロック
独自パーツ：目次、ブログカード、吹き出し、埋め込みHTML

初心者でも迷いにくい「安全な直し方」を、手順でまとめます。

1）まず“直す対象”を絞る（重要）

いきなり全記事を直すとほぼ確実に息切れします。最初はこれでOKです。

Search Console / GAで 上位20〜50記事 をリスト化
収益導線がある記事（比較・レビュー・ランキング）を追加
合計 30〜80記事 を「優先修正」にする

2）崩れパターンを分類して、直し方を固定する

記事ごとに毎回やり方を変えると遅くなるので、パターン別に“型”を作ります。

囲み枠が崩れている → WordPressの「グループ」「引用」「注釈」などに統一
はてな独自の装飾が残っている → 削って読みやすく（装飾は最小限でOK）
見出しが太字扱いになっている → 見出しブロックに変換（h2/h3の階層を揃える）
コードが文章扱いになっている → コードブロックへ移動（改行が命）

3）修正は「ブロックエディタのHTML表示」を使い分ける

おすすめはこの使い分けです。

見た目で直る：ブロックを入れ替える（囲み・引用・見出し・箇条書き）
見た目で直らない：該当部分だけHTMLで確認して最小修正

💡コツ：全体をHTML編集すると事故が増えます。崩れている部分だけ触るのが安全です。

4）“よく使う装飾”はテンプレ化して速度アップ

毎回同じ囲み・注意書き・手順ボックスを作るなら、

再利用ブロック（またはパターン）として保存
記事ごとに呼び出して文章だけ差し替え

これだけで、整形スピードが一気に上がります。

画像の移行：3つの選択肢（残す・移す・置換する）

画像は「表示の安定」「速度」「資産性」に直結します。
結論から言うと、初心者はハイブリッドが現実的です。

選択肢1：残す（はてな画像URLのまま）

向いているケース

低アクセス記事
いずれリライトしない記事
画像が少なく、表示崩れがない

注意点

将来、画像URLの管理が二重になる
表示速度・安定性は環境次第

選択肢2：移す（WordPressメディアに集約）※おすすめ

向いているケース

上位記事（検索流入が多い）
収益記事（比較・レビュー）
今後伸ばす予定の記事

メリット

画像の管理が一元化でき、資産性が上がる
alt（代替テキスト）も整えやすい

選択肢3：置換する（画像を新しく作り直す）

向いているケース

古いスクショ（UIが変わった）
解像度が低い、見づらい
そもそも画像が内容と合っていない

メリット

記事品質が上がり、CV改善にも効きやすい
SEOでも「分かりやすさ（ユーザー満足）」に寄与しやすい

画像URLを自前に寄せるときの考え方（置換・再アップロード）

画像をWordPress側に寄せる場合、作業が破綻しないように“手順”を固定します。

おすすめ手順（上位記事から）

記事を開き、画像の場所をざっと確認
画像を保存（必要ならファイル名を整理）
WordPressのメディアにアップロード
記事内の画像を差し替え
altを最低限入れる（画像が何を示すか一言でOK）
表示確認（PC/スマホ）

一括置換は最後にやる
検索置換（URLの一括置換）は便利ですが、初心者が事故りやすいです。

✅ 先に上位記事で“手作業の型”を確立
✅ バックアップが取れている状態で実行
✅ 置換対象が明確なときだけ（無差別にやらない）

内部リンク・カード・埋め込み（YouTube/SNS/リンクカード）調整

ここは「読者の回遊」と「収益導線」に直結します。
整形の中でも効果が出やすいので、上位記事から優先するとコスパが高いです。

1）内部リンク：まず“切れているリンク”を潰す

移行直後に起きがちなのは、

旧ドメイン（はてな）のままリンクしている
仮URL（テスト環境）のまま残っている
末尾スラッシュ違いなどで意図しないページへ飛ぶ

最短の直し方

上位記事から順に、本文内リンクをクリックしてチェック
壊れていたら、WordPress側の該当記事へ貼り直し
重要導線（比較→レビュー→申込み）の順で優先

2）リンクカード・ブログカード：WordPressの表示方式に統一

はてな時代のカード表現が崩れる場合は、次の方針が簡単です。

まずは 通常リンクとして成立させる（見た目は後回しでもOK）
余裕が出たら、WordPress側のカード機能（テーマ機能等）に寄せる

3）YouTube・SNS埋め込み：ブロックで入れ直すのが速い

埋め込みが崩れる原因は、旧コードの仕様差が多いです。迷ったら、

旧HTMLを維持しようとせず、URLを貼って埋め込みブロックで再生成
表示されない場合は「カスタムHTML」ブロックに切り替え

確認ポイント

スマホ表示で横はみ出ししていないか
埋め込みが重くて表示が遅くなっていないか（上位記事ほど重要）

アフィリエイトリンクの貼り直し・計測の再設定

移行で一番痛いのが、リンクはあるのに成果が発生しない状態です。
ここは“漏れなく確認する仕組み”を作るのが正解です。

1）まず棚卸し：どこにリンクがあるか把握する

初心者がやりやすい方法はこれです。

収益記事（比較・レビュー・ランキング）をリスト化
各記事で「リンクが多い場所」をメモ
例：ボタン、比較表、記事下CTA、本文中リンク

2）貼り直しの基本方針（事故を減らす）

旧ブログのリンクを“流用”するより、WordPress側で再貼り付けが安全
記事内にタグを直貼りしていた場合は、ブロックの種類（カスタムHTML等）に注意

最低限の確認チェック（記事ごとに）

✅ クリックして正しい遷移になる
✅ スマホでも押しやすい（ボタンが小さすぎない）
✅ 表示が崩れていない（表・ボタン・注釈）
✅ 必要なら rel="sponsored" など属性が適切（テーマやプラグイン側の挙動も確認）

3）計測の再設定：移行後の“数字が取れる状態”に戻す

やることはシンプルで、次の順が安心です。

GA（またはタグマネ）を設置
Search Consoleで新環境の確認（サイトマップ送信）
成果に直結するイベント（クリック計測など）があるなら、最後に復旧

おすすめの動作確認

自分で1回クリックして、リアルタイム計測（またはデバッグ）で反映を見る
「動いてる確信」を持ってから、次の記事へ進む

サイト引っ越し屋さん公式サイト

SEO最重要：パーマリンク設計（旧URLを極力“再現”する）

パーマリンク（記事URL）は、移行の中でも特にSEO影響が大きい部分です。
一度公開して流入がついたURLを変えると、検索エンジンは「別ページ」として再評価しやすくなります。

だからこそ基本方針はシンプルで、

できるだけ旧URLの型に寄せる
寄せられない部分は、301リダイレクトで確実に案内する

この2つをセットで考えるのが安全です。

旧URLの型を確認する（/entry/・日付・カスタムURL）

まずは「自分のはてなブログが、どのURL型なのか」を確定させます。
ここが曖昧なままWordPressの設定をすると、後で301設計が破綻しやすいです。

確認する場所は2つだけ

ブログ全体の既定URL形式：はてなブログ管理画面の「設定」→「詳細設定」→「記事URL」
記事ごとの例外（カスタムURL）：記事編集画面の「編集オプション」→「カスタムURL」

はてなブログでよくあるURL型（ざっくり）

/entry/ + 日付 + 時刻の連番
例：/entry/2026/03/06/123456
/entry/ + 日付 + タイトル（日本語含むことも）
例：/entry/2026/03/06/記事タイトル
ダイアリー風（区切りが少ない）
例：/entry/20260306/xxxxxxxxxx
カスタムURL（記事ごとに任意文字）
例：/entry/your-custom-slug

初心者向けの実務メモ

上位記事（検索流入が多い記事）を10本くらい開き、URLをコピペして並べるだけでもOKです。
→ 「/entry/があるか」「日付の区切り」「末尾が時刻か文字列か」が見えれば十分です。

WordPress側で近い形に寄せる（無理な場合の代替案）

WordPress側は「設定」→「パーマリンク」でURLの型を決められます。
ただし、はてなのURLを“100%同じ”にするのが難しいケースもあるため、再現できるところ／できないところを切り分けます。

まず押さえる前提

WordPressのパーマリンクは「記事スラッグ（%postname%）」や「日付（%year%等）」を組み合わせて作ります。
はてなの「時刻連番（HHMMSS）」のような“完全一致”は、WordPress標準だけでは再現が難しい場合があります。

旧URL型別：寄せ方の考え方（初心者向け）

1）/entry/ + 日付 + “タイトル系”に近い場合

目標：/entry/YYYY/MM/DD/スラッグ/ に寄せる
WordPress側の例：/entry/%year%/%monthnum%/%day%/%postname%/
コツ：記事スラッグ（%postname%）は、移行後に短めで意味が通る英数字にすると管理が楽です
（日本語スラッグも可能ですが、共有時に長く見えたり、%エンコード表示になったりすることがあります）

2）/entry/ + 日付 + “時刻連番”に近い場合

目標：見た目は近づけつつ、現実的な運用に落とす
選択肢は主に2つです。

A：できるだけ似せる（上級寄りだが最も近い）
/entry/%year%/%monthnum%/%day%/%postname%/ にして、各記事のスラッグを連番（例：123456）に寄せる
→ ただし、インポート結果次第では手直しが増えるため、記事数が多いと現実的でないこともあります。

B：完全一致は捨てて、301で守る（初心者におすすめ）
WordPressは管理しやすい構造（例：/%postname%/）にして、旧URL → 新URLを301で確実に接続する
→ 作業の中心は「リダイレクト設計」になりますが、長期的には運用しやすいです。

3）ダイアリー風（/entry/YYYYMMDD/…）に近い場合

WordPress側はカスタム構造で “日付を区切らない形” に寄せることは可能です。
ただし末尾（タイムスタンプ等）の完全一致は難しいことが多いです。
ここも基本は、
近い形に寄せる + 足りない分は301で補う
の発想が安全です。

“代替案”として強いのは「段階移行」

初心者が失敗しにくいのは、次の順です。

WordPress側のパーマリンクは「長く運用しやすい形」で固定
検索流入が多い記事だけ、旧URLから新URLへ確実に301
404（リンク切れ）が出た分だけ、301ルールを追加して塞ぐ

このやり方なら、最初から完璧な対応表を作らなくても、実害（リンク切れ）を潰しながら仕上げられます。

URLを変える判断基準（変えない方がいいケース／変えていいケース）

URL設計は「SEO」だけでなく「今後の運用のラクさ」にも効きます。
そこで、初心者でも判断しやすい基準をまとめます。

変えない方がいいケース（基本はこちら）

すでに検索流入が安定している記事が多い
外部サイトからのリンク（被リンク）や、SNSで拡散された記事が多い
収益記事（比較・レビュー）が多く、URL変更で機会損失が出る
記事数が多く、全URLの再設計・検証に現実的な時間が取れない

この場合は、方針として
✅ 旧URLに寄せる努力をする
✅ 寄せきれない分は 301で守る
が最も堅実です。

変えていいケース（例外としてアリ）

ほぼアクセスがない、または今後育てない記事が中心
カテゴリや導線を根本から作り直して、メディア型に再構築したい
古い記事が多く、URLが読みにくい（意味のない文字列・重複スラッグ等）
移行を機に、「上位記事だけ残して整理」する戦略を取る

この場合でも、いきなり全部を変えるより
✅ 主要記事だけは丁寧に（URL・301・内部リンク）
✅ それ以外は段階的に
が安全です。

最後に：パーマリンク設計でやりがちなNG

パーマリンクを決めずに大量インポート → 後からURLを変える（手戻りが最大化）
何度もURL構造を変更する（評価が安定しにくい）
旧URLの接続（301）を後回しにする（404が増えやすい）

結論：
パーマリンクは「先に固定」して、「再現できない差分は301で埋める」。これが移行SEOの基本形です。

サイト引っ越し屋さん公式サイト

独自ドメインの切り替え（DNS/ネームサーバー/SSL）

このパートは「はてなブログPro＋独自ドメイン」など、自分のドメインを持っている人向けです。
独自ドメインの切り替えは、ざっくり言うと “行き先（サーバー）を変える住所変更”。

ここで慌てると、表示崩れや404よりも先に、「そもそも見えない」が起きます。
なので、切替は次の順でいきましょう。

切替前チェック（壊れていないか）
DNS/ネームサーバー変更（反映中に起きることを理解）
SSL（https）と混在コンテンツの仕上げ

切替前に必ず確認する項目（表示・ログイン・画像・404）

切替当日は、DNS反映の待ち時間が発生します。
その間に直すのはしんどいので、先に「最低限の動作確認」を終わらせておきます。

まずやること（失敗しない最小チェック）

以下は、チェックできたら✅を入れるだけでOKです。

✅ トップページが表示できる（スマホでも確認）
✅ WordPress管理画面にログインできる（ID/パスを控える）
✅ 記事ページが表示できる（上位3記事だけでOK）
✅ 画像が表示される（アイキャッチ＋本文画像を1記事ずつ）
✅ 404が出ない（トップ→カテゴリ→記事の導線で確認）
✅ パーマリンク（URLの形）が“確定している”（あとから変えない）

切替直前にやると効く「2つの保険」✨

バックアップを“復元できる形”で用意
「保存した」だけで安心せず、管理画面で復元手順が見える状態にしておくと強いです。
旧サイト（はてな）をすぐ消さない
切替直後は確認が必要なので、旧環境はしばらく残すのが安全です。

よくある見落とし（初心者が詰まりやすい）

管理画面URLを控えていない（切替後にログイン先が分からない）
“http”でアクセスしたときだけ挙動が違う（あとで混在やリダイレクトが発生）
主要記事だけ画像が崩れている（上位記事から見ておくのが正解）

ネームサーバー変更→反映待ちの間に起こる現象

ここは「知ってるだけで焦りが半減」します。
反映待ちに起きる現象は、故障ではなく仕様のことが多いからです。

まず整理：変更は2タイプある

ネームサーバー（NS）変更：ドメインの“案内所”ごと変える
DNSレコード変更（A/AAAA/CNAMEなど）：案内所は同じで“行き先だけ”変える

この違いで、反映の挙動が変わります。

反映待ちで起きる代表例（全部「あるある」）

👀 人によって表示が違う
ある人は旧サイト、ある人は新サイトが見える（混在状態）
🔁 更新しても変わらない
端末・ブラウザ・回線側のキャッシュで、古い行き先が残ることがあります
🧩 画像やCSSだけおかしい
旧データが残ったまま、新サイトのHTMLだけ見えている…などが起きがち
🔐 httpsの警告が出たり消えたりする
切替直後はhttps周りの状態が揺れやすいです（後述）

“待つべき時間”の考え方（目安）

反映には幅があります。重要なのは「揺れるのが普通」と理解すること。

DNSはTTL（キャッシュ時間）やISP側のキャッシュ状況で、反映が遅れることがあります
ネームサーバー変更は、環境によって 数時間〜数日 かかることもあります

反映待ちでやるべきこと（やる順が大事）

焦って設定をいじる前に、次を順番に試すと切り分けが早いです。

シークレットウィンドウで開く（ブラウザキャッシュの影響を減らす）
スマホの4G/5G回線で開く（自宅Wi-FiとDNSが違うため、切り分けになる）
少し時間を置いて再確認（反映待ちの可能性が高い）

💡逆に、反映中に何度も設定を変えると「どれが正しい状態か」分からなくなりがちです。

SSL（https）と混在コンテンツの解消

ドメイン切替後は、最後に httpsを安定させる のがゴールです。
鍵マークが付かない、警告が出る、画像だけhttpのまま…は、移行直後によくあります。

1）まず確認：サイトURLがhttpsで統一されているか

WordPressには「WordPressアドレス」と「サイトアドレス」があります。
ここがhttpのままだと、いくらSSLを入れても挙動が不安定になります。

管理画面に入れる場合：設定でURLがhttpsになっているか確認
管理画面に入れない場合：サーバー側・設定ファイルで復旧する手段があります（最終手段として覚えておくと安心）

2）混在コンテンツとは？（なぜ鍵が付かないの？）

httpsのページの中に、httpの画像・CSS・JS・埋め込みが混ざる状態です。

画像（http） → 画像だけ表示されない / 鍵が“完全”にならない
スクリプトやiframe（http） → ブラウザがブロックして、機能が動かないこともあります

3）混在コンテンツの直し方（初心者向けの現実解）

いきなり全ページを完璧に直す必要はありません。効率がいい順でいきます。

優先度A：全体に効く修正（先にやる）

WordPressのURL設定をhttpsに統一
可能なら、http→httpsへ自動転送（リダイレクト）を有効化
→ 「httpで来た人」が迷子になりにくくなります

優先度B：上位記事だけ直す（効果が出やすい）

Search Console/アクセス上位の記事から、本文内の httpリンク を修正
画像URLがhttpなら、httpsに差し替え（または画像をWP側に移す）

優先度C：埋め込み・外部サービスを点検（残りやすい）

YouTube / X / 広告タグ / ランキングパーツなどは、古いhttpコードが残りがちです
→ 迷ったら「公式の最新埋め込みコード」に貼り替えるのが早いです

4）最後の仕上げチェック（ここまで来れば安心）

✅ トップと上位3記事で鍵マークが安定している
✅ 画像が欠けない
✅ お問い合わせフォームなど重要機能が動く
✅ httpでもhttpsでも、最終的にhttpsへ集約される（運用がラク）

サイト引っ越し屋さん公式サイト

SEO資産を守る：301リダイレクトと正規化（canonical）

はてなブログ→WordPress移行でSEOを守る要点は、かなりシンプルです。

URLが変わるなら 301リダイレクト で旧URLの評価を新URLへ引き継ぐ
URLが増えたり重複したりするなら canonical（正規URL） で「本物のURL」を明確にする

この2つを押さえるだけで、移行後の「順位が戻らない」「インデックスがぐちゃぐちゃ」を避けやすくなります。

301が必要なケース／不要なケース

301（恒久的リダイレクト）は、検索エンジンに「このURLは引っ越しました」と伝える仕組みです。
必要かどうかは “旧URLが存在していたか” と “新URLが別になるか” で決まります。

301が必要なケース（移行で一番多い）

はてなの記事URLと、WordPressの記事URLが 一致しない
ドメインは同じでも、URL構造（例：/entry/ や日付の有無）が変わる
http→https、wwwあり→なし（または逆） の統一を行う
カテゴリページのURLを変えた（スラッグ変更、階層変更など）
旧URLでアクセスがあり、今後も内容を引き継ぐ（同等のページが新URLにある）

✅ 基本は「旧URLで人が来る可能性があるなら、301で案内する」です。

301が不要（または別対応が適切）なケース

旧URLと新URLが 完全に同じ（URLが変わらない）
→ 当然、301は不要です。
テスト環境（仮ドメイン）を閉じるだけで、検索に出さない運用だった
→ そもそもインデックスされない設計が前提なら、301に頼らない方が安全です。
旧記事を 完全に削除 し、代替ページも作らない
→ この場合は 301ではなく 404/410 の考え方が合うことがあります（無理にトップへ飛ばすと不自然になりやすい）。
旧記事と内容が大きく変わり、別テーマの記事になる
→ 近いページへ飛ばすより、整理（統合記事を作る等）を検討した方が安定しやすいです。

💡初心者がよくやるNG

「全部トップに301」→ ユーザー体験が悪くなりやすく、評価も不安定になりがち
「とりあえず302」→ 一時転送扱いで、移行用途に合いません（基本は301）

旧URL→新URLの対応表を作る（考え方と作り方）

対応表は、移行の“設計図”です。
完璧を目指すより、重要ページから確実にが正解です。

作り方のおすすめ手順（破綻しない進め方）

優先度A（上位記事） を先に集める
- 検索流入が多い記事（GA/サチコ上位）
- 収益記事（レビュー・比較・ランキング）
- 被リンクがありそうな記事
旧URLをコピーして一覧化（30〜100件でOK）
WordPress側で確定した新URLを並べる
まずは 優先度Aだけ 301を実装
公開後は、404（リンク切れ）を見ながら追加で埋める（段階方式）

対応表テンプレ（これだけで進められます）

スクロールできます

優先度	旧URL	新URL	ページ種別	301の方法	備考
A	（コピペ）	（コピペ）	記事/固定/カテゴリ	ルール/個別	旧URLの型など
B
C

ポイント

最初から全記事を埋めない（時間が溶けます）
“ページ種別”を書いておくと、あとで正規表現ルールが作りやすくなります
旧URLの「型」が揃っているほど、後述の“ルール化”が効きます

実装方法：プラグイン方式 vs .htaccess方式

301の実装は、大きく2つに分かれます。
結論は「初心者はプラグインで管理、安定後にサーバー側へ寄せる」が失敗しにくいです。

プラグイン方式（初心者向け）

メリット

管理画面で追加・修正できる（復旧が早い）
ログ（何がどれだけリダイレクトされたか）を見られることが多い
ルールを試しやすい

デメリット

プラグインが増える（相性や負荷がゼロではない）
設定ミスでループしても気づきにくいことがある（テスト必須）

.htaccess方式（Apache系サーバーでよく使う）

メリット

サーバー側で高速・安定しやすい
WordPressが動く前に転送できる（移行直後の保険になる）

デメリット

1文字ミスでサイトがエラーになることがある（バックアップ必須）
ルール設計が難しい（特に大量URL）

もしサーバーがNginx系の場合は .htaccess が使えないことがあります。
その場合は管理画面（プラグイン）か、サーバー側設定（Nginx設定）で対応します。

最低限の安全ルール（どちらでも共通）

実装前にバックアップ
まず上位ページだけでテスト
リダイレクトチェーン（A→B→C） を作らない（A→Cの一発に）
ループ（A→A） を必ず避ける
「旧URLが存在しないのに301を作る」より、まずは404を観測してから追加

大量記事でも破綻しにくいルール設計（正規表現の発想）

大量記事を“個別登録”すると、どこかで必ず破綻します。
そこで効くのが 「URLの型を見つけて、まとめて転送する」 という発想です。

1）まず「旧URLの型」を3〜5本見てパターン化

例（イメージ）

旧：/entry/2026/03/06/slug
旧：/entry/2026/03/07/slug
→ /entry/YYYY/MM/DD/slug 型

ここまで分かれば、ルールでまとめやすくなります。

2）ルール化の基本は「共通部分を残して、可変部分だけ拾う」

正規表現が苦手でも、考え方はこれだけです。

固定：/entry/ の部分は毎回同じ
可変：年/月/日/スラッグは記事ごとに違う
→ 可変を “まとめて受け取る” のが正規表現

3）ルール例（考え方のサンプル）

※環境により記法が違うので、ここでは「発想」を掴むための例です。

# 旧 /entry/年/月/日/スラッグ → 新 /年/月/日/スラッグ
RewriteRule ^entry/([0-9]{4})/([0-9]{2})/([0-9]{2})/(.+)$ /$1/$2/$3/$4 [R=301,L]

ルール設計で事故を減らすコツ

まずは「限定的に当たる」ルールから（当たりすぎが一番危険）
1本入れたら必ずテスト（上位記事3本＋適当な記事2本）
URL末尾のスラッシュ有無を統一（どちらでも最終的に1つへ集約）

canonical・サイトマップ・パンくずなど“重複判定”を避ける設定

移行後に検索評価が不安定になる原因のひとつが「重複・類似ページの増殖」です。
WordPressは便利な反面、設定次第で“似たページ”が増えやすいので、正規化を早めに固めます。

1）canonical（正規URL）で「代表ページ」を宣言する

次のような状態があると、検索エンジンが迷います。

httpとhttpsが両方アクセスできる
wwwあり/なしが両方生きている
同じ記事に複数のURLで到達できる（末尾スラッシュ違い、パラメータ付き等）

対策の基本

表示の入口を1つに統一（301で集約）
canonicalは“その1つ”を指すようにする

2）サイトマップは「正規URLだけ」を出す

サイトマップに混ざると、クロールが無駄撃ちになりやすいです。

canonicalに合わせたURLが載っているか
旧URLやテストURLが混ざっていないか
タグ・日付アーカイブなど、薄いページを無理に増やしていないか

3）パンくずは「サイト構造の宣言」

パンくずはユーザーの回遊だけでなく、検索エンジンに構造を伝えます。

カテゴリの階層はシンプルに（増やしすぎない）
1記事の所属カテゴリをブレさせない（主要カテゴリを決める）
移行でカテゴリを再設計したなら、パンくずもそれに合わせて整える

4）重複しやすい“アーカイブ系”の扱いを決める

WordPressは放っておくと、次が増えがちです。

タグ一覧
日付アーカイブ
投稿者アーカイブ
検索結果ページ

判断の目安

「ユーザーが探しやすく、内容が十分ある」→ 残す（インデックス可）
「薄い／似たページが大量にできる」→ noindex等で整理（SEOプラグイン等の設定で行うことが多い）

サイト引っ越し屋さん公式サイト

Search Console・GAの移行（順位下落を検知できる状態にする）

移行後に一番怖いのは「順位が落ちたのか、計測が壊れただけなのか分からない」状態です。
そこで、Search Console（サチコ）とGAを先に整えて、異常を早期発見できる状態を作ります。

サチコ：新プロパティ追加／サイトマップ送信／エラー監視

1）まず結論：やるべきは「プロパティ」と「所有権の確認」

移行パターン別に、最短ルートはこうです。

独自ドメインをそのまま使う（はてなPro→WP）
→ 原則、同じプロパティを使い続けられます。
ただし、所有権の確認方法が「HTMLタグ」だった場合は、はてな側に置いていたタグが消えるので、WordPress側で再設定が必要になりがちです。
ドメインが変わる（はてな無料サブドメイン→新ドメイン）
→ 新しいプロパティを追加して、必要なら「住所変更（サイト移転）」の扱いも検討します（※これは“ドメイン移転”のときだけ）。

初心者におすすめの所有権確認
可能なら、今後の移行にも強い DNS（TXT）での確認が安心です（テーマ変更やCMS移行でも外れにくい）。

2）サイトマップ送信：インデックスの土台を作る

WordPress側でサイトマップURLが確定したら、サチコで送信します。

送信前のチェック（ここが抜けると遠回り）

サイトマップURLを開いて、表示できる（エラーにならない）
httpsで統一されている（httpのまま混ざっていると後でややこしい）
テスト環境のURLが混ざっていない（仮ドメインなど）

送信後に見るポイント

「送信はできた」だけでは弱いので、
“読み取り成功”になっているか、エラーが出ていないかを確認します。

3）エラー監視：見るべきレポートを絞る（初心者向け）

移行直後は、全部見ると疲れます。まずはこれだけでOKです。

ページのインデックス（旧：カバレッジ）
404、リダイレクト、重複（正規URLの選択）など、移行のダメージが出やすい場所です。
URL検査（ライブテスト）
上位記事やトップページを数本だけ選び、
「Googleが見に来たときに問題なく取得できるか」を確認します。
サイトマップ
送信したサイトマップが処理されているか、エラーがないかを確認します。
クロール統計
切替直後に「サーバーが重い」「5xxが出ている」などを見抜くのに役立ちます。
（該当するなら）HTTPSレポート
httpsの品質が落ちていないか、混在や設定ミスの早期発見に使えます。

移行直後にありがちな“異常のサイン”

404が急増（301不足・内部リンク切れ）
「見つかりましたが未登録」が増え続ける（サイト構造・クロール導線の問題が多い）
正規URLが意図と違う（canonicalやリダイレクトの整合性が崩れている）

GA：計測IDの付け替えとイベントの確認

1）まず結論：GA4は「同じ計測IDで継続」が基本

はてなでGA4を入れていたなら、移行後は 同じ計測ID（G-から始まるID） をWordPressに入れ直すのが基本です。
これで「移行前後の比較」がしやすく、データが途切れにくいです。

※ドメインが変わる場合でも、運用方針によっては同じプロパティを使い続けられます。ただし、後で混乱しないように「データストリーム（サイトの登録先）」のURLや扱いは整理しておくのがおすすめです。

2）設置方法は3択（初心者は“管理しやすさ”で決める）

GTM（タグマネ）で管理
今後イベント計測を増やすなら強い。
WordPressの公式/定番プラグインで設置
初心者が最短で安定させやすい。
テーマ or ヘッダー挿入で直接設置
シンプルだが、設定場所を忘れると見失いがち。

大事なのは「どこに入れたか」をメモして、二重計測を防ぐことです。

3）イベント確認：移行後は“最低限の動作確認”だけでOK

移行直後は、まず 「計測が生きている」 を確認します。

最短チェック（5分）

GAのリアルタイムでアクセスが入るか確認
クリックやスクロールなど、最低限のイベントが来ているか確認
もしイベントを作り込んでいるなら、DebugViewで意図どおり発火しているか確認

移行で壊れやすいイベント（要注意）

クリック計測（ボタンのCSSクラスやDOM構造が変わると死にやすい）
フォーム送信（サンクスページ方式→イベント方式などで仕様が変わる）
アフィリエイト導線（リンクの構造が変わるとトリガー条件がズレる）

💡コツ：最初は「主要なCV導線（申込ボタン等）」だけ確認し、細かいイベントは後回しでOKです。

インデックスの様子を見るチェック指標（何日単位で見るか）

移行後は、“毎日がっつり見る”より、見る項目と頻度を固定した方が安定します。
理由は、サチコもGAも反映にタイムラグがあり、短期の上下に振り回されやすいからです。

1）最初の2週間は「技術指標＞順位」の順で見る

順位（平均掲載順位）は揺れます。最初は次を優先してください。

404 / リダイレクト / サーバーエラーが増えていないか
正規URL（canonical）が意図どおりか
サイトマップが正常に処理されているか
主要ページがインデックス可能か（URL検査のライブテストで確認）

2）チェック頻度のおすすめ（初心者向け）

スクロールできます

期間	チェック頻度	見るもの（優先順）	目安のアクション
0〜3日	毎日（短時間）	404/5xx、サイトマップ、主要ページのURL検査、GAリアルタイム	“致命傷”を即修正（301不足・表示不具合）
4〜14日	2〜3日に1回	インデックス状況、正規URLのズレ、クロール統計、GAイベント	404を潰し、主要記事から整形・内部リンク修正
15〜30日	週1回	検索パフォーマンス（表示回数/クリック/CTR）、インデックス総数の推移	伸びる記事のリライト・導線改善へ移行

3）“正常な揺れ”と“危険な揺れ”の見分け方

正常な揺れ（よくある）

表示回数や順位が上下しながら、徐々に落ち着く
インデックス数が増減しつつ整う（重複整理が進む）

危険な揺れ（早めに手を打つ）

404が増え続ける
主要記事がインデックス不可になっている（noindex、robots、取得不可など）
正規URLが別ページ扱いになり続ける（canonical/301の不整合）
GAが途切れる（タグの外れ、二重計測、イベント消失）

サイト引っ越し屋さん公式サイト

移行後チェックリスト（公開前・公開直後・1〜4週後）

移行後は「全部を一気に完璧」にするより、時期ごとに“見るべきもの”を固定した方が失敗しません。
ここでは、初心者でも回せるように 公開前 → 公開直後 → 1〜4週後 の順で、優先度つきチェックに落とし込みます。

表示崩れ・404・画像切れ・内部リンク切れの総点検

公開前（いったん公開しても致命傷が出ない状態にする）

✅ 優先度高（必須）

表示確認（最低限でOK）
- トップ / カテゴリ / 上位記事3本 / 収益記事3本
ログイン確認
- 管理画面に入れる（ブックマーク＋ID/パス控え）
画像の“代表サンプル”確認
- アイキャッチ1枚＋本文画像が多い記事1本
内部リンクの導線チェック
- まとめ記事 → 比較記事 → レビュー記事（自分の想定導線でクリックして辿れるか）
404の事前潰し（最短ルート）
- メニュー・サイドバー・フッターのリンクを全部クリックして死んでないか

⚠️ よくある見落とし

テスト環境URL（仮ドメイン/仮URL）が本文内に残っている
旧はてなURLへの内部リンクが残っている
画像だけ別ドメイン参照で、特定記事だけ崩れる

公開直後（0〜3日：壊れている箇所を“即”ふさぐ）

✅ 優先度高（毎日10分でOK）

404の発生源を特定して対処
- 旧URL→新URLへ 301を追加（上位ページから）
- そもそも消したページなら、無理にトップへ飛ばさず整理（必要なら統合記事へ）
画像切れのパターン把握
- 「特定ドメインの画像だけ切れる」「https混在だけ切れる」など、傾向を掴む
内部リンクの“重要導線”だけ先に修復
- 収益導線（申込ボタン・比較表）に繋がるリンクを最優先

💡コツ

“全部の404を即ゼロ”は狙わなくてOKです。
まずは 上位記事・収益記事の404をゼロにすると、被害が最小になります。

1〜4週後（安定化：漏れを埋めて品質を整える）

✅ 優先度高（週1〜2回）

404の“残党狩り”
- Search Consoleの「ページのインデックス」で Not found（404）を見て、対応が必要なものだけ処理
画像の方針を確定
- 上位記事は WordPressメディアへ移す（または差し替え）
- 低優先記事は、当面そのままでもOK（ただし将来の方針は決めておく）
内部リンクの再設計（伸びる形に寄せる）
- 上位記事同士をつなぐ（関連・比較・手順の導線）
- カテゴリの役割を揃える（カテゴリが“迷子”だと回遊が落ちます）

速度・モバイル表示・構造化データの確認

公開前（点数より“事故防止”）

✅ 優先度高

モバイル表示（スマホで3ページだけ確認）
- 見出しが詰まっていないか
- 表が横にはみ出していないか
- ボタンが押しにくくないか
速度は「重い原因が分かる状態」にする
- まずはPageSpeed InsightsやLighthouseで 上位記事1本だけ計測し、重い要因を確認
  （最初から全ページ計測しない）

⚠️ ありがちトラブル

画像が重すぎてモバイルで崩れる（特に古いスクショ）
表や比較表がスマホで横スクロール地獄になる

公開直後（0〜3日：サーバー負荷と体感を守る）

✅ 優先度高

「体感が重い」ページを優先して対策
- アイキャッチが巨大 → 圧縮 or 適正サイズへ
- 埋め込み（SNS/動画）が多い → 上位記事だけ軽量化を検討
キャッシュ系は“触りすぎない”
- 速度改善プラグインを増やしすぎると、表示崩れや不具合の原因になります
  → 導入するなら1つに絞り、変えたら必ず表示確認

1〜4週後（ここでSEOの伸びやすさが変わる）

✅ 優先度高

コア指標の見方を固定（点数ゲームにしない）
- 目安として LCP / INP / CLS の改善に寄せる（「どこが遅いか」「どこで引っかかるか」）
構造化データは「必要なものだけ」確認
- ブログ全体で必須：パンくず（テーマが対応していれば自動のことも多い）
- 該当するなら：FAQ、レビュー、商品情報など（“記事内容に合うものだけ”）
Rich Results Testで、主要ページを数本だけテスト
- エラーがあるか
- 必須項目が不足していないか
  ※ここも全ページは不要。まずは 上位記事・収益記事 だけでOKです。

主要記事から優先的にリライト（順位回復を早める）

移行後のリライトは「文章を全部書き直す」ではなく、戻すべきところを戻し、伸びる形に整える作業です。

公開前（リライトの“対象”を決める）

✅ 優先度高

リライト対象を3つに分類（これだけで迷わない）
1. 最優先：収益記事（比較・レビュー・申込導線がある）
2. 優先：検索流入が多い記事（上位10〜30）
3. 後回し：日記系・伸ばさない記事

公開直後（0〜3日：戻すリライト）

✅ 優先度高（最優先は“損失を止める”）

収益記事だけ先にチェックして修正
- 比較表が崩れていないか
- ボタン・リンクが正しく遷移するか
- 注意書きや免責が欠けていないか
検索意図に直結する箇所が欠けていないか
- 「結論」「手順」「注意点」「料金/条件（必要な場合）」が落ちていないか

💡コツ

この段階は“加点”より“減点の回避”が効きます。
崩れ・リンク・見出し階層を戻すだけで、回復が早まることが多いです。

1〜4週後（伸ばすリライト：検索意図と導線を磨く）

✅ 優先度高

伸びる記事から順に「上書き」する
- 旧情報の更新（スクショ・手順・仕様）
- 競合と比べて薄い部分の補強（FAQ・比較軸・失敗例など）
内部リンクを“戦略的に”張り直す
- 入口記事 → 比較記事 → レビュー記事 → 申込導線（この流れを強化）
タイトル・見出しの微調整（やりすぎない）
- 検索意図に合う語句を補強しつつ、煽りすぎない
- 1記事に詰め込みすぎず、関連記事へ逃がす

✅ リライトの進捗目安（初心者向け）

1週目：収益記事（上位5〜10本）
2週目：流入が多い記事（上位10〜30本）
3〜4週目：回遊を増やす内部リンク整理＋不足記事の追加

サイト引っ越し屋さん公式サイト

旧はてなブログをどうする？（残す/非公開/告知の最適解）

移行が終わったあとに意外と迷うのが、「旧はてなブログをどう扱うか」です。
結論から言うと、最適解は “目的”で決まります。

SEO資産を守りたい → 旧URLの役割（誘導・案内）を残す
読者を迷わせたくない → 告知記事＋導線を整える
管理コストを減らしたい → しばらく様子見してから整理

ここでは、初心者でも判断しやすいように「残す/非公開/告知」の考え方をまとめます。

読者向けの案内記事（引っ越し告知テンプレ）

旧ブログに残すべき最重要コンテンツは、たった1本の 案内記事（引っ越し告知） です。
これがあるだけで、読者にも検索エンジンにも「移転した」ことが伝わりやすくなります。

1）告知記事に入れるべき内容（これだけでOK）

文章を盛りすぎる必要はありません。必要な要素は次の5つです。

移転した事実（いつから新ブログに移ったか）
新ブログのURL（1つに絞って載せる）
新ブログで読んでほしい理由（内容が最新／読みやすい等）
よく読まれる記事へのリンク（入口を用意）
問い合わせ先（必要なら）

💡ポイント

旧ブログの記事をすべて書き換える必要はありません。
まずは 告知記事1本＋サイドバー（または上部）に新URL だけで十分効果があります。

2）引っ越し告知テンプレ（コピペして調整OK）

※本文用テンプレです（見出しに太字・絵文字を使わない条件に合わせてあります）。

【テンプレ】

いつも当ブログをご覧いただきありがとうございます。
このブログは、内容を最新の状態でお届けするため、運営サイトをWordPressへ移転しました。

新しいブログはこちらです。
新ブログURL：〇〇〇〇（新サイトのURL）

今後の記事更新は、原則として新ブログで行います。
旧ブログの記事も一部残しますが、最新情報は新ブログをご覧ください。

よく読まれている記事（新ブログ）
・（新ブログの主要記事リンク）
・（新ブログの主要記事リンク）
・（新ブログの主要記事リンク）

お問い合わせがある場合は、こちらからお願いします。
・（問い合わせページ or メール）

3）告知記事を“機能する状態”にする配置（初心者向け）

告知記事は書くだけでは弱いので、旧ブログ内で目立たせます。

✅ 旧ブログのトップで見える位置に固定（可能なら）
✅ サイドバーやプロフィール欄に 新ブログURL を常設
✅ 旧ブログ内の人気記事に、可能なら「移転案内」を追記（上位5本だけでOK）

4）旧ブログに“残しすぎ”ないための注意点

旧ブログに情報を残しすぎると、新ブログに読者が移りにくくなります。

旧ブログは「案内所」と割り切る
旧ブログで更新を再開しない（情報が分散する）
“最新はこちら”を明確にする（迷わせない）

アカウント・フォト管理を残すべきケース

旧はてなブログを「残すかどうか」は、次の2軸で判断すると迷いません。

読者導線（案内所として価値があるか）
データ管理（はてな側に残っている資産があるか）

1）残すべきケース（当面は維持が無難）

次に当てはまるなら、すぐに削除・解約しない方が安全です。

旧ブログの記事が検索結果に多く残っている（旧URLからの流入がまだある）
他サイトからのリンク（被リンク）が多い記事がある
SNSで過去に拡散した記事が多い（ブックマークやシェアが残っている）
画像が旧ブログ参照のまま残っている（移行が終わっていない）
移行後の不具合対応がまだ終わっていない（404・混在・計測など）
はてな側のプロフィール・読者機能など、コミュニティ導線がまだ意味を持つ

💡初心者向けの目安

少なくとも 移行後1〜3か月 は残しておくと安心です。
（旧URLの評価移行や、読者の移動に時間がかかるため）

2）フォト（画像）をはてなに残すべきケース

画像の扱いは特に重要です。次のような場合は、旧環境を急いで消さない方が安全です。

WordPress側に画像を移し切っていない
記事内で、はてなの画像URLを参照している記事が多い
旧画像がないと記事の意味が崩れる（手順記事・レビュー記事など）

✅ 対応方針のおすすめ

上位記事から順に画像をWordPressへ移す
全部終わるまでは、旧フォト/旧ブログを残す

3）非公開（または更新停止）にするのが向くケース

逆に、次の条件なら整理を進めても問題が出にくいです。

旧ブログのアクセスがほとんどない
旧記事を今後育てない（役目が終わっている）
旧情報が多く、残すと誤解を招く（古い料金・仕様など）

ただし、非公開にする場合でも、読者の迷子を防ぐために

告知記事だけ残す
新ブログURLへの導線を残す

このどちらかは確保しておくのがおすすめです。

サイト引っ越し屋さん公式サイト

よくあるトラブル集（原因→対処を最短で）

移行トラブルは「原因が複数重なっている」ことが多いので、最短で直すコツは順番を固定することです。

① まず 症状を1ページで再現（トップではなく記事URLで）
② 次に HTTPステータスを確認（200 / 301 / 404 / 5xx）
③ その上で 原因の当たりを付けて一点突破（一度に全部いじらない）

下の各トラブルでは、よくある原因 → すぐ効く対処の順にまとめます。

インポートで止まる／文字化けする／一部だけ欠ける

よくある原因

MTファイルが大きすぎる（アップロード上限・処理時間の上限に引っかかる）
サーバー側の制限（max_execution_time や memory_limit など）
途中で処理が落ちる（タイムアウト、WAF・セキュリティがブロック）
文字コードの問題（UTF-8以外、UTF-8でもBOM付きなど）
インポートが完了していないのに「終わったように見える」（一部だけ登録）

最短で効く対処（止まる・欠ける系）

MTファイルを分割して再インポート
- いきなり全量ではなく、まずは小さめで成功パターンを作ります。
サーバーの上限を調整（できる範囲で）
- 実務的には 処理時間とメモリがボトルネックになりやすいです。
“10記事テスト” → “本番” の順にする
- テストで崩れ方が分かると、本番での手戻りが激減します。
インポートの結果を数で確認する
- はてな側の記事数と、WordPress側の投稿数が大きくズレていないかチェック。

文字化けの最短対処

MTファイルが UTF-8 になっているか確認
文字化けが「本文だけ」「カテゴリ名だけ」など、発生箇所を分けて見る
WordPress側のデータベースが utf8mb4 系で運用されているか（絵文字・特殊文字で崩れやすい）

一部だけ欠けるときの確認ポイント

「下書き」「限定公開」など、公開状態の違いで見落としていないか
予約投稿を多用していた場合、取り込み後に 日時や状態が想定とズレていないか
途中で止まっている場合、同じファイルを何度も入れると重複が起きることがあるため、
分割＋段階投入に切り替えるのが安全です。

画像が表示されない（URL・権限・https混在）

よくある原因

画像URLが はてな側のままで、参照に失敗している（環境・制限・URL変更）
https混在（httpsページ内にhttp画像が混ざり、ブラウザがブロック）
WordPressの wp-content/uploads の 権限・所有者が崩れている
画像はあるが パスが変わっている（移行時の置換・差し替えミス）
画像の縮小版だけがない（サムネイル生成の不整合）

最短で切り分ける手順

画像が出ないページを開き、画像のURLだけを別タブで開く
- ここで表示できないなら、原因は「画像の所在・URL」に寄っています。
URLが http:// なら、まず https化が必要（混在の可能性）
画像がWordPress内にあるはずなら、管理画面で
- メディアに存在するか
- アップロードできるか（権限が死んでないか）
  を確認します。

最短で直す（頻出パターン別）

混在コンテンツが原因
→ まずサイト全体を httpsに統一し、本文内の http 参照を上位記事から修正
はてな画像参照が残っている
→ 上位記事から「移す or 差し替える」を決め、順番にWordPress側へ寄せる
権限の問題
→ サーバー側で uploads の権限・所有者を確認（突然の画像アップ不可も同根）

💡コツ：最初から全記事の画像を完璧にしようとせず、
上位記事（流入・収益）だけを先に“完全表示”へ寄せると、成果への影響が大きいです。

パーマリンクが一致しない／301がループする

よくある原因

インポート後に パーマリンク設定を変更してしまった
http ↔ https、wwwあり ↔ なし、末尾スラッシュの違いが混在している
リダイレクトの二重管理（プラグイン＋.htaccess＋CDN など）
正規表現ルールが広すぎて、意図しないURLまで転送している
canonical（正規URL）と301の方向が食い違っている

最短で切り分ける手順（迷ったらこれ）

「正解のURL」を1つ決める
- 例：https、wwwなし、末尾スラッシュあり、など
旧URLを開いたときに、1回の301で正解URLに着地するか確認
- 2回以上転送されるなら、どこかで二重化しています。
一時的に、リダイレクト関連のプラグインを止めて挙動を見る
- 原因が .htaccess 側か、プラグイン側かを切り分けできます。

301ループ（ERR_TOO_MANY_REDIRECTS）を最短で止める

重複している転送ルールを1つに絞る
- “同じ目的の転送”を複数箇所でやるとループの温床になります。
WordPressの「WordPressアドレス」「サイトアドレス」が想定どおりか確認
- ここがズレていると、直しても直しても戻ることがあります。
キャッシュをクリアして再確認
- ブラウザキャッシュ、CDNキャッシュ、サーバーキャッシュの順で疑います。

順位が落ちた（見るべき指標と打ち手の優先順位）

移行直後の順位変動は珍しくありません。問題は、落ち方が“正常な揺れ”か“事故”かです。
そこで「指標→対処」を優先順位で固定します。

まず見るべき指標（優先順位）

優先1：インデックスと取得の異常

インデックス不可（noindex、robots、取得不可）
404/5xxの急増
正規URLのズレ（意図しないURLが正規扱い）

優先2：リダイレクトの品質

旧URL→新URLが301でつながっているか（上位ページから）
チェーン（A→B→C）になっていないか

優先3：サイトマップ・内部リンク

サイトマップが読み取れているか
上位記事への内部リンク導線が壊れていないか

優先4：コンテンツの変化

見出し構造・本文・タイトルが大きく変わっていないか
表や比較要素が崩れて「読めない状態」になっていないか

打ち手の優先順位（最短で回復を狙う）

404を潰す（上位記事優先）
- 旧URLにアクセスがあるのに404なら、回復が遅れやすいです。
canonical・https・wwwを統一
- “同じ内容が複数URLで存在”すると評価が割れやすいです。
上位記事だけ整形＋導線修復
- 画像切れ・表崩れ・リンク切れを直すだけで戻るケースが多いです。
その後にリライト（追い込み）
- 移行直後は“大改造”より、まず“元の強さに戻す”が近道です。

見る頻度の目安（初心者向け）

公開〜3日：毎日（404/5xx/主要ページの取得可否）
1〜2週：2〜3日に1回（インデックス状況・正規URL・サイトマップ）
3〜4週：週1回（検索パフォーマンスの推移と改善対象の選定）

サイト引っ越し屋さん公式サイト

FAQ：移行前に不安が多いところだけ先回り回答

無料版（サブドメイン）からでも可能？現実的なやり方は？

可能です。ただし、無料版（例：○○.hatenablog.com）は “SEOを引き継ぐ王道手段（301リダイレクト）”が取りにくい ため、現実的には次の2ルートに分かれます。

ルートA：SEOをなるべく守りたい（おすすめ）

一時的にProへ移行 → 独自ドメイン運用 → その独自ドメインのままWordPressへ の順で進めます。

独自ドメインを軸にすると、移行後も「サイトの住所」がブレにくい
301や正規化も設計しやすい
結果として「立て直し」ではなく「引っ越し」になりやすい

ざっくり手順

はてなブログをProにして独自ドメインを設定
URL構造・記事の棚卸しを済ませる
WordPress側を完成に近い状態まで作る
独自ドメインの向き先をWordPressへ切り替える
必要に応じて旧URL→新URLの301を整備

ルートB：無料版のまま移行する（“新規サイトとして再構築”寄り）

無料版のままでも記事データは持っていけますが、基本は 新ドメインのWordPressへ移し替えて育て直す 形になります。

現実的にやること

旧はてな側：移転告知記事を作り、新ブログへのリンクを目立つ位置に固定
新WordPress側：上位記事から整形・内部リンク再構築・最新化
旧記事は「案内所」と割り切り、更新は新サイトへ一本化

補足（期待値の置き方）

301で“評価を移す”のではなく、読者導線とコンテンツ改善で“取り戻す”発想が合います
伸びやすいのは、比較・レビュー・手順など「検索意図が明確な記事」からです

記事数が多いけど、どこから手をつけるべき？

記事数が多いほど、最初に 優先順位を固定しないと破綻します。
結論：「全部やる」ではなく「収益・流入に直結するところから」 が正解です。

迷わない優先順位（この順でOK）

収益記事（比較・レビュー・ランキング・申し込み導線がある）
検索流入の多い記事（上位10〜50本）
被リンクやSNS拡散がある記事（外から来る入口）
その他（思い出記事・今後伸ばさない記事）

作業を3段階に分けると早い

第1段階：移行を“完了”させる（最短）
記事を入れる／最低限表示できる／重大な404を止める
第2段階：主要記事だけ“品質を戻す”
表示崩れ・画像・内部リンク・アフィリンクを直す
第3段階：全体を“伸びる形に整える”
内部リンク再設計、カテゴリ整理、リライト

大規模でも折れないコツ

まず「上位20本」を完璧にする（ここが戻れば被害が小さい）
残りは “最低限の体裁” → “後で改善” の二段構えにする
一括置換や大量のURL変更は、成功パターンができてから（先にやるほど事故りやすい）

アドセンスはどうなる？審査や設定はやり直し？

ポイントは 「ドメインが変わるかどうか」 です。

ドメインが変わらない場合（独自ドメインをそのまま使う）

基本的には、広告コードや設定をWordPress側へ移せば継続できます。ただし移行直後は次をチェックしてください。

広告コードの設置場所（二重計測・二重広告を防ぐ）
ads.txt の設置（サイトのルートで配信できる状態）
表示が出ないときは、まず「https混在」や「キャッシュ」を疑う

ドメインが変わる場合（新しい独自ドメインに移す）

新ドメインは、AdSense側で “新しいサイトとして追加・確認（レビュー）” が必要になることが一般的です。

最短の進め方（やる順）

AdSenseの「サイト」へ新ドメインを追加
所有確認（コード／ads.txt／メタタグ等の方法）
レビュー（審査）をリクエスト
ステータスが「Ready」になるのを待って配信開始

注意点

反映には幅があり、短期間で終わることもあれば時間がかかることもあります
旧サイトの広告が動いていても、新サイトは別扱いになることがあります

移行タイミングはいつが良い？

移行は「技術作業」なので、タイミングの最適解は “あなたが監視できる時期” です。
初心者ほど、ここを間違えるとしんどくなります。

避けたいタイミング

長期旅行・繁忙期の直前（見張れないのが最大のリスク）
収益ピークの直前（広告・導線が崩れると損失になりやすい）
サーバー・ドメイン更新期限ギリギリ（事故時に逃げ場がない）

“日時”の選び方（実務）

アクセスが少ない時間帯＋作業後に確認できる時間（早朝〜午前が選ばれやすい）
変更直後に、最低でも「トップ＋主要記事3本」は必ず確認できる状態にしておく

サイト引っ越し屋さん公式サイト

まとめ：SEOを守りつつ“資産ブログ”へ移行するための要点

はてなブログ→WordPress移行は、作業量が多く見えますが、SEO視点で大事なのは実はシンプルです。
「検索エンジンが迷わない状態」を作り、「読者が迷わない導線」を整えれば、移行後のブレは最小化できます。

最重要は「URL設計」「301」「移行後の監視」

移行でSEOを守るために、最優先で押さえるべき要点はこの3つです。

1）URL設計：移行前に“先に決める”のが勝ち

URLはページの住所。住所が変わるほど評価が揺れやすい
できるだけ 旧URLの型に寄せる（無理なら最終的に1つへ集約できる形に整える）
パーマリンクは後から変えるほど、301も内部リンクも崩れやすい

✅ 結論：URLは最初に固定してからインポート・整形を進めるのが安全です。

2）301：旧URLの評価と読者を“確実に案内”する

URLが1文字でも変わるなら、基本は301が必要
旧URLを全部トップへ飛ばすのは避け、できるだけ「同じ内容」に着地させる
大量URLは「個別登録」ではなく「ルール化（型でまとめる）」が破綻しにくい

✅ 結論：上位記事から優先して301 → 404を見ながら穴埋め、が最短で確実です。

3）移行後の監視：順位より先に“技術の異常”を見る

移行直後は順位が揺れます。ここで焦って記事をいじりすぎると、逆に悪化しやすいです。

まず見るのは 404 / 5xx / インデックス不可 / 正規URLのズレ
その次に サイトマップの処理状況
最後に 検索パフォーマンス（クリック・表示回数・CTR） を見る

✅ 結論：移行後は「順位」より先に、Search Consoleで異常を早期発見するのが正解です。

迷ったらこの手順（結論ベースの最短チェック）

「結局、何からやればいい？」となったら、次のチェック順に沿って進めるのが最短です。
初心者でも破綻しにくい“一本道”にしています。

ステップ1：移行前の準備（ここで8割が決まる）

✅ 旧URLの型を把握（/entry/・日付・カスタムURL）
✅ 上位記事（流入・収益）のリスト化（最低20本）
✅ バックアップ方針を決める（記事・画像・タグ・埋め込み）
✅ WordPress側の土台を用意（SSL、初期設定、パーマリンク確定）

ステップ2：インポート（“入れる”より“確認”が大事）

✅ 小さくテスト取り込み（10記事）→問題なければ本番
✅ 投稿者・公開状態を確認（公開事故を防ぐ）
✅ 取り込み後は、記事数と文字化けをざっとチェック

ステップ3：整形（上位記事だけ先に“戦える状態”へ）

✅ 表示崩れ（見出し・囲み・引用）を修復
✅ 画像方針を決めて、上位記事からWordPressへ寄せる
✅ 内部リンクと埋め込みを整える（回遊とUXを戻す）
✅ アフィリエイトリンクの遷移と計測を確認（収益の血管）

ステップ4：独自ドメイン切替（安全に切り替える）

✅ 切替前に「トップ＋上位記事」だけ最終確認（表示・ログイン・画像）
✅ DNS切替後は“混在”が起きても慌てない（反映待ちは仕様）
✅ httpsを安定化（混在コンテンツを上位記事から潰す）

ステップ5：301と正規化（SEO資産を守る本丸）

✅ 旧URL→新URLを上位記事から301
✅ 正規URL（canonical）と www/https を統一
✅ サイトマップ送信（正規URLだけ載っているか確認）

ステップ6：監視と改善（順位回復を早める）

✅ 公開〜3日：404/5xx/インデックス不可の監視（毎日10分）
✅ 1〜2週：404を追加で塞ぐ＋主要記事の整形を完了
✅ 3〜4週：主要記事のリライトと内部リンク強化（伸ばす工程へ）

最後にひとこと
移行は「一発で完璧」を狙うほど失敗しやすいです。
最初は “上位記事だけ完璧、その他は最低限” で十分。
そのうえで、監視しながら段階的に整えるのが、SEOも運用も一番安定します😊

サイト引っ越し屋さん公式サイト