vue单页⾯项⽬SEO优化问题
之前⽤vue做了⼀个动态官⽹项⽬，后期客户要求seo，百度上之前搜索不到官⽹地址，后来在项⽬的⼊⼝⽂件index.html页⾯加上了，固定的meta标签，加上name名为keywords、description的meta标签。
例⼦：
<meta charset="utf-8">
//下⾯这个meta标签是ie8的专⽤标记，指定ie8浏览器器模拟特定版本的ie浏览器渲染⽅式，下⾯指定的是edge
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
//在ie、360等浏览器打开时，默认使⽤极速模式，然后是兼容模式，然后是标准模式
<meta name="renderer" content="webkit|ie-comp|ie-stand">
//seo相关，百度收录时，的描述⽂字
<meta name="description" content="第⼗七届xxxxx医学⼤会">
//seo相关：百度搜索时的关键字，就是⽤那些关键字可以搜索到此⽹站
<meta name="keywords" content="中国国际xx医学⼤会，第⼗七届,xx，医学，国际">
以上做了个简单的seo优化，这个项⽬有⼏个官⽹，但是其中只有⼀个官⽹要求seo，也就是在百度能够搜索到，当时为了应急，就写死了，但是，其它的⽹站也就会受到⼲扰了，也就是对于⼀个项⽬对应⼏个官⽹，写死的meta标签做seo是不科学的。
于是下⾯⼜来寻更科学的seo优化⽅案，下⾯是⼀些相关连接，很感谢作者：
⽂中提到了关于vue单页项⽬的⼀些seo优化⽅案：
⾸先想vue、react、angular三⼤前端框架都有spa页⾯，做起来seo就很⿇烦，当然，不是必须要求⽤这三个框架就必须采⽤spa的开发模式，但是spa前后端分离的形式真的是太⽅便了，如果不采⽤spa⽅式进⾏开发，⽤古⽼的混合开发⾃然不会存在seo的问题，但是我们现在⼤多采⽤的是spa的形式开发的，
⽅案1：服务端渲染
上⾯这个截图是vue作者，为解决seo优化所提出的⼀个⽅案，服务端渲染（ssr）：官⽹链接：
如果项⽬刚开始就考虑到seo，采⽤服务端渲染，那么就⽤服务端渲染就得了。
但是⼀般来讲，项⽬做到后期才会考虑到seo的问题，这时再去搞服务端渲染，相当于重头写项⽬，⾮常耗费⼈⼒物⼒。
那么，不采⽤服务端渲染该如何最⼤程度解决seo问题呢？
⽅案2：预渲染
原⽂链接：
这⽐服务端渲染要简单很多，⽽且可以配合来⽣成title和meta标签，基本可以满⾜SEO的需求
TIPS: 使⽤预渲染vue-router必须使⽤history模式
// 安装
npm install prerender-spa-plugin --save-dev
然后在f.js⾥⾯添加：cli3项⽬在fig.js⽂件中配置
// 头部引⼊
const PrerenderSPAPlugin = require('prerender-spa-plugin')
const Renderer = PrerenderSPAPlugin.PuppeteerRenderer
在plugins⾥⾯添加：
config.js
const webpack = require('webpack');
const path = require('path');
const CompressionPlugin = require('compression-webpack-plugin');//引⼊gzip压缩插件
// 预渲染
const PrerenderSPAPlugin = require('prerender-spa-plugin')
const Renderer = PrerenderSPAPlugin.PuppeteerRenderer
function resolve(dir) {
return path.join(__dirname, dir)
}
  // 选项...
//基本路径
publicPath: v.NODE_ENV === 'production'? '/': '/',//部署服务器的路径默认在根路径上(影响静态资源的引⽤路径)    outputDir: 'customizationWeb',
assetsDir: 'static',
productionSourceMap:false,//打包时不要map⽂件
// filenameHashing: true,
  devServer: {
  port: 9522,
proxy:{
'/qiantai':{
target:':xxxx',
changeOrigin: true,
pathRewrite: {
"^/qiantai": ''
}
}
}
},
configureWebpack:()=> {
if (v.NODE_ENV === 'development'){
return {
externals: {//如果不想影响开发环境，这⾥也要配置externals  没⽤它的就不⽤在开发环境也配置⼀份了
'vue': 'Vue',
'vuex': 'Vuex',
// 'vue-router': 'VueRouter',
'Axios':'axios'
},
}
}else{
return {
externals: {
'vue': 'Vue',
'vuex': 'Vuex',
// 'vue-router': 'VueRouter',
'Axios':'axios'
},
plugins: [
new CompressionPlugin({//gzip压缩配置
test:/\.js$|\.html$|\.css/,//匹配⽂件名
threshold:10240,//对超过10kb的数据进⾏压缩
deleteOriginalAssets:false,//是否删除原⽂件
}),
new PrerenderSPAPlugin({
/
/ ⽣成⽂件的路径，也可以与webpakc打包的⼀致。
// 下⾯这句话⾮常重要
// 这个⽬录只能有⼀级，如果⽬录层次⼤于⼀级，在⽣成的时候不会有任何错误提⽰，在预渲染的时候只会卡着不动。              staticDir: path.join(__dirname, 'customizationWeb'),
// 对应⾃⼰的路由⽂件，⽐如a有参数，就需要写成 /a/param1。
routes: ['/'],
// 这个很重要，如果没有配置这段，也不会进⾏预编译
renderer: new Renderer({
inject: {
foo: 'bar'
},
headless: false,
// 在 main.js 中 document.dispatchEvent(new Event('render-event'))，两者的事件名称要对应上。
renderAfterDocumentEvent: 'render-event'
})
})
]
}
}
},
chainWebpack(config) {
// set svg-sprite-loader
.
rule('svg')
.exclude.add(resolve('src/icons'))
.rule('icons')
.test(/\.svg$/)
.include.add(resolve('src/icons'))
.end()
.use('svg-sprite-loader')
.loader('svg-sprite-loader')
.options({
symbolId: 'icon-[name]'
})
.end()
// 打包依赖分析
// config
//  .plugin('webpack-bundle-analyzer')
//  .use(require('webpack-bundle-analyzer').BundleAnalyzerPlugin)
}
}
绿⾊背景的代码是预渲染相关都⼆代码
在main.js加上这点代码：
new Vue({
router,
store,
render: h => h(App),
mounted: () => document.dispatchEvent(new Event("x-app-rendered")),
mounted() {
document.dispatchEvent(new Event('render-event'))
},
}).$mount("#app");
这种操作不需要你去添加任何⼀段代码，直接npm run build，dist⽂件中就有你写的⼏个html静态⽂件。
然后运⾏npm run build
发现打包好的index.html中多了⼀⼤堆的代码，部署到nginx上试试看看什么效果
下⾯的报错是之前⽤另⼀种⽅式 vue add 什么什么的全⾃动做预渲染的，⽹上可以查查，打包后会出现这些坑，第⼆次直接按照以上的步骤就没有下⾯的问题了
和其它⼈⼀样，⼀直打包不成功，有错误：
然后和⼤佬们的⼀样安装
npm i puppeteer    太慢
直接⽤cnpm i puppeteer  就⾏分分钟下载好
之后再执⾏npm run build
还是上⾯的报错：
查⼀下这个报错：
使⽤cnpm或者
npm config set puppeteer_download_host=/mirrors
npm i puppeteer
然后下载成功了，也不慢，
之后打包npm run build
打包成功，index.html中多了好多代码，但是本地运⾏项⽬出问题了，后续接着看
搞了半天，感觉对于纯动态的页⾯，预渲染好像并⽆卵⽤。因为动态获取的内容，预渲染是预渲染不出来的，还的看服务端渲染，。。。
这是⼀位⼤佬的⽂章，付费的哦：
想了想，我掏钱了，我的把⼤佬的⽂章偷来，给⼤家免费看，嘻嘻：复制粘贴⾛起：
-
------------------------------------------------------------------------------------------------------------------------------------------------------
前⾔
如果开发需要复杂交互的 Web 应⽤，我们多半会选择 SPA；如果要做提供内容资讯的⽹站，更有利于 SEO、加载速度更快的服务器端渲染（Server-Side Rendering，SSR）⾃然是⼤家的⾸选；那么，如果是⼀个 CMS ⽣成纯静态⽹页呢？
前阵⼦公司官⽹升级，我尝试⽤ Webpack 多页配置，成功的升级了⼯具链，收获了⽐较理想的效果。我还写了⼀篇 Chat 分享这期间的收获：。实际运⾏⼀阵⼦之后，我发现⼀些新问题：这套技术链对于⾮前端开发者来说，还真算不上简单，开发环境搭建、不同⽂件的功⽤，对后端同事来说仍然显得很复杂。于是，有时候虽然只是⼩⼩的⽂案错误，也要我来改；或者“加⼊我们”页⾯⾥的岗位信息，也需要熟悉代码的前端负责增删。
于是我就想，能否把各页⾯以 Vue 组件的形式搭建起来，每个组件可以有“编辑/显⽰”两个状态，在本地启动开发环境，在浏览器⾥“编辑”内容，⽤户可以获得所见即所得的体验。最后以“显⽰”状态渲染成静态页，继续使⽤纯静态的⽅式部署。这就相当于，基于原先的项⽬开发⼀个所见即所得 CMS，把原先的静态 HTML（或 Pug）页⾯改造成 Vue 页⾯，然后利⽤ Vue 的 SSR 机制发布成纯静态 HTML。感觉上
是个不错的想法。
我以前只是听说过 SSR，⼀直没有实操经验，有了这个想法之后，就想研究下这个过程，搞个最⼩⽤例，将来官⽹升级 3.0 的时候可以考虑。我本以为只是举⼿之劳，最多 1，2 个⼩时就搞定了，没想到最后折腾了⼤半天。所以我觉得，很有必要再写⼀篇 Chat，分享这个过程中的收获。
本次分享⼤纲如下：
1. ⽹页形态的历史
2. Vue CMS 的产品形态
3. 了解 Nuxt.js
4. ⽣成静态页的相关配置
5. 添加 SEO 关键信息
6. 注⼊专有 JS
⾯向读者
1. 初中级开发者，熟悉 Vue
2. 希望了解前端⼯具链
3. 希望了解静态化和 Nuxt.js
名词及约定
我假定所有读者都是有⼀定经验的开发者，⼤家⾄少都具备：
1. 能读懂 JavaScript
2. 了解 Vue，使⽤过 Vue 开发项⽬
3. 知道 Webpack，了解前端⼯具链中各⼯具的⾓⾊和基础⽤法
其它约定：
1. 为节省时间，范例代码中的 HTML 会以 pug 书写，这种语⾔很容易阅读，⽂中也⽤不到⾼级语法，应该问题不⼤。另外，如果你还在写
原⽣ HTML 或 CSS，我建议你尽快切换到新语⾔。
2. 范例代码以 ES6+ 为基础，如果你对这些“新”语法不熟悉，附录⾥有⼀些资源⽅便你学习。
名词：
1. SEO：搜索引擎优化。指改进⽹页，让搜索引擎更容易理解它的内容，提⾼页⾯的排名。
2. CMS：发布系统。没有特指的话，特指本⽂中发布静态页的⼯具。
⽂中代码的⽬标环境：
1. Vue >=
2.6
2. Vue-router >=
3.1
3. Nuxt.js >= 2.8
作者介绍
⼤家好，我叫翟路佳，花名“⾁⼭”，这个名字跟 Dota 没关系，从⾼中起伴随我到现在。
我热爱编程，喜欢学习，喜欢分享，从业⼗余年，投⼊的⽐较多，学习积累到的也⽐较多，对前端⽅⽅⾯⾯都有所了解，希望能与⼤家分享。
我兴趣爱好⽐较⼴泛，尤其喜欢旅游，欢迎⼤家相互交流。
我⽬前就职于 OpenResty Inc.，定居⼴州。
你可以在这⾥到我：
或者通过联系我。
编程入门先学js限于个⼈能⼒、知识视野、⽂字技术不⾜，⽂中难免有疏漏差错，如果你有任何疑问，欢迎在任何时间通过任何形式向我提出，我⼀定尽快答复修改。
再次感谢⼤家。
⽹页形态的发展
在正式开始之前，先介绍⼀下⽹页形态发展的历史，⽅便⼤家理解。
远古时期：纯静态
发明 HTML 的⽬的是⽅便⼤家看论⽂⽂献，所以早期的 HTML 都是静态的，放在服务器上，直接映射本地⽂件⽬录结构。
当然那个时候也没多少⽹页，很多服务并没有⽹页版本，⽐如论坛，是以 Telnet 形式提供服务的；⽂件共享，⼤多使⽤ FTP。
古典时期：动态⽹站
所谓“动态⽹站”，就是根据⽤户请求，返回合适的内容。或者换⽤技术的说法，接受请求之后，从数据库中读取数据，⽣成页⾯，返回给⽤户。其实现在没什么⽹站不是动态⽹站了，感觉这是个上个世纪的词，⽐如去京东上搜“动态⽹站”，能搜到⼀⼤堆书，⼤多有着深刻的时代印记，⽐如《ASP+Dreamweaver动态⽹站开发》，简直辣眼睛。
⽂艺复兴：伪静态
相⽐于纯静态⽹站⽽⾔，动态⽹站通常需要更长的响应时间，⽽且 URL 也经常难以阅读。⽐如：/post.php?id=157，没⼈知道它是什么意思。这个时期的搜索引擎也⽐较弱，⾯对类似的⽹页，会降低权重。所以⽹站运营⽅要想办法改进 SEO，就⽤服务器 rewrite 的⽅式，把形似静态页的路径指向
动态路径，提升搜索排名。
伪静态常常和真静态共同⼯作，这个阶段 CDN 还不够普及，所以⽣成静态页⾯并部署到终端服务器的操作也很常见。
近代：SPA
随着各项技术的发展，浏览器在整个互联⽹产品中的地位越来越重要，承担的职责也越来越多，最终单页应⽤（Single Page Application，简称 SPA）脱颖⽽出，成为最流⾏的产品形态。关于它的好处我就不⼀⼀叙说了，相信⼤家都了解。
⽽接下来，MVVM 框架横空出世，⼀统江湖，更是⼤⼤提升了 SPA 的开发体验，同时⼤⼤降低了⼊门门槛。然后，类似的产品如⾬后春笋搬涌现。
现代：SPA + SSR
SEO 的问题在 SPA 这⾥更明显：对于⼀些不思进取的搜索引擎爬⾍来说，SPA 应⽤⾥什么内容都没有。⽽不思进取，是很多统治级公司、统治级产品的常态。所以没办法，它们不适配我们，我们就得去适配它们。然后，服务器端渲染（Server-Side Rendering，简称 SSR）就显得⾮常必要。
SPA 的 SSR 和以前的伪静态不同。伪静态时期，业务逻辑都是通过后端完成的，前端主要⽤来收集数据；SPA 时期，⼤部分业务逻辑已经移到前端，后端只负责数据校验和必要的存储。此时 SSR 的⽬的是让⽤户尽快看到第⼀波需要的数据，接下来的操作仍然由 SPA 负责。所以我们就⾯临两种选择：
1. 前后端共⽤⼀套模板，渲染后的页⾯拥有全部功能，可以继续与⽤户交互
2. 部分页⾯⽣成纯静态内容，可以部署在服务器上；其它重交互的部分保持 SPA，独⽴⼯作

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。