说实话，WordPress装好之后很多人第一件事就是闷头写文章、调主题，很少有人会认真看一眼后台"设置 → 固定链接"那个页面。直到某天你把文章链接发给朋友，发现地址栏里躺着一串/?p=123，才意识到事情不对劲。链接结构这件事，平时不显山不露水，但它决定了你每一篇文章的长期身份证，也直接影响了搜索引擎对你网站内容层次的理解。这个系列走到第4篇，前面几篇把环境、安装和基础设置都过了一遍，今天专门把"文章与链接结构"这块地基聊透，适合刚入门的新手，也适合准备从其他CMS迁到WordPress、或者正在为404头疼的站长。
1. 文章与页面：WordPress内容体系的两大基本盘
1.1 文章和页面的本质区别
很多新手会把"文章"和"页面"当成一回事，后台两个入口摆在那里，随便点一个就开始写。这是第一个需要纠正的认知：这两个东西从设计之初就不是一个物种。
文章（Post）是内容流。它有时间属性，有作者，有分类，有标签，会出现在首页的文章列表里，出现在日期归档里，出现在RSS订阅里。你写一篇"2025年装机配置推荐"，它是你博客时间线上的一个点；三个月后你更新一篇"2025年下半年配置调整"，两篇文章可以独立存在、互不遮蔽，读者可以通过分类目录一次性看全同一主题下的所有内容。文章的生命周期是流动的，它天然适合博客、新闻、教程这类持续产出的内容形态。
页面的定位是门面。关于我们、联系方式、服务介绍、隐私政策，这些内容不需要出现在时间流里，也不需要被打上分类标签，它们就是固定的、长期存在的"信息牌"。页面还支持父子层级，比如"服务介绍"下面挂"建站服务""维护服务"两个子页面，URL会自动生成层级关系，这在做企业站、产品站时非常实用。
这里的核心逻辑是：文章服务于"持续更新"，页面服务于"永恒存在"。内容规划的第一步，就是把你手头所有要写的东西分到这两个池子里。判断标准很简单——三个月后这条内容还会不会因为时效性而过时？如果会，放文章；如果不会，放页面。
1.2 一张表看懂文章与页面的差异
| 对比项 | 文章（Post） | 页面（Page） |
|---|---|---|
| 时间属性 | 有发布时间，按时间倒序排列 | 没有时间流概念，固定展示 |
| 列表展示 | 出现在首页、归档页、分类页 | 默认不出现在文章列表中 |
| 分类与标签 | 支持分类目录和标签 | 不支持分类和标签 |
| 层级结构 | 平铺，无父子关系 | 支持父子层级 |
| 作者信息 | 有作者，支持多作者站点 | 也有作者字段，但通常不作为展示重点 |
| 模板选择 | 使用文章模板（single.php） | 使用页面模板（page.php），还可选自定义模板 |
| 典型用途 | 博客文章、新闻、教程、案例 | 关于我们、联系页面、落地页、隐私政策 |
| URL倾向 | 常带slug、分类、日期 | 以层级路径为主，通常不带日期 |
这张表是我给客户做培训时必讲的内容。很多企业站的内容乱，根子不在排版，而在从一开始就把"产品介绍"这种应该做成页面或自定义文章类型的内容，用文章的方式发了一堆，结果首页列表越滚越长，分类页一团糟，访问者找不到想要的固定信息。
1.3 那些"看不见"的文章类型
WordPress内部其实把一切都当成post来管理，只是通过post_type字段区分类型。默认就有一堆：post（文章）、page（页面）、attachment（附件，你上传的每一张图片都是一条post记录）、revision（修订版本）、nav_menu_item（导航菜单项），还有WordPress 5.0之后默认启用的wp_block（可复用区块）等。
第三方插件和主题还能注册自定义文章类型（Custom Post Type，简称CPT），比如"产品""案例""作品集""课程"。这意味着什么？意味着链接结构不是你写一个URL那么简单，背后有一套统一的"文章类型 + 分类法 + 别名"的路由逻辑。比如你用CPT做了一个产品库，产品链接可能是/product/xxx/，而不是走文章那套/category/xxx/路径。理解了这个体系，后面所有关于URL的讨论才有了坐标系。
2. 固定链接结构：一篇文章的URL到底该怎么长
2.1 固定链接设置面板的常用选项
在后台"设置 → 固定链接"页面，WordPress给了几套预设结构，底部还有一个自定义结构输入框。不同结构的差异，直接决定了你整站URL的风格。
朴素结构（?p=123）是默认值。它的优势是零配置、任何服务器环境都能跑，不存在伪静态导致的404问题。代价是URL完全没有语义，访问者看到一串数字不知道内容是什么，搜索引擎对这个链接能获取的上下文信息也极少。如果只是本地测试，这个结构无所谓；但要做正式站，建议从第一天就换掉。
日期和名称型（/%year%/%monthnum%/%day%/%postname%/）是很多老博客的经典结构。它在URL里嵌入了发布日期，读者一眼能看出文章什么时候发的。这种结构适合新闻资讯站、日更站，因为日期本身就是信息的一部分。它的缺点是URL长，而且日期一旦写进URL，就永远改不掉——哪怕你一年后把这篇文章全面重写更新，URL里的日期还是旧的，等于每天都告诉搜索引擎和读者"这是老文章"。
月份和名称型（/%year%/%monthnum%/%postname%/）是上面那个结构的精简版，去掉了"日"，逻辑类似。文章名型（/%postname%/）是我个人最推荐的，URL最短，语义完全由自己控制。分类目录型（/%category%/%postname%/）会让URL自带分类层级，比如/news/tech-news/，但一旦你改了分类名称或层级，整站相关链接全要跟着变，后患无穷。
2.2 我为什么推荐直接用文章名型
从实战角度看，/%postname%/是性价比最高的选择，理由有三点。
第一，URL最短，没有冗余信息。同样的文章，/2025/06/wordpress-cache-plugin/和/wordpress-cache-plugin/相比，后者在地址栏、搜索结果展示、社交媒体分享时都更干净利落。
第二，URL完全由你控制。你可以把核心关键词放进slug里，让它对用户和搜索引擎都可读。比如一篇讲WordPress缓存的文章，slug设为wordpress-cache-plugin，任何人看到这个链接都能大致猜到内容主题。
第三，改版时最抗折腾。你用日期型结构，以后想换结构，所有老链接作废；你用分类型结构，分类改名就炸。文章名型只有slug一个变量，只要slug不变，链接就永远稳定。
带日期的结构并非一无是处，我之前给一个新闻类站点做方案时还是保留了日期型，因为新闻的时效性本身就是内容价值的一部分。但普通内容站，尤其是教程、知识库这类长期有效的文章，日期出现在URL里只会不断暗示"这篇文章已经过时了"。发布时间不等于内容的有效期，这个观念越早建立越好。
2.3 别忘了路径末尾的"尾巴"和后缀
有人喜欢给URL加.html后缀，觉得看起来像静态站、显得"正规"。技术上确实可以实现，在自定义结构里填/%postname%.html就行。但我不建议这么干。WordPress的URL体系是高度模块化的，一旦你用死后缀，后面接入自定义文章类型、某些插件生成的特殊页面时，URL风格很难统一，到处是奇怪的拼接。URL要的是稳定、可预测、可扩展，不是单纯的好看。
另外，后台固定链接页面底部还有两个独立设置：分类目录前缀和标签前缀。默认分别是category和tag，也就是分类页长这样/category/news/，标签页长这样/tag/wordpress/。如果你觉得默认前缀太长，可以改成短词，比如column、topic，这不算折腾，改完记得验证分类页和标签页都能正常打开。
3. 伪静态背后的重写机制：保存固定链接后变404是怎么回事
3.1 WordPress的URL解析流程
很多人保存固定链接设置后，兴冲冲去前台打开文章，迎面一个404，心里一凉。这不是WordPress坏了，而是你的Web服务器没有把"漂亮的URL"正确转交给WordPress处理。
理解这个问题，先要明白WordPress是怎么"认路"的。当你访问https://example.com/hello-world/时，服务器收到请求后，会按配置规则把这个请求交给站点根目录的index.php。WordPress拿到路径/hello-world/，去数据库里找别名（slug）等于hello-world的文章，找到就渲染，找不到就404。这个"把路径统一转交给index.php"的动作，就是所谓的伪静态（Rewrite）。它并没有真的把动态页面变成静态文件，只是让URL看起来像静态路径，内部依然是PHP在处理。
拿生活里的场景类比：你把所有信件都先寄到公司前台，前台看了收件人姓名再转交给具体同事。重写规则就是那个前台，它不关心信件内容，只负责按规则把信件分流。
3.2 Apache环境：.htaccess与mod_rewrite
Apache环境下去年保存固定链接后，WordPress会尝试往站点根目录的.htaccess文件里写入一套重写规则。如果目录允许写入，规则会生成这样一段代码：
# BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> # END WordPress规则的核心逻辑是：如果请求的路径不是真实存在的文件（!-f），也不是真实存在的目录（!-d），就全部交给index.php处理。
LAMP环境部署WordPress报404，绝大多数情况下是三个原因：一是.htaccess文件没生成或没写入成功，权限没给到；二是httpd.conf或虚拟主机配置里设置了AllowOverride None，导致.htaccess里的指令完全不生效；三是mod_rewrite模块没有启用。排查优先级依次是：模块是否启用、AllowOverride是否允许、.htaccess是否存在且内容正确。
3.3 Nginx环境：try_files 与404定位
Nginx是完全不同的思路，它不认.htaccess，所有重写逻辑都必须写在站点配置里。Nginx + MySQL + WordPress这种典型环境下，如果打完固定链接就404，90%是location /块里少了一句try_files。
location / { try_files $uri $uri/ /index.php?$args; }这行的含义是：先尝试按字面路径找对应文件，找不到就找对应目录，还找不到就把请求交给index.php，并把原始查询参数（$args）一并传过去。少了这一句，Nginx就会尝试直接访问不存在的文件，然后原样返回404。
很多人在网上搜到这一段，复制粘进了配置文件，结果还是不行，刷新后依旧404。这时候要检查的常见坑包括：规则有没有写对位置（有的放到了location ~ \.php$前后，甚至放到了server块外部）；改动配置文件之后有没有执行nginx -t检查语法并systemctl reload nginx重载；如果启用了CDN或缓存插件，源站的规则更新后CDN边缘节点还在缓存旧的404响应。
| 环境 | 常见404原因 | 快速处理 |
|---|---|---|
| Apache/LAMP | mod_rewrite未启用 | 执行a2enmod rewrite后重启Apache |
| Apache/LAMP | AllowOverride None | 在虚拟主机配置中改为AllowOverride All并重启 |
| Apache/LAMP | .htaccess没有写入权限 | 确保站点目录对Web用户可写 |
| Nginx | 缺少try_files规则 | 补上try_files $uri $uri/ /index.php?$args; |
| Nginx | 配置语法错误 | 执行nginx -t检查后用systemctl reload nginx重载 |
| 任意环境 | 改完固定链接后没刷新规则 | 到"设置 → 固定链接"页面底部点一次"保存设置" |
| 任意环境 | PHP版本过低 | 升级到当前PHP官方支持的版本再排查 |
这里还要提一句PHP版本的问题。有些老站还在用PHP 5.6或7.0这种早已停止安全维护的版本，不仅安全风险高，一些新版主题和缓存插件在高版本PHP下跑得好好的，到旧版本上就会行为异常，甚至导致后台能打开、前台文章404的诡异情况。排查链接问题之前，先确认PHP版本在官方支持范围内，这能省去很多绕弯子的时间。
3.4 一次完整的404排查思路
如果你正在为404头疼，按这个顺序走，基本能定位问题。第一步，后台把固定链接临时切回"朴素"结构，刷新前台。如果朴素结构能正常打开文章，说明PHP和数据库链路是通的，问题100%出在重写规则上。这个二分法是排查效率最高的分水岭。第二步，检查.htaccess是否存在、内容是否为上面那段标准规则，或者Nginx配置里try_files有没有生效。第三步，用curl -I https://你的域名/某篇文章的slug/看返回码，确认当前是404还是200。第四步，按刚才表格里的环境对应项逐条排查。
提示：改完固定链接后，不管有没有改动，都习惯性去"设置 → 固定链接"页面底部点一下"保存设置"。这个动作会强制WordPress刷新重写规则，很多"明明配置了但还是404"的玄学问题，就是因为没做这一步。
4. URL别名与内容规划：slug讲究的是一个"稳"字
4.1 别名：一篇文章真正的身份证
固定链接结构定好后，每篇文章最后一段路径就由别名（slug）决定。比如标题是"WordPress缓存插件性能对比"，你手动把slug设成wordpress-cache-plugin-performance，最终URL就是/wordpress-cache-plugin-performance/（如果你用的是文章名型结构）。
WordPress默认会根据标题自动生成slug，中文标题就会生成一个中文slug。中文slug不是不能用，但很多环境对中文URL编码处理不友好，浏览器地址栏里会显示一长串百分号编码（%E4%B8%AD%E6%96%87这种），分享出去既不美观，某些老服务器上还有可能出现编码差异导致打不开。
我的建议是：发布之前先把slug定好，用英文短词，去掉冠词和连接词，把核心关键词嵌进去。一篇文章的slug定了就不要改，这是整站URL里最重要的一环。我给自己定了个规矩：slug是给搜索引擎和访客看的最终标签，它不等于标题的英文翻译，而是内容的浓缩关键词组。
4.2 分类和标签：同名冲突与基址设置
分类目录和标签是两套独立的分类法，但它们的URL结构在WordPress里默认分别带/category/和/tag/前缀。因为前缀不同，理论上分类和标签即使slug相同也不会直接冲突。
问题出在不少人为了追求URL最短，在固定链接设置里把分类目录前缀和标签前缀都删成了空白。一旦某个分类和某个标签的slug碰巧同名，比如分类叫"教程"、标签也叫"教程"，两者的URL都变成了/jiao-cheng/，路由就无法区分到底该展示分类页还是标签页，结果表现为404或者内容来回摇摆。
我的建议是分类前缀和标签前缀保留一个短词，不要全部删空。默认的category和tag虽然长一点，但语义清楚；如果你想精简，分类可以用column、topic，标签保持tag就好。改完前缀后，记得老分类页是否有外部链接，如果有，也要做301映射，否则又是一批404。
4.3 页面层级、分页与其他链接小细节
页面的父子层级会直接影响URL结构。父页面slug是services，子页面slug是wordpress-maintenance，子页面的URL就是/services/wordpress-maintenance/。这种层级链接适合企业站的服务体系展示，但层级不建议太深，三层以上就是在考验用户的耐心。
链接结构不只是文章页这一层，还有一堆容易被忽略的分页形态。文章内容如果用了<!--nextpage-->分页，文章页会生成/slug/2/、/slug/3/这种分页URL；留言很多时会出现/slug/comment-page-2/；分类页翻页是/category/news/page/2/。这些链接都属于链接结构的组成部分，做站点地图、做内链规划、做CDN缓存策略时都要纳入考虑。尤其是CDN，很多人只缓存了文章第一页，分页没缓存，流量一上来源站全被打穿，这是运营中非常实际的教训。
4.4 别忽略"短链接"这个隐藏保底
WordPress还有一个短链接功能，形态是/?p=123，不依赖任何重写规则。有些主题会把它隐藏在文章页里，或者通过社交分享插件输出。它的优点是绝对可靠——哪怕固定链接结构炸了、重写规则出了岔子，这个链接依然能访问到对应文章。我在排查问题时经常问对方拿短链接来测试，因为它能直接绕开伪静态这一层，快速判断问题属于"内容层"还是"服务器层"。日常写作时不需要刻意使用短链接，但心里要知道它永远是你的逃生通道。
5. 链接结构的变更与迁移：改动一次，代价半年
5.1 改固定链接结构的连带影响
如果你已经上线一段时间，流量和收录都有了一些积累，这时候把固定链接从日期型换成文章名型，恭喜你，所有老URL全部失效。搜索引擎索引的是老地址，其他网站引用的是老地址，你的收藏夹、微信转发的历史链接，全都会变成404。
这不是重设一个选项就算完的事。正确的姿势是：如果网站还没正式上线、没有被搜索引擎收录，那尽量趁早改，现在就是最好的时机；如果已经上线且有一定流量，必须做好完整的301重定向方案，把旧结构的URL逐条映射到新结构。分类页、标签页、分页的URL也跟着变了，同样要处理。市面上比较成熟的方案是用Redirection插件，它支持正则批量匹配，可以快速把/%year%/%monthnum%/%day%/%postname%/这类结构映射到/%postname%/。
改结构这件事还有一个容易被忽略的成本：所有在文章中写死的内部链接。你以前写文章时如果复制了带日期的完整URL粘贴到正文里，那这些内链全部失效。做完301迁移后，最好再用网站爬虫工具全站爬一遍，找找有没有直接在HTML里写死旧URL的残留。
5.2 从其他CMS迁移过来，链接怎么保
从zblog、Typecho、帝国CMS、DedeCMS这些系统迁到WordPress是常见需求，但老站点的URL形态往往和WordPress完全不同。比如老站是/post/123.html这种静态化后缀，或者是/article/?id=456这种动态参数，迁移后这些URL在WordPress里全是404，等于把网站多年的外部引用积累一次性清零。
安全做法是分三步。第一步，迁移前把老站全部URL列表导出一份，最好连同页面标题一起存成表格。第二步，迁移完成后用Redirection插件逐条写规则，老URL映射到WordPress对应的新URL。写规则时可以用正则批量处理，但重点页面建议手动逐条验证。第三步，全站访问检查，特别是老站首页、分类页、热门文章页这几个高权重入口，必须手动确认能301到正确的新地址。
有些站还会遇到"文章ID对不上"的问题。老站文章ID号段和新站不一样，做映射时不能靠猜，务必要以导出的老URL清单为准。
5.3 内容更新与URL：能不动就不动
内容更新时顺手改slug，是我见过频率最高的自杀式操作。标题从"WordPress入门教程"改成"WordPress从零开始学"，顺手把slug也改了，旧的wordpress-tutorial链接全部失效。标题改动对SEO的影响还在可控范围，URL一改等于把历史权重作废重来。
如果标题确实要改，请保留slug不变；实在要改slug，必须为旧URL添加301跳转。我自己运营博客时有个习惯：slug在发布前反复确认，一旦发布就当合同一样对待，改标题可以，改链接免谈。这个原则坚持下来，几年后你会发现那些老文章还在持续带来搜索流量，这全是当初"不动链接"的功劳。
6. 进阶玩法：菜单过滤器、自定义文章类型与后台入口
6.1 导航菜单URL与nav过滤器
导航菜单的输出函数是wp_nav_menu()。默认生成的HTML里，<a>标签的href、class、当前项高亮都是主题根据菜单项类型自动处理的。如果你想对菜单输出的链接做细粒度控制，官方提供的过滤器是nav_menu_link_attributes，它可以修改每一个菜单项的HTML属性。
add_filter('nav_menu_link_attributes', function($atts, $item, $args) { // 给分类菜单项添加一个自定义class if ($item->object === 'category') { $atts['class'] = 'menu-cat'; } // 给外链自动加rel，防止被恶意爬虫盯上 if ($item->type === 'custom' && strpos($atts['href'], home_url()) === false) { $atts['rel'] = 'nofollow'; } return $atts; }, 10, 3);这个方法在做企业站时非常实用，尤其是需要给不同菜单项定制样式、给外链加安全属性的时候。如果连菜单的整个HTML结构都要重排，那就需要写一个自定义Walker类继承Walker_Nav_Menu，重写start_el()和end_el()方法。属于主题定制中的进阶玩法，但很多"菜单渲染结果跟我想的不一样"的困惑，根子都在这里。
6.2 自定义文章类型的链接设计
用自定义文章类型搭建产品库或案例库时，链接结构要提前想清楚。注册CPT时的rewrite参数直接决定URL形态。
register_post_type('product', array( 'has_archive' => true, 'rewrite' => array( 'slug' => 'product', 'with_front' => false ), ));按这个配置，产品详情页的URL是/product/某产品slug/，产品列表归档页是/product/。这里的with_front参数经常被忽略。如果你的主固定链接结构是分类目录型，并且设置里以/blog/为前缀，with_front不设为false时，产品链接可能会变成/blog/product/xxx/——归档页和详情页之间路径逻辑混乱，语义也不清晰。设置自定义文章类型时，建议把with_front显式设为false，让CPT的URL完全由自己掌控。
这里还要顺带提一下应用市场现象。WordPress生态下的插件和主题越来越多，很多开发者在自己的插件里注册了自定义文章类型或新的重写规则。你装一个插件后发现某些URL结构变了、某些页面多出来了，往往就是它的注册规则在生效。从应用中心安装任何不熟悉的插件前，先去插件说明页看看它是否声明了"添加自定义文章类型""添加重写规则"这类行为。很多"网站突然出现奇怪URL""保存固定链接后规则被冲掉"的问题，源头都是插件之间互相覆盖rewrite规则。
6.3 管理员入口分离：wp-login.php的安全姿势
后台登录地址默认是/wp-login.php，这个路径全世界所有的WordPress网站都一样，所以它天然是批量扫描和暴力破解的重点目标。所谓"管理员入口分离"，就是让登录地址变成一个只有你自己知道的路径。
实现方式要选对。WordPress官方没有提供登录入口改名的开关，一些人直接改wp-login.php文件名，这是大忌——核心文件在升级时会被覆盖，而且很多功能仍会硬编码引用这个文件名。稳妥做法是使用成熟的隐藏登录插件，这类插件的原理是拦截你自定义的slug，然后动态映射到真实的登录处理逻辑，并不会实际移动任何核心文件。还有一种纯代码方案，是通过login_url过滤器和重写规则实现自定义登录路径，但复杂度稍高，适合有开发能力的用户。
注意：隐藏登录入口只是降低了被扫描到的概率，它不是安全保险箱。登录口令强度、登录失败次数限制、双因子认证，这些基础安全措施该做还得做，也别把隐藏入口的URL告诉不必要的人。
6.4 链接结构相关的插件与"应用中心"现象
WordPress强大的生态意味着你几乎可以给网站加任何功能，但每一次安装插件都等于往URL解析链条里塞进一段新逻辑。不少缓存插件会生成查询参数、追踪参数，一些编辑器插件会在固定链接设置里偷偷加入自己的规则。我见过最典型的问题是：装了一个声称"一键开启漂亮URL"的优化插件后，整站的.html后缀和伪静态规则互相打架，后台保存一次固定链接就被插件重置一次。
所以记住一条原则：链接结构是网站的地基，任何第三方工具都只能在这个地基上做装饰，不能允许它们反客为主。插件安装前看清说明，安装后测试全站URL是否异常，修改固定链接设置时全站爬一遍确认没有404新增。这些习惯说起来简单，真能坚持做的人，运营三五年都不会被链接问题拖住后腿。
我个人这几年的体会是：链接结构就像新建楼盘时的管道设计，装修怎么折腾都好办，管道埋错了再改就是砸墙。新站上线前，花半个小时把文章、页面、分类、标签、自定义文章类型的URL规则全部过一遍，写进建站备忘清单；给内容团队定一个铁律——slug一律英文短词、发布前定稿、绝不事后修改。把这些基础打牢，后面不管换主题、加插件、做SEO，你都不会被"链接突然全挂了"这种问题半夜叫醒。
