公平會對創業家兄弟與松果公司的 SEO 誘導轉向開罰

好像很少提到國內的新聞,但這則應該是這兩天蠻熱門的一個新聞,創業家兄弟與松果公司 (也是創業家兄弟公司) 被公平會開罰:「操作SEO搜尋關鍵字誤導消費者 創業家兄弟、松果公司挨罰」,相關的備份先留起來:Internet Archivearchive.today

公平會官方的新聞稿則可以在「利用程式設計引誘消費者「逛錯街」,公平會開罰」這邊看到,對應的網頁備份:Internet Archivearchive.today

用的是公平交易法第 25 條:

公平會於4月12日第1594次委員會議通過,創業家兄弟股份有限公司及松果購物股份有限公司利用「搜尋引擎優化 (Search Engine Optimization,簡稱SEO)」技術,並在搜尋引擎的顯示結果上不當顯示特定品牌名稱,使消費者誤認該賣場有販售特定品牌產品,藉以增進自身網站到訪率,違反公平交易法第25條規定,處創業家兄弟公司200萬元、松果公司80萬元罰鍰。

這條的條文可以從「公平交易法§25-全國法規資料庫」這邊看到:

除本法另有規定者外,事業亦不得為其他足以影響交易秩序之欺罔或顯失公平之行為。

主要的原因是點進去後卻沒有該項商品:

公平會發現,消費者在Google搜尋引擎打上特定品牌名稱,例如「悅夢床墊」時,搜尋結果會出現「悅夢床墊的熱銷搜尋結果│生活市集」、「人氣熱銷悅夢床墊口碑推薦品牌整理─松果購物」等搜尋結果,消費者被前述搜尋結果吸引點選進入「生活市集」、「松果購物」網站後,卻發現該賣場並無「悅夢床墊」之產品,此係生活市集及松果購物之經營者創業家兄弟公司及松果公司分別利用SEO技術所產生的現象。

而且會透過使用者在往站上搜尋的關鍵字產生對應的頁面:

公平會進一步調查後發現,創業家兄弟公司及松果公司對其所經營之「生活市集」及「松果購物」網頁進行設計,只要網路使用者在該2網站搜尋過「悅夢床墊」,縱然該2網站賣場並沒有賣「悅夢床墊」,其網站程式也會主動生成行銷文案網頁,以供搜尋引擎攫取。若有消費者之後在Google搜尋引擎查詢「悅夢床墊」時,搜尋結果便會帶出「悅夢床墊的熱銷搜尋結果│生活市集」、「人氣熱銷悅夢床墊口碑推薦品牌整理─松果購物」等搜尋結果項目,經消費者點選後即會導向「生活市集」、「松果購物」之網站。

然後判罰的部份:

公平會過往即曾就事業使用競爭對手事業名稱作為關鍵字廣告,並在關鍵字廣告併列競爭對手事業名稱之行為,認定違反公平交易法第25條規定。本案雖非創業家兄弟公司及松果公司直接使用「悅夢床墊」等他人商品品牌作為關鍵字廣告,但最終呈現之結果,本質上都是「誘導/轉向」(bait-and-switch)的欺罔行為,除了打斷消費者正常的商品搜尋與購買過程,也對其他販售該等品牌商品之經營者形成不公平競爭的效果。若任由發生而不予規範,未來將可能導致其他競爭者之競相仿效,消費者將更難以分辨搜尋結果呈現資訊之真偽,進而威脅電商市場之競爭秩序及消費者利益。故公平會認為違反公平交易法第25條「足以影響交易秩序之欺罔及顯失公平行為」,並分別處創業家兄弟公司200萬元、松果公司80萬元罰鍰。

所以這算是對 Dark pattern SEO 的部份開罰...

GET 與 POST 的差異

看到這篇在講 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 跑 JavaScript 了

Googlebot 先前一直都是用 Chrome 41 版的引擎在跑,如果要考慮 SEO (for JavaScript),就得確認網站在 Chrome 41 上面可以執行 (於是 ES6 就...)。

今天從 John ResigTwitter 上看到 Googlebot 更新了引擎:「The new evergreen Googlebot」。

這樣針對 JS 的 SEO 省了不少事情...

Googlebot 的 Web rendering service 的細節

在「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...

在討論 Google Search 是不是會執行 javascript。半年前的文章了,不過最近作者發現又有新東西:「Does Google execute JavaScript?」。

作者用了幾段 javascript 程式碼測試 (可以參考原文),發現其實不保證會執行 javascript,所以還是建議大家乖乖跑 server-side render 產生資料,這樣對其他搜尋引擎的 SEO 也比較好:

HTTPS 的進展

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 好、速度又快 (這兩個對營收有影響),而另外也可以增加安全性 (對聲譽有幫助)。

快速衝高 Alexa 排名的方法

很久前 (突然找到我在 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 排名還得參考他有沒有掛這東西,好累...

Hostname 最後面的點 (dot) 會造成的影響...

在這邊探討了 FQDN 形式 (hostname 最後面有 dot 結尾的形式) 對於瀏覽器的影響:「The danger of the trailing dot in the domain name」。

影響包括了 HTTPS 的 SSL Certificate 會失效:

另外,cookie domain 會不一樣,所以在有 dot 的頁面上登入後,重導到沒有 dot 的網址上會讀不到 cookie 而造成登入失敗。

瀏覽器應該對 dot 處理嗎?一時間想不到有什麼問題,不過好像又不應該處理...

Google 調整參數處罰 Content Farm 的進度

Slashdot 上有人提到 Google 最近調整的情況,繼續調降 low-quality site (這次是 eHow) 在搜尋的排名:「Google Tweaks Algorithm; EHow Traffic Plummets」。

最近用中文版的 search 發現愈來愈找不到想要的東西了,把語系切到英文版試一陣子看看...

Amazon「導入」Wikipedia 並加上廣告連結

參考 Slashdot 的「Wikipedia Pages Now On Amazon — With Product Links」這篇文章。

Amazon 所產生的 Wikipedia 對應頁面在這:「Main Page - Shopping-enabled Wikipedia Page on Amazon」。

依照 Wikipedia 的文章授權,是可以這樣做沒錯 (沒有禁止商業使用)。不過 Google 禁止複製別人的重複內容:「Duplicate content」。

以目前 www.amazon.com/robots.txt 的內容看起來是沒對 /wiki 設限,接下來就來看 Google 會不會認定 Amazon 試著在惡搞 SEO 而列入處罰清單...