6月份开始在公司内部培训、提倡做一些结构化数据和Google富媒体搜索结果的深入研究。前些天记录了一篇《Google富媒体搜索结果之站点链接搜索框 Sitelinks searchbox》，今天再记录一下FAQ常见问答：
先来看看官方的Google搜索中心的文档：使用结构化数据标记 FAQ。
schema.org 上提供了
EmojiAll.com这个网站是2019年开始创办的，从一开始就在原创性方面下了的我们最大的力气，专门人员在各种语言撰写Emoji相关内容，也看到有人模仿或者抄袭我们。
2021年我们EmojiAll网站申请、办理了软件著作权登记和作品登记，并且也开始申请注册商标。™️
而在申请注册商标的时候，居然在商标局网站上搜索到另外一个厦门的公司申请emojiall的商标，而这个公司也正是模仿或者跟风我们做emoji相关内容的网站之一，模仿、跟风也就罢了，还要申请我们的域名emojiall作为他们的商标就过分了。😠
我们咨询
6月份在做IPSHU网站页面改版的时候，使用了常见问答FAQ的结构化数据，并且对Google富媒体搜索结果进行了进一步的研究，当时给同事们还进行了一次名为“高级SEO及结构化数据”的培训交流，目录如下：
同事在使用工具对网站进行检查的时候遇到这种报错：
查看对应网页的html代码类似如下：
<!DOCTYPE html> <html lang="zh-hant" dir="ltr"> <head> <meta http-equiv="Content-Type" content="text/html; c
最近用Google Search Console中的URL检测查看我们的网站，发现一些问题，一些站的首页使用的是Drupal中的node/1，在没有设置别名网址（alias path）或者别名网址不是/的情况（例如下图中的/page/首页_(Home)）下，规范网址（canonical url）就成了node/1本身或者其它别名网址（例如/page/首页_(Home)），而Google选择的是真正的首页。
近期我们发现Apache日志中2a06:98c0:3600::103这个IPv6地址出现非常多，User Agent一般都是显示的googlebot，我们刚开始以为是Google爬虫使用了IPv6地址，但有些User Agent又不是googlebot，所以有点迷惑，因为这是来自Cloudflare的访问，所以我们想可能是一个反向代理IP，想获取其背后真实访问者的IP地址。🤔️
查看以前博文《Apache安装mod_remoteip获取CDN背后访问者真实IP》，我们的httpd.conf中设置了：
RemoteIPHeader CF-Connecting-I
去年以来我们的Apache日志中总看到一个奇怪的IP地址：253.102.157.193，查询归属地是一个E类保留地址，查询Whois是预留未来使用，而User Agent一般都是显示的googlebot，我们还以为Google有什么特权可以使用保留地址。
最近发现这个地址访问的页面越来越多，可以导致服务器不堪重负，就花时间仔细去了解，才发现这不是访问者的真实IP，而是Cloudflare对IPv6地址转换的一个伪IPv4地址，Cloudflare的面板中在这里设置：
上一篇博客《有人恶意刷百度关键词陷害我们网站》写的是百度对一些黑帽SEO手段判断的不准确，导致我们网站被陷害。百度的作弊识别算法还不够完善，需要人工去发现、处理。我们觉得Google的作弊识别算法应该更好，但最近我们网站上发生的问题让我们看到Google的算法也是有漏洞可以钻的。😒
去年6月我们有一个站在Google的核心算法更新后就遇到流量下降，直到11月核心算法再次更新后流量才恢复，但核心算法的更新为什么会影响我们网站流量、具体问题出在甚么地方？这些问题一直没有搞懂。
今年5月Google的核心算法更新后，我们这个站的流量再次
去年11月份的时候，我们陆续有几个网站发现流量大幅减少，一开始还以为是正常波动或其它常规原因而没有引起重视，直到几周后来自百度搜索的流量持续大幅下降、好几个网站都情况类似，才去深入检查原因。🕵️
结果在百度资源平台中发现"流量与关键词"的热门关键词里面有些明显异常的数据，例如：
红框中的一些关键
最近几天我们国内的两个网站都遇到访问困难，检查发现是百度爬虫抓取量大增，是以前正常情况的很多倍，导致Web服务器CPU、带宽以及数据库服务器都难以应付。Googlebot也曾经出现类似情况。
按照以前的办法，我们是在百度资源平台或者Google Search Console中设置降低爬虫的抓取速率，不过这样设置后需要等待2-3天时间生效，而不能解决当时的问题。
2002-2023 v11.7 a-j-e-0
