一覧に戻る
    WordPressからLovableへのブログ移行:5年・100記事を2日で刷新した話

    WordPressからLovableへのブログ移行:5年・100記事を2日で刷新した話

    12 分で読める

    「SEOが怖いからURLを変えない」判断は、3年スパンではほぼ確実に損です。

    ChatGPTとの対話でこの言葉が出てきたとき、私は決心しました。5年運用してきたTIELEC Blogを、WordPress(DB管理)からLovable(Markdownファイル管理)に移行する。それも、URL構造から見直す形で。

    100記事。積み上げてきたコンテンツ。そのすべてを、今、刷新する。

    決断のきっかけ:Lovableとの出会い

    2025年の後半、Lovableを使い始めました。

    最初は「また新しいツールか」くらいの気持ちでした。でも、実際に触ってみて感じたんです。これは、ものすごいツールだなと。

    LLMを使いながら、ウェブサイトを自由に構築できる。自分のやりたいことを思い描いて、それを形にするスピード感。WordPressでは、カスタマイズしたいと思っても、そこまで素早くできるわけじゃなかった。テーマを選んで、プラグインを探して、PHPをいじって...という流れ。

    でもLovableは違いました。柔軟に、デザイン性も高く、しかも速い。

    もしLovableを試してみたいなら、こちらの招待リンクから始められます。

    https://lovable.dev/invite/HN8QQET

    lovable.dev

    「これからは、Lovableを活用していく」

    そう決めたとき、同時に思ったんです。ここは今、移行するべきなんじゃないか、と。

    5年運用してきたブログ。100記事も積み上げてきた。でも、だからこそ。今変えないと、この先もずっとWordPressのまま。多言語化も、Git管理も、理想的なURL設計も、全部「いつかやりたいこと」のままになる。

    ChatGPTとの要件整理:対話が生んだ明確さ

    最初、私はChatGPTにこう尋ねました。

    「このブログをLovableでの実装に置き換えたい。要件を整理して、Lovableに渡すプロンプトを書いてほしい」

    ChatGPTは現状のブログを確認し、WordPress特有のURL構造(/index.php/<slug>/)を指摘しました。そして選択肢を示してくれました。

    A案:URL維持プラン(安全・保守的)

    • 現在のURLをそのまま維持
    • 301リダイレクトが最小限
    • SEOダメージほぼなし

    B案:URL再設計プラン(成長重視)

    • /ja/blog/<slug>//en/blog/<slug>/に変更
    • 多言語対応を構造に組み込む
    • 短期的なSEOダメージあり、長期的には強くなる

    私は迷いました。100記事のSEO評価。それを、本当に手放していいのか。

    SEOが回復するまでの時間を尋ねると、ChatGPTはこう答えてくれました。

    「URLが変わってもSEOは回復します。ただし回復までの時間には幅があり、設計と移行品質で"数週間"にも"半年以上"にもなります」

    フェーズごとの目安も示されました:

    • 初期混乱:1〜2週間(順位が一時的に下落)
    • 再評価:3〜8週間(301を辿って評価が移行)
    • 回復:2〜4か月(旧URLと同等に回復)
    • 成長:3〜6か月〜(構造改善の効果が出始める)

    でも、と私は思いました。これから記事を増やしていく。多言語化も本気でやりたい。今、痛みを伴っても理想的な構造にしておく方が、長期的には正しいんじゃないか。

    「B案でいきます」

    段階的移行という知恵:3フェーズ戦略

    B案を選んだ後、もう一つ重要な議論がありました。

    私は最初、こう考えていました。「デザインを確定してから、後でURL構造を決めてマッピングすればいいんじゃないか」

    ChatGPTは丁寧に、でもはっきりと指摘してくれました。

    「あとでマッピング」は、SEO的には"まずい"です。

    理由は明快でした:

    1. Googleは「最初に見た状態」を強く記憶する
    2. 一度404を踏ませると回復が遅くなる
    3. slugを「あとで考える」と、ほぼ確実にズレる

    つまり、新しいブログを作る段階で、旧URLとのマッピングまで確定しておく必要がある。でも、デザインの試行錯誤中に検索エンジンにインデックスされたら困る。

    そこで生まれたのが、3フェーズ戦略でした。

    フェーズ1:デザイン確定(検索エンジンに見せない)

    • 新ブログのUI/UXを作り込む
    • 全ページにnoindex, nofollow
    • sitemap.xmlは生成しない
    • robots.txtでクロール不可に

    この段階では、検索エンジンから「存在しない」のと同じ。何度作り直してもSEOに影響しない。

    フェーズ2:slug確定 → マッピング → 記事移行

    • 旧WordPress URLのslug一覧を確定
    • 新URL(/ja/blog/<slug>/)を確定
    • 301リダイレクト表を完成
    • Markdown記事を配置
    • 内部リンクも新URL前提に修正

    ここまでやって初めて「公開できる構造」になる。

    フェーズ3:ドメイン切替(初公開)

    • 301リダイレクトを有効化
    • noindexを解除
    • sitemap送信
    • Search Consoleで監視開始

    Googleは最初から「旧URLは新URLに移った」と理解できる。これが、SEOダメージを最小化する鍵でした。

    移行作業の実際:準備していた伏線

    実は、移行作業にはある程度の準備がありました。

    以前から、WordPressのプラグイン「Git it Write」を使って、記事をMarkdown形式でGit管理していたんです。だから、Markdownファイルのエクスポート自体は比較的簡単でした。

    でも、一番面倒だったのはサイトのマッピングでした。

    旧URL(/index.php/<slug>/)と新URL(/ja/blog/<slug>/)の対応付け。8割くらいはスムーズにマッピングできたんですが、残りの2割は個別確認が必要でした。

    • カテゴリ構造が変わった記事
    • スラッグに特殊文字が含まれていた記事
    • 過去にURLを変更した履歴がある記事

    これらを一つ一つ確認しながら、LLMの力も借りて進めました。ChatGPTに旧URL一覧を渡して、「この形式を新URL形式に変換して」と依頼したり。手作業では気が遠くなるような作業でした。

    Lovableでの実装:2日間の驚異

    ChatGPTと議論を重ねて完成したLovable用プロンプトは、約1,000単語にもなりました。

    重要だったのは、今やることと、やらないことを明確に分けた点です。

    ■ 今回のスコープ(① デザイン確定フェーズ)
    
    やること
    
    - ブログ全体のベースデザイン
    - 多言語前提のUI設計
    - 将来のURL再設計に耐えられる構造
    
    やらないこと(重要)
    
    - 本番公開
    - SEO対応(canonical / hreflang / sitemap 等)
    - slug の確定
    - 旧WordPress URLとのマッピング
    - 301リダイレクト

    このプロンプトをLovableに渡してから、驚くほど速く進みました。

    一発で完璧、とまではいかなかったですが、大枠のデザインを固めて、必要な機能を一つずつ追加していく。その速度感が、WordPressとは比較にならなかった。

    2日間

    たった2日で、ブログの基本構造が完成しました。WordPressをサーバーに立ててインストールして、テーマをカスタマイズして...という作業と比べても、明らかに速い。

    ものすごいツールだな、と改めて実感しました。

    SEOの現実:まだわからない

    移行後、実際のSEO状況はどうなのか。

    正直に言うと、まだわかりません

    稼働し始めたばかりなので、長期的な影響は見えていません。ただ、PVを見る限り、影響はそこまで受けていないように見えます。もちろん、これが回復なのか、それとも元々この程度なのか、判断するには時間が必要です。

    数ヶ月後、Search Consoleのデータを見て、301リダイレクトがきちんと評価されているか。新URLがインデックスされているか。順位がどう変動しているか。

    そのすべてを見守る期間に、今はいます。

    これからの運用:Git管理の可能性

    Markdown管理に変えて、記事執筆の環境が大きく変わりました。

    まだ移行直後なので、「記事を書くスピードが上がった」とまでは言えませんが、これから上げていきたいと思っています。Gitで管理できるようになったことで、記事のレビューもしやすくなるし、バージョン管理も明確になる。

    多言語対応も、これから本格的にやっていきます。URL構造は既に/ja//en/で分けているので、あとは翻訳して配置するだけ。

    振り返って:「楽しかった」と言えるように

    今振り返って、B案(URL構造再設計)を選んだ判断は正しかったのか。

    まだ、何とも言えません。

    移行直後の今は、正直「これで良かったのか」と不安もあります。SEOが回復するのか。多言語化は本当にうまくいくのか。Git管理の運用は定着するのか。

    でも、一つだけ確信していることがあります。

    後から「楽しかった」と言えるようにすることが、大事なんじゃないか。

    技術的負債と向き合うのは、痛みを伴います。5年・100記事という積み上げを、一度リセットする決断は重かった。でも、それを先送りにしていたら、3年後も「いつかやりたい」のままだったと思います。

    Lovableという新しいツールに可能性を感じた。だから、移行した。ChatGPTと対話しながら、リスクを最小化する戦略を立てた。GitIt Liteで事前準備していたから、移行もスムーズだった。

    すべてが計画通りではなかった。マッピングの2割は個別対応が必要だったし、SEOの結果もまだわからない。

    でも、このプロセス自体が、学びだったんです。

    もし後輩エンジニアが同じ状況で「SEOが怖いからURLは変えたくない」と言ったら、私はこう伝えると思います。

    「怖いのは当然だよ。でも、今変えないなら、いつ変えるの? 3年後、5年後の方が、もっと怖くなるよ」

    技術的負債は、時間とともに膨らみます。でも、向き合うタイミングを見極められれば、それは「負債」じゃなくて「投資」になる。

    この移行が「投資」だったと言えるように、これからも記事を書き続けます。

    この記事は役に立ちましたか?

    Coffee cup

    この記事が、何かの整理につながったら

    コーヒー1杯分の応援をもらえると嬉しいです。

    ※ これは応援とは別の話ですが、

    同じようなテーマを自分の文脈で整理したい場合は、 (文章だけだと詰まりやすい人向けに) 思考整理の壁打ちという形で対話の時間も取っています。

    対話の時間について