从 Next.js 到 GitHub Pages:个人作品集网站的静态部署、自定义域名与搜索收录实践

📅 2026/7/17 21:05:20 👁️ 阅读次数 📝 编程学习
从 Next.js 到 GitHub Pages:个人作品集网站的静态部署、自定义域名与搜索收录实践

Next.js 静态导出与 GitHub Pages 自动部署:自定义域名、HTTPS 和百度验证实战

前言

对于个人作品展示、项目文档、技术博客等以内容展示为主的网站,如果暂时不需要数据库、用户登录、文件上传和服务端接口,可以将 Next.js 项目导出为静态文件,并部署到 GitHub Pages。

这种部署方式不需要单独维护服务器,同时还能实现:

  • GitHub Actions 自动构建与发布;
  • 自定义域名访问;
  • 自动配置 HTTPS;
  • 多页面静态路由;
  • JavaScript 动画和前端交互;
  • 百度搜索资源平台验证;
  • robots.txtsitemap.xml配置。

本文以一个实际的 Next.js 静态网站为例,记录从项目配置到公开上线的完整过程,并重点分析部署中容易遇到的 DNS、404 和搜索验证问题。


一、整体部署架构

本次使用的部署流程如下:

本地 Next.js 项目 ↓ 提交到 GitHub 仓库 ↓ 触发 GitHub Actions ↓ 安装依赖并执行构建 ↓ 生成 out 静态目录 ↓ 上传 GitHub Pages 部署产物 ↓ 通过自定义域名访问

这种方案适合:

  • 个人作品集;
  • 企业展示页;
  • 产品介绍页;
  • 项目文档;
  • 静态博客;
  • 活动专题页面。

不适合直接运行以下功能:

  • Node.js 服务端接口;
  • 数据库实时读写;
  • 用户登录和注册;
  • 后台内容管理;
  • 服务端文件上传;
  • 依赖运行时服务器的动态渲染;
  • 无法在构建阶段确定参数的动态页面。

因此,在改造之前,应先确认项目是否可以静态化。


二、配置 Next.js 静态导出

在 Next.js 配置文件中启用静态导出。

如果项目使用next.config.js,可以参考:

/** @type {import('next').NextConfig} */constnextConfig={output:"export",trailingSlash:true,images:{unoptimized:true,},};module.exports=nextConfig;

如果项目使用next.config.mjs

constnextConfig={output:"export",trailingSlash:true,images:{unoptimized:true,},};exportdefaultnextConfig;

1.output: "export"

该配置会让 Next.js 在构建完成后生成静态 HTML、CSS 和 JavaScript 文件。

构建产物默认位于:

out/

2.trailingSlash: true

启用后,页面会输出为目录形式。

例如:

/about/

对应的文件为:

out/about/index.html

这种路径形式在 GitHub Pages 等静态托管平台中通常更加稳定。

3.images.unoptimized: true

Next.js 默认图片优化功能需要服务端参与。

GitHub Pages 只能托管静态资源,因此需要关闭服务端图片优化,或者改用普通<img>标签及提前压缩好的图片。


三、处理动态路由

如果项目存在动态路由,例如:

app/projects/[slug]/page.tsx

静态导出时,需要提前告诉 Next.js 应当生成哪些页面。

可以通过generateStaticParams提供参数:

constprojects=[{slug:"project-a",title:"项目 A",},{slug:"project-b",title:"项目 B",},];exportfunctiongenerateStaticParams(){returnprojects.map((project)=>({slug:project.slug,}));}

最终会生成:

out/projects/project-a/index.html out/projects/project-b/index.html

如果动态参数只能在用户访问时从服务器获取,就不适合直接导出到 GitHub Pages。


四、本地执行构建测试

完成配置后,先不要立即推送。

在本地执行:

npminstallnpmrun build

如果使用锁文件并希望严格按照锁定版本安装,可以使用:

npmcinpmrun build

构建成功后,应出现:

out/

典型目录结构:

out/ ├── index.html ├── 404.html ├── about/ │ └── index.html ├── projects/ │ ├── project-a/ │ │ └── index.html │ └── project-b/ │ └── index.html ├── _next/ ├── images/ ├── robots.txt └── sitemap.xml

部署前建议重点检查:

  1. out/index.html是否存在;
  2. 所有项目详情页是否生成;
  3. 图片路径是否正确;
  4. CSS 和 JavaScript 是否正常;
  5. 刷新二级页面是否出现 404;
  6. 页面是否仍然依赖服务端接口;
  7. 页面是否包含错误的绝对路径;
  8. public中的文件是否复制到out根目录。

五、创建 GitHub Pages 自动部署工作流

在项目中创建文件:

.github/workflows/deploy.yml

写入:

name:Deploy Next.js site to GitHub Pageson:push:branches:-mainworkflow_dispatch:permissions:contents:readpages:writeid-token:writeconcurrency:group:github-pagescancel-in-progress:falsejobs:build:runs-on:ubuntu-lateststeps:-name:Checkout repositoryuses:actions/checkout@v4-name:Setup Node.jsuses:actions/setup-node@v4with:node-version:20cache:npm-name:Install dependenciesrun:npm ci-name:Configure GitHub Pagesuses:actions/configure-pages@v5-name:Build Next.js projectrun:npm run build-name:Upload static siteuses:actions/upload-pages-artifact@v4with:path:./outdeploy:needs:buildruns-on:ubuntu-latestenvironment:name:github-pagesurl:${{steps.deployment.outputs.page_url}}steps:-name:Deploy to GitHub Pagesid:deploymentuses:actions/deploy-pages@v4

工作流的核心过程是:

拉取代码 → 安装 Node.js → 安装依赖 → 执行 npm run build → 上传 out 目录 → 发布到 GitHub Pages

需要特别注意:

path:./out

这里必须指向真正的静态构建产物。

如果错误上传.next、项目根目录或其他文件夹,线上网站可能出现空白页、404 或资源加载失败。


六、在 GitHub 中启用 Pages

进入仓库:

设置 → GitHub Pages

在“构建和部署”的来源中选择:

GitHub Actions

然后将代码推送到main分支:

gitadd.gitcommit-m"configure GitHub Pages deployment"gitpush origin main

进入仓库中的:

操作

查看工作流状态。

绿色表示部署成功,红色表示失败。

如果失败,可以点开具体步骤查看日志。

常见错误包括:

  • npm ci找不到锁文件;
  • Node.js 版本不兼容;
  • TypeScript 编译失败;
  • ESLint 检查失败;
  • 动态路由没有生成静态参数;
  • 图片优化功能与静态导出冲突;
  • 构建完成但没有生成out目录。

七、配置自定义域名

GitHub Pages 默认地址通常类似:

https://username.github.io

如果已经购买独立域名,可以在:

仓库 → 设置 → GitHub Pages → 自定义域

填写:

www.example.com

然后到域名服务商的 DNS 控制台添加 CNAME 记录:

记录类型:CNAME 主机记录:www 记录值:username.github.io

注意:

  • 记录值不要填写https://
  • 不要在结尾添加/
  • 同一个www记录不能同时存在冲突的 A 记录;
  • DNS 生效需要一定时间;
  • GitHub 会自动检查域名配置。

正确关系如下:

www.example.com ↓ username.github.io

八、配置不带www的根域名

如果还希望下面这个地址能够访问:

example.com

需要为根域名添加解析。

根域名的主机记录通常填写:

@

然后添加 GitHub Pages 的 A 记录地址。

结构如下:

记录类型:A 主机记录:@ 记录值:GitHub Pages 官方提供的 IP

最终建议统一到一个正式域名,例如:

https://www.example.com

这样可以避免:

https://example.com https://www.example.com

被搜索引擎识别为两个不同的网站版本。

网站中的以下内容也应保持一致:

  • canonical;
  • sitemap;
  • Open Graph;
  • JSON-LD;
  • 站内链接;
  • robots.txt。

九、开启强制 HTTPS

DNS 检查成功后,GitHub Pages 会为自定义域名签发 HTTPS 证书。

证书生成后,可以在 Pages 设置中勾选:

强制 HTTPS

启用后:

http://www.example.com

会自动跳转到:

https://www.example.com

如果“强制 HTTPS”暂时无法勾选,通常是以下原因:

  • DNS 尚未完全生效;
  • CNAME 配置错误;
  • 根域名存在冲突记录;
  • GitHub 仍在签发证书;
  • 自定义域名刚刚变更。

此时不要频繁删除和重新添加域名,否则可能延长证书签发时间。


十、配置百度搜索资源平台文件验证

网站部署完成后,可以添加到百度搜索资源平台。

文件验证通常会提供一个 HTML 文件,例如:

baidu_verify_codeva-xxxxxxxx.html

对于 Next.js 静态导出项目,应将文件放入:

public/

目录结构示例:

project/ ├── public/ │ ├── images/ │ ├── robots.txt │ └── baidu_verify_codeva-xxxxxxxx.html ├── app/ ├── package.json └── next.config.js

执行构建后,文件应出现在:

out/baidu_verify_codeva-xxxxxxxx.html

部署成功后,可以通过以下地址访问:

https://www.example.com/baidu_verify_codeva-xxxxxxxx.html

只有该地址能够直接打开,百度才能完成验证。

验证成功后,不要删除这个文件。


十一、百度验证文件出现 404 的原因

在实际部署中,经常会出现:

本地 public 中存在验证文件 但是线上访问返回 404

这通常不是百度的问题,而是文件没有进入最终部署产物。

1. 检查构建产物

执行:

npmrun build

然后检查:

out/baidu_verify_codeva-xxxxxxxx.html

是否存在。

如果public中有文件,但out中没有,说明构建配置存在问题。

2. 检查文件名

文件名必须完全一致,包括:

  • 字母大小写;
  • 连字符;
  • 下划线;
  • 扩展名。

GitHub Pages 使用 Linux 文件系统,文件名大小写敏感。

例如:

Verify.html verify.html

会被视为两个不同文件。

3. 检查最新提交是否推送

执行:

gitstatusgitlog-1gitremote-v

确认验证文件已经提交:

gitaddpublic/baidu_verify_codeva-xxxxxxxx.htmlgitcommit-m"add Baidu verification file"gitpush origin main

4. 检查 GitHub Actions 状态

进入:

仓库 → 操作

确认最新工作流已经成功。

本地文件存在,并不代表远程仓库和线上网站已经更新。

5. 检查上传目录

工作流必须上传:

path:./out

如果上传目录错误,即使构建成功,验证文件也不会出现在网站根目录。

6. 等待部署节点更新

GitHub Actions 显示成功后,线上节点仍可能存在短暂延迟。

可以等待几分钟,再使用无痕窗口访问:

https://www.example.com/baidu_verify_codeva-xxxxxxxx.html

也可以临时增加查询参数排除浏览器缓存:

https://www.example.com/baidu_verify_codeva-xxxxxxxx.html?v=2

十二、配置 robots.txt

public目录创建:

robots.txt

内容示例:

User-agent: * Allow: / Sitemap: https://www.example.com/sitemap.xml

构建后应能够访问:

https://www.example.com/robots.txt

需要避免出现:

Disallow: /

该配置会阻止搜索引擎抓取整个网站。

还需要检查正式页面中是否存在:

<metaname="robots"content="noindex"/>

如果线上页面包含noindex,搜索引擎可能不会将页面加入索引。


十三、创建 sitemap.xml

网站地图用于列出网站中的重要页面。

示例:

<?xml version="1.0" encoding="UTF-8"?><urlsetxmlns="http://www.sitemaps.org/schemas/sitemap/0.9"><url><loc>https://www.example.com/</loc></url><url><loc>https://www.example.com/about/</loc></url><url><loc>https://www.example.com/projects/project-a/</loc></url><url><loc>https://www.example.com/projects/project-b/</loc></url></urlset>

将文件放入:

public/sitemap.xml

线上地址:

https://www.example.com/sitemap.xml

然后可以在百度搜索资源平台的普通收录功能中提交该地址。

网站地图的作用是帮助搜索引擎发现页面,不代表提交后一定立即收录。


十四、添加部署前检查脚本

为了避免后续修改时误删验证文件、Sitemap 或 robots 文件,可以在构建完成后增加自动检查。

创建:

scripts/check-static-files.mjs

内容:

importfsfrom"node:fs";importpathfrom"node:path";constoutputDirectory=path.join(process.cwd(),"out");constrequiredFiles=["index.html","robots.txt","sitemap.xml","baidu_verify_codeva-xxxxxxxx.html",];constmissingFiles=[];for(constfileofrequiredFiles){constfilePath=path.join(outputDirectory,file);if(!fs.existsSync(filePath)){missingFiles.push(file);}}if(missingFiles.length>0){console.error("静态构建检查失败,缺少以下文件:");for(constfileofmissingFiles){console.error(`-${file}`);}process.exit(1);}console.log("静态构建检查通过");

然后在package.json中增加:

{"scripts":{"build":"next build","check:static":"node scripts/check-static-files.mjs"}}

GitHub Actions 中增加:

-name:Build Next.js projectrun:npm run build-name:Validate static filesrun:npm run check:static

这样,如果后续构建缺少必要文件,工作流会停止部署,避免错误版本上线。


十五、常见问题总结

1. 静态网站还能使用动画吗?

可以。

静态部署仍然能够运行浏览器端 JavaScript,因此滚动动画、轮播、弹窗、菜单、卡片交互等功能都可以保留。

2. 为什么二级页面刷新后出现 404?

应检查:

  • 是否启用了trailingSlash
  • 页面是否真正生成到out
  • 动态路由是否配置了静态参数;
  • 内部链接是否指向正确路径。

3. 为什么图片部署后不显示?

常见原因包括:

  • 使用了错误的绝对路径;
  • 文件名大小写不一致;
  • 图片没有放在public
  • next/image仍然依赖服务端优化;
  • 构建后路径发生变化。

4. 为什么 DNS 检查一直失败?

应检查:

  • CNAME 是否指向正确地址;
  • 记录值是否误加https://
  • 是否存在同名 A 或 AAAA 记录;
  • DNS 是否尚未完全生效;
  • 自定义域名是否填写正确。

5. 为什么验证文件本地存在但线上 404?

重点检查:

public 文件 → out 构建产物 → Git 提交 → 远程 main 分支 → GitHub Actions → Pages 部署结果

任何一个环节没有完成,线上都可能访问不到。


十六、总结

将 Next.js 网站部署到 GitHub Pages,涉及的不只是执行一次构建。

完整流程包括:

  • 静态导出配置;
  • 动态路由处理;
  • 本地构建检查;
  • GitHub Actions 自动部署;
  • 自定义域名 DNS 配置;
  • HTTPS 证书签发;
  • 百度文件验证;
  • robots.txt 和 sitemap.xml;
  • 404 与构建产物排查;
  • 部署前自动检查。

对于内容展示型网站,这套方案可以在不维护独立服务器的情况下,获得稳定的自动部署和独立域名访问能力。

真正需要重点关注的是构建产物。

无论本地源代码看起来是否正确,最终线上网站实际发布的都是:

out/

因此,排查问题时应始终围绕:

源文件是否存在 → 构建产物是否存在 → 远程提交是否存在 → 工作流是否成功 → 线上文件是否可访问

建立清晰的检查链路后,大部分 GitHub Pages 部署问题都可以快速定位。