ToolArc

ブログ記事

  • Next.js
  • リダイレクト
  • 301リダイレクト
  • SEO
  • URL設計
  • Vercel

Next.jsで/postsの旧URLを301リダイレクトする手順

"旧URL（/posts/...）が本番で404のまま残っている場合の対処法です。Next.jsのredirectsで301恒久リダイレクトを設定し、リンク切れとSEO評価の分散を防ぐ手順を、実際に404を確認した経験をもとに整理しました。"

ブログのURL構造を途中で変更すると、旧URLがそのまま宙に浮いてしまうことがあります。筆者も実際に、/posts/ から /blog/ へURL設計を変えたあと、旧URLへアクセスすると404が返る状態を本番環境で確認しました。

見た目上はサイトが正常に動いているように見えても、外部からの被リンクや過去のSNS投稿、検索エンジンにキャッシュされたURLは古いままです。放置すると、リンク切れの体験だけでなく、旧URLと新URLでSEO評価が分散してしまう可能性があります。

この記事では、Next.jsの redirects を使って旧URLを301（恒久リダイレクト）で正規URLへ送る手順を、筆者が実際に確認した内容をもとに整理します。

今日の結論

  • /posts/ から /blog/ へURL設計を変えた場合、旧URLは自動では消えず、放置すると404のまま残ります
  • Next.jsの redirects（next.config）で301恒久リダイレクトを設定すれば、旧URLへのアクセスを正規の /blog/... へ引き継げます
  • GSCの「ページにリダイレクトがあります」という表示とは別の問題です。本記事はアプリ側の旧URL修正に絞って解説します
  • 設定後は、ローカルビルドと本番デプロイ後の両方で301の挙動を確認する必要があります

こんな症状が出ていたら旧URLの404を疑う

URL設計を変更したあと、次のような状態に心当たりがあれば、旧URLの404が原因の可能性があります。

  • 過去にシェアしたSNS投稿やブックマークのリンクを開くと、404ページが表示される
  • 外部サイトからの被リンクが古いURL形式（例: /posts/記事スラッグ）のままになっている
  • GSCのカバレッジレポートで、旧URL形式のページが「見つかりませんでした（404）」として検出される

Next.jsは、pages または app ディレクトリのルーティング定義に存在しないパスへのアクセスに対して、自動的に404を返します。URL構造を /posts/ から /blog/ に変更した場合、旧パス（/posts/...）へのルーティング自体がコード上に存在しなくなるため、Next.jsは「該当するページがない」と判断します。

サイト内部のリンクを新URLに張り替えるだけでは、この問題は解決しません。外部からの被リンク、検索エンジンにキャッシュされたURL、読者のブックマークなど、サイトの外側にある古いURLの参照には対応できないためです。

Next.jsのredirectsで301恒久リダイレクトを設定する手順

旧URLから正規URLへの301リダイレクトは、next.config の redirects 機能で設定します。

  1. 本番で404になっている旧URLを一覧化する（例: /posts/記事スラッグ の形式）
  2. 対応する現行slugを確認する（lib/blog/posts.ts やサイトマップで、旧URLに対応する /blog/... の正規URLを特定する）
  3. next.config の redirects に設定を追加する（source → destination を permanent: true で指定する）
// next.config.ts
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  async redirects() {
    return [
      {
        source: "/posts/:slug",
        destination: "/blog/:slug",
        permanent: true,
      },
      // slugの命名規則が変わっている個別記事は1件ずつ追加する
      {
        source: "/posts/old-article-slug",
        destination: "/blog/new-article-slug",
        permanent: true,
      },
    ];
  },
};

export default nextConfig;
  1. ローカルで動作確認する
npm run build

ビルド後、旧URLにアクセスして301で新URLへ遷移するかを確認します。

  1. 本番デプロイ後、GSCで確認する（URL検査ツールで、旧URLがリダイレクト先を正しく指しているかを確認します。ただし、Googleの再クロールタイミングに依存するため、反映は条件付きです）

動作確認とよくある注意点

設定を入れて終わりにせず、以下のポイントを確認しておくと安心です。

  • ローカル環境で、旧URLにアクセスした際のステータスコードが301になっているか（ブラウザの開発者ツールのNetworkタブで確認できます）
  • リダイレクト先（Locationヘッダー）が意図した正規URLになっているか
  • 本番デプロイ後、実際に旧URLへアクセスして正規URLへ遷移するか
  • 旧URL→別の旧URL→新URLのような**多重リダイレクト（リダイレクトチェーン）**になっていないか

GSC側の反映（インデックスの更新やカバレッジレポートの変化）は、Googleのクロールスケジュールに依存するため、設定直後にすぐ反映されるとは限りません。執筆時点では、反映までに数日〜数週間かかるケースがあると考えられます。

また、GSCのカバレッジレポートに表示される「ページにリダイレクトがあります」という項目は、すでにリダイレクトが設定された後の分類であり、本記事で扱った「旧URLが404のまま放置されている」状態とは別の問題です。この違いについては、GSCの「ページにリダイレクトがあります」はドメイン正規化なら放置でよいもあわせて確認してください。

チェックリスト

#確認項目完了
1本番で404になっている旧URLを一覧化した☐
2対応する現行slugをposts.ts等で確認した☐
3next.configのredirectsにpermanent: trueで追加した☐
4ローカルのnpm run build後に301の挙動を確認した☐
5本番デプロイ後、GSC URL検査で確認した☐
6リダイレクトチェーンになっていないか確認した☐

まとめ・次に読む

URL構造の変更は、公開後の運用フェーズで見落としやすいポイントです。旧URLの404を放置せず、301リダイレクトで正規URLに引き継ぐことで、リンク切れの体験とSEO評価の分散をどちらも防げます。

サイト全体の公開の流れについてはAI初心者がゼロからWebサイトを公開するまでにやったこと・詰まったこと全部まとめも参考にしてください。

免責: 本記事はNext.jsのredirects機能に関する、2026年7月5日時点の実務メモです。Next.jsの仕様は変更される可能性があります。重要な判断は公式ドキュメントで確認してください。