回到主页

网站迁移没有这样的事情

网站,如经营它们的企业,往往是看似复杂的机器。

它们是脆弱的系统,更改或替换任何一个部件很容易影响(甚至破坏)整个设置 - 通常以对利益相关者或开发人员不会立即显而易见的方式。

即使看似简单的网站也常常由复杂的技术提供支持,如内容管理系统,数据库和模板引擎。幕后工作 - 技术上和组织上 - 比通过爬网站或查看源代码容易观察到的要多得多。

当您更改网站并删除或添加元素时,引入新的错误,缺陷或错误并不罕见。

这就是为什么每当我听到客户或企业宣布他们打算进行“网站迁移”时,我都会非常紧张。

机会和经验表明,某些事情会出错。

哎哟。#ecomchat #seo pic.twitter.com/flgncLVJBT
-马克·库克(@thetafferboy)2017年2月26日,

迁移的范围差异很大

作为一名搜索引擎优化顾问和从业者,我参与了更多的“网站迁移”,而不是我记忆中或计算在内 - 对于慈善机构,创业公司,国际电子商务网站甚至是全球家用品牌。每个人都具有独特的挑战和压力。

在每种情况下,所涉及的企业都低估了(在某些情况下,增加了)成功执行“迁移”所涉及的复杂性,风险和细节。

因此,许多项目以可轻易避免的方式对绩效和潜力产生了负面影响。

这不是“移民”范围太大的情况,而是理解,目标,方法和优先事项的错位,导致利益相关者在完全不同的范围内工作。

我所经历的迁移包括简单的域名转移,服务器基础设施,内容管理框架,模板和页面的全面检修 - 有时甚至可以扩展到包括多个网站和品牌的整合(或碎片化)。

然而,在每个组织的头脑中,尽管范围明显不同(且定义不明确),但这些都是“迁移”项目。在每种情况下,“迁移”一词的定义和理解都有很大差异。

我们嘲笑定义

作为一个行业,我们习惯于与标签斗争。我们仍然不确定我们是否是SEO入境营销人员数字营销人员或仅仅是...... 营销人员。问题在于,当我们彼此交谈(以及我们行业以外的人)时,这些词语可以带有不同的含义和期望。

即使在我们自己之间,两位数字营销人员,分析师或SEO之间就他们的专业领域进行的对话也可能表明他们对自己的角色,职责和疏忽有着截然不同的定义。对他们来说,像“内容”或“平台”这样的词可能意味着不同的东西。

同样地,“ 站点迁移”在形式,功能和执行方面也有很大差异 - 当我们讨论它们时,我们不一定谈论同样的事情。如果我们不澄清我们的意思并且有共同的定义,我们就会面临误解,错误甚至冒犯的风险。

歧义造成风险

管理不善的迁移可能会产生许多后果,而不仅仅是排名,流量和性能下降。也存在次要影响。他们也可能无意中:

  1. 提供糟糕的用户体验(例如,旧URL现在为404,或者错误状态使用户感到困惑,或者用户到达与他们预期不同的页面)。
  2. 中断或省略跟踪和/或分析实施,从而导致商业智能的丧失。
  3. 限制网站的大小,形状或可扩展性,导致静态,停滞或不灵活的模板和内容(例如,省略在CMS中添加或编辑页面,内容和/或部分的功能),以及因此努力竞争。
  4. 错过了从SEO最擅长的方面受益的机会:融合对消费者需求和行为,市场和竞争对手以及相关品牌的理解,以创建更有效的策略,功能和内容。
  5. 建立利益相关者之间的冲突,当我们需要“喧嚣”在最后一分钟改造我们的要求到一个已经复杂的项目(“我知道这是关于去住,但我们可以添加的分析转换跟踪?”) -在常我们的声誉成本。
  6. 浪费未来资源,其中错误要求未来资源用于弥补过程中的错误或遗漏导致的公平,而不是建立和提高绩效。

我应该指出,在这种情况下,喧嚣并没有错; 事实上,在这种情况下,乞讨,借用和偷窃往往是一种可行的解决方案。不止一次,在网站迁移之前的深夜,我通过乞求开发人员包括模板审核流程,实现重定向或停止部署来避免灾难。

但这不是一种明智或可持续或可靠的工作方式。

不可避免地会犯错误。资源,恩惠和耐心是有限的。过多地依赖个人(或多个人)的“喧嚣”可能会进一步扩大理解和范围的差距,并将骗子定位为单一的失败点。

更重要的是,喧嚣可能只能解决症状,而不是这些问题的原因。这意味着我们仍然处于破坏性局外人的角色,他们在第11个小时不断挤压额外的无范围需求。

哪里出了问题

如果我们要开始解决其中一些挑战,我们需要了解迁移项目出错的时间,地点和原因。

所有不太完美的迁移的根本原因可以追溯到以下至少一种情况:

  1. 迁移项目未经协商就进行。
  2. 在此过程中和/或迁移后寻求咨询的时间太晚。
  3. 没有足够的计划资源/时间/预算来添加需求(或流程)/对简报进行建议的更改。
  4. 范围在项目中期改变,无需咨询,或以不优先考虑要求的方式进行。
  5. 要求和/或建议的更改在第11个小时被削减(由于资源/时间/预算限制或教育/政治冲突)。

每种情况都有一个共同的主题。我们在这个过程中没有及早参与,或者我们的意见和优先事项没有足够的重要性来影响时间表和资源。

可能是,这些错误很少是偶然或有意遗漏的产物; 相反,它们源于所涉及的利益相关者和决策者的教育和经验方面的差距。

我们可以在一定程度上解决这个问题,将自己提升为这类项目的高级利益相关者,并在时间表中提前咨询。

让我们更具体一点

我认为,我们有责任帮助我们工作的组织避免这些错误。最简单的机会之一就是尽可能早地确保我们谈论同样的事情。

否则,迁移将继续出错,我们将继续花费太多的集体时间来修复损坏的链接,建议对模板进行更改或改进,以及将受损的网站放在一起 - 所有这些都是以牺牲有意义为代价的,有影响力的工作。

也许我们可以通过创建更好的定义并帮助明确说明“站点迁移”过程中涉及的内容来开始回答其中的一些挑战。

不幸的是,我怀疑至少现在我们仍然坚持使用“迁移”这个词。这个术语已被广泛使用,人们认为这是一个正确和恰当的定义。当我们已经来不及谈话时,尝试改变别人的语言是不现实的。

我们下一个减少歧义和风险的最佳机会是编纂移民类型。这使我们有机会进一步探索和更好的定义。

例如,如果我们可以说“这听起来它实际上是一个迁移与模板迁移配对”,我们可以稍微引导对话并依赖更好的共享参考框架。

如果我们可以提出一个挑战,例如,业务的另一部分正在处理的“翻译项目”实际上是一大堆交织的迁移类型,那么我们可以提前提出我们的问题并寻求更合适的资源,预算和权限(例如,“此项目实际上包含一系列涉及模板内容的迁移因此,我们必须将XY视为项目范围的一部分。”)。

通过坚持这种方式标记,利益相关者可以逐渐理解,例如,改变设计通常还涉及更改模板,因此SEO人员应该在此过程中更早地参与。通过挑战语言,我们可以挑战思维。

让我们编纂迁移类型

我已经确定了至少七种不同类型的迁移。下次遇到“迁移”项目时,您可以调查建议的更改,将它们映射回这些类型,并标记理解,期望和资源方面的任何差距。

你可以争辩说,其中一些并不是技术意义上的严格“迁移”(即,改变某些东西与移动它不同),但是以这种方式对它们进行分组是有意的。

请记住,我们的目标不是对任何可能的迁移类型的所有要求进行整齐的分类。有很多资源,指南和列表已经尝试过这样做。

相反,我们正试图提供简洁,通用的标签,帮助我们(SEO人)和他们(业务利益相关者)共享定义并删除未知的未知数。

它们是一组共享定义,我们可以用来触发早期预警信号,并帮助我们更好地管理利益相关者的期望。

随意建议您自己,增长,收缩,组合或装箱任何这些,以满足您自己的经验和要求!

1.托管迁移

广泛捆绑的基础架构硬件服务器注意事项(虽然这些都是各自的大类,但在这种情况下将它们捆绑在一起是有意义的)。

如果您的迁移项目包含以下任何更改,那么您正在讨论托管迁移,并且您需要探索SEO影响(以及开发资源需求)以确保对底层平台的更改不会影响前端 - 性能或可见性。

  1. 你正在改变托管服务提供商。
  2. 您正在更改,添加或删除服务器位置。
  3. 您正在改变物理(或虚拟)服务器的规格(例如,RAM,CPU,存储,硬件类型等)。
  4. 您正在更改服务器技术堆栈(例如,从Apache迁移到Nginx)。*
  5. 您正在实施或删除负载平衡,镜像或额外的服务器环境。
  6. 您正在实现或更改缓存系统(数据库,静态页面缓存,清漆,对象,memcached等)。
  7. 您正在改变物理或服务器安全协议和功能。**
  8. 您正在更改,添加或删除CDN。***

*如果更改影响任何前端组件(例如,CMS)的配置或行为,则可能会重叠到软件迁移中。

**可能会与其他迁移重叠,具体取决于其显示方式(例如,模板,软件,域)。

***如果CDN作为/显示在不同的主机名(例如,AWS)上,而不是无形地(例如,Cloudflare),则可能与域迁移重叠。

2.软件迁移

除非您的网站由纯静态HTML文件组成,否则它可能正在运行某种软件来为用户提供正确的页面,行为和内容。

如果您的迁移项目包含以下任何更改,那么您谈论的是软件迁移,您需要了解(并输入)管理错误代码,网站功能和后端行为的工作方式。

  1. 你正在改变CMS。
  2. 您正在CMS中添加或删除插件/模块/加载项。
  3. 您正在升级或降级CMS或插件/模块/插件(通过重要程度/主要版本)。
  4. 您正在更改用于呈现网站的语言(例如,采用Angular2或NodeJS)。
  5. 您正在开发网站上的新功能(表单,流程,小部件,工具)。
  6. 你正在合并平台; 例如,在单独的域上运行的博客和系统正在集成到单个CMS中。*

*如果您正在吸收先前在不同域上定位/访问的软件,则可能会重叠到域迁移中。

3.域迁移

如果单独执行,域迁移可以非常简单,但这种情况很少发生。对域的更改通常与其他结构和功能更改(或其结果)配对。

如果您的迁移项目改变了用户能够访问您网站的URL,包含以下任何更改,那么您正在谈论域迁移,您需要考虑重定向,协议(例如HTTP)的方式/ S),主机名(例如,www /非www)和品牌受到影响。

  1. 您正在更改网站的主域名。
  2. 您正在为您的生态系统购买/添加新域名。
  3. 您正在添加或删除子域(例如,在迁移到HTTP2后删除域分片)。
  4. 您在域之间移动网站或网站的一部分(例如,将子域上的博客移动到子文件夹中,反之亦然)。
  5. 您有意允许活动域名到期。
  6. 您正在购买已过期/已弃用的域名。
4.模板迁移

您的网站可能会使用大量HTML模板来控制网页的结构,布局和外围内容。控制内容外观,感觉和行为方式的逻辑(以及隐藏/元素元素(如描述或规范URL)的行为)往往会存在于此处。

如果您的迁移项目改变了内部导航(例如页眉或页脚)等元素,<head>中的元素,或者以我概述的方式更改了内容周围的页面结构,那么您谈论的是模板迁移。您需要考虑用户和搜索引擎如何感知和参与您的网页,内容链接结构的上下文,相关性和权限如何流动,以及HTML(和JS / CSS)代码的结构如何。

  1. 您正在更改内部导航。
  2. 您正在更改重要页面/模板的布局和结构(例如,主页,产品页面)。
  3. 您正在添加或删除模板组件(例如,侧边栏,插页式广告)。
  4. 你改变你的<head>代码元素,如标题规范的或者的hreflang标签。
  5. 您正在添加或删除特定模板(例如,显示特定作者的所有博客帖子的模板)。
  6. 您正在更改一个或多个模板使用的URL模式。
  7. 您正在更改设备特定的渲染工作方式*

*可能涉及域,软件和/或托管迁移,具体取决于实现机制。

5.内容迁移

您的内容就是吸引,吸引并让用户相信您是回答他们的问题并满足他们需求的最佳品牌的一切。其中包括您用来描述产品和服务的词语,您在博客上谈论的内容以及您制作或使用的每个图像和视频。

如果您的迁移项目以我概述的方式显着改变了内容的基调(包括语言,人口统计定位等),格式或数量/质量,那么您就是在谈论内容迁移。您需要考虑您的市场和受众的需求,以及您网站上的文字和媒体如何回答这些问题 - 以及与竞争对手相比如何做到这一点。

  1. 您可以显着增加或减少网站上的页数。
  2. 您可以显着更改内容的基调,定位或焦点。
  3. 您开始在/关于新主题制作内容。
  4. 您翻译和/或国际化您的内容。*
  5. 您可以更改博客或产品内容的分类,标记或其他分类系统。**
  6. 您可以使用规范标签,元机器人索引指令或robots.txt文件等工具来控制搜索引擎(和其他机器人)如何访问内容片段(单独或大规模)的属性值。

*可能涉及域,软件和/或托管以及模板迁移,具体取决于实现机制。

**如果布局和/或URL结构因此而更改,则可能会重叠到模板迁移中。

6.设计迁移

您网站的外观并不一定会直接影响您的表现(尽管用户信号如参与信任肯定会这样做)。但是,对设计组件的简单更改通常会产生意想不到的连锁效应和后果。

如果您的迁移项目包含以下任何更改,那么您正在谈论设计迁移,并且您需要澄清变更是否纯粹是装饰性的,还是更深入并影响其他领域。

  1. 您正在改变关键页面的外观(例如您的主页)。*
  2. 您正在添加或删除交互层,例如,根据设备或状态有条件地隐藏内容。*
  3. 您正在进行设计/创意更改,以更改特定元素的HTML(而不仅仅是图像或CSS文件)。*
  4. 您正在更改关键消息,例如徽标和品牌标语。
  5. 您正在改变对更改策略或货币化模型做出反应的外观(例如,在侧边栏中引入广告空间,或者删除广告以支持使用插页式广告/状态)。
  6. 你正在改变图像和媒体。**

* 所有模板迁移。

**不要忘记301重定向这些,除非您要替换类似的文件名(如果您希望使本地或远程缓存无效,这并不总是最佳做法)。

7.战略迁移

组织或营销战略的变化可能不会直接影响网站,但品牌的受众,目标和平台之间的差距越大,对绩效的影响就越大。

如果您的市场或受众(或您对其的理解)发生重大变化,或者您的使命,声誉或您描述产品/服务/目的的方式发生变化,那么您就是在谈论战略迁移。您需要考虑如何构建网站,如何定位受众,如何编写内容以及如何进行广告系列(所有这些都可能触发一系列新的迁移项目!)。

  1. 您更改公司使命声明。
  2. 您可以更改网站的主要目标,目标或指标。
  3. 您进入一个新的市场(或留下一个)。
  4. 您的频道焦点(和/或您的受众群体)会发生重大变化。
  5. 竞争对手扰乱了市场和/或占据了大量的市场份额。
  6. 对网站/其性能/ SEO /数字变化的责任。
  7. 您指定一个负责网站性能的新机构或团队。
  8. 高级/ C级利益相关者离开或加入。
  9. 法律框架的变化(例如隐私合规或规范部门中新的/不断变化的内容限制)限制了您的发布/内容功能。
让我们早点进入

有了更好的定义,我们就可以开始围绕“迁移”项目实际涉及的内容进行更加深思熟虑的对话。我们可以使用共享语言,并确保利益相关者了解他们打算进行的更改的风险和机会。

然而,不幸的是,在我们已经决定和签署之前,我们并不总是听到提议的更改。

人们不知道他们需要告诉我们他们正在改变域名,模板,托管等等。所以通常为时太晚 - 或者 - 如果 - 我们终于介入了。在他们逐渐意识到这一点之前,已经做出了决定。

那还是个问题。

当你意识到一个项目时,影响它通常为时已晚。

虽然我们新的和改进的定义是在您遇到风险时抓住风险的良好起点,但完全避免这些风险需要我们更好地了解迁移的计划,管理和开始的方式,地点和时间错误。

让我们确定触发点

我已经确定了导致组织决定接受迁移项目的四种常见场景。

如果您能够保持警惕并发现这些类型的事件正在展开,您就有机会允许自己插入对话,并询问以确切了解哪些类型的迁移可能正在逼近。

值得找到添加到部署列表和通知,内部项目管理工具和其他系统的方法,以便您可以查找早期警告标志(不会产生不必要的开销和通信进程)。

1.合并,收购和关闭

当品牌被买卖,合并时,这几乎普遍会触发其网站的变化。这些要求通常由高端指标决定,并且有限(或没有)影响该简报的机会。

在这些情况下的迁移策略很少是舒适的,并且几乎总是具有防御性(专注于最小化影响/成本而不是利用机会)。

通常,这些场景以少数方式表现出来:

  1. “父母”品牌将购买品牌的网站吸收到自己的网站中; 或者通过“将其固定”到其现有架构,将其移动到子域/文件夹,或者通过在其现有站点中分发可抢救内容并杀死旧站点(通常触发大多数(如果不是每种类型的迁移))。
  2. 购买的品牌网站保持原样,但经历了设计迁移模板迁移,以使其与母品牌保持一致。
  3. 品牌网站已退役并重定向(域名迁移)。
2.重新品牌

各种压力和机会导致品牌重塑活动。保持相关性,在市场中重新定位或改变品牌代表自身的压力可以触发迁移要求 - 尽管这些活动通常由品牌和创意团队领导,他们不一定了解其含义。

通常,品牌推广流程和举措的结果会对市场和消费者产生新的或替代的理解,和/或创建必须在网站上反映的新指南/宣传材料/创意。通常,这可能导致:

  1. 核心/目标受众的变化,以及用于与他们沟通的内容或语言/措辞(战略内容迁移 -如果涉及,例如,向国际受众开放,则更多)。
  2. 新的抵押品,替换或添加到现有媒体,内容和消息(内容设计迁移)。
  3. 对网站结构和域名(模板 迁移)的更改,以符合新的品牌要求。
3. C级视觉

高级利益相关者决定拯救陷入困境的企业,发展新市场或在组织中留下自己的印记的策略是推出一个全新的,有光泽的网站,这种情况并不少见。

这些决定往往涉及焦土方法,拆除其前任的工作或以前表现不佳的策略。决策者越高级,他们就越不可能理解他们决策的含义。

在这种情况下,避免灾难的最佳机会是观察警告标志,并在为时已晚之前让自己听到。特别是,您可以注意:

  1. 具有营销,IT或C级职责的高级利益相关者加入,离开或被替换(特别是如果与绩效不佳有关)。
  2. 董事会,投资者或类似的压力网络/数字团队,以实现不切实际的绩效目标(基于当前的绩效/约束)。
  3. 逐步减少日常管理的预算和资源以及改进网站(作为大型战略迁移的可能前奏)。
  4. 新的代理商被引入以优化网站性能,受到当前框架/约束的阻碍。
  5. 采用新的martech和营销自动化软件。*

* SalesForce,Marketo等类似解决方案的集成有时依赖于利用代理子域,嵌入式表单/内容以及其他需要在模板迁移过程中仔细考虑的机制。

4.技术或财务必需品

目前的网站处于如此糟糕,限制或成本无效​​的状态,这使得无法采用新的和必需的改进(例如符合新标准,新的martech堆栈的整合,品牌购买后的变化/合并等)。

一般来说,就像我上面概述的那种C级“新网站”倡议一样,这些都会导致焦土解决方案。

特别令人沮丧的是,这些迁移项目是你自己可能会争论和争取的,多年来,只有在没有你的输入或意识的情况下才发现它们已被限制(甚至可能已经开始或完成)。

以下是一些需要注意的危险迹象,这可能意味着您的迁移项目迫在眉睫(或者,至少,绝对需要):

  1. 部件或整个平台的许可成本变得成本过高(例如,企业CMS平台,用户座位,开发人员培训等)。
  2. 维护站点所需的软件或硬件技能组变得更少或更昂贵(例如,过时的技术)。
  3. 实施轻微但紧急的技术变革需要六个多月的时间。
  4. 新技术实施/集成原则上已达成一致,已编入预算但未实施。
  5. 技术积压的任务增长速度快于收缩,因为它填补了破损和修复,而不是新的功能,举措和改进。
  6. 网站生态系统不支持组织的工作方式(例如,组织采用敏捷方法,但网站仅支持瀑布式代码库版本)。
  7. 支持该网站的关键技术正在被弃用,并且没有简单的升级途径。*

*可能会触发托管或软件迁移。

我们不要指望这一点

虽然这种标签无疑在某种程度上帮助我们发现和更好地管理迁移,但它远非一个完美或完整的系统。

事实上,我怀疑它可能过于雄心勃勃,而且其愿望也不切实际。尽早访问对话 - 并在这些对话中倾听和授权 - 依赖于并非总是被SEO完全收购或迷恋的公司的善意和开放。

这只适用于对这种思维和内部挑战持开放态度的组织 - 而且很有可能,他们不是那些经常打破网站的组织。需要我们帮助的人和这种系统从根本上不适合接收它。

我怀疑,在许多情况下,可能无法做出改变行为所需的各种变化并更早地发现这些问题。至少在大多数组织中。

避免因模糊迁移项目而导致的灾难严重依赖于广泛的教育。除此之外,人们倾向于更快地改变公司,而不是建立足够深刻的部落知识。

然而,这并不意味着该结构仍然没有价值。我概述的更改和触发类型仍然可以用作警报铃声和方向供您自己使用。

让我们变得真实

如果您无法有效地教育利益相关者了解他们对网站进行更改的复杂性和影响,那么就会有更多“轻量级”解决方案。

至少,您可以将这些类型的项目(并使用您自己的,并且更详细地展开)转换为可以打印,层压和粘贴到墙上的简单列表。至少,也许你会提醒有人在认识到问题时拿起电话给SEO团队。

在一个更务实的世界中,如果利益相关者至少明白他们在更改域名时要求帮助,或者在他们的网站上添加新模板时,他们不一定必须了解细微差别或细节。 。

虽然这不能解决潜在的问题,但它确实提供了一种机制,通过该机制可以系统地避免或限制损害。您可以提前发现问题并成为对话的一部分。

如果现在还为时已晚,事情确实出错了,那么你可以指点并说“我告诉你了”,或者更具建设性地说,“这是你需要的资源,以避免下次发生这种情况。”

在你自以为是的辩护的那​​一刻,成功完成了这篇文章并且现在武装起来,让你的公司从拙劣的迁移项目中解脱出来,你可以迁移到酒吧。

所有文章
×

还剩一步!

确认邮件已发至你的邮箱。 请点击邮件中的确认链接,完成订阅。

好的