幹壞事是進步最大的原動力
前陣子從日本買的電器附的線是兩孔加地線，與 IEC 60320 C5 的頭：
雖然我手上剛好有 Panasonic WH 2881P 可以把地線硬接起來：
但想了想既然是標準接頭，弄一條新的線好像比較好，所以就在網路上找，結果發現都找不到... 本來想說是不是台灣沒在用這種頭，但後來想到很多筆電好像就是用這種頭？
多花了一些時間找資料，後來看到維基百科上面這樣寫：
許多用於筆記本電腦的小型開關模式電源。由於其形狀，通常稱為「三葉草」或「米老鼠」連接器。
改用「米老鼠 電源線」就出現一堆，苦啊...
前幾天很熱門的「An Anonymous Source Shared Thousands of Leaked Google Search API Documents with Me; Everyone in SEO Should See Them」消息，裡面提到有拿到一份疑似 Google 搜尋引擎的內部 API 文件， 可以證實有很多 Google 搜尋引擎的運作與 Google 對外宣稱的不符。
作者找了業內人士幫忙分析 (他自己說他先前也在碰 SEO 這塊，但是已經離開這個行業六年了)：
Next, I needed help analyzing and deciphering the naming conventions and more technical aspects of the documentation. I’ve worked with APIs a bit, but it’s been 20 years since I wrote code and 6 years since I practiced SEO professionally.
包括作者的一些 Google 朋友，或是 ex-Googler 都確認這份文件符合 Google 內部的文件規範要求，另外裡面的元素編排也都很像是 Google 的文件。
本來以為事情大概就這樣，後續應該就是會有很多人從這份文件分析 Google 有哪些 SEO 的偏好，找出哪些東西與 Google 宣稱的不符。
不過事情突然有個意外的轉折，Google 本來一直是「拒絕評論」的態度，但突然承認這份文件的確是他們內部文件：「Google confirms the leaked Search documents are real」。
"We would caution against making inaccurate assumptions about Search based on out-of-context, outdated, or incomplete information," Google spokesperson Davis Thompson told The Verge in an email. "We’ve shared extensive information about how Search works and the types of factors that our systems weigh, while also working to protect the integrity of our results from manipulation."
反正也沒有人會相信 outdated 了，但可以預想的是 Google 的搜尋結果應該又會變差，因為會有更多 SEO 垃圾開始想辦法衝排名上去...
在 Hacker News 上看到的討論，裡面剛好有 Reddit 第一個雇用的工程師，Jeremy Edberg 的留言：「Reddit is taking over Google (businessinsider.com)」。
在 id=40068381 這邊提到了不少東西，首先是把 title 放進 url 裡面的作法：
To this day, my most public contribution to reddit is that I wrote the code to put the title of the post in the URL. That was done specifically for SEO purposes.
這個在 Google Webmasters (現在叫做 Google Search Console) 也針對 Reddit 處理，將速率強制設為 Custom，不讓 Reddit 的人改：
It was pretty much the only SEO optimization we ever did (along with a few DOM changes), because shortly after that, Google basically dedicated engineering effort specifically to crawling reddit. So much so that we lost the "crawl rate" button in our SEO admin page on Google, it was just set to "Custom".
後續還要針對 Google 的抓取在 load balancer 上把流量拆開處理，不然 crawling pattern 與一般使用情境很不一樣，會造成 cache 的效率極度低落：
I had to stand up a fleet of app servers and caches and databases, and change the load balancers so that Google basically had their own infrastructure (although we would shunt all crawlers there). Crawler traffic was very different than regular traffic -- it looked at pages more than two days old, something humans rarely did at the time. It would blow out every cache (memory, database, disk, etc.). So we put them on their own infra to keep them from killing the rest of the site.
這些算是頗有趣的經驗？
好像很少提到國內的新聞，但這則應該是這兩天蠻熱門的一個新聞，創業家兄弟與松果公司 (也是創業家兄弟公司) 被公平會開罰：「操作SEO搜尋關鍵字誤導消費者 創業家兄弟、松果公司挨罰」，相關的備份先留起來：Internet Archive、archive.today。
公平會官方的新聞稿則可以在「利用程式設計引誘消費者「逛錯街」，公平會開罰」這邊看到，對應的網頁備份：Internet Archive、archive.today。
用的是公平交易法第 25 條：
公平會於4月12日第1594次委員會議通過，創業家兄弟股份有限公司及松果購物股份有限公司利用「搜尋引擎優化 (Search Engine Optimization，簡稱ＳＥＯ)」技術，並在搜尋引擎的顯示結果上不當顯示特定品牌名稱，使消費者誤認該賣場有販售特定品牌產品，藉以增進自身網站到訪率，違反公平交易法第25條規定，處創業家兄弟公司200萬元、松果公司80萬元罰鍰。
這條的條文可以從「公平交易法§25-全國法規資料庫」這邊看到：
除本法另有規定者外，事業亦不得為其他足以影響交易秩序之欺罔或顯失公平之行為。
主要的原因是點進去後卻沒有該項商品：
公平會發現，消費者在Google搜尋引擎打上特定品牌名稱，例如「悅夢床墊」時，搜尋結果會出現「悅夢床墊的熱銷搜尋結果│生活市集」、「人氣熱銷悅夢床墊口碑推薦品牌整理─松果購物」等搜尋結果，消費者被前述搜尋結果吸引點選進入「生活市集」、「松果購物」網站後，卻發現該賣場並無「悅夢床墊」之產品，此係生活市集及松果購物之經營者創業家兄弟公司及松果公司分別利用ＳＥＯ技術所產生的現象。
而且會透過使用者在往站上搜尋的關鍵字產生對應的頁面：
公平會進一步調查後發現，創業家兄弟公司及松果公司對其所經營之「生活市集」及「松果購物」網頁進行設計，只要網路使用者在該2網站搜尋過「悅夢床墊」，縱然該２網站賣場並沒有賣「悅夢床墊」，其網站程式也會主動生成行銷文案網頁，以供搜尋引擎攫取。若有消費者之後在Google搜尋引擎查詢「悅夢床墊」時，搜尋結果便會帶出「悅夢床墊的熱銷搜尋結果│生活市集」、「人氣熱銷悅夢床墊口碑推薦品牌整理─松果購物」等搜尋結果項目，經消費者點選後即會導向「生活市集」、「松果購物」之網站。
然後判罰的部份：
公平會過往即曾就事業使用競爭對手事業名稱作為關鍵字廣告，並在關鍵字廣告併列競爭對手事業名稱之行為，認定違反公平交易法第25條規定。本案雖非創業家兄弟公司及松果公司直接使用「悅夢床墊」等他人商品品牌作為關鍵字廣告，但最終呈現之結果，本質上都是「誘導/轉向」(bait-and-switch)的欺罔行為，除了打斷消費者正常的商品搜尋與購買過程，也對其他販售該等品牌商品之經營者形成不公平競爭的效果。若任由發生而不予規範，未來將可能導致其他競爭者之競相仿效，消費者將更難以分辨搜尋結果呈現資訊之真偽，進而威脅電商市場之競爭秩序及消費者利益。故公平會認為違反公平交易法第25條「足以影響交易秩序之欺罔及顯失公平行為」，並分別處創業家兄弟公司200萬元、松果公司80萬元罰鍰。
所以這算是對 Dark pattern SEO 的部份開罰...
看到這篇在講 HTTP (& HTTPS) 裡面 GET 與 POST 的差異，剛好把一些標準的定義拿出來翻一翻，算是複習基本概念：「Get safe」。
第一個基本概念主要是 idempotence (& idempotent)，重複被呼叫不會造成狀態的再次改變：
Idempotence ([...]) is the property of certain operations in mathematics and computer science whereby they can be applied multiple times without changing the result beyond the initial application.
數學定義是這樣跑：
An element x of a magma (M, •) is said to be idempotent if:
x • x = x.
If all elements are idempotent with respect to •, then • is called idempotent. The formula ∀x, x • x = x is called the idempotency law for •.
這點在 HTTP 標準 (RFC 7231) 裡面的定義也類似：
A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent.
第二個基本概念是 Safe method (也是在同樣的 RFC 裡被提到)，主要的思想是 read-only，這也是文章作者的標題要講的事情：
Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.
然後標準的 HTTP method 是有定義的：
+---------+------+------------+---------------+ | Method | Safe | Idempotent | Reference | +---------+------+------------+---------------+ | CONNECT | no | no | Section 4.3.6 | | DELETE | no | yes | Section 4.3.5 | | GET | yes | yes | Section 4.3.1 | | HEAD | yes | yes | Section 4.3.2 | | OPTIONS | yes | yes | Section 4.3.7 | | POST | no | no | Section 4.3.3 | | PUT | no | yes | Section 4.3.4 | | TRACE | yes | yes | Section 4.3.8 | +---------+------+------------+---------------+
不過文章裡面提到的第一個例子並沒有很好，POST 不保證 safe 沒錯，但不代表 safe operation 就不能用 POST。
這邊用 URI resource 的概念 (以及 SEO？) 或是用 Post/Redirect/Get 的概念來說明會比較好：
<form method="get" action="/search"> <input type="search" name="term">
不過文章後續提到的問題的確就是我自己都會犯錯的問題：
“Log out” links that should be forms with a “log out” button—you can always style it to look like a link if you want.
“Unsubscribe” links in emails that immediately trigger the action of unsubscribing instead of going to a form where the POST method does the unsubscribing. I realise that this turns unsubscribing into a two-step process, which is a bit annoying from a usability point of view, but a destructive action should never be baked into a GET request.
這兩個動作都會造成 server 端的狀態改變，不應該用 GET，而我自己常常忘記第一個... 這邊其實可以用 form 產生 POST 需求，並且用 css 效果包起來，達到看起來跟一般的連結一樣。
寫起來讓自己多一點印象，之後避免再犯一樣的錯誤...
Googlebot 先前一直都是用 Chrome 41 版的引擎在跑，如果要考慮 SEO (for JavaScript)，就得確認網站在 Chrome 41 上面可以執行 (於是 ES6 就...)。
今天從 John Resig 的 Twitter 上看到 Googlebot 更新了引擎：「The new evergreen Googlebot」。
The day has finally arrived - Googlebot is now evergreen!!! https://t.co/pByE8WWjYT Time to drop so many polyfills, this is really exciting!
— John Resig (@jeresig) May 7, 2019
這樣針對 JS 的 SEO 省了不少事情...
在「Polymer 2 and Googlebot」這邊文章裡面才看到 Google 官方在今年八月就有公開 Googlebot 所使用的 Web rendering service (WRS) 的細節：「Rendering on Google Search」。可以想像到是基於 Google Chrome 的修改：
Googlebot uses a web rendering service (WRS) that is based on Chrome 41 (M41). Generally, WRS supports the same web platform features and capabilities that the Chrome version it uses — for a full list refer to chromestatus.com, or use the compare function on caniuse.com.
裡面提到一些值得注意的事情，像是不支援 WebSocket，所以對於考慮 Google 搜尋結果的頁面來說，就要注意錯誤處理了...
在討論 Google Search 是不是會執行 javascript。半年前的文章了，不過最近作者發現又有新東西：「Does Google execute JavaScript?」。
作者用了幾段 javascript 程式碼測試 (可以參考原文)，發現其實不保證會執行 javascript，所以還是建議大家乖乖跑 server-side render 產生資料，這樣對其他搜尋引擎的 SEO 也比較好：
Tony Hunt 在「We’re struggling to get traction with SSL because it’s still a “premium service”」這篇文章裡抱怨了目前 web 要朝向 HTTPS only 還很遠，甚至還酸了一下 Let's Encrypt 冨樫問題：
可是東尼... 你的站也沒上 HTTPS 啊 :/
順便整理一下目前 HTTPS 技術發展出來的優點：
現在網站的 best practice 是 HTTPS + HTTP/2，對 SEO 好、速度又快 (這兩個對營收有影響)，而另外也可以增加安全性 (對聲譽有幫助)。
很久前 (突然找到我在 2006 的文章) 就說 Alexa 只是個參考用的工具... (參考「Search Results for: alexa」)
如果要看結論的人請直接跳到文章尾部，中間是說明發現的過程。
昨天 (星期五) 的時候跑去找肥睡睡餵食「摩斯吃到飽」，然後 xdite 也一起亂入，剛好聊到兩件事情。
第一件事情是要幫友站 Logdown 測試流量，講了一堆嘴砲方式... (惡搞的方式先拿掉了)
第二件事情是前天 (星期四) 的時候我發現前公司 pixnet.net 的 Alexa 從六月開始排名突然爆增，大約從全球 600 名跳到 120 名，台灣排名的部份居然超越了 YouTube (目前 PIXNET 在第五名，YouTube 在第六名)，但到達率、PV、停留時間都沒有大的變化，就問問 xdite 與肥睡睡有沒有什麼想法，是不是最近有上什麼功能是我沒注意到的 XD
不過餵食席間沒有討論出結果來，吃飽後閃人了... (我不確定肥睡睡有沒有吃飽啦，不過我是不怎麼餓...)
回到家後想說來研究 Logdown 使用的服務，asset 什麼的就先不管好了，到是有一段 code 我之前沒遇過：
Update：結果回到家後研究 Logdown 的服務，就看到 xdite 把 Alexa 的 js 丟上去在玩了：(剛好 xdite 也想到就同時在測了...)
<!-- Start Alexa Certify Javascript -->
<script type="text/javascript">
_atrk_opts = { atrk_acct:"KOI0g1aYS500G0", domain:"logdown.com",dynamic: true};
(function() { var as = document.createElement('script'); as.type = 'text/javascript'; as.async = true; as.src = "https://d31qbv1cthcecs.cloudfront.net/atrk.js"; var s = document.getElementsByTagName('script')[0];s.parentNode.insertBefore(as, s); })();
</script>
<noscript><img src="https://d5nxst8fruw4z.cloudfront.net/atrk.gif?account=KOI0g1aYS500G0" style="display:none" height="1" width="1" alt="" /></noscript>
<!-- End Alexa Certify Javascript -->
一開始眼殘沒看到 Alexa Certify Javascript 這段文字，第一個想法是「xdite 你沒事自己寫個 analytics service 幹嘛啊，嫌時間太多嗎」，後來轉念一想「啊啊這會不會是什麼服務？」。
拿 atrk.js 當關鍵字一查就發現是 Alexa 的服務，再回頭來看就發現自己眼殘了... XD
嘲笑自己三秒後就突然想到「咦，餵食時提到的 Alexa 排名會不會跟這個有關？」
接下來就是查證的時間了，這時候 Internet Archive Wayback Machine 拿來考察變得超好用：「http://web.archive.org/web/*/http://www.pixnet.net/」，6/9 的 snapshot 時首頁還沒有 atrk.js，6/20 就有了：
gslin@GSLIN-DESKTOP [~] [12:02/W3] curl -s http://web.archive.org/web/20130609121320/http://www.pixnet.net/ | g atrk.js
gslin@GSLIN-DESKTOP [~] [12:02/W3] curl -s http://web.archive.org/web/20130620181016/http://www.pixnet.net/ | g atrk.js
(function() { var as = document.createElement('script'); as.type = 'text/javascript'; as.async = true; as.src = "https://d31qbv1cthcecs.cloudfront.net/atrk.js"; var s = document.getElementsByTagName('script')[0];s.parentNode.insertBefore(as, s); })();
另外兩個也有類似現象的網站，分別是 mobile01.com：
以「http://web.archive.org/web/*/http://www.mobile01.com/」的資料來看，2012/12/27 的 snapshot 還沒加入 atrk.js，2013/1/15 的則加入了：
gslin@GSLIN-DESKTOP [~] [12:06/W3] curl -s http://web.archive.org/web/20121227040802/http://www.mobile01.com/ | g atrk.js
gslin@GSLIN-DESKTOP [~] [12:06/W3] curl -s http://web.archive.org/web/20130115110655/http://www.mobile01.com/ | g atrk.js
<script type="text/javascript" src="/web/20130115110655js_/https://d31qbv1cthcecs.cloudfront.net/atrk.js"></script>
以及 ck101.com：
以「http://web.archive.org/web/*/http://ck101.com/」的資料來看，4/24 還沒有 atrk.js，4/30 的加入了：
gslin@GSLIN-DESKTOP [~] [12:07/W3] curl -s http://web.archive.org/web/20130423092213/http://ck101.com/forum.php | g atrk.js
gslin@GSLIN-DESKTOP [~] [12:08/W3] curl -s http://web.archive.org/web/20130504162245/http://www.ck101.com/forum.php | g atrk.js
(function() { var as = document.createElement('script'); as.type = 'text/javascript'; as.async = true; as.src = "/web/20130504162245/https://d31qbv1cthcecs.cloudfront.net/atrk.js"; var s = document.getElementsByTagName('script')[0];s.parentNode.insertBefore(as, s); })();
所以結論就很簡單啦，如果 Alexa 排名對你是很重要的 KPI，Alexa Internet - Get Certified Site Metrics 趕快付錢加入試看看吧！XDDD
可以看到有三個不同的版本，如果要測試的話 USD$9.99/month 的第一個月還免費，可以先測試看看？(不知道是不是要 USD$149/month 的才有效...)
PS：以後看 Alexa 排名還得參考他有沒有掛這東西，好累...