在百度、Google遇到網站抓取、收錄、索引、展示等方面的問題，一般都是自己看數據、自己看幫助，或者在網上搜一些文章了解，但也有一些疑惑無法解開。好像沒有找到人工咨詢的渠道，百度、Google官方也給出交流論壇，但實際沒有去發過帖子。
最近在熊掌号提交鍊接、MIP驗證等方面一直有些問題不知道原因，找來找去在百度搜索資源平台的反饋中心發現可以留言、等待人工回複：
博客文章
我們采用了直接建表方式搭建Drupal網站後，我記錄了一篇《Drupal網站Views生成頁面的XML網站地圖構建》，這個辦法很通用，一般都沒有問題，隻是在少量情況下可能需要修改MySQL查詢語句，例如當數據量很大（如果超過100萬條記錄）的時候，SQL語句執行時間很長，容易造成RDS雲服務器卡死。
陸續發現過幾種情況，也采取措施解決了，但忘記記錄博客了。今天再次發生一個站sitemap被爬堵住，導緻整台數據庫服務器卡住的情況，用下面辦法解決，記錄下來。
SELECT DISTINCT person FROM gongshang l
最近一段時間因為新書的出台，我也進入“高光時刻”：又是線上交流會、又是Google專訪😁
下面這篇是剛剛谷歌廣告聯盟公衆号發布的文章：《訪問 AdSense 老大哥祁勁松老師》，我摘錄如下：
訪問 AdSense 老大哥祁勁松老師
原創： 谷歌廣告聯盟 谷歌廣告聯盟 2018年12月26日
本期文章我
上周應谷歌廣告聯盟Iris的邀請，進行了一次線上新書讨論會。在開始之前的一個星期Iris就給我寫了預備的10個問題，如果讨論會沒人提問就用，但實際上一個都沒用用上，從第一個問題就是回答網友提出的問題，原定30-45分鐘，一共用足了45分鐘，網友還有不少問題，但也隻好結束了。
線上讨論會使用的千聊軟件平台，可以從微信進去，也可以下載app，我是直接使用的微信，頭一天測試了一次，知道大概流程和用法，第二天正式使用中還算基本順利，沒有遇到特别的意外，當時都是用語音回答的，現場Iris都做了一個簡短的文字小結，其内容在千聊平台永久保存，錯過的同學可以随時去聽：本次線上
我們做了這麼多年的AdSense，在廣告的擺放上還是很注意的，特别是位置，要讓可見率提高非常重要。
當然，還有一些細節，例如前一陣子發現有些廣告自動在手機端變成了全屏寬度，在某些地方遮蓋住了頁面中的邊框線，顯得不夠美觀，于是我們就改為了300x250的固定寬度。
接下來還有一個問題，300x250固定寬度廣告在不同寬度的手機上的位置有時居中有時偏左，特别是大屏手機上，偏左也不好看，最好能居中顯示。
請教美工設計同事後，給出了修改CSS的方案：
辦法1 - 直接在AdSense代碼中修改。
Linux中crontab是一個很有用的定時工具，可以設置很多定時任務，我們一直都在使用。
最近同事提出白天在服務器上導入數據會讓負載增大、影響用戶正常訪問，希望能設置到晚上自動運行，這個應該很簡單，隻要把手工運行的導入程序命令放在一個定時批處理文件dingshi.sh中，設置crontab晚上自動運行就可以，但要考慮不能重複運行導入。
00 3 * * * root sh /root/dingshi.sh
避免重複的辦法應該不止一種，我想到的辦法是在這個dingshi.sh的最後一行寫一條修改自己文件名
最近寫了幾段PHP程序，給同事來導入數據到MySQL數據庫，同事偶爾反映遇到這樣類似的報錯：
PDOException: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'state' at row 1: UPDATE `table` SET `address` = 'xxx', `state` = '過長内容', `id` = 
昨天剛寫了一篇《不要誤屏蔽百度MIP的爬蟲》，順着我們就繼續檢查其它站是否有被誤屏蔽的事情，流量來源主要是百度的國内站可以看百度站長平台（百度搜索資源平台）裡面的信息，流量來源主要是Google的國外站可以看Google Webmaster Tools (Google Search Console)。
今天同事發現一個台灣繁體版站的索引情況有異常：
我們很早前就開始做百度MIP版本頁面了，通過這種方式也獲得了流量的增長和比較好的用戶體驗。但最近流量不太穩定，有的站MIP流量曾經很高，但後來跌落很厲害。還有的站MIP流量下降後，對應的普通WEB版流量上升。
我們做了各種推測和試驗，今天發現了一條重要線索：百度的MIP爬蟲曾經被我們屏蔽。
按照百度官方的說法，其MIP爬蟲的User Agent是這樣的：
Mozilla/5.0 (Linux;u;Android 4.2.2;zh-cn;) AppleWebKit/534.46 (KHTML,like Geck
最近和采集者杠上了，不斷與這些采集者糾纏，周一一大早就看到網站監控報警，服務器帶寬被占滿，在從iftop -i eth1看到有兩個IP段一直占據前列：
再仔細一查，這兩個IP段是已經被我們在.htaccess裡面屏蔽的，從tail -f access.log看這兩個IP段的地址訪問都是403被拒絕狀态，但不知道是哪家的傻爬蟲（220.243.135.*/220.243