简介杰迅CMS全国城市分站系统是一套基于ThinkPHP 5.0框架开发的开源免费城市分站内容管理系统面向生产型企业、本地服务公司、集团学校及招商加盟类站点解决一个主域名下搭建多个城市分站或独立站群的建站与管理需求。支持无限二级域名或目录分站分站可继承主站栏目数据也可独立运营站群模式则允许各子站使用不同模板与独立数据灵活度较高。资源包共1257个文件约33.5MB以php核心逻辑、html模板、js/css前端资源为主另含png/gif/jpg图片素材、sql数据库脚本、nginx/iis配置文件等目录结构清晰便于部署与二次开发。目前已吸引451人学习查看。配套的多站点管理平台可提供SEO监控、文章组合与采集自动发布、外链发布等自动化功能SaaS小程序平台支持微信、百度、支付宝、抖音、头条、QQ六端小程序与网站数据同步适合需要搭建城市分站矩阵或站群体系的读者下载参考。1. 城市分站到底在解决什么一个后台统治所有站点的运营逻辑先把我接手杰迅CMS城市分站系统时的第一个疑问摆出来明明一个CMS站就能跑为什么非要搞出几十个城市分站后来在真正运营层面想明白了一件事——城市分站不是技术问题是业务增长问题。做本地服务、区域资讯、同城电商这类项目用户搜索习惯里天然带着地域词。你搜“装修公司”可能只是想找报价但你搜“北京装修公司”意图就变成了要找一个本地的、可上门服务的商家。搜索引擎对这类地域搜索词的匹配逻辑也倾向于展示本地特色更明确的站点。单站玩法在只有一个域名的情况下很难同时覆盖几十个城市的搜索需求。强行用栏目模拟分站——比如在域名后面加/beijing、/shanghai——内容归属感很弱收录权重也不好做。杰迅CMS这种国内PHP开发的CMS在栏目、模板、扩展机制上有足够的灵活性改造为城市分站系统不算伤筋动骨再加上本身就是国内团队在做文档和社区资源也跟得上踩坑后的解决成本远低于那些冷门框架。杰迅CMS做全国城市分站系统核心不是“多站点”而是“一套后台、一套会员体系、一套内容库前台按城市维度对外输出”。这才是分站系统的本质。每一个城市站点的定位本质是一个独立站点但背后共享控制面板。我先花点时间给还不熟悉这个概念的读者解释一下分站系统的结构。传统多站玩法是每个城市单独装一套CMS各自有独立的管理后台和数据库。这种模式维护成本极高——几十个站点意味着几十次补丁更新、几十个可能被挂马的后台入口。杰迅CMS的分站系统则是使用单一主站作为总控在系统内部以插件或扩展模块方式维护城市数据对外则通过域名绑定或URL规则让每个城市看起来都是一个独立站点。这套设计最直接的价值在于运营效率。你做全国市场的时候总部的运营人员只需要维护一个后台发布一篇总站文章可以一键推送至全部分站也可以定向推送至指定分站。分站管理员如果存在则只拥有管理自己城市数据的权限。权限体系、内容归属、模板变量这些全部通过站点标识来隔离不需要再做二次开发。后端数据是共享的前端访问是通过URL规则和模板变量来区分的。2. 底层架构怎么搭单库分站ID与多库部署的取舍城市分站的第一个技术决策就是数据库方案。这个决定直接影响后续的数据维护难度、查询性能、备份策略所以必须放在最开始讲。我推荐首选单数据库、数据表增加分站标识字段的方案。原因很简单几十个城市的数据量级在一个库里完全可以扛住共享一个后台意味着信息发布、会员管理、订单系统都能天然打通。杰迅CMS的模型字段扩展机制允许你为内容模型添加city_id这类自定义字段然后通过栏目绑定的方式区分内容归属。具体实操时我在内容模型里增加了一个“所属城市”字段值为城市ID然后为每个城市建立一个虚拟栏目模板通过判断当前访问的域名或参数来筛选数据。数据表结构可以做这样的设计维度方案A单库分站字段方案B多库多站点数据隔离逻辑隔离靠字段区分物理隔离库之间互不可见维护成本低备份/升级只需处理一套高每个分站都要单独备份跨站调用方便一条SQL即可查询全局困难需要跨库或接口性能瓶颈出现较早但可做缓存优化分散压力性能空间大适合场景内容资讯、企业站集群交易量级大、SaaS平台我在实操中的结论是对于杰迅CMS这种定位的CMS产品几乎不需要考虑多库方案。哪怕城市数量到100个只要MySQL配置合理、栏目缓存开好单库的性能完全够用。如果你的信息模型涉及复杂查询——比如同城活动列表加地理坐标距离排序单库反而更好优化一条SQL带JOIN就能解决。技术方案确认后接下来做域名规划。我采用“主域名二级子域名”模式www.example.com是总站bj.example.com对应北京、sh.example.com对应上海。杰迅CMS的站点管理机制允许绑定多个域名到不同站点也可以只用一个站点、通过URL前缀做城市区分。前者更利于分站SEO的独立性因为每个子域名在搜索引擎眼里就是一个独立域名后者则适合只想加地域页、不想真正做分站的场景。部署层面我做了三件事第一在服务器上配置泛解析*.example.com指向主站IP第二在Web服务器配置中把城市子域名重写到统一的入口文件同时将城市标识作为PATH_INFO参数传给杰迅CMS第三在杰迅CMS的全局配置里增加城市识别逻辑根据当前域名自动切换模板变量中的城市信息包括城市名、城市ID、城市热线、城市地图坐标等。这样做的理由在于二级子域名在SEO中的权重独立性要优于目录形式。搜索引擎会把bj.example.com视作一个相对独立的站点你可以为它单独建设外链、单独提交站点地图。而这种基础又不需要真的部署多套系统只在入口层做一层分发就够了。3. 模板如何做出“城市感”URL规则、变量替换与页面定制很多人在做城市分站的路上翻车不是倒在架构上而是倒在模板上——所有城市页面长得一模一样只是把标题里的城市名换了一下用户毫无体验可言。这违背了做分站的初衷。杰迅CMS的模板引擎提供了成熟的标签调用机制可以按栏目、按模型、按自定义字段筛选内容。我在做城市分站模板时大量使用了自定义字段匹配将当前城市的ID作为全局参数贯穿所有列表页和详情页的查询条件。模板层面的核心改造分为三层。第一层是“城市变量全局化”。我在公共头部模板中定义了城市相关变量当前城市名称、拼音、电话、地址、地图坐标。这些变量写在站点配置里随域名切换自动变化。第二层是“分站专属内容块”。每个城市页面的首页除了展示总站推送的内容还要有自己专属的本地内容版块。我在内容模型里增加了城市ID字段后又增加了一个“推荐到分站首页”的开关。总站编辑发布内容时可以选择推送范围。这样既保证了总部的信息管控又给城市站留出了差异化空间。第三层是个性化定制的灵活性。城市站的运营者如果对模板有自己的要求——比如南方城市更喜欢浅色调北方城市更喜欢大气深色块——只需在模板目录中建立以城市拼音命名的模板子目录杰迅CMS会在解析时优先查找城市专属模板找不到才回落到默认模板。这个机制可以说是我整场改造中最划算的一个功能点。URL规则上我做了两套方案。生产环境用https://bj.example.com/News/这种二级子域名加栏目路径的结构URL末尾生成静态化页面。测试环境为了方便调试则使用https://www.example.com/bj/目录形式切换。这里要注意确定正式上线URL规则后尽量不要更改否则之前积累的收录权重会全部丢失。我在演示站上反复切换过几次URL结构导致搜索资源平台的收录数据波动很大这个教训后面接入的朋友要避开。分站页面的TDK设置也要单独处理。标题、关键词、描述这些元信息我在杰迅CMS的栏目设置里每个城市单独写了一套。虽然工作量会大一些但这个钱绝对不能省。标题格式参考“城市名核心词品牌词”描述里自然融入当地地标、区县名称。搜索引擎对重复度极高的标题会做折叠处理你如果让一百个城市站共用一个标题模板分站的价值直接腰斩。4. 城市站的数据喂养采集接口、防重复与内容填充实战模板做好后分站跑起来最大的问题不是技术是内容从哪来。总部人工录入只适合总站精品内容城市站的本地资讯、商家信息、行业文章必须依赖采集和API对接。杰迅CMS本身带有一套采集规则机制可以自定义采集节点、列表页规则、详情页规则、字段映射。但这个内置功能用来做总站内容的日常更新还行做城市分站的数据批量填充还是需要配合接口方式。我会优先建议分站数据通过标准接口方式对接。具体做法是在总站后台提供一个JSON数据接口输出已发布且允许推送的内容接口参数包含城市ID或城市拼音分站则通过杰迅CMS的自定义扩展包定时拉取。这样做的好处是数据源头可控总站编辑审核过的内容才会被分站拉取不会出现采集站常见的垃圾内容泛滥问题。这里要专门讲一个我从苹果CMS系产品上迁移过来的经验数据重复问题。城市分站的内容经常会有交集比如“全国装修行业峰会”这类内容不仅总站要发北京站、上海站也要发。如果你在多个分站里分别插入同一条内容就会在搜索结果中看到大量重复页面。解决方案是给内容表增加一个“来源哈希”字段。在内容入库前对“标题摘要”计算一个MD5值入库时先查这个哈希是否已存在存在则跳过或提示去重。这个思路对采集接口同样适用——苹果CMS的采集器经常做这类校验杰迅CMS的二次开发同样可以在接口层实现。我实测这个方案对重复内容的拦截率在99%以上剩下的1%是纯正文高度一致但标题改了的变体这类可以在后续清洗任务中处理。采集规则的设计上我强烈建议不要直接用默认的“整页抓取”模式。城市分站的目标是每一条内容都要有地域相关性你从非本地来源采集的内容必须要有机制去校验。我在采集规则里增加了关键词白名单和黑名单白名单是城市名加区县名、本地商圈名、本地标志性建筑黑名单则是明显的异地特征词。命中黑名单的条目直接丢弃只有同时满足白名单条件的才进入待审核池。这套粗暴但有效的规则把分站内容的质量下限拉高了一大截。内容自动发布后还有一个细活就是分站详情页内的“本地化替换”。我写了一个替换规则层把采集稿正文中出现的异地联系方式、地址、地名等统一替换成本地对应信息。替换逻辑不复杂就是用PHP正则匹配规则表但要注意不要无脑全替换——有些品牌分店信息是真实的替换反而伤害内容。所以我只替换结构化明确的地址块和电话块页面内的自然描述文本保持原样。5. 分站SEO的正确姿势独立TDK、站点地图与权重布局城市分站系统的SEO是整个项目的重头戏。做分站本质上不是为了给用户多几个入口而是为了多圈占搜索引擎的地域流量。所以每一个分站都要按照独立站点的标准来做SEO配置。首先是站内结构。杰迅CMS的URL规则我做了重写分站页面的路径结构是“域名/栏目/ID.html”栏目之间不混用参数。二级子域名、静态化链接这两个是基础中的基础。然后每个分站独立生成一个XML站点地图提交到搜索资源平台。数据量大的时候我会把站点地图拆成几个子文件——资讯地图、商家地图、活动地图避免单文件过大导致抓取不全。TDK的差异化处理我在前文说了这里再展开讲一下实施细节。我是在杰迅CMS的“栏目文档”模式基础上为每个城市栏目标注了独立的SEO标题和描述。模板中使用{$cityInfo.seo_title}、{$cityInfo.seo_keywords}、{$cityInfo.seo_description}三个变量输出。这样即使两个分站展示同一篇总部推荐内容页面的标题也能根据当前城市的SEO配置自动生成不同的前缀避免搜索结果页面出现连续重复的标题列表。权重布局上我采用金字塔结构。总站首页权重最高链接指向各个城市分站的首页分站首页再向内页权重传递。城市子域名之间不做大规模互链只在底部“友情城市”区域保留少量入口。搜索引擎对同一IP下大量站点互链是有警惕的适可而止就好。这里还要提一个细节是其他教程很少讲的分站数据统计代码要分开配置。我在杰迅CMS的站点配置里增加了“统计代码”字段每个分站绑定独立站点ID。这样在流量统计工具里就能清晰看到每个城市的真实访问数据。否则所有分站都共用总站的统计编码后续分析分站运营情况时根本拆不开数据。另外做分站系统一定要配置好主域名与子域名的robots规则。总站的robots文件要放行所有子域名同时子域名根路径也要能访问到robots文件。我最初上线时忘记在子域名的伪静态规则里排除robots文件导致搜索引擎抓取robots时返回了HTML页面浪费了不少宝贵抓取配额。6. 上线前必须做的安全加固把getshel风险一口堵死讲到安全这个话题我必须严肃起来。CMS程序只要暴露在公网就无时无刻不在承受扫描器的“问候”。拿杰迅CMS这类国内生态的PHP系统来说攻击者主要盯的就是后台地址、上传接口、模板注入、SQL注入这几类目的通常是拿到执行权限也就是安全圈常说的“getshell”。先解释一下getshell在CMS场景下的常见含义。攻击者通过CMS自身的功能点绕过限制向服务器写入一个可执行的WebShell脚本然后通过这个脚本控制网站文件、读取数据库、发起内网扫描等。CMS站点的getshel路径非常多比如上传点没有做类型校验、模板编辑功能允许写入PHP代码、后台登录没有验证码可以暴力破解等。安全加固的核心不是某一个单点而是把所有入口都堵住。我在项目上线前做了一套完整的加固流程。第一步是修改后台路径。杰迅CMS的后台默认目录是/admin这个几乎是公开的秘密。我在配置文件里把它改成了无规则的随机字符目录名。这一步能挡掉绝大多数自动化扫描。第二步是上传目录的写入权限收敛。将Uploads目录设置为PHP无法执行在Nginx配置中加一段location ~ \.(php|php5)?$ { deny all; }。这样即使攻击者通过某种手段上传了PHP文件也无法在网站目录下直接执行。第三步是模板编译目录的权限隔离。杰迅CMS在运行时会生成编译模板缓存如果这个目录被写入恶意模板代码同样存在执行风险。我把模板编译目录调整到Web根目录之外并通过配置文件指向新路径。这一步在大多数虚拟主机上做不了但如果你用的是云服务器务必做到。第四步是强制所有后台操作走HTTPS。通过SSL证书加密避免后台密码和数据包在传输过程中被截获。我在Web服务器配置层面把admin目录强制跳转到HTTPS同时设置HSTS头。这个配置虽然简单但是很多中小站长都会忽略等到后台密码被人撞库了才追悔莫及。最后一件事就是对杰迅CMS的官方补丁保持关注。CMS产品都会有版本迭代补丁不及时是最常见的安全隐患之一。我的习惯是每月固定时间检查一次官方更新和社区安全公告有更新就在测试环境验证后灰度上线。如果你接手的是别人开发的分站系统还要仔细审查一下插件代码尤其是来源不明的第三方采集器、装修组件——这些第三方组件是隐藏后门的高发区。可以用文本搜索工具全局检索整站代码查看是否存在eval、base64_decode、assert这类敏感函数然后再决定是否禁用或替换。对于不在白名单里的插件我的原则是直接不用哪怕功能再诱人。这套流程跑完后我又通过开源扫描工具对整站做了一次常见漏洞模式扫描重点检查了SQL注入点和越权访问路径。剩下的就是日常监控了。分站系统因为域名多、入口多安全日志的体量比单站大很多我在服务器上配置了简单的日志告警看到可疑的POST请求、异常用户代理、频繁的登录失败记录第一时间就人工复核。只要把自动化检查和人工响应结合起来分站系统在安全层面的风险就能控制在可控范围内。7. 分站系统上线后的几件收尾事以及我踩过的坑系统上线不等于项目结束反而是一堆新问题的开始。我在交付杰迅CMS城市分站系统后连续一周都在处理各种“看着是小问题、实际很致命”的细节。挑几个有代表性的坑说说。第一个坑是伪静态规则导致的分站URL混乱。子域名城市分站上线后我发现部分分站的列表页第二页出现了404检查发现是伪静态规则中的页码参数没有正确传递到子域名站点。这个问题从底层看不是杰迅CMS本身的bug而是我配置的Nginx规则没有考虑到二级子域名的PATH_INFO转发。修复方式是在重写规则里显式带上页码参数并在杰迅CMS的URL配置里检查“伪静态后缀”设置。第二个坑是模板缓存导致的分站配置串位。分站切换城市变量后如果开启了模板缓存偶尔会出现页面头部显示北京配置、主体内容却是上海的情况。原因是模板缓存键生成时没有把城市ID纳入考量。解决办法是修改模板缓存键的生成逻辑在缓存标识中拼接城市ID。这个改动对性能几乎没有影响但对使用体验的改善非常明显。第三个坑要提醒计划上城市分站的朋友早做打算分站广告位和运营位规划。城市分站上线后总部往往会针对不同城市做不同的活动推广。在杰迅CMS的模板标签里把广告位写死是最省力的方式但后患无穷。我建议在系统里建立“分站运营位”数据表内容包含城市ID、位点标识、关联内容ID或链接地址。模板中通过位点标识调取数据。这样后续运营调整不用改模板后台操作即可完成。第四个坑是搜索资源平台的验证。每个子域名在搜索资源平台上都要单独验证归属权这个流程不能在总站验证后就以为万事大吉。我一开始图省事只在总站做了验证结果子域名长时间没有被收录。后来逐个校验、提交之后收录速度才恢复正常。如果你手里的城市数量多建议按批次提交不要一次性把五十个子域名全部提交平台对短时间大量新增子域名会有一个观察期。最后一个建议关于监控和备份。分站系统涉及多个域名、多个入口日常监控要覆盖到Web可用性、数据库连接数、磁盘空间、SSL证书有效期任何一个环节出问题都会直接影响所有分站。备份策略我采用“整站文件数据库”双备份每天凌晨自动执行保留最近30天。这个策略不复杂但在几次意外中保住了我的数据算是整个项目最稳健的投资。如果你正在规划自己的城市分站系统前期的架构选型、模板方案、SEO规则和安全加固都值得多花时间但这些收尾事也千万不要等到上线后才重视提前配置好后面能少熬很多个凌晨。本文还有配套的精品资源点击获取