WordPress 404问题需从服务器响应、路由机制、模板渲染三层协同解决：统一用pre_get_posts固定posts_per_page、Nginx/Apache补全try_files路由、404.php首行强制http_response_code(404)，并结合日志定位真实来源。

WordPress 的 404 页面不是靠“插件一装就灵”或“主题自带即可靠”来保障体验的。真正稳定、可控、可维护的 404 处理，需要从服务器响应、WordPress 路由机制、模板渲染三层协同入手——尤其当站点已存在自定义查询、分页逻辑或重写规则时，零散配置极易冲突，导致第3页起404、静态资源误判404、或错误页面不返回404状态码等隐性问题。

统一入口：用 pre_get_posts 拦截并标准化主循环查询

很多404异常源于首页/分类页中手动设置 posts_per_page 不一致（如首页7篇、其余页6篇），或在 WP_Query 中误用 offset。这类操作绕过 WordPress 分页计算逻辑，使 paged 参数与数据库偏移严重错位。

• 在 functions.php 或专用钩子文件中，用 pre_get_posts 统一修正主循环参数，禁用动态 offset
• 确保 posts_per_page 全局恒定（例如固定为6），首页样式差异改用 CSS 类或模板条件判断（如 is_home() && !is_paged()）
• 对非主循环的自定义查询，也必须显式传入 'paged' => get_query_var('paged') 和固定 posts_per_page

路由兜底：Nginx/Apache 层补全前端路由缺失

单页应用（SPA）式主题、AJAX 导航或自定义伪静态结构，常出现“页面能打开，但直接访问子路径返回404”的问题。这是因为服务器未将深层路径全部指向 index.php，导致 PHP 层根本没机会处理。

在SEO发布前，从路由清单生成XML网站地图和robots.txt

当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。

下载

• Apache 用户：确认 .htaccess 含完整 WordPress 重写规则，特别是末尾的 RewriteRule . /index.php [L]
• Nginx 用户（含宝塔）：在站点配置中，location / 块内添加 try_files $uri $uri/ /index.php?$args;
• 避免仅靠 ErrorDocument 404 补救——它只在服务器层判定404后才触发，无法覆盖路由未接管场景

状态码可信：确保自定义404模板真实返回HTTP 404

很多主题或插件的“404页面”只是视觉替换，响应头仍是200 OK。这会误导搜索引擎、破坏缓存策略，甚至影响CDN行为。

• 在 404.php 模板最顶部第一行加入：<?php http_response_code(404); ?>（无任何空白或输出）
• 使用浏览器开发者工具 → Network 标签，刷新一个不存在的路径，检查响应状态码是否确为 404
• 若使用缓存插件（如 WP Super Cache），需确认其未对404页面做静态缓存；建议在插件设置中排除 404.php 或启用“跳过404缓存”选项

异常归因：用日志定位真实404来源

盲目优化页面设计不如先搞清谁在触发404。大量无效请求来自失效外链、爬虫试探、旧版APP接口或JS路由错误，而非用户主动访问。

• 开启 Nginx 错误日志（error_log /www/wwwlogs/your-site.error.log warn;），筛选 "404" 关键词定位高频路径
• 在 wp-config.php 中临时启用 define('WP_DEBUG_LOG', true);，配合插件（如 Query Monitor）查看哪些钩子或查询中途失败
• 对高频404路径（如 /wp-content/plugins/xxx/old-script.js），优先用 Nginx rewrite 重定向到有效资源，而非放任其进入PHP流程