总结:一个月上权重4三个月上权重6的优化思路！

　　总结:一个月上权重4三个月上权重6的优化思路！

　　我们从7月份开始培训，不到半个月的时间，就把7月份的学员都招进来了。下半月招的学生都排在8月份。本文主要介绍其中一个网站在7月份优化的案例，用1个月的时间达到了4的权重。

　　上图是我们学生操作的一个网站案例。有一天 采集 我 网站 有 100 多人。为了更好的保护同学们的网站，为了避免被采集，所以这里我还是放了马赛克。

　　一个月前，我注册了我们并开始学习。经过一周左右的学习，开始步入实战操作的正轨。目前，大约有 2500 个 PC 关键词 和大约 1700 个移动 关键词。

　　在注册之前，这个站点已经运营了一年多，一直不温不火。只有几十个关键词。靠着市面上所谓的SEO方案优化，并没有起色。它始于七月初。注册后网站暴涨，合理避开了7月份打击恶意采集的算法。如何操作，主要分三步！

　　1. 网站结构优化

　　因为和我的长城是同一个主题，我已经优化了代码，优化问题我会反馈给主题作者，所以他的主题只需要更新一下，代码基本优化好了，所以没有需要过多考虑代码优化。

　　wpcom主题地址：

　　当然，如果你不是我们的主题之一，我们的课程也会讲到代码细节的优化。事实上，我发现很多人不知道如何为 SEO 编写代码。这是一个基本问题，因为代码优化涉及大量文本。而且不同的cms有不同的优化方法，所以如果需要学习可以报名我们的seo培训课程，当然也可以在我的公众号搜索以前的文章。

　　

　　2. 收录问题

　　这个问题自5月以来一直是很多人最关心的问题。毕竟5月份以后，所有没有备案的网站都不再是收录，而一些已经备案的网站就不是收录了，它有击中了很多站长的痛点。我觉得可以从这三个方面很好的解决。

　　小程序：小程序可以获得快捷的收录权限。基本上小程序的最低要求是收录 1天以内。当然，如果你没有公司，这个可以忽略。继续阅读。

　　热点新闻：搜索引擎使用 Aladdin 频道 收录 搜索时效性热点。说白了，他们走的是后门收录。毕竟，如果不把热点内容给收录，很容易导致搜索引擎份额的流失，所以搜索引擎对热点内容收录比较宽容。至于如何更方便地编辑热点内容收录，如何让蜘蛛通过热点内容和收录爬取非热点内容，大家可以报名参加我们的SEO培训课程，毕竟这门课主要讲的是思考，当思考变成实践的时候需要自己去实现。

　　提交：也许你认为提交没有用，但实际上提交效果很好。当然，你可能无法在几秒钟内完成。你有很多网站周刊收录，周刊收录也可以排名很好，所以我不在乎内容是不是第二收录，毕竟，周收录也可以这样排，排的速度不比第二收录慢。

　　做普通投稿的时候有个不好的地方，就是只投今天的内容，我问一下，其实老站一般每天10万个收录，而新站有少则几千 为什么给你那么多配额？无非是希望你主动提交。

　　所以我长城账户上的文章总数只有70,000。我几乎每天都提交所有文章，不管有没有收录。可能有人会觉得，这对百度不友好了，还是那句话，百度不要你提交那么多，为什么给你那么多配额？

　　也正是因为我是这样操作的，所以我长城的每周收录基本还不错。一周下来基本可以做到100%收录，当然第二个收录就没有了，主要是网站前段时间被CC和ddos了，网站一直打不开，第二个收录不见了。但是，可以肯定地说它很快就会恢复。

　　

　　3.排名问题

　　仅仅收录是不够的，因为收录和排名是两个不同的东西，我看到很多人有网站几十万收录，但是关键词只有排名几十个，我的长城号总共只有七万页，关键词排名将近六万。可以说基本上每个文章都有一个等级。

　　所以想要排名好，最重要的不是收录越多越好，而是收录质量越高越好，所以我们网站做的就是让搜索引擎 收录 高质量的内容以获得更好的排名。

　　那么这里肯定有人会说，高质量谁都知道，问题是怎么做出那么多高质量的文章？怎么批量操作还是那句话。操作问题很难用语言解释。您可以报名参加我们的SEO培训课程，我们将按照长城的优化方案进行授课。这篇文章主要是关于想法。大致如下：

　　高质量原创高质量原创一切

　　前几天我把这句话发到论坛上，可见99%的人都没有意识到这句话是什么意思，所以在这里给大家解释一下。

　　毫无疑问，优质的原创是目前百度最喜欢的内容。毕竟内容权威性、原创度、价值、时效性都是高质量的，但是多少人一天能写出多少高质量的文章呢？可以说，目前做网站的人，一天能写出100篇优质文章，还怕人家采集。

　　所以我们可以直接放弃高质量原创，用高质量来做排名，正是因为目前市面上没有网站可以做到所有高质量文章，而且数量非常多high 大，如果这个时候我们只做高质量，我们就有很大的机会排名，所以真的不重要是不是原创，不管是百度还是用户，他们想看的是有没有能解决用户问题的内容，不是作者是谁，是原创内容。

　　尽管百度一直在喊着打击恶意采集、支持优质原创的口号，但大家似乎并不觉得百度支持原创内容，因为它“恶意”采集，支持就是“高质量”原创，理解了这句话，相信你的思路就清晰了。

　　总结：本文主要是为了记录同学们的成长。顺便分析一下优化的基本思路。当然，文章字数有限，不可能全部写在一个文章里。翻看之前的文章，如果你想系统的学习，那么推荐报名我们的SEO培训课程。以下是我们部分学员近一个月的优化案例。

　　解决方案:DDD as Code：如何用代码诠释领域驱动设计？

　　简介：与常规的MVC架构相比，DDD更加抽象和难以理解，每个开发者对DDD的理解也不尽相同。那么哪种设计方法更好呢？如何在学习的时候知道哪个DDD更正统，不被别人误导？本文尝试使用“DDD as Code”的概念，即用DSL代码来描述DDD，统一DDD的设计思路，详细介绍如何通过基于ContextMapper的DSL表达来完成一个基于DDD的项目一个案例，分享现实中DDD设计中流程和微服务的关系。

　　网上有很多关于DDD的文章，这当然是好事。每个人都想掌握好的设计方法来解决软件开发中的问题。但也存在一些问题。如果随便翻开网上几篇DDD文章文章，虽然每个作者都说自己是按照DDD思想设计架构的，但是细心的同学会发现，每个作者在DDD中绘制的结构描述和架构图文章 非常不同。你会很惊讶，这些都是DDD设计吗？这里其实有个问题，就是在通过文字和插图来描述一些抽象概念的时候，会有很大的区别。不要用盲人摸象的概念来类比。这是不合适的。即使两个同学都非常了解DDD，并且实践了好几年的多个项目，写出来的东西还是不一样的。我进入Java行业的时间稍早一些。当然，你可以说我老了，保守了。记得当时没有那么多中间件。它是基于Struts 1.x的MVC框架开发的。不同同学写的设计文档也大不相同。这么简单的MVC架构，可以有不同的架构设计文档，而DDD相对来说更抽象，更难理解，所以架构设计文档长短不一，也无可厚非。你可以说我老了，保守了。记得当时没有那么多中间件。它是基于Struts 1.x的MVC框架开发的。不同同学写的设计文档也大不相同。这么简单的MVC架构，可以有不同的架构设计文档，而DDD相对来说更抽象，更难理解，所以架构设计文档长短不一，也无可厚非。你可以说我老了，保守了。记得当时没有那么多中间件。它是基于Struts 1.x的MVC框架开发的。不同同学写的设计文档也大不相同。这么简单的MVC架构，可以有不同的架构设计文档，而DDD相对来说更抽象，更难理解，所以架构设计文档长短不一，也无可厚非。

　　那么我们是否必须接受“每个作者对 DDD 的解释不必相同”、“DDD 设计文档可以以不同的形式呈现”这样的事实呢？如果真是这样的话，那么想要学习DDD的同学们的负担就会很重。哪种设计表达方式更好，更容易理解。同时，我怎么知道我学的DDD是比较正统的，没有被别人领歪。我不是说创造性思维不可以，但是从传福音的角度来说，还是要尊重理论事实。

　　我们都知道，代码在表达一些业务或者逻辑的时候，能够很好的反映真实的情况。即使是不同开发者写的，考虑到Design Pattern、命名约定、开发语言约束等，代码大体相同，还是方便的。我明白了，如果有单元测试和Code Review就更好了。这也是一些文件不完善的时候。很多同学选择看代码，也有同学说“直接看代码，不要看他们的PPT和文档，会被误导，不然不知道怎么死的”。另外，我们都知道一个非常好的实践就是Everything as Code，比如Infrastructure as Code的Terraform，Platform as code的Kubernetes YAML，Diagram as Code的PlantUML等等。我们可以使用 DDD 作为代码的概念吗？，让我们的设计更加统一，更容易表达设计思想，更容易被人理解。

　　国内专线

　　使用 DSL 意味着在代码中表达 DDD。这个由来已久，但更偏向DDD的战术设计（Tactic Design）和代码层面，如Sculptor[1]和DDD DSL[2]。一般认为，它是一个基于Xtext的DDD代码*敏*感*词*。学那么费劲，就是生成一些代码，而且只是Java代码，所以普遍关注度不是很高。

　　能不能让DDD DSL除了代码生成的部分更具有策略性的设计（Strategic Design），突出设计的思想，那么DDD as Code会更全面。接下来介绍一下ContextMapper的框架。

　　名词解释：很多同学对DDD的Strategic Design和Tactic Design的区别有些困惑。DDD有专门的介绍，如下：

　　其实比较简单。战略设计更大、更宏观。你可以理解为公司高层讨论的业务和技术方向，各个团队或产品之间的分工合作；而战术设计比较少，主要集中在一个BoundedContext内部，比如DDD的Entity、Service、Repository等如何设计，再加上应用开发可能的技术选型，可以说比较重视到技术层面。

　　ContextMapper框架介绍

　　ContextMapper是一个开源项目[3]，主要为DDD设计提供DSL支持，如DDD战略（Strategic）设计、上下文映射（Context Mapping）、BoundedContext建模和服务解耦（Service Decomposition），那么我们就拿一个看看如何基于ContextMapper完成一个基于DDD DSL表达式的项目。

　　在介绍ContextMapper的时候，我们先来介绍一下项目背景。Ruhua 是一位架构师，对 DDD 也非常熟悉，并在多个项目中实践过 DDD。近期加入会员线，负责完成会员体系的改造，更好的匹配公司的微服务设计思路。在会员专线之前，有三个应用：会员中心提供的大量REST API服务；会员注册及登录申请；会员中心，处理会员登录如修改个人密码、基本信息、SNS第三方绑定、支付方式绑定等。

　　如花加入成员团队后，跟大家交流了基于DDD+MicroServices的架构思路，大家一致认同，但是在具体的架构设计和文档上如何实现，对大家来说是有难度的。我们来看看最典型的DDD设计图：

　　SubDomain, BoundedContext, Entity, ValueObject, Service, Repository, Domain Event, Context Mapping这些概念都没错，但是怎么表达给别人呢？你总不能每次都贴上DDD设计图和分层图，然后说我是按照DDD设计的。

　　从子域开始

　　如花在DDD上的第一步是子域的划分。当然，DDD包括通用（Generic）、支持（Supporting）和核心（Core）三种SubDomains。以下是对它们之间差异的一些解释：

　　这三者的总体关系是：核心最有特色，耗费的精力也更多。在复杂度Y维度，一定要避免高复杂度的general和supporting Domains，这会分散你的注意力，同时投入大量的精力，如果真的需要，可能最好的方式就是购买服务。

　　图片来源：

　　如花首先将会员分为几个Sub Domains，比如Account用于处理账户，UserTag用于会员标记，PaymentProfile用于支付方式，SnsProfile用于社交平台整合，以及其他Profiles。这里我们不涉及Generic和Supporting Doman的规划，主要从核心业务Domain入手。一位同学用PPT解释了划分结构和出发点，如下：

　　不过也有同学说用UML的Component图比较好，方便后面和UML图统一，如下：

　　当然，还有许多其他的图形工具，例如用于显示*敏*感*词*的 Visio。DDD第一步：SubDomain的划分与展示，理解方式不同，如何描述，如何图形化展示，有很多不同。

　　回到问题的起点，我们要划分SubDomain，那么下面的DSL代码是不是也可以：

　　Domain User {

domainVisionStatement = "User domain to manage account, tags, profiles and payment profile."

Subdomain AccountDomain {

type = CORE_DOMAIN

domainVisionStatement = "Account domain to save sensitive data and authentication"

}

Subdomain UserTagDomain {

type = GENERIC_SUBDOMAIN

domainVisionStatement = "UserTag domain manage user's KV and Boolean tag"

}

Subdomain PaymentProfileDomain {

type = CORE_DOMAIN

domainVisionStatement = "User payment profile domain to manage credit/debit card, Alipay payment information"

}

Subdomain SnsProfileDomain {

type = CORE_DOMAIN

domainVisionStatement = "User Sns profile domain to manage user Sns profile for Weibo, Wechat, Facebook and Twitter."

}

Subdomain ProfilesDomain {

type = CORE_DOMAIN

domainVisionStatement = "User profiles domain to manage user basic profile, interest profile etc"

}

}

　　虽然我们还不知道对应的DSL代码语法，但是我们已经知道了域名、域类型和域视觉声明（visionStatement）。至于后面如何展示系统域，比如表格、图形等，这个可以考虑根据当前数据进行Presentation。UserTagDomain类型为GENERIC_SUBDOMAIN，表示标记为通用域。比如我们后期可以和产品、图片或者视频团队合作，大家一起搭建一个标记系统。

　　注意：Subdomain不仅包括type和domainVisionStatement，还可以添加Entity和Service。目的是为了突出核心特性，方便大家对Domain的理解。例如，将 resetPassword 和 authBySmsCode 添加到 Account 中。相信大多数人都知道这是什么意思。但是注意不要在Subdomain中加入其他对象，比如VO、Repository、Domain Event等，这些都是辅助开发，应该在BoundedContext中使用。

　　Subdomain AccountDomain {

type = CORE_DOMAIN

domainVisionStatement = "Account domain to save sensitive data and authentication"

Entity Account {

long id

String nick

String mobile

String ^email

String name

String salt

String passwd

int status

Date createdAt

Date updatedAt

}

<p>

Service AccountService {

void updatePassword(long accountId, String oldPassword, String newPassword);

void resetPassword(long acountId);

boolean authByEmail(String email, String password);

boolean authBySmsCode(String mobile, String code);

}

}

</p>

　　上下文映射

　　ContextMap主要描述了各个Domain中各个BoundedContext之间的关系，可以理解为BoundedContext的拓扑图。这里不详细介绍BoundedContext。现在你只需要把它理解为实现Domain的载体，比如你写的HSF服务应用，处理客户请求的Web应用或移动应用，或者你租用的外部SaaS系统。举个例子，你的系统有一个博客SubDomain，你可以自己开发，或者搭建一个WordPress，或者使用Medium来实现Blog。回到微服务场景，如何划分微服务应用？SubDomain 对应一个业务或者虚拟域，而 BoundedContext 是一个专门支持 SubDomain 的微服务应用。当然，

　　既然是描述每一个BoundedContext关系，必然会涉及到关联关系，比如Partnership([P][P]), Shared Kernel([SK][SK]), Customer/Supplier([C] DDD推荐

　　图片来源：

　　如果自己画图来表达这些关系，一定要下很多功夫，细化到箭头、注释的种类等等，否则会引起误解。这里直接进入ContextMapper DSL对ContextMap的描述，代码如下：

<p>ContextMap UserContextMap {

type = SYSTEM_LANDSCAPE

state = TO_BE

contains AccountContext

contains UserTagContext

contains PaymentProfileContext

contains SnsProfileContext

contains ProfilesContext

contains UserLoginContext

contains UserRegistrationContext

UserLoginContext [D]