网站建设

WordPress百度自动推送JS优化,规避错误、重复推送问题

导读:关注SEO、关注收录的站长,应该都知道百度搜索提供了一段自动推送的js代码,可将任意网页推送到搜索引擎,加快收录。但是,这段代码并不是简单的增加到网页中万事大吉了!百度埋坑技术,你我都懂的!本文主要分享埋坑之自动推送JS代码的优化... 一、问题描述 百度近些年推出过多种收录推送工具,比如结构化数据插件、主动推送、自动推送js等等。每一次张戈都会对这些东西进行优化处理,主要是因为这些工具都会出现重复推送的弊病!虽然百度并没有申明重复推送会带来什么副作用。但根据我个人的经验,同一篇文章,如果重复推送,可能会让百度蜘蛛认为你这文章更新频繁,不稳定从而进入收录沙盒短期内不会展示! 这一点,在以往的文章中我都反复提出过: BaiduSubmit:百度WordPress结构化数据插件(改进版) WordPress百度链接主动提交插件:Baidu-links-submit优化版 WordPress发布文章主动推送到百度,加快收录保护原创 对于百度最新推出的自动推送JS代码,通过站长平台的反馈来看,依然存在重复推送的坑: Ps:看到这个回复,其实我是打心底鄙视了百度一把!这js只需要添加到新页面?那新页面收录之后,我们再去删除js代码?那我还要经常关注页面是不是被收录?那几万个页面的网站还得靠工具检测咯? 重复推送到底有没有副作用,百度并没有给我明确的答复。不过管理员明确回复,无需添加主动推送,就算是没有副作用,已收录的页面也添加自动推送js代码,也会浪费每天的可推送额度( 当天剩余的可推送url条数)! 另外,我们知道,很多时候多个url地址其实是同一个页面内容,比如: 而且,当我们给页面带上查询参数,显示的依然是同一个页面内容,但是Url地址变了!!那么自动推送js获取到的Url也变了!它就会将这个 Url 推送到搜索引擎!实际上,这些相同内容的页面我们并不希望重复抓取和收录! 二、问题解决 根据上面的分析,这类自动推送js代码就不能整站添加,而是只需添加到未收录且正规Url的页面。 比如: https://zhang.ge/5093.html 百度已收录,这种页面不添加 https://zhang.ge/5096.html 百度未收录,这种页面要添加 https://zhang.ge/5096.html?from_weixin 百度未收录,但属于重复内容页面,所以不添加 已收录、未收录的判断,关注张戈博客的朋友肯定记得我之前在博客分享过百度是否收录的插件和代码吧!而对于是否是正规页面,也只需要添加一个简单判断。 如上PHP代码,添加到主题functions.php即可。当页面未被百度收录,且被访问的页面地址等于WordPress唯一页面地址时,将会输出百度自动推送js代码,不符合条件的页面则不会输出。 2016年5月31日更新说明:有朋友反馈收录判断不准确,花时间DEBUG看了下,发现抓取到的百度搜索结果可能是空白内容等错误内容,导致判断为已收录! 所以,上述代码加入百度搜索结果必要关键词【百度为您找到相关结果】的条件判断,目前来看应该比较准确了,已在使用的朋友请更新到最新代码。 三、其他说明 和以前分享的百度是否收录代码一样的工作原理,文章加载时,会在百度搜索当前文章的url地址,如果百度未收录,查询结果中会匹配到【没有找到该URL。您可以直接访问】或【很抱歉,没有找到与】文字内容。当代码确认页面已收录时,将会在文章中添加一个值为1的 baidu_record 自定义栏目。 只有当 baidu_record 这个自定义栏目的值不存在时,代码才会去百度查询收录结果。并且在确认未收录之后,才会在网页 footer 中输出自动推送js代码。 这样就规避了已收录页面重复推送和百度实时查询导致加载慢两个问题! 另外,其实还有另一个值得关注的坑:百度统计代码也会自动推送,是否也存在本文提到的问题,就不得而知了。 最后,顺便说明一下,360搜索也推出了主动收录js代码,喜欢折腾的朋友可以参考本文进行优化。 效果补充:实施后,自动推送数量以从200+降为20+,说明已收录的文章不会重复推送了。
阅读全文
shell脚本实现整站缓存和预缓存,进一步提升网站整体加载速度 网站建设

shell脚本实现整站缓存和预缓存,进一步提升网站整体加载速度

在Linux中,shell脚本结合系统任务计划crontab,非常简单就能实现一些复杂程序才能完成的工作,开发成本低,且简单易学。 张戈博客之前也分享过不少shell在网站运营方面的妙用,比如: CCKiller:Linux轻量级CC攻击防御工具,秒级检查、自动拉黑和释放 SEO技巧:Shell脚本自动提交网站404死链到搜索引擎 Linux/vps本地七天循环备份和七牛远程备份脚本 nginx日志切割及7天前的历史日志删除脚本 Shell+Curl网站健康状态检查脚本,抓出中国博客联盟失联站点 感兴趣的可以挑选看一看。 本文继续分享一个shell的实用案例:全站缓存和定时预缓存,进一步提供网站速度。 一、何为预缓存 用过WP-Super-cache插件的站长肯定都知道,这个插件有一个预缓存功能,开启此功能后,插件会对全站预先缓存一遍,并且后面还会定期更新缓存。 显而易见,全站预缓存的好处就是在用户访问之前,就已经生成了静态缓存,而不是被用户访问触发才生成缓存,那么所有用户来访问几乎都是静态缓存,不管是平均还是总体速度都会有质的提升!当然,最重要还是优化了蜘蛛抓取的速度! 大家去百度站长平台查看那个抓取频次的时候,可以看到蜘蛛的平均耗时数据,我博客做了静态缓存,按理说每个抓取都不会超过500ms,但是依然会出现一些十几二十秒的请求: 排除蜘蛛抓取的时候存在网络延时或并发负载等情况,还有一个很可能的原因就是蜘蛛正好抓取了一个缓存过期或缓存不存在的页面,也就是说蜘蛛抓取的时候,这个页面缓存正好过期被删除了,那么它抓取的时候就是动态页面,所以耗时就上去了! 因此,全站预缓存还是有必要的。 二、预缓存前身 见识到预缓存的重要性,那么就该想办法实现了。分享方法之前,先说一下灵感来源吧! 记得博客之前分享过各种Wordpress缓存方案,有php代码版本、有nginx的 fastcig缓存等等,当时有人问,有没有办法让sitemap也静态缓存(纯代码版本sitemap)? 当时是对sitemap.php伪静态成sitemap.xml的,所以是动态数据的,而且就放在根目录,所以直接访问sitemap.php也是可以的,由于是全站数据,所以这个文件跑起来很慢! 后来,我用linux命令+crontab就解决了这个需求:将sitemap.php放到某个不为人知的目录,然后定时使用wget去请求这个文件,并将数据保存为sitemap.xml存放到网站根目录就可以了!比如: Ps:使用这个方法,注意sitemap.php里面的 require('./wp-blog-header.php'); 要改成 require('../wp-blog-header.php'); 也就是注意相对位置! 这样一来,就解决了sitemap.xml是动态数据问题了! 三、全站预缓存 有了上面的案例,如果实现全站预缓存真的太简单了。 可以有如下多种实现形式: ①、已有缓存功能的博客 对于已有缓存功能的博客,比如安装了缓存插件,或使用了nginx缓存,那么只需要从数据库拉出所有文章id或别名,然后组成页面地址,最后使用wget或curl全部请求一遍即可实现缓存,比如: 但是,各个博客的固定地址可能不一样,所以这样拼接ID或别名,不能照搬,而且分类、tag等都没覆盖到位,甚是遗憾。 我也懒得研究如何从数据库弄出所有页面,最后用了一招偷懒的办法:从sitemap.xml中获取页面地址! 几乎每个网站都会有一个sitemap.xml文件,如果你网站没有,那么还是先参考前文弄一个吧! 所以脚本可以改成如下代码: 将此代码按实际修改后保存为 g_cache.sh ,上传到Linux系统,比如就放到 /root 目录,先手工执行看看是否成功: bash /root/g_cache.sh 如图,如果没有报错(图中的骇人速度无需在意,和磁盘IO有关),最后新增一个任务计划即可: duang的一下,就搞定了! ②、没有缓存的博客 没有缓存的博客,说明你不喜欢缓存,可能也没必要开启缓存,所以下面只是为了保持文章的完整性而写的,大家选择性看看就好! 没有缓存的博客,要全站预缓存有2个途径: 安装缓存插件或开启其他缓存后,再用方法①实现 我就不开启缓存,但是我还是要用全站预缓存,你说怎么办吧! 第1个途径就没必要啰嗦了,简单分享第2种如何实现吧。 从第①步中可以看到,我们只请求页面,但是不保存数据,全部扔黑洞了。那如果我将数据保存为对应的html文件,并存放在网站对应的目录下呢?那不就实现了和cos-real-html插件一样的静态缓存了吗? 很明显还是可以的!代码如下: 按照实际情况,修改代码中的网站根目录和缓存白名单,保存为 g_cache.sh 上传到服务器,接着我们需要新增一个Nginx 伪静态,其实就和之前wp-super-cache的一样: 保存之后,reload 重载 nginx 以生效。 最后,如下新建计划任务,定时执行 g_cache.sh: 如此就实现了wp-super-cache预缓存和cos-real-hmtl的静态缓存功能了。 四、最后的啰嗦 其实,个人觉得本文最大的亮点是最后一个脚本,及实现了缓存,也实现了预缓存,神马缓存插件、神马伪静态都可以丢一边了!而且,只要网站有sitemap.xml文件,那么就可以实现静态缓存,而且不局限与建站程序是什么! 但是,除了爽,我们还是有一些要注意的细节,请务必仔细看看。 ①、hosts解析 由于是在服务器本地全站抓取,为了提高速度,缩短路径,强烈推荐在hosts中将网站域名解析到服务器IP,不在走外部DNS解析,以减少解析时间,或者CDN消耗。 很简单,编辑 /etc/hosts 文件,在里面插入一条解析即可,比如: 127.0.0.1  zhang.ge 最后,保存即可。 ②、生成间隔 文章中分享的计划任务都是1天一次,如果你觉得有必要缩短间隔,可以自行修改crontab语句,具体可以搜索下crontab配置,了解crontab中 分 时 日 月 周得定义,此处不再赘述。 ③、缓存删除 本文只分享了如何生成缓存,并没有说如何自动删除缓存。整体上来说,反正crontab会定期重新生成缓存的,原则上并不用去理会自动刷新缓存。 但是,往往一些强迫症看到评论不刷新,文章修改了也不刷新,就抓耳挠腮,好不舒服。所以这里还是指明一条出路。。。 对于已有缓存功能的网站,使用这个预缓存脚本,实际上不会有任何影响,之前有自动刷新缓存的话,现在依然会刷新,无需操作。 对于使用最后一个脚本的网站,也就实现了和之前分享的php生成html缓存同样的功能,如果想更新文章或提交评论的时候删除这个缓存,可以参考博客之前的文章,修改下缓存路径即可搞定: WP Super Cache静态缓存插件纯代码版(兼容多域名网站) 哦了,分享到此,有事留字。。。 最新补充:偷懒用sitemap.xml的方法感觉有点Low,所以还是提供一下没有sitemap.xml的方案吧!为了不和上面的内容混淆,还是另起一页,有需求的可以看看,没需求的请忽略。
阅读全文
网站建设

一行代码彻底禁用WordPress缩略图自动裁剪功能

记得在博客分享七牛缩略图教程的时候,提到过 WordPress 默认会将上传的图片裁剪成多个,不但占用磁盘空间,也会拖慢网站性能,相当闹心! 当时也提到了解决办法: ①、关闭主题自带缩略图裁剪功能(若有); ②、多媒体设置里面,将所有尺寸都设置为0。 详见:《WordPress简单代码开启七牛CDN及集成七牛缩略图的方法》—谈图片尺寸 而自从WordPress升级4.4之后,推出了srcset这个图片多屏自适应功能之后,这个恶心的裁剪又出现了,用新版本 WordPress 的朋友可以查看下你的图片目录,是不是有这样的情况: 之前不是禁用了裁剪么?还真是春风吹又生啊!看来得下猛料才行了! 全盘搜了半天文件关键词  thumbnail ,找到了如下代码: 看得出,这是设置图片裁剪尺寸的函数,而且很明显调用了 add_image_size 这个函数功能,继续搜索了解了到  add_image_size 这个函数的功能是“注册一个新的图片尺寸,意味着你上传新的图片,WordPress 就会创建一个按照这个尺寸的新特色图片。” 尼玛,看来这才是本文的“罪魁祸首”!如果想彻底禁止 WordPress 私自裁剪图片,就只能干掉这个函数了! 最野蛮粗暴的方法就是找到这个函数,然后在函数里面加入retrun 返回即可,也就是让函数中的代码见鬼去。。。但是,这样的做法实操性太烂,每次更新WordPress都得重新来一遍,好不苦逼! 通过观摩网上已有的一些禁止某个功能的做法,得出了一个比较合理的做法: 将上述代码复制到 WordPress 主题 functions.php 里面即可彻底禁止缩略图裁剪功能。 其实和上文提到的野蛮粗暴的方法原理是一样的,就是在函数里面硬插入一个return,将这个函数废弃掉了! 到这里,本文相关内容就分享完了,但如果你只满足于此,那还是只学到了鱼,而不是渔! 那本文的渔是什么呢? 下一页告诉你... 2017-03-14更新:很多同学反馈使用本文提供的方法之后,仍然会生成缩略图,由于太忙也没去深究以及持续检查图片目录,今天博友牧羊人在文章留言告知,使用上述代码后,仍然会生成一个768像素缩略图,并且给出了一个解决办法:《wordpress4.4+版本自动生成一个768w像素缩略图的解决办法》,我看了下代码,确实是一个根因:在WordPress 4.4版本安装/更新的时候会将这个尺寸写入到options中,导致后面会一直生成这个尺寸缩略图。 当然,前人这个解决方案是要修改数据库,不是很方便。实际上,一直关注张戈博客的朋友,可能还记得之前介绍过的一个WordPress上帝模式,那这里的解决办法就简单了: 打开WordPress上帝模式(后台一次点击【设置】-->【全部设置】),然后在浏览器按下Ctrl+F搜索medium_large_size_w,找到如下位置: 将值改为0,然后拉到页面底部,点击【保存更改】即可。
阅读全文
网站建设

WordPress发布/更新文章、提交/审核评论自动清理VeryCloud缓存

上一篇文章分享了WordPress发布文章评论自动刷新腾讯云CDN的教程,而博客现在还用到了VeryCloud的CDN,正好有朋友在文章后面留言说VC也有刷新缓存的API,于是就利用中午的时间折腾了下,成功搞定! 下面分享一下部署方法。 将以上代码粘贴到WordPress主题functions.php中,然后将 19,20行对应的中文改成VeryCloud的用户名和密码,保存即可。 Ps:貌似VC的缓存刷新API暂时还没完全公开,如果需要部署这个功能,需要联系客服,然后告知需要使用这个刷新CDN缓存的API,然后提供以下用户名给他就好了。而且代码中的lockstream的值可能需要VC客服提供,如果发现上述代码无法成功,请自行咨询VC客服。 部署好了之后,可以去更新文章或提交评论,然后登陆VeryCloud云分发后台,即可看到提交记录: 至此,说明你已部署成功。
阅读全文
网站建设

WordPress发布/更新文章、提交/审核评论自动清理腾讯云CDN缓存

目前张戈博客同时使用了腾讯云、VeryCloud以及七牛CDN,其中腾讯云负责电信线路流量,VeryCloud负责默认线路流量,而七牛主要是用于缩略图展示,你觉得这样做有什么好处? 一、兵分三路 本来博客自身就有PHP缩略图功能,不过腾讯云缓存后,这个带参数的缩略图经常出50x等问题,所以只好弃用。腾讯云负责电信线路的原因只有一个:其实没鸟用的安全认证(也就是QQ聊天的绿色钩钩),这里简单分享下吧: 不使用腾讯云的主机也能获得安全认证的方法: 很简单,使用腾讯云CDN即可,道理也挺简单,安全认证它检测的就是你的网站是否解析到了腾讯服务器,而且只检测电信线路!如果是腾讯的服务器,那么就可以通过安全认证申请,而且是不定期检查,如果发现解析到了别家的IP,呵呵,认证就取消了。 申请认证地址:http://console.qcloud.com/security 所以,为了这个没啥鸟用的认证,我还是将电信线路解析到了腾讯云CDN。当然,好处还是很明显的:3家CDN都有50G免费流量(其中七牛邀请朋友注册还送了40G),加起来就是150G流量,相信绝大部分博客是够用了吧? 好了,扯得有点远了,回归正题。 二、部署代码 同时使用3个CDN,其中VC和腾讯云的CDN主要是负责主站缓存,也就是html页面。相当于套了一次百度云加速一样。再设定下CDN缓存时间,比如1天,那么文章或评论有更新就得1天后才能刷新了。 偶然了下腾讯云CDN的WIKI,发现其实腾讯云提供了非常丰富的API接口,其中就包含了清理CDN缓存,感觉这个不错,于是就花时间折腾了下。 在腾讯云CDN开发大牛廖大师的指点下,成功搞定了WP发布文章或评论刷新腾讯云CDN缓存,下面开始分享。 完整的php代码如下: 先访问 https://console.qcloud.com/capi 创建或获取你在腾讯云的API密钥:然后正确替换上述代码中的8,9行的secretKey和secretId值,比如: 最后,将修改后的PHP代码添加到WordPress主题的 functions.php 函数模板文件当中即可! 三、其他啰嗦 部署后,博客发布或更新文章、评论的提交或审核都会调用API去清理CDN缓存,其中文章和评论的提交可能会比没有部署略微卡一点,评论的审核是异步提交,所以感知不到什么。 最终,我百度了一把php异步,将以上代码中的curl_init请求改造了伪异步,将时间缩短到1秒(因为CUROPT_TIMEOUT的值最小是1秒【相关文章】),所以挂上这个函数也就是略卡1秒而已,完全可以接受! 好了,本文分享到此告一段落,正在使用腾讯云CDN或打算做腾讯云安全认证将要使用腾讯云CDN的朋友可以尝试下,非常方便!
阅读全文
网站建设

解决IE响应式的解决方案css3-mediaqueries.js不生效问题

前阵子解决了博客在低版本IE下会假死的问题,发现居然是因为我自定义CSS的闭合误用了中文大括号导致的! 解决这个问题之后,又发现了另外一个坑:发现博客在IE8及以下版本的响应式不生效。 奇了怪了,记得鸟哥老早更新Begin的时候就解决了这个IE下CSS3响应式问题,咋就无效呢? 看了下源代码,发现Begin下会在head部分引入如下代码: 其中 css3-mediaqueries 就是用来解决IE8及以下版本浏览器不支持 CSS3 media queries 的问题的。 大概工作原理想想知道,应该就是用js的方式,先取得写好的css3属性,然后动态改变元素样式,从而解决兼容性问题。当然,这种方式肯定会比纯css效率低得多,IE下很明显会略显迟钝,大家自行体验。 经过测试发现,鸟哥的博客在IE8下的响应式除了略卡一点,并没有出现响应式失效的情况,为啥我博客就不行呢?苦逼重复的替换了几次js文件、刷新各种缓存,硬是没有解决! 没办法了,看来还得求助搜索引擎了。最终,发现居然因为这个js不支持跨域(文章忘记收藏了)! 也就是说,这2个js只能用和主站一样的域名,而不能用其他域名,否则就不会生效! 好吧,懒得去深究为什么它不支持跨域了,直接把上述代码修改如下就搞定了: 问题终于得到解决,可以安心睡觉了! 最新补充:上次全量更新Begin主题的时候,发现问题又重现了!按照本文的经验处理之后还是不行,于是又折腾了大半天,终于搞清楚上文说的不支持跨域指的什么了。 原来,不支持跨域不是说这个js,而是指含有响应式代码的CSS文件! 这里说的响应式CSS代码是如下形式: 也就是说,如果要让css3-mediaqueries.js生效,那么含有上述响应式的css代码就不能跨域! 比如,Begin主题大部分响应式属性的代码都写在了style.css,那么要解决这个IE兼容性问题,只需要将style.css使用和网站相同的域名即可,而不能使用二级域名的CDN了! 如果是强迫症,可能觉得不够爽,因为style.css算是比较大的文件了!不用CDN总是觉得是一个带宽占用大户! 如何解决这个问题呢?很简单!将style.css中响应式写法的css代码全部复制一份,放到额外的一个css文件中,然后使用和网站相同域名,引入到head部分的IE判断语句中即可! 比如,张戈博客如下引入: 其中 /wp-content/themes/begin/OldIE.css 就是放了主题所有的响应式CSS属性,使用了相对路径,不再使用CDN,且只在IE9以下的浏览器生效!从而完美解决IE兼容性问题!
阅读全文