一个想法，是否存在只渲染 header 的服务端渲染技术？

做过 SEO 相关的需求，需求做的比较简单。简要来说涉及 tdk 优化（ title ，description ，keyword 这三 meta 标签），jsonld 结构化搜索，url 缩短，图片 Alt ，sitemap ，内容重复检测，链接 404 检测等。

但是有个更大的问题, 一般要做 seo 优化, 那就涉及到了整个页面的内容提供给搜索引擎读取了, 简单讲就是内容的索引. 如果只处理 header 的话, 其实就相当于只能检索到 meta 里面的东西, 那么讲道理你这项目需要的不是 seo, 只是动态改一下 meta 里面的数据就够了...seo 在我看来只适合企业官网、以及以内容为商业化输出的页面.

想多了， 信网站自述尤其是 header 自述是 2000 年前搜索引擎的搞法，google 搞 PR 体系就是因为有大量网站通过自述作弊， 零几年的时候 google 还说过 header 部分是没什么特殊权重的(不是完全没用， 是比起 body 部分没特殊权重), 国内大量 SEO 文章强调 header 是因为都在洗十年前玩培训割 SEO 韭菜那波的稿， 而十年前国内割 SEO 韭菜发的文章都是抄的再十年前的国外的 SEO 文章.......SEO 其实真的无它， 养高相关性的站群， 不过现在也没多少人玩儿了......

@wu67

商业化的内容其实和 SEO 更没关系， 真正意义上属于 SEO 的最后一波狂欢是利用长尾词去做商业产品的单页站群， 但那已经是北京奥运的事了........

商业化平台其实就一句， 不充钱你怎么变得更强.......关键是怎么高效的砸竞价.........

根据我的经验，百度和谷歌都会抓取具体的正文和图片，所以我前几天新开的坑就是利用假期用 next 写一个完全静态的个人网站

刚好遇到和你部分相同的需求，这里是标签列表，我希望如果是爬虫就列出全部，如果是真实客户端就列出随机 12 个

具体到 next 上，就是

import shuffle from 'lodash/shuffle';
import take from 'lodash/take';
// database 是我用 ts 实现的前端数据库
import Database from '/database';

// 此时 tagList 是可预测的，没有脱离 SSG
const tagList = Database.select().where().from('tag').toList();

const TagListElement = function() : ReactElement {
// list 也是可以预测的，由于 SSG 阶段不存在 window ，所以最终生成就是完整的列表
--const [list,listSetter] = useState<Tag>(tagList);
--useEffect(function(){
----if(!window){return;}
----// 当是浏览器的时候就替换成随机 12 个
----const clientList = take(shuffle(tagList),12);
----listSetter(clientList);
--},[listSetter]);
--return <div ... />
};

由于在浏览器里面替换足够快（数据是现成的），所以真实访客看起来这里就是 12 个随机标签，他完全不会想到这里几毫秒之前是一大堆东西

这套玩意的缺点就是一个超大的 database.[content-hash].js ，我现在迁移了 80 多个文章或页面，这个文件已经超过 100 KiB 了

"""
Google 是否曾在确定网页搜索排名时考虑过 keywords 元标记？
简言之，不曾有过。Google 确实有销售 Google Search Appliance ，且该产品具有匹配元标记的功能，其中可能包含 keywords 元标记。但该企业搜索工具完全独立于我们的主要网页搜索。我们的网页搜索（大家熟知的 Google.com 搜索，每天有数亿人使用）会完全无视 keywords 元标记。此类元标记目前对我们的搜索排名没有任何影响。

Google 为什么不使用 keywords 元标记？
大约十年以前，搜索引擎仅根据网页内容而非任何所谓的“页外”因素（例如指向网页的链接）评判网页。在那个阶段，keywords 元标记迅速成为堆叠通常毫无关联的关键字来影响网页排名的手段，而访问者通常不会在网页中见到这些关键字。因为 keywords 元标记经常被滥用，所以许多年前 Google 就开始无视 keywords 元标记。

这是否意味着 Google 会忽略所有元标记？
不是，Google 会支持其他若干元标记。此元标记页面列有关于我们使用的若干元标记的更多信息。例如，我们有时会使用 description 元标记作为搜索结果摘要的文本，如以下屏幕截图所示：


虽然我们有时会对所显示的摘要使用 description 元标记，但在确定网页排名时依然不会考虑 description 元标记。

这是否意味着 Google 会始终无视 keywords 元标记？
Google 将来可能会使用此类信息，但可能性不大。Google 已忽略 keywords 元标记多年，目前我们不需要更改该政策。
"""
摘一下吧， 我就记得 google 强调是 html head meta 是没特殊权重的

搜索引擎又不是只分析你的 header,它的重点是抓取你的网页主要内容进行分析

@westoy 感谢分享，学到很多知识，所以综合看下你的内容，结论是 SEO 本身在今天的互联网环境下用处不大，如果需要则最好是靠充钱变强，最后才是 ssr 渲染整个页面，而且渲染了也未必搜得到？

@LeeReamond

商业化内容直接充钱变强啊， 这个研究方向是怎么提高竞价效率， 怎么挖掘低价和高 ROI 的关键词， 还有复购的转化。 这个不止搜索引擎， 找自媒体恰饭， 找网红带货都属于这个范畴的

非商业化的可以做做， 但是权重大头也在外链上， 网站本身只要保证页面结构清晰就可以了

新网站最好不要用 SSR 。 SSR 是可以读到的， 这个是没问题， 问题是搜索引擎为了防止网站针对性吐数据作弊， 都会通过非标准的 IP 段和 UA 去检测， 那时候可能触发的就是单页内容了， 虽然理论上都具备读取能力， 但是多少会挖一些坑存在误盘(google 当年推出过一套标准， 通过读取_escaped_fragment_参数的输出去爬 ajax 输出， 结果坑死一堆照着做的网站)， 但是对于权重已经上去基本不会被搜索引擎误判的就无所谓了。

这不就上古技术 turbolinks 嘛


https://github.com/turbolinks/turbolinks

body 全替换，header 合并。。。。当年 ruby on rails 把这个玩出了花～～～～～～～

看着目前掘金网站就是这么玩的，你可以打开他的一篇文章看下，header 中有该文章相关的内容，实际内容再通过 js 进行渲染，不过我不知道他这个网站的 seo 效果怎样。

@wenzichel 掘金 seo 效果还行 因为他们对搜索引擎提供的是完整的网页内容 模拟蜘蛛抓取一下就知道了