Next.js Sitemap と robots.txt 設定ガイド:検索エンジンに素早くインデックスしてもらう
サイトを公開して、Google で自分のサイト名を検索したのに——何も出てこない。何度か更新して、キーワードを変えても、結果はゼロ。Google Search Console を開くと、送信した Sitemap が「取得できませんでした」と表示。心臓が冷えます。検索トラフィックがなければ、どんなに良いコンテンツも埋もれたままです。
以前も同じ問題に直面しました。初めて Next.js プロジェクトを作ったとき、あるチュートリアルどおりに Sitemap を設定したのに、Google がまったく取得できませんでした。1 週間試行錯誤した末、原因は robots.txt の設定——サイト全体をブロックしていたことでした。初歩的なミスなのに、あの無力感は今でも覚えています。
この記事では、自分が踏んだ落とし穴、調べたドキュメント、試した設定をすべて整理します。2 つのファイルの役割をわかりやすく説明し、Sitemap 生成の 3 方式、よくあるミス、実際の失敗事例と復旧方法までお届けします。サイトがインデックスされない、Sitemap がエラーになる、動的ページの設定方法がわからない——そんな悩みがあれば、少しは近道できるはずです。
なぜ Sitemap と robots.txt が必要なのか?
Sitemap の役割
Sitemap は検索エンジン向けの「地図」です。サイト上のページ、更新頻度、重要度を伝えます。Sitemap がなければ、クローラーはリンクを辿ってページを発見するしかなく、深い階層や動的生成コンテンツは数か月クロールされないこともあります。
業界データによると、Sitemap があるサイトはインデックス速度が約 40% 向上します。新規サイトでは、1 週間以内にインデックスされるか、1 か月後になるかの差が顕著です。
robots.txt の役割
robots.txt は「どこをクロールしてよいか、ダメか」を伝えるファイルです。管理画面、API エンドポイント、ビルドファイルなど、インデックス不要なものをブロックし、クロール枠を重要ページに集中させられます。
ただし、ここが重要です。robots.txt を設定しないほうが、誤設定よりマシなこともあります。特定ディレクトリをブロックしたつもりが、サイト全体をブロックして Google から消えてしまう——よくある話です。設定したら必ずテストを。テスト、テスト、もう一度テスト。
Next.js で Sitemap を生成する 3 つの方法
Next.js 13+ の App Router 導入以降、Sitemap 生成方法も変わりました。シンプルなものから順に 3 方式を紹介します。
方法 1:App Router 標準 sitemap.ts
向いている場面:Next.js 13+ プロジェクト、ページ数が少なめ(数十〜数百)
公式推奨の方式で、追加依存なしが最大のメリット。app ディレクトリに sitemap.ts を作成します:
// app/sitemap.ts
import { MetadataRoute } from 'next'
export default function sitemap(): MetadataRoute.Sitemap {
return [
{
url: 'https://yourdomain.com',
lastModified: new Date(),
changeFrequency: 'yearly',
priority: 1,
},
{
url: 'https://yourdomain.com/about',
lastModified: new Date(),
changeFrequency: 'monthly',
priority: 0.8,
},
{
url: 'https://yourdomain.com/blog',
lastModified: new Date(),
changeFrequency: 'weekly',
priority: 0.5,
},
]
}
デプロイ後、https://yourdomain.com/sitemap.xml にアクセスすると Sitemap が表示されます。
メリット:
- 公式サポートで安定
- 追加依存なし
- TypeScript の型チェックが使える
デメリット:
- 静的ページは手動メンテナンスが必要
- 動的ページはコード内でデータ取得が必要
方法 2:next-sitemap パッケージ
向いている場面:自動化、マルチ環境、大規模サイト
next-sitemap はコミュニティで最も使われている Sitemap 生成ツールで、機能が豊富です。
インストール:
npm install next-sitemap
設定ファイル next-sitemap.config.js:
/** @type {import('next-sitemap').IConfig} */
module.exports = {
siteUrl: process.env.SITE_URL || 'https://yourdomain.com',
generateRobotsTxt: true, // robots.txt も自動生成
sitemapSize: 50000, // 1 つの Sitemap 最大 50,000 URL
exclude: ['/admin/*', '/api/*', '/secret'], // 除外パス
robotsTxtOptions: {
policies: [
{
userAgent: '*',
allow: '/',
disallow: ['/admin', '/api'],
},
],
additionalSitemaps: [
'https://yourdomain.com/server-sitemap.xml', // 動的 Sitemap
],
},
}
package.json にスクリプトを追加:
{
"scripts": {
"build": "next build",
"postbuild": "next-sitemap"
}
}
npm run build のたびに Sitemap が自動生成されます。
メリット:
- 複数 Sitemap 分割など高機能
- robots.txt も自動生成
- 動的ルート対応
- マルチ環境設定可能
デメリット:
- 追加依存が必要
- 設定がやや複雑
方法 3:API ルートで手動生成
向いている場面:極限のカスタマイズ、リアルタイム更新が必要な Sitemap
App Router では Route Handler を使います:
// app/sitemap.xml/route.ts
import { NextResponse } from 'next/server'
export async function GET() {
// データベースや CMS からデータ取得
const posts = await fetchAllPosts()
const sitemap = `<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://yourdomain.com</loc>
<lastmod>${new Date().toISOString()}</lastmod>
<priority>1.0</priority>
</url>
${posts.map(post => `
<url>
<loc>https://yourdomain.com/blog/${post.slug}</loc>
<lastmod>${post.updatedAt}</lastmod>
<priority>0.7</priority>
</url>
`).join('')}
</urlset>`
return new NextResponse(sitemap, {
status: 200,
headers: {
'Content-Type': 'application/xml',
'Cache-Control': 'public, s-maxage=3600, stale-while-revalidate',
},
})
}
メリット:
- 完全にコントロール可能
- リアルタイム生成
- 複雑なロジックを追加できる
デメリット:
- XML 形式を自分で書く必要
- パフォーマンスは自己責任
- キャッシュも手動対応
3 方式の比較
| 方法 | 向いている場面 | 難易度 | 柔軟性 | おすすめ度 |
|---|---|---|---|---|
| App Router 標準 | 小規模静的サイト | ⭐ | ⭐⭐ | ⭐⭐⭐⭐ |
| next-sitemap | 中〜大規模プロジェクト | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| API ルート | 極限カスタマイズ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
自分のプロジェクトの多くは next-sitemap を使っています。一度設定すれば放置でき、機能も十分だからです。
動的ルート実践:ブログ記事の Sitemap
最もよくあるシーン——ブログ、商品ページ、ユーザーページなど、動的コンテンツを Sitemap にどう載せるか。
App Router 標準方式を使う
// app/sitemap.ts
import { MetadataRoute } from 'next'
import { getAllPosts } from '@/lib/posts'
export default async function sitemap(): MetadataRoute.Sitemap {
// 静的ページ
const staticPages = [
{
url: 'https://yourdomain.com',
lastModified: new Date(),
changeFrequency: 'yearly' as const,
priority: 1,
},
{
url: 'https://yourdomain.com/about',
lastModified: new Date(),
changeFrequency: 'monthly' as const,
priority: 0.8,
},
]
// 動的にすべての記事を取得
const posts = await getAllPosts()
const postPages = posts.map(post => ({
url: `https://yourdomain.com/blog/${post.slug}`,
lastModified: new Date(post.updatedAt),
changeFrequency: 'weekly' as const,
priority: 0.7,
}))
return [...staticPages, ...postPages]
}
// 再検証時間を設定(ISR)
export const revalidate = 3600 // 1 時間ごとに再生成
ポイント:
changeFrequencyとpriorityにはas const型アサーションが必要export const revalidateでインクリメンタル静的再生成(ISR)を有効化lastModifiedは記事の実際の更新日時を使うのがベスト
大規模サイト:50,000 URL を超える場合
Google の仕様では 1 つの Sitemap 最大 50,000 URL。超える場合は複数に分割します。
generateSitemaps 関数を使います:
// app/sitemap.ts
import { MetadataRoute } from 'next'
// 複数 Sitemap を生成
export async function generateSitemaps() {
const totalPosts = await getTotalPostsCount()
const sitemapsCount = Math.ceil(totalPosts / 50000)
return Array.from({ length: sitemapsCount }, (_, i) => ({
id: i,
}))
}
// 各 Sitemap の内容を生成
export default async function sitemap({
id,
}: {
id: number
}): Promise<MetadataRoute.Sitemap> {
const start = id * 50000
const end = start + 50000
const posts = await getPosts(start, end)
return posts.map(post => ({
url: `https://yourdomain.com/blog/${post.slug}`,
lastModified: new Date(post.updatedAt),
priority: 0.7,
}))
}
生成される Sitemap:
sitemap/0.xmlsitemap/1.xmlsitemap/2.xml- …
Next.js が自動的に sitemap.xml インデックスファイルを生成し、すべての子 Sitemap へのリンクを含めます。
robots.txt の完全設定
基本設定例
最もシンプルな robots.txt:
# すべてのクローラーにすべてのコンテンツのクロールを許可
User-agent: *
Allow: /
# Sitemap の場所を指定
Sitemap: https://yourdomain.com/sitemap.xml
実際のプロジェクトでは、もう少し細かく設定します:
User-agent: *
Allow: /
# これらのディレクトリのクロールを禁止
Disallow: /_next/
Disallow: /api/
Disallow: /admin/
Disallow: /dashboard/
# 特定ファイルタイプのクロールを禁止
Disallow: /*.json$
Disallow: /*.xml$
Disallow: /*?* # クエリパラメータ付き URL
# Sitemap を指定
Sitemap: https://yourdomain.com/sitemap.xml
補足:
/_next/:Next.js のビルドファイル。検索エンジンがクロールする必要なし/api/:API エンドポイントはインデックス不要/admin/と/dashboard/:管理画面は当然インデックス不可/*.json$:JSON ファイルはインデックス不要- Sitemap 行は重要:忘れずに追加。検索エンジンが Sitemap の場所を知るため
Next.js で robots.txt を動的生成
App Router では robots.ts を使います:
// app/robots.ts
import { MetadataRoute } from 'next'
export default function robots(): MetadataRoute.Robots {
const baseUrl = 'https://yourdomain.com'
// 開発環境ではすべてのクローラーを禁止
if (process.env.NODE_ENV === 'development') {
return {
rules: {
userAgent: '*',
disallow: '/',
},
}
}
// 本番環境の設定
return {
rules: [
{
userAgent: '*',
allow: '/',
disallow: [
'/_next/',
'/api/',
'/admin/',
'/dashboard/',
],
},
{
userAgent: 'GPTBot', // OpenAI クローラーを禁止
disallow: ['/'],
},
],
sitemap: `${baseUrl}/sitemap.xml`,
}
}
マルチ環境設定のメリット:
開発・プレビュー環境は検索エンジンにインデックスされるべきではありません。環境変数で制御すれば、テストコンテンツのインデックスを防げます。
ここで強調したいのは、本番と開発で同じ設定ファイルを使うのは重大なリスクだということ。こう設定することをおすすめします:
// app/robots.ts
import { MetadataRoute } from 'next'
export default function robots(): MetadataRoute.Robots {
const baseUrl = process.env.NEXT_PUBLIC_SITE_URL || 'https://yourdomain.com'
const isProduction = process.env.NODE_ENV === 'production'
const isDeployPreview = process.env.NEXT_PUBLIC_VERCEL_ENV === 'preview'
// 非本番環境:クローラーを完全禁止
if (!isProduction || isDeployPreview) {
return {
rules: {
userAgent: '*',
disallow: '/',
},
}
}
// 本番環境のみクローラーを許可
return {
rules: [
{
userAgent: '*',
allow: '/',
disallow: [
'/_next/',
'/api/',
'/admin/',
'/dashboard/',
'/*.json$',
],
},
{
userAgent: 'GPTBot',
disallow: ['/'],
},
],
sitemap: `${baseUrl}/sitemap.xml`,
}
}
これで「テストコンテンツが誤ってインデックスされる」「本番が誤ってブロックされる」の両方を防げます。
よくあるミスと回避策
ミス 1:サイト全体を誤ってブロック
# ❌ 誤った書き方
User-agent: *
Disallow: /
こう書くとサイト全体がブロックされます。正しい書き方:
# ✅ 正しい書き方
User-agent: *
Allow: /
Disallow: /admin/
ミス 2:Sitemap 参照の記載忘れ
Sitemap を設定しても、robots.txt に宣言を忘れると、検索エンジンが Sitemap を見つけられません。
# ❌ この行がない
Sitemap: https://yourdomain.com/sitemap.xml
ミス 3:パス形式の誤り
# ❌ 誤り:パスが / で始まっていない
Disallow: _next/
# ✅ 正しい:パスは / で始める
Disallow: /_next/
ミス 4:過度な制限
# ❌ 過度な制限:画像までブロック
Disallow: /*.jpg$
Disallow: /*.png$
画像もコンテンツの一部。特別な理由がなければクローラーに取得させましょう。
テスト方法:
https://yourdomain.com/robots.txtにアクセスして内容を確認- Google Search Console の robots.txt テストツールを使う
- 特定 URL がクロール許可されているかテスト
Google Search Console 連携と検証
Sitemap と robots.txt を設定したら、Google Search Console に送信する必要があります。Google がより早くサイトを発見・インデックスできます。
Search Console にサイトを追加
- Google Search Console にアクセス
- 「プロパティを追加」をクリック
- 「ドメイン」または「URL プレフィックス」で確認
DNS 確認を推奨:
- ドメインプロバイダーで TXT レコードを追加
- 数分待って DNS が反映
- Search Console に戻って確認
または HTML ファイル確認:
public ディレクトリに Google が提供する確認ファイル(例:google1234567890abcdef.html)を配置。
Sitemap を送信
確認完了後:
- 左メニューの「サイトマップ」をクリック
- Sitemap URL を入力:
sitemap.xml - 「送信」をクリック
待ち時間:
- 送信直後に処理されるわけではない
- 通常 1〜7 日でクロール開始
- Search Console でクロールステータスを確認可能
よくあるエラーのトラブルシューティング
エラー 1:「Sitemap を読み取れませんでした」
最もよくある問題。考えられる原因:
原因 1:Middleware が Googlebot をブロック
Next.js Middleware で認証を使っていると、Googlebot もブロックされることがあります。
解決策:
// middleware.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'
export function middleware(request: NextRequest) {
const { pathname } = request.nextUrl
const userAgent = request.headers.get('user-agent') || ''
// 検索エンジンクローラーか判定
const isBot = /googlebot|bingbot|slurp|duckduckbot|baiduspider|yandexbot/i.test(
userAgent
)
// Sitemap と robots.txt は全員(クローラー含む)にアクセス許可
if (
pathname === '/robots.txt' ||
pathname === '/sitemap.xml' ||
pathname.startsWith('/sitemap-')
) {
return NextResponse.next()
}
// クローラーなら全体を通す
if (isBot) {
return NextResponse.next()
}
// 通常ユーザーの認証ロジック
const token = request.cookies.get('session-token')
if (!token && pathname.startsWith('/dashboard')) {
return NextResponse.redirect(new URL('/login', request.url))
}
return NextResponse.next()
}
export const config = {
matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
}
この設定で、クローラーは Sitemap と robots.txt に正常アクセスでき、認証ロジックは通常ユーザーに引き続き適用されます。
原因 2:キャッシュ問題
Google Search Console は失敗した取得試行をキャッシュします。問題を修正しても「取得できませんでした」と表示され続けることがあります。
解決策:
- Sitemap URL にタイムスタンプパラメータを追加:
sitemap.xml?v=20231220 - 数日待って Google の再クロールを待つ
- または古い Sitemap 送信を削除し、新しく再送信
原因 3:XML 形式エラー
Sitemap の XML 形式が正しいか確認:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://yourdomain.com</loc>
<lastmod>2024-12-20</lastmod>
</url>
</urlset>
注意:
- 1 行目の XML 宣言は
<?xmlで始める(<xmlではない) lastmod形式は ISO 8601(YYYY-MM-DD または完全タイムスタンプ)
オンライン XML 検証ツールで形式を確認できます。
エラー 2:「送信済みだがインデックスされない」
Sitemap 送信は成功したのに、ページがインデックスされない。考えられる原因:
- robots.txt がページをブロック:robots.txt の誤設定を確認
- ページ品質の問題:コンテンツが薄い、重複、低品質と判断される
- サイトが新しすぎる:新規サイトは信頼構築に時間がかかる
- 被リンクがない:外部リンクがゼロだとインデックスが難しい
解決策:
- Google Search Console の「URL 検査」ツールで Google の見方を確認
- ページに
noindexmeta タグがないか確認 - ページコンテンツに実質的な価値があるか確認(300 字以上推奨)
- 被リンク獲得を試みる
インデックス状況の監視
送信後、定期的にインデックス状況を確認:
- カバレッジレポート:どのページがインデックスされ、問題があるか
- インデックス状況:総インデックスページ数
- Sitemap ステータス:Sitemap が正常に読み取られているか
インデックスされていないページがあれば、「URL 検査」ツールで再クロールをリクエスト。
実践事例:自分が踏んだ落とし穴
ここで、実際の話を共有します。昨年、3 か月前に公開された EC サイトを引き継ぎましたが、Google 検索ではページが一切ヒットしませんでした。
まず robots.txt を確認——結果は:
User-agent: *
Disallow: /
サイト全体がブロックされていました。しかも 3 か月間。この設定、誰が変えたのか部署した同僚は「自分じゃない」と。調査の末、テスト環境のクロール防止のために本番でも同じ設定を使っていた臨時開発者が原因でした。
その後の 1 か月は辛かった。誤った robots.txt を削除し、正しい Sitemap を生成して Search Console に送信——あとは待つだけ。1 週間後、ようやく検索結果にサイトが現れ始めました。
それ以来、デプロイ前に必ず Sitemap と robots.txt を確認し、環境ごとに設定を分ける習慣がつきました。
もう一つは Middleware の問題。JWT 認証 Middleware を追加したら Googlebot がブロックされ、Search Console がずっと「Sitemap を読み取れませんでした」と表示。Sitemap 形式の問題かと半日悩んだ末、Middleware が原因だと判明しました。
SEO はシンプルに見えて、細部が命。小さな設定ミス一つで、サイトが検索結果から消えることもあります。
問題のトラブルシューティングと最適化
デプロイ前チェックリスト
デプロイ前に、このリストで確認:
- Sitemap に正常アクセスできる(
https://yourdomain.com/sitemap.xml) - Sitemap の XML 形式が正しい
- robots.txt に正常アクセスできる(
https://yourdomain.com/robots.txt) - robots.txt が重要ページをブロックしていない
- robots.txt に Sitemap 参照が含まれている
- Sitemap にすべての重要ページが含まれている
- 動的ページが Sitemap に自動更新される
- Search Console でサイト確認が完了している
- Sitemap を Search Console に送信済み
- Middleware が検索エンジンクローラーをブロックしていない
パフォーマンス最適化
Sitemap キャッシュ戦略
API ルートで Sitemap を生成する場合、キャッシュを設定:
// app/sitemap.xml/route.ts
export const revalidate = 3600 // 1 時間キャッシュ
export async function GET() {
// ...Sitemap 生成
return new NextResponse(sitemap, {
headers: {
'Content-Type': 'application/xml',
'Cache-Control': 'public, s-maxage=3600, stale-while-revalidate',
},
})
}
増分更新 vs 全量再構築
- 小規模サイト(1,000 ページ未満):毎回全量再構築でシンプル
- 中規模サイト(1,000〜10,000 ページ):ISR で時間単位または日単位に再検証
- 大規模サイト(10,000 ページ超):複数 Sitemap に分割し、変更部分のみ増分更新
CDN 設定
Cloudflare など CDN を使っている場合、Sitemap と robots.txt もキャッシュ対象に:
- 適切な Cache-Control ヘッダーを設定
- CDN が XML と TXT ファイルをキャッシュできるようにする
- コンテンツ更新後は CDN キャッシュをパージ
まとめ
設定フローを振り返ると:
-
Sitemap 生成方式の選択:
- 小規模プロジェクト → App Router 標準方式
- 中〜大規模プロジェクト → next-sitemap
- 極限カスタマイズ → API ルート
-
robots.txt の設定:
- インデックス不要なディレクトリをブロック
- Sitemap 参照を追加
- 開発環境ではクロール禁止
-
Google Search Console への送信:
- サイト所有権を確認
- Sitemap を送信
- インデックス状況を監視
-
よくある問題のトラブルシューティング:
- Middleware でクローラーをブロックしない
- XML 形式を正しく
- キャッシュ問題はタイムスタンプパラメータで対応
Sitemap と robots.txt の設定は難しい技術ではありませんが、細部が多く、少しの不注意で問題になります。自分も初回設定で多くの落とし穴を踏み、robots.txt でサイト全体を 1 か月ブロックして気づきませんでした。
今は新プロジェクト公開のたびにこのチェックリストで確認し、ほぼ問題なく運用できています。この記事が、あなたのサイトを検索エンジンに素早くインデックスする一助になれば幸いです。
他に遭遇した問題や経験があれば、コメントでぜひ共有してください!
Next.js Sitemap と robots.txt 設定の完全フロー
ファイル作成から Google Search Console への登録までの SEO 設定手順
⏱️ 目安時間: 1 時間
- 1
ステップ1: 動的 Sitemap を作成する
app/sitemap.ts を作成:
• default 関数をエクスポートし、sitemap 配列を返す
• 各エントリに url、lastModified、changeFrequency、priority を含める
• async 関数で動的データを取得可能
例:
export default async function sitemap() {
const posts = await getPosts()
return [
{
url: 'https://example.com',
lastModified: new Date(),
changeFrequency: 'yearly',
priority: 1,
},
...posts.map(post => ({
url: `https://example.com/posts/${post.id}`,
lastModified: post.updatedAt,
changeFrequency: 'weekly',
priority: 0.8,
}))
]
} - 2
ステップ2: robots.txt を作成する
app/robots.ts を作成:
• default 関数をエクスポートし、robots 設定を返す
• クローラーの許可/禁止を設定
• Sitemap パスを指定
例:
export default function robots() {
return {
rules: {
userAgent: '*',
allow: '/',
disallow: ['/api/', '/admin/'],
},
sitemap: 'https://example.com/sitemap.xml',
}
}
注意:サイト全体を誤って disallow しないこと - 3
ステップ3: 生成ファイルを検証する
生成結果を確認:
• /sitemap.xml にアクセスして Sitemap を確認
• /robots.txt にアクセスして robots 設定を確認
• すべてのページが Sitemap に含まれているか確認
• robots.txt がサイト全体を誤ってブロックしていないか確認
検証ツール:
• Google Search Console
• オンライン XML バリデータ
• ブラウザで直接アクセスして形式を確認 - 4
ステップ4: Google Search Console に送信する
手順:
1. Google Search Console アカウントを登録
2. サイトプロパティを追加(所有権を確認)
3. sitemap.xml の URL を送信
4. robots.txt がクロールを許可しているか確認
確認方法:
• HTML ファイルのアップロード
• HTML タグによる確認
• DNS レコードによる確認
• Google Analytics による確認 - 5
ステップ5: 動的ページを処理する
動的ルートの対応:
• sitemap.ts ですべての動的ページデータを取得
• 各動的ページの URL を生成
• 正しい lastModified 時刻を設定
例:
const products = await getAllProducts()
const productUrls = products.map(product => ({
url: `https://example.com/products/${product.id}`,
lastModified: product.updatedAt,
changeFrequency: 'weekly' as const,
priority: 0.8,
})) - 6
ステップ6: 監視と最適化
継続的な監視:
• Google Search Console を定期的に確認
• Sitemap 送信ステータスを確認
• robots.txt がクロールに影響していないか確認
• インデックス状況をモニタリング
最適化のヒント:
• 新ページは Sitemap を随時更新
• 適切な changeFrequency を設定
• 重要ページには高い priority を設定
• robots.txt 設定を定期的に確認
FAQ
Sitemap は必須ですか?
動的ルートの Sitemap はどう生成しますか?
robots.txt の設定ミスはどんな影響がありますか?
Sitemap 送信後、Google がクロールするまでどれくらいかかりますか?
Sitemap が正しいかどう検証しますか?
robots.txt で特定のクローラーをブロックできますか?
Sitemap にすべてのページを含める必要がありますか?
6分で読めます · 公開日: 2025年12月20日 · 更新日: 2026年6月8日
Next.js 完全ガイド
検索からこのページに来た場合は、前後の記事もあわせて読むと同じテーマの理解がかなり早く深まります。
前の記事
Next.js 本番環境モニタリング完全ガイド:Sentry 連携・ログ管理・アラート設定の実践
Next.js 本番モニタリングを一から構築する実践ガイド。Sentry 連携、ログ管理、パフォーマンス監視、アラート設定まで網羅。App Router 向け設定例とコピーして使えるコードテンプレート付き。
第 42 / 47 記事
次の記事
Next.js + Tailwind CSS ベストプラクティス:設定からダークモードまでの完全ガイド(2025年版)
2025年最新の Next.js + Tailwind CSS v4 実践ガイド。クラス名の肥大化、カスタムテーマ設定、ダークモード実装、パフォーマンス最適化を解説。500KB から 50KB まで削減した実例と完全なコード例付き。
第 44 / 47 記事
関連記事
Next.js App Router 入門ガイド:コア概念と基本操作を解説
Next.js App Router 入門ガイド:コア概念と基本操作を解説
Next.js 15 実践:週末で本番級ブログシステムを構築した方法
Next.js 15 実践:週末で本番級ブログシステムを構築した方法
Next.js Middleware 実践ガイド:パスマッチ、Edge Runtime 制限とよくある落とし穴
コメント
GitHubアカウントでログインしてコメントできます