Google+ 關閉對 Blogger 的影響整理

February 3, 2019, 8:10 pm

≫ Next: 如何用 Javascript 複製文字﹍跨瀏覽器相容 iOS

≪ Previous: 主流 CC0 圖庫已不再宣告「CC0 條款」，原因究竟為何？

$

0

0

相信每個人最近都會收到一封 Google 寄來的郵件「您的 Google+ 個人帳戶將於 2019 年 4 月 2 日停用」，而不少 Blogger 站長們對這個訊息感到恐慌，紛紛詢問是否會造成什麼影響，例如圖片會不會不見？Blogger 是不是會收起來？

由於 Blogger 部落格過去幾年為了推廣 G+，用盡各種方法鼓勵站長們轉換 Blogger 帳號為 G+ 帳號，在網站安裝各種 G+ 工具、轉換為 G+ 留言板等等，因此 Blogger 與 G+ 的黏著度還不少。

Blogger 官方對此事有發佈公告，調列了所有會影響的細節，本篇會進行重點整理。這裡也先聲明一下，大多數的站長都可以安心，G+ 關閉對 Blogger 影響不大，只有使用 G+ 留言板的網站有影響。

(圖片出處: flickr.com)

一、Blogger 官方公告內容

以下內容整理自「An update on Google+ and Blogger」，從 2019/2/4 開始，Blogger 與 G+ 整合的相關功能將會關閉。


1. G+ 小工具

這些小工具將無法使用：

• +1 按鈕
• G+ 追蹤者
• G+ 徽章

2. G+ 相關按鈕

Blogger 各處的 G+ 相關按鈕將會移除：







官方另外提醒使用者，如果使用了非官方範本，且含有 G+ 相關功能，需洽範本作者如何處理。

我的看法是，如果真的網站造成異常，也可乾脆換個比較沒問題的範本。


3. G+ 留言板

這個比較麻煩，官方表示 G+ 留言板會關閉，如網站有使用的話：

• 2019/2/4 會自動換回 Blogger 官方留言板
• 但所有過去的 G+ 留言討論串，並不會整合回 Blogger 留言板
• 意思就是 G+ 所有的留言將成為回憶

4. G+ 簡介

官方表示 2019 三月之後，原本站長的 G+ 簡介模式還原為 Blogger 簡介模式，而且有一點很重要：

• 三月之後，別人看到的 Blogger 站長簡介可能會是 "unknown" (未知的使用者)
• 必須等到站長重新登入 Blogger，選擇正確的帳號、頭像等等之後，才能顯示正確的簡介資訊。

官方對以上造成的不便感到抱歉，也表示期待今年 Blogger 會提供的新功能，就讓我們拭目以待吧。

二、Blogger 留言

1. G+ 留言究竟有沒有救？

對於這次的事件，受傷最重的會是使用 G+ 留言板的站長，而且如果留言數很多、非常踴躍的話，這些珍貴的資產瞬間消失真的很心疼。

從官方這篇公告的留言，國外網友的討論以這件事最為踴躍，大家都在罵官方不處理這件事，也有人提供解法，例如這個作法大概是最有可能做到的：

• 先想辦法用程式爬所有 G+ 相關留言
• 大概是存成 xlm 檔、能夠匯入 Blogger 成為文章的格式
• 匯入 Blogger 後，再將原本文章內容貼過來新產生的文章，讓文章與留言能夠對應

但我認為沒有任何最佳解就是了，因為上述這個作法會變更文章網址，代表該篇文章的 SEO 得從頭來過了。

另外一點是，我想要利用 Google Takeout 把 G+ 留言備份出來看看格式長得怎麼樣，結果大概是這陣子太多人排隊要備份了，過了整整一天結果處理進度還是 0%...


2. 不建議使用第三方留言板外掛

過去寫過一篇「Blogger 官方留言板的優點及妙用﹍加強 SEO 搜尋排名」，曾大力推薦站長們使用官方留言板就好，盡量不要使用留言板外掛。

現在 G+ 留言板關閉後，相信也可以給站長們一個借鏡，使用任何留言板外掛，無論是 Disqus、FB、Cbox，得祈禱這些第三方服務都不能倒，否則所有日積月累、放在別人家資料庫的留言，都可能一夕之間消失。

讓所有留言待在自己網站上，跟著部落格文章一起保存，將來就算要搬家、自架站也能一併帶走，這是最安心的選擇。

三、其他問題

最後一併回答這次 G+ 宣布關閉，讀者提出的問題：

• Blogger 圖片會不會不見→ 只要是從 Blogger 後台產生的圖片，都不會有影響。原本的 G+ 相片官方表示會刪除，但 Blogger 後台應該也無法處理 G+ 圖片才是，所以 G+ 圖片基本上跟 Blogger 沒什麼關係
• Blogger 是不是會收起來？→ G+ 關閉跟 Blogger 沒什麼關聯性，至於 Blogger 的存續可參考這篇「究竟 Blogger 會不會關閉？從 Google 商業經營的角度分析」

如果 G+ 關閉，讀者擔心對於 Blogger 還會造成什麼影響，可在本篇留言討論。

更多 Blogger 相關消息：

----
如這篇文章對您有幫助，請順手按個 +1 或分享，謝謝！

---

如何用 Javascript 複製文字﹍跨瀏覽器相容 iOS

February 10, 2019, 8:07 am

≫ Next: 利用 Github API 上傳檔案﹍操作範例心得整理

≪ Previous: Google+ 關閉對 Blogger 的影響整理

$

0

0

最近接到的需求類似「點擊按鈕後自動複製折價券代碼」這樣的功能，因此研究了一下如何實現前端利用 Javascript 複製文字。

多年前曾在「如何用語法保護網頁文章著作權」多篇系列文寫相關功能，但這些年網頁技術進展很快，HTML5 新的 api 讓複製文字變得相當簡單。

過去網頁前端的大魔王是 IE，為了 IE 的相容性得傷透腦筋，然而隨著 IE 的式微，取而代之的是另一個大魔王 iOS，蘋果裝置的諸多限制讓 JS 複製文字異常難解，因此本篇詳細研究該如何跨瀏覽器、跨平台相容 JS 複製文字的問題。

一、Javascript 複製文字的進程

以前網頁用 JS 複製文字很困難，必須用 Flash 繞過瀏覽器的限制，可參考這篇「點選自動複製 ( ZeroClipboard )」，缺點是瀏覽器的 Flash 功能被關閉就無效。

後來 HTML 5 新增了「Clipboard API」，可直接存取剪貼簿的資料，真的方便許多，但缺點是蘋果 iOS 裝置不支援。

所以這件事要做到跨裝置、瀏覽器支援，一方面可使用 Clipboard API，一方面需要單獨對 iOS 裝置進行處理。

二、iOS 的限制

這個討論串「Copy to clipboard using Javascript in iOS」對 iOS 的狀況說明的很詳細，摘錄重點如下：

• iOS 版本 > 10 的時候：
  
  • 只有 input、textarea 這兩個元素的文字可以複製
  • 這兩個元素的屬性必須是可以編輯(contenteditable)、不能是只讀狀態(readonly)
  • 這兩個元素內的文字必須是選取狀態才能複製
  • 符合以上條件後，即可使用 Clipboard API
• iOS 版本 < 10 的時候：
  
  • Safari 有些限制，只能經由 "點擊" 這個動作來觸發複製文字的程式碼
  • 意思就是無法偷偷在背景自動執行程式來複製文字

另外 iOS 裝置用 JS 執行複製文字時，上還有些不太好的效果，例如：

• 可能會彈出鍵盤
• 螢幕會捲動到要複製文字的 input、textarea 位置

三、範例程式碼

有國外高手寫了「clipboard.js」解決複製文字的問題，也能相容 iOS 裝置。這篇「實現前端點擊按鈕自動複製剪貼板功能」取用了 clipboard.js 的程式碼進行調整。

那麼開頭提到的「點擊按鈕後自動複製折價券代碼」這個功能，根據以上相關資訊進行修改後，提供範例程式碼如下：

<input value="填入要複製的字串 例如 123456" style="display:none;"/><button class="copy_coupon">【123456】點擊複製數字</button>

<script src='//ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js'></script>
<script>
window.Clipboard = (function(window, document, navigator) {
var textArea,
copy;

function isOS() {
return navigator.userAgent.match(/ipad|iphone/i);
}

function createTextArea(text) {
textArea = document.createElement('textArea');
textArea.value = text;
document.body.appendChild(textArea);
}

function selectText() {
var range,
selection;

if (isOS()) {
range = document.createRange();
range.selectNodeContents(textArea);
selection = window.getSelection();
selection.removeAllRanges();
selection.addRange(range);
textArea.setSelectionRange(0, 999999);
} else {
textArea.select();
}
}

function copyToClipboard() {
document.execCommand("Copy");
document.body.removeChild(textArea);
}

copy = function(text) {
createTextArea(text);
selectText();
copyToClipboard();
};

return {
copy: copy
};
})(window, document, navigator);

$(".copy_coupon").on("click", function() {
var $this = $(this),
value = $this.prev("input").val();
window.Clipboard.copy(value);
});
</script>

範例程式碼的效果，如同下面這個按鈕，複製後會自動複製數字 123456，可自行測試：

【123456】點擊複製數字

四、補充

若在 iOS 進行複製，會發現如前所述，螢幕自動捲到下方，因為這個用來暫時存放複製文字的 textarea 元素，預設放在 body 的最後面，當 iOS 進行選取的動作時，游標就會自動移動到頁尾。

要解決這個問題，需要在觸發 click 的程式碼最後面，例如在 window.Clipboard.copy(value); 的下一行，加入以下程式碼，計算按鈕元素的座標，強制螢幕捲回按鈕的位置：

$("html, body").scrollTop($this.offset().top)

更多 Javascript 相關技巧：

----
如這篇文章對您有幫助，請順手按個 +1 或分享，謝謝！

利用 Github API 上傳檔案﹍操作範例心得整理

February 13, 2019, 8:07 pm

≫ Next: 不是使用 CC0 圖片就沒事，若要「商業使用」請注意這些案例

≪ Previous: 如何用 Javascript 複製文字﹍跨瀏覽器相容 iOS

$

0

0

「Github」是免費架設靜態網頁的好選擇，同時也提供了完善的 API，不必手動操作，用程式就能更新網頁，也能管理 Github 上的所有檔案。

本篇整理如何利用 Github API 上傳檔案的流程，並提供前端操作的範例程式碼。

(圖片出處: flickr.com)

一、準備動作

1. API 文件說明

官方說明文件都是英文，直接啃可能會消化不良，可先參考這篇整理：

• 一篇文章搞定Github API 调用

大概熟悉 API 可做哪些事情之後，可再對照官方原文教程。


2. 取得 Token

「上傳檔案」這個動作需要安全性，因此呼叫 API 得先取得金鑰(Access Token)，操作流程可參考官網說明：

• Creating a personal access token

這個頁面有圖文說明應該不難懂，摘要中文重點：

• 先確認 Github 帳號已進行 Email 驗證
• 登入 Github 網頁後，點擊右上角帳號圖示 → Settings
• 點擊左側選單 Developer settings
• 點擊左側選單 Personal access tokens
• 點擊按鈕 Generate new token
• Token descript 隨意填入描述文字
• 下面借用官網的圖，勾選 repo 所有選項即可，其他不用勾選
• 點擊按鈕 Generate token
• 複製產生的 token 字串
• 請好好保存，token 字串只會出現一次，以後不會再出現
• 如 token 遺失，可重新產生 token 即可

二、上傳檔案 API

操作上傳檔案的 API 官網文件在此：

• REST API v3 Contents

上傳檔案的部分是「Create a file」，操作的語法如下：

PUT /repos/擁有者帳號/目錄/contents/檔案路徑

其他重點可參考文件，但我必須說，文件內容非常不完整，除非已經有開發工程師的底子，否則光靠文件根本無法成功操作 API。除了參考其他教學文章，自己也亂試一通才找出成功上傳的方法，因此不如直接看範例程式碼比較快。

三、上傳檔案範例程式碼

製作上傳檔案的按鈕，可參考這篇「自訂 Input File 檔案上傳按鈕 CSS 最佳解法」，取得檔案內容後，接者用 jQuery Ajax 來呼叫 Github API 上傳檔案：

<script src='//ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js'></script>
<script>
var url = "https://api.github.com/repos/wfublog/test/contents/abc.txt?access_token=xxxxxxxxxxxxxxxxxxxxxxx",
data = {
"message": "test", // 檔案的備註資訊
"content": "bXkgbmV3IGZpbGUgY29udGVudHM=" // base64 編碼
};

$.ajax({
type: "put",
url: url,
headers: {
"Content-Type": "application/json" // 指定送出資料為 json 格式
},
data: JSON.stringify(data), // 一定要將物件轉成字串才會被接受
success: function ()json {
console.log("good! " + JSON.stringify(json));
},
error: function ()json {
console.log("error! " + JSON.stringify(json));
}
});
</script>
以下一一詳細說明：

• 呼叫 api 的 url 紅色字串：
  
  • "wfublog" 字串換成你的 owner 名稱
  • "test" 字串換成你要上傳的目錄
  • "abc.txt" 換成你的檔案名稱，也可加上子目錄的路徑，例如 "sub/abc.txt"；如果子目錄不存在，系統會自動建立子目錄。
  • "xxxxx...." 換成你的 token 金鑰
• 送出的 data 內容：
  
  • message 參數可隨意填入自己的檔案描述文字
  • content 參數即為上傳的檔案內容，必須是 base64 編碼
• 用 jQuery 的 Ajax 呼叫 API 時，要加入 headers 指定送出資料為 json 格式
• 不能直接送出 data 物件，Github API 只能吃字串格式，所以要用 JSON.stringify 把 data 轉成字串

成功送出後，可在 Chrome 開發人員工具看到 console 訊息如下：



返回的物件有各種上傳檔案的相關路徑、其他資訊，可做進一步的後續處理。

四、補充說明

本篇提供的程式碼，僅供學習理解、前端測試之用，千萬不能直接在公開網頁上使用，因為 token 大喇喇被別人看到，你的 Github 權限大開，網頁、檔案所有資料都將不保。

瞭解概念後，請將範例程式碼改為後端執行，不讓 token 曝光才能安心上傳檔案。

更多 相關文章：

----
如這篇文章對您有幫助，請順手按個 +1 或分享，謝謝！

不是使用 CC0 圖片就沒事，若要「商業使用」請注意這些案例

February 18, 2019, 1:33 pm

≫ Next: 讓 FB 社團文章能依「貼文主題」分類﹍實作記錄

≪ Previous: 利用 Github API 上傳檔案﹍操作範例心得整理

$

0

0

製作「CC0 免費圖庫搜尋引擎」幾年下來，「留言板」累積了不少提問，其中有很多商業使用的相關問題，代表使用者會擔心 CC0 圖片仍有侵權問題。

這樣的考量是正確的，因為 CC0 圖片雖然標榜「可商業使用」，但請注意以下的邏輯：

• 「CC0 圖片可商業使用」不等於「所有 CC0 圖片的商業使用方式都合法」

本篇整理一些可能的侵權案例供參考，也請注意 CC0 圖片在商用時需特別小心。

(圖片出處: pixabay.com)

一、我們沒有 CC0 圖片的主權

開始說明案例之前，可先參考這篇「主流 CC0 圖庫已不再宣告 CC0 條款，原因究竟為何？」→「五、總結」，瞭解以下概念：

• CC0 圖片被誤用的所有狀況，可以追溯到同一個源頭，誤以為自己擁有這張圖片的全部主權。
• 一張圖片的主權歸屬，還包含了 "創作者"、"內容物"、"人物"、"商標"...等等，是非常複雜的狀態。
• 在商業使用上，別讓這張圖片成為創作中的主角，否則就可能侵犯到圖片中的某個主權

本文根據這些概念，來說明各種商用容易侵權的案例。

二、侵犯肖像權

CC0 圖庫可以搜尋到許多含有清晰臉孔的高畫質圖片，也包括不少吸睛的美女圖片，用來當部落格文章封面圖，至少被分享時會有很好的傳播效果。

當然，這類圖片的肖像權仍歸屬於被拍攝者，如果要拿來商用就必須很小心了，可參考這篇「人物影像分享的相關法律議題」，是否會造成侵權、導致被告，情況很複雜，無法一概而論，不過可以試著用前述的概念來簡易分辨。


(出處: pexels.com)


例如拿 CC0 圖庫中的美女圖加工，製作成「醫美整形」的宣傳海報，很明顯這張美女圖會成為創作中的主角，擺明消費美女的肖像權來獲得商業利益、增加宣傳效果，而沒有付出任何代言費用，那麼就可能會被圖片中的主角提出告訴。

如果 CC0 圖片中的人物與獲得商業利益不會產生對價關係，那麼就比較不容易引起肖像權訴訟，但最好還是尋求法律專業人士的判斷。

三、侵犯商標權

CC0 留言板 #11 有這樣的提問：

請問一下，https://goo.gl/0yj2fX 如果要使用這張圖片後製並大圖輸出，除了網站已標示為CC0以外，真的不會有侵權樂高的問題嗎?

(出處: pixabay.com)


這張圖片所屬權利不少，除了有 "樂高積木"，也有 "超人 Logo" 圖示，可以跟文章開頭那張有 "蘋果 Logo" 筆電的圖片一起說明。

跟前一個案例 "侵犯肖像權" 的判別方式一樣，重點在於如何使用這張 CC0 圖片，如果商用、且明顯利用 "樂高積木"、"超人 Logo"、"蘋果 Logo"、"蘋果筆電" 等等主題來獲得利益，那麼就可能侵犯到 "樂高產品"、"蘋果商標" 的權益，因為並沒有取得授權、以及付出授權費用。

就算使用方式很小心，這些物件與商業利益不會產生對價關係，我認為參照 CC0 圖庫「PicJumbo」的 FAQ 說明最保險：

Note: Be respectful to registered trademarks, logos, objects or properties. Let's say if there is an Apple product, you should write "Apple, the Apple logo and iPhone are trademarks of Apple Inc., registered in the U.S. and other countries." The same with other brands, you're responsible for how you use the photos

中文的意思大致是這樣，請謹慎面對註冊過的商標、Logo、產品(或附屬品)，例如蘋果產品，最好註明類似 "蘋果圖示及相關產品的商標權歸屬於蘋果公司所有" 這樣的字句，以免被大公司告到破產。

四、侵犯其他主權

CC0 留言板 #11 有這樣的提問：

想請問, 網站上搜尋到的圖片印製T恤, 例如動物照片之類, 想知道 "可商業用途" 是否包含印T恤販售 ?

(出處: pexels.com)


將 CC0 圖片直接印在 T-Shirt 上販賣，很明顯圖片上的物體必定成了主角，那麼需要很嚴肅地看待是否造成侵權。

如果單純是 "動物" 照片就還好，畢竟動物無法對我們提起告訴。但如果圖片中還有其他物體，例如明顯看出是某 "動物園"、或附屬設施等，就需要請教法律專家了。

除了前面提到的 "肖像權"、"商標權"，將 CC0 圖片印在衣物上營利，算是很危險的事，必須很小心這張圖片是否侵犯了各種主權，例如圖片包含了：

• 經過設計的物品、藝術品等
• 印刷物、出版書籍內容或封面等
• 特別的圖案、符號表徵、Logo 等
• 使用了有版權的字體，例如金萱體

必須再重複一次，不想惹上麻煩的話，CC0 圖片要進行商用，請避免讓圖片中任何物體成為產品的主角。

如果是出版一本書，這張 CC0 圖片位於其中一頁不起眼的插圖，比較不會出事；但若當成封面圖使用，具有宣傳效果(成為主角，產生直接的對價關係)，就必須非常小心了。

五、上傳版權圖片到 CC0 圖庫

在「高畫質免費圖庫搜尋引擎﹍2015 版」留言 #6 有這則提問：

如果有人盜圖並刊登上cc0讓人使用 使用者是否會因為用了而觸犯法律問題?

這的確是很麻煩的一個狀況，因為我們信任 CC0 圖庫會做好把關，每張圖片都一定是 CC0 圖片，但若有人惡意上傳版權圖片的話，就會造成我們誤用。

關於這個難題，讓我們看看 CC0 圖庫龍頭 Pixabay 的作法，參考官網說明「Terms of Service」→「Uploading Content」這部分的內容，"上傳規範" 中文的意思大致如下：

• 關於上傳圖片的作者，您允許 Pixabay 及圖片使用者，對圖片進行下載、複製、修改
• 也允許商業或非商業使用
• 但您必須對上傳的圖片負責，您需保證以下：
  
  • 您必須擁有這張圖片，且圖片內容不能違反版權、商標權...等其他第三方權利。
  • 您必須持有證明文件或許可聲明，可保證此圖能在 CC0 條款下使用
• Pixabay 無法預期使用者會以何種方式運用圖片，我們也保留移除圖片的權利

這些內容算是 Pixabay 單方面的免責條款，我不是法律專家，就個人字面上的理解，如果真有惡意上傳版權圖片的狀況，導致我們誤用且被告訴的話，大概會走這樣的流程：

• 雖然我們可主張是「善意的第三者」，但如果告成功的話，我們還是得賠錢
• 賠錢後換我們對 Pixabay 或上傳者提起告訴進行求償

無論如何這個流程都是一件麻煩事，所以商用比較安全的作法是，我們也學 Pixabay 進行「免責宣告」，聲明 "圖片取自 Pixabay，所有權利歸於圖片中的物體，責任由上傳者負擔..." 類似這樣的內容，將責任轉嫁出去，或許不會直接成為被告。

六、切勿主張「版權所有」

CC0 留言板 #14、#16 有這樣的提問：

請問我使用CC0上傳的照片，被下載後重新上傳，並標示版權所有不得轉載 有違反法律嗎？(如：著作人格權)

我們將使用CC0圖片於出版品(書籍)中，已經確定圖片皆為CC0，並會在出版品上標示我們不擁有圖片版權。請問以上我們是否即可使用，或者還有其他需要注意的事項呢?

這是非常重要的一件事，使用 CC0 圖片絕對不可以宣稱「版權所有，不得轉載」，這違反了 CC0 的精神，也是非常嚴重的錯誤，因為「創用 CC」的宗旨就是鼓勵流通分享，讓所有人受益。

「版權所有，不得轉載」這句話在非常多網站都會看到，出版物也會附上這句話。若一定要聲明這句話的話，請務必記得：

• 不要使用任何 CC0 圖片
• 如果要用 CC0 圖片，請另外在圖片旁標示「圖片出自 xxx，我們不擁有圖片版權」類似這樣的字句

七、總結

總結一下本文的內容，如果要對 CC0 圖片進行商業用途的話：

• 「五、上傳版權圖片到 CC0 圖庫」的狀況雖然罕見，但必須提防
• 不可聲稱版權所有，或者請另外註明不擁有圖片版權
• 既然要商用，代表有獲利，那麼必須撥一部份預算聘請法務人員、或諮詢法律專家。
• 使用 CC0 圖片之前務必先問過專家意見，不能看完本篇所有案例就認為自己是專家了(被告過一次才能真的成為專家)。
• 如果覺得聘請或諮詢法務的費用太高，那我會建議直接付費購買圖庫，不要使用 CC0 圖片，除了費用比較少，也可省下溝通法律事務的時間。

更多 相關文章：

----
如這篇文章對您有幫助，請順手按個 +1 或分享，謝謝！

讓 FB 社團文章能依「貼文主題」分類﹍實作記錄

February 23, 2019, 11:06 pm

≫ Next: 網頁 API 測試工具整理﹍免費線上服務 + 軟體

≪ Previous: 不是使用 CC0 圖片就沒事，若要「商業使用」請注意這些案例

$

0

0

FB 社團長久以來給我的印象一直都不太好，因為實質上只是個大型塗鴉牆，除了 Google 搜尋不到，再怎麼有內容的分享、再優質的討論串，2~3 天後就沈得不見蹤影。對於資訊的分類、保存、去蕪存菁，都不具備一個正常討論區該有的功能。

直到近期看到不少 FB 社團有「貼文主題」的功能(比較像是 "標籤" 的作用)，如此可做出類似精華區的效果，讓我重燃好好經營 Blogger 討論區的念頭，於是開始研究如何在自己的 FB 社團弄出整個架構。

先說結論，這件事很困難，而且要有破釜沈舟的決心才做得到。請讀者先有心理準備，再來看本篇的心得整理。

一、需另外成立新社團

1. 「貼文主題」功能介紹

首先這是 FB 在 2018 年中推出的功能，可參考這篇「2018年FB推出的4組社團新功能」。

而「貼文主題」的操作方式、功能介紹，可見這篇「FB 社團新功能 管理員自訂討論主題 幫助社團成員快速索引」的詳細說明。

不過照著做以後，會發現自己的社團根本找不到相關選項。


2. 舊社團無法使用「貼文主題」

找到這個 FB 粉絲團討論串「管理社團頁籤內的貼文主題」，從留言者提供的各種交叉測試結果才知道：

• 有個類似的新功能叫做「單元」，但不等於「貼文主題」，比較難用一些。
• 目前舊社團無法使用此功能
• 開立新的社團也不一定有「貼文主題」
• 從有「貼文主題」的社團來歸納，共通點是需要先成立 FB「企業管理平台」

所以結論大致是，開新的社團不一定有此功能，但舊社團一定不會有這個功能！

所以現在讀者可以了解，為何「貼文主題」需要有破釜沈舟的準備，因為你的 FB 社團得砍掉重練！！


3. 進行方針

這篇「【Facebook社團新功能】管理社團頁籤內的貼文主題」對如何進行整理了兩種方向，本篇以 "第一種情況" 來測試，建立全新的社團。

二、新社團處理流程

1. 成立 FB「企業管理平台」

請參考這篇「企業管理平台要如何創建？」，完成所有設定流程。



記得將自己的粉絲團連結到「企業管理平台」。


2. 從粉絲頁建立社團

進入粉絲專頁後，如果左邊頁籤沒有「社團」的選項，請按以下流程建立社團：



按右上角「設定」，點擊左側的「範本和頁籤」。




螢幕往下捲到底，按「新增頁籤」。




彈出的視窗選擇「社團」這一項，按「新增頁籤」。

然後關閉此視窗。




重新進入粉絲團頁面，可發現左側頁籤多了「社團」，進入此頁籤。

右邊紅框處點擊「建立社團」，這個新成立的社團，就有「貼文主題」的功能了。

最右邊還有個按鈕「連結你的社團」，可以讓粉絲頁連結舊的社團，但我測試過了，過了好幾天依然不會出現「貼文主題」功能，所以只能乖乖從頭經營新的社團。

三、轉移社團成員及粉絲

為了讓 FB 社團文章能有「貼文主題」功能，流程做到這裡讀者會發現最大的困難點，在於一個空空如也的新社團，如何讓新成員有動力加入。

對於走過、路過、搜尋來的 FB 使用者，絕對不敢加入幾乎沒有使用者、或人數稀少的社團，以下是建議的作法：


1. 把社團公開

開始招收成員之前，先充實社團文章數量，例如把舊社團精華文章轉貼過來，利用「貼文主題」功能做好初步分類，並將社團設定為「公開」，讓路過的 FB 使用者能先看到社團內容，好料夠多才能提升加入的意願。

等到人數達標之後，如需要再改為「不公開」。


2. 轉移舊社團成員

準備動作完成後，可在舊社團發置頂公告，請成員加入新社團。

只是必須有心理準備，除非原本社團的凝聚力非常高，否則願意加入新社團的比例並不高，這也是打掉重練為何這麼困難的原因。


3. 其他增加社員的管道

接下來可說得各憑本事了，如果粉絲團、部落格經營得好，也是有可能將粉絲、忠實讀者轉變為社團成員。

這部分的詳細作法請參考這篇：

• FB 社團初期如何增加成員人數

四、小結

這陣子為了讓社團文章能分類，開新社團著實辛苦了好一陣子，不過長久來看的確是一件必須的事，可以讓 FB 社團功能更完善，內容也更有價值。

再加上 FB 原本就具備的社交功能，對於部落格的站長而言，等於可提供給讀者更多的交流管道。我相信一個互動良好的社團對於想經營品牌的部落格站長而言，絕對是大大的加分，因此本篇流程雖然痛苦，但鼓勵去嘗試。

更多 Facebook 相關技巧：

----
如這篇文章對您有幫助，請順手按個 +1 或分享，謝謝！

網頁 API 測試工具整理﹍免費線上服務 + 軟體

February 28, 2019, 8:07 am

≫ Next: SEO 紅利還剩多少空間可以操作？為何部落格不需要在意 SEO 架構？

≪ Previous: 讓 FB 社團文章能依「貼文主題」分類﹍實作記錄

$

0

0

前端開發工程師常需要串接各種第三方服務，例如 FB API、Google API 等。如果直接寫程式呼叫 API，可能會花不少時間 debug，來排除各種意想不到的錯誤。

Google 與 FB 很體貼開發者，官方大部分都有提供線上 API 測試工具，例如：

• FB Graph API
• Google Blogger API

那麼除了網路龍頭大公司以外的眾多 API 要如何測試呢？本篇整理一些免費軟體、線上測試工具，供前端工程師參考。

(圖片出處: getpostman.com)

一、Postman 軟體

• 操作教學：使開發API更方便的工具 Postman
• 官網下載：Get Postman for Windows
• Chrome 外掛：Chrome 商店

這個軟體有桌面版及 Chrome 外掛，使用桌面版介面比較完整，操作起來也比較舒服。

使用線上工具的優點是不用安裝軟體，但介面、功能會比不上桌面版軟體。所以如果常常需要測試 API 的話，會比較建議花個時間來下載軟體、進行安裝，將來作業環境可以比較順手。

二、線上服務 API Tester

• 官網：API Tester

以這篇「利用 Github API 上傳檔案」的範例程式碼進行測試：

• 上圖中間紅框處為送出的參數資料，API Tester 這個區塊我覺得設計不好，需要手動輸入所有 JSON 格式的字串，使用體驗不佳
• 但是優點為這個 Github API 的 PUT 能成功呼叫，代表這工具能自動將 JSON 物件轉成 Github 能吃的格式
• 下面紅框的 PASS 代表 API 執行成功

• 上圖為呼叫 API 後的回傳資料，可看到 Response Headers 資訊完整
• 而 Response Body 欄位設計不佳，所有資訊擠在一行呈現，除了要用滑鼠往右拉，也不易閱讀、操作及複製字串

三、線上服務 REST test

• 官網：REST test

用同樣的範例程式碼測試這個工具：

• 左邊紅框的按鈕可看出這個工具，在操作介面上設計得比較好，新增、移除參數都有圖形介面可操作，不必手動需入 JSON 格式的一大堆符號。
• 可惜 Github API 的 PUT 不能成功呼叫，從右方的錯誤訊息來看，代表這個工具無法將 JSON 資料轉成 Github 能吃的格式

• 上圖為呼叫 API 後的回傳資料，可看到 Response Body 欄位已將所有資訊格式化，很容易閱讀。
• 而 Response Headers 回傳內容比較少一些

四、總結

根據本篇的操作心得，免費線上 API 測試工具各有利弊，都有需要再加強的地方，所以最好在書籤裡面多準備幾個，根據不同 API 的性質使用不同測試工具。

而桌面版工具 Postman 則非常完善，沒有任何問題。那麼有時間研究的話建議裝桌面版，沒時間可直接使用線上工具。

更多網頁開發工具：

----
如這篇文章對您有幫助，請順手按個 +1 或分享，謝謝！

SEO 紅利還剩多少空間可以操作？為何部落格不需要在意 SEO 架構？

March 4, 2019, 5:44 pm

≫ Next: 為何 Blogger 封存頁面(archive)不該被索引？

≪ Previous: 網頁 API 測試工具整理﹍免費線上服務 + 軟體

$

0

0

接到的 Blogger 商業架站需求中，常會附帶要求加強 SEO，其中有些甚至希望改善 Blogger 的 SEO 架構。

從這些站長提供的背景故事中，發現某些共同現象：

• 以前搜尋結果大多在第一頁，但近期排名越來越後面，甚至快要搜尋不到了。
• 於是開始懷疑自己做錯了什麼，是否裝了什麼外掛影響到 SEO？是否沒做結構化資料？是否網站結構不佳？是否...(以下省略 500 字)

我想就特別寫一篇來回答，同樣的一個網站，為何 "一直以來 SEO 排名很好，但後來開始不斷下降"？

(圖片出處: pixabay.com)

一、經濟、產業發展週期

這個現象其實跟經濟發展的週期很類似，因此使用一些相關術語來說明，不過讀者不必恐慌，都是很簡單的概念。

一個國家的經濟成長期、成熟期，通常是由「人口紅利」所帶來，勞動人口比例由青壯年佔多數，不需扶養太多老年人口時，經濟起飛速度會很快。

台灣早已經歷人口紅利的階段，現在成為高齡社會，必須負擔各種年金、長照，經濟成長速度無法再與二、三十年前相比。而中國的 "人口紅利" 即將枯竭，經濟衰退也勢成必然。

從網路發展的週期來看，較早期的網站可以享受到「流量紅利」。接著 FB 崛起後，初期就投入 FB 行銷的粉絲團可以獲得「Facebook 紅利」。

同樣的道理，在大部分站長對 SEO 概念還濛濛懂懂的時期，最早開始操作 SEO 的一批人，則可以享受到 SEO 紅利。

所有的紅利 Bonus 都會過去，最近 Line@ 紅利也沒了，SEO 操作很快就會有失效的一天，當紅利用光之後怎麼辦呢？

二、Blogger 網站結構

所以站長們不必懷疑自己做錯了什麼，純粹就是「台灣錢淹腳目」的美好年代已經過去。如果使用 Blogger 架站的話，擔心 SEO 算是多餘的，因為 SEO 或網站架構有問題的話，怎麼會之前排名這麼好，等到現在才排名下降呢？

1. 部落格是最適合 SEO 的架構

既然這麼多來求援的 Blogger 站長都提到「SEO 架構」這件事，我認為一定是從別的地方聽來的，例如架站廠商、朋友等等。

找到了這篇「我應該要做 SEO嗎？在開始 SEO前你該知道的事」，算是證實了我的想法，引述部分文字：

有些網站本身的架構就非常符合 SEO，請了顧問後也只需要微幅的調整，就能有很理想的成效。但如果你的網站架構非常地不符合 SEO，要做到 SEO最佳化可能會動到商品分類方式、網址架構、前後台架構、導覽列，要做到 SEO最佳化就需要數個月以上的持續修改網站...

部落格站長非常有福氣，這段話是講給那些自架站的商業網站聽的，因為自架站如果沒有使用 CMS 內容管理系統，等於整個網站架構是自行組裝，那麼不一定適合搜尋引擎索引，所以需要進行 SEO 架構優化。

這部分我在「10 個不建議使用 Blogspot 建立網站的錯誤觀念釐清」說明過，直接引用相關內容：

請參考「部落格網站是否加強 SEO 就能帶來流量？」→「一、SEO 是什麼？」→「3. 誰需要做 SEO？」，部落格(不管是那個平台)先天擁有搜尋引擎最喜歡的 CMS (內容管理系統)架構，非常利於索引，一般自架站才需要調整架構方便搜尋引擎索引。

也請參考「Blogger 新版 RWD 範本，對 SEO 有哪些加分之處？」，只要使用官方 RWD 範本，會有最新的 HTML5 語意標籤、結構化資料標記，而且 Blogger 是 Google 產品，自然會符合最新的 SEO 規範，所以完全不用煩惱 SEO，只要專心寫文章就好了。

2. Google 測試 SEO 的工具

剛好 Google 去年推出一個線上網站評量工具，可以證實這部分的概念：

• WEB.DEV

以下來看看幾個網站的測試結果。




這是本站的測試結果，其他部分差強人意，但 SEO 被判定為 100 分。




這是 Facebook 的測試結果，SEO 被判定為 88 分。




另一個部落格平台「痞客邦」的網站，SEO 一樣是 100 分喔。




這是 PCHOME 的測試結果，SEO 被判定為 95 分。

現在讀者知道了嗎，在 Google 眼中，部落格平台的網站 SEO 都是滿分，所以哪需要調整網站架構呢？

三、SEO 操作空間

不同的網站類別，SEO 紅利用完的時間點不一樣。有間加拿大 SEO 公司，非常大方地分享了他們操作 SEO 的初階心得，概念其實很好理解，可以讓我們知道自己的網站還有沒有 SEO 紅利。

• 【SEO攻略】溫哥華網站 SEO 排名 操作分享

這家公司在接案前，會先分析案主的目標關鍵字，在搜尋結果第一頁的狀況，並進行評比。前10個搜尋結果中，打分數的重要指標是：

• 權威性網站的數量
• 擁有大量優質外連的網站數量

當數量太多，該關鍵字被判定為「高競爭性」，代表這個案子很難做，也代表「沒有什麼 SEO 操作空間」，也就是本文表達的「SEO 紅利用完了」。

整個世界網站的數量一定是越來越多，完全競爭的結果，遲早有一天搜尋第一頁都會是 "權威性網站"、"擁有大量優質外連的網站"，到了那個時候，怎麼操作 SEO 都沒有用。

說到底，「SEO 操作」只能趁搜尋結果第一頁 "家裡沒大人" 時混水摸魚一番，絕對不是佔據第一頁的真實因素，潮水退了之後還是要回歸真正的實力。

四、加強綜合實力才是關鍵

1. 紅利有用完的一天

回頭來看一開始 Blogger 站長的求救情形，其實某些領域的網站很可能好幾年前就該遇到 SEO 紅利用光的狀況，那麼為何某些領域的站長現在才覺得排名下降呢？

• 一開始「流量紅利」還在的時候，上網總人數還沒飽和，所以網站流量持續有成長空間
• 接著「Facebook 紅利」還在的時候，只要有進行 FB 行銷，網站流量繼續有成長空間
• 再來「SEO 紅利」還在的時候，只要有進行 SEO 操作，網站流量一樣還有成長空間
• 等到所有紅利都耗光，再也沒有手段可以吸引新的流量，就等著被後面陸續超車了

想要不被超車，自然得開車實力比別人好、車子性能比別人好，過彎、甩尾各種技巧樣樣通。


2. 結論

想要長期留在搜尋排名第一頁，最好的方法，就是變成「SEO 公司」眼中害怕的人物：

• 成為權威性網站
• 擁有大量優質外連

把這件事當成目標來努力，盡量不要想著短短一兩年就爆紅、炒短線，除非你經營這個網站的目的本來就是「能撈就撈」、「賺一筆大的就跑」。

目標明確之後，一般網站還不必十八般武藝樣樣通，但如果是商業網站，就需要加強綜合實力，讓自己成為最好的十名車手：

• 開車實力比別人好 → 寫出大量專業文章，或是要比其他網站更能解決問題
• 車子性能比別人好 → 網站速度快、網頁設計有質感、友善的閱覽體驗
• 過彎、甩尾各種技巧樣樣通 → 基本 SEO 概念、關鍵字經營、行銷宣傳能力都需到位

網路總體流量飽和後，想獲得好的搜尋排名只會越來越困難，但在不同時空環境條件之下，至今不變的依然是，實力、內容才是勝出關鍵。

更多 SEO 相關文章：

----
如這篇文章對您有幫助，請順手按個 +1 或分享，謝謝！

為何 Blogger 封存頁面(archive)不該被索引？

March 9, 2019, 5:01 pm

≫ Next: 千萬別用 Wix、Weebly 這一類架站平台，將來想搬家都不行

≪ Previous: SEO 紅利還剩多少空間可以操作？為何部落格不需要在意 SEO 架構？

$

0

0

用 Google 搜尋自己網站名稱時，如果權重還不錯的話，可能會有 2~6 個額外的「網站連結」 (sitelink)。如不清楚這是什麼意思，可參考這篇「認識搜尋結果的 Sitelinks」。

由於這 6 個額外的 sitelink 連結無法自行決定，我常常搜尋自己的「WFU BLOG」時看到很糟糕的結果：



上圖紅框的兩個連結，其實都是 Blogger「封存頁面」(archive)，從摘要文字可以判斷得出來不是文章頁面。其網址大致是 {http://網域/年份}這樣的形式，例如：

https://www.wfublog.com/2019

會發生這樣的狀況，主要是 Blogger 封存頁面都被 Google 索引了。而且不知是何種原因，這些頁面被 Google 認為比一般頁面更重要，這樣對搜尋結果不太有利。

因此最近決定徹底解決這些異象，本篇會說明如何設定，讓 Google 不索引 Blogger 的封存頁面，改善 SEO 的搜尋結果。

一、封存頁面影響搜尋結果

過去常有讀者表示搜尋不到自己網站的文章，根據「Google 搜尋不到自己的文章嗎？各種搜尋結果不如預期的疑難雜症整理」→ Q1 →「3. 查詢搜尋結果」，我測試了一下發現，其實大多數情況都搜尋得到文章連結，但有幾次發現奇特的現象，搜尋出來的大部分是封存頁面的連結。

我也對自己網站進行測試，搜尋以下字串：

site:wfublog.com

結果是這樣：




紅框處都是本站的封存頁面，但我並不希望封存頁面的權重這麼高，導致文章頁面被排擠到後面去。那麼最好的方法，我想就是讓「封存頁面」完全不要被索引，可以解決所有問題。

而且其實這些「封存」頁面，對 Google 來說都是重複的內容，基本上「Google 不鼓勵重複內容」，所以我建議網站中這些重複內容的頁面，都不要被 Google 索引：

• 標籤頁面 (按下標籤後產生的頁面)
• 封存頁面 (「網誌存檔」小工具，按下年份、月份後產生的頁面)

二、修改後台設定

1. 設定流程

官方後台提供了很完整的功能，讓站長們直接就能設定 Blogger 各種頁面，是否讓 Google 進行索引。

但必須先提醒，一般不建議去動這些 SEO 相關設定，請非常清楚自己在做什麼，否則設定錯誤可能會讓你的文章在搜尋引擎就此消失！！！

請按下面流程進行：

後台 → 設定 → 搜尋偏好設定 → 自訂漫遊器標頭標籤

如果是「停用」的狀態，請按「編輯」後選擇 "是" 進行啟用：



請務必參照上圖，設定的完全一模一樣：

• 首頁：勾選「all」、「noodp」
• 封存與搜尋網頁：只勾選「noindex」
• 文章與網頁的預設設定：勾選「all」、「noodp」

然後按「儲存變更」即可。


2. noodp 參數說明

以上的設定就能讓文章頁面被索引，而封存與搜尋網頁都不會被索引。

其中有個 "noodp" 比較特殊，可參考「善用各種Meta標籤」的說明：

ODP是Open Directory Project的簡寫，即開放式分類目錄搜索系統。ODP是目前網上最大的人工編制的分類檢索系統。NOODP顧名思義就是告訴搜尋引擎，不要按照目前開放式分目錄搜索系統的匹配方法擅自改動我的標題和描述

根據我查詢資料的結果，這篇「Google Stops Support For NOODP Robots Directive & Taking DMOZ Description」提到，因為 DMOZ 早已關站，所以 Google 已經停止處理 ODP，那麼我認為 "noodp" 有沒有勾選差別不大。

但我不是 SEO 專家，無法驗證 "noodp" 不勾選的結果，所以保險起見還是勾選吧。

三、修改範本

如果擔心修改設定錯誤，有個比較不影響 Google 索引文章頁面的方法，直接修改範本也有同樣效果。

參考這篇「How to block indexing of Blogger archive pages」，修改範本的方式為──

後台「主題」→「編輯 HTML」，游標點進範本區塊，按 Ctrl-F 搜尋 <head>這個字串，找到後在此字串的下一行，插入以下程式碼：

<b:if cond='data:blog.pageType == "archive"'>
<meta content='NOINDEX' name='ROBOTS'/>
</b:if>
儲存後 Blogger 封存頁面就不會被 Google 索引了。

這篇文章的作者提供了他的經驗，進行處理後大約 2 個月後，封存頁面從 Google 搜尋結果消失了。

四、查看網站管理員(Search Console)

我們也可測試一下以上做的這些設定有沒有生效，例如進入 Google 網站管理員的索引頁面：

• Google Search Console

左上角下拉選單選擇網站 → 左邊選單「索引」的「涵蓋範圍」→選擇分頁「排除」→ 下方找到「遭到 noindex 標記排除」




網站所有封存頁面都已經被 Google 排除囉~

P.S. 雖然這裡可看到封存頁面被排除，但 Search Console 不等於 Google 搜尋引擎，所以搜尋結果要看到封存頁面消失，仍得等待一段時間。

更多 Blogger 使用技巧：

----
如這篇文章對您有幫助，請順手按個 +1 或分享，謝謝！

---

千萬別用 Wix、Weebly 這一類架站平台，將來想搬家都不行

March 15, 2019, 9:07 pm

≫ Next: 前端操作 Apps Script 上傳檔案到 Google Drive 並取得連結﹍實作範例

≪ Previous: 為何 Blogger 封存頁面(archive)不該被索引？

$

0

0

前陣子接到一個搬家需求，想要從 Wix 搬到 Blogger。其實 Wix 風評很差過去已有耳聞，例如我在「是否痞客邦、WordPress 的 SEO 比 Blogger 好，有這樣的事嗎？」說過，Wix 的內容都是用 JS 產生，對 SEO 而言很糟糕。

而客人表示要搬家的理由是「速度越來越慢」，我也想實際體驗一下傳聞中的 Wix，所以找了一下資料，是否有管道能將 Wix 搬到 Blogger，看到這篇「如何將Wix網站轉移到WordPress」提到取得 Wix 網站 RSS 的方法，初步構想是：

• 先取得網站的 RSS 內容
• 想辦法將 RSS 轉換為 Blogger 能讀取的 XML 格式
• 再將 XML 檔匯入 Blogger

以上這一切只是理論、沒有現成工具，準備等成案之後再來研究。沒想到真的接了案子後，竟是接連災難的開始...

所以本篇必須紀錄下來，讓大家知道 Wix、Weebly 這類平台有多可怕，在開始架站之前務必要避開這類看似可以簡單架站，但將來會成為惡夢的平台。

(圖片出處: wix.com)

一、Wix 初體驗

1. 速度非常慢

需要分兩方面來說：

• 除了開啟一般網頁的速度慢，有些沒圖片的頁面照理說應該開啟很快，但由於 Wix 背景不知道在執行什麼，也常常因不明原因停滯住。
• 後台開啟速度也是誇張的慢，要編輯一個頁面得等很長一段時間來載入系統工具。
• 一方面懷疑 Wix 伺服器頻寬不夠，沒有因應新增的用戶來更新硬體，一方面對 Wix 工程師的能力打很大的問號。

2. 後台功能、網頁效果很強



Wix 後台頁面我相信如果上手以後應該不錯用，介面算是很整齊、有條理。




各種常見的特效功能也一應俱全，選項非常多。

使用滑鼠拖拖拉拉很容易就能做出一個網頁，包含各種有質感的特效。因為圖形化操作介面算是滿友善的，沒找設計師也能做出效果不差的版面。


3. 無法編輯 HTML

但是當我想要找出網頁的 HTML 原始內容時，卻發現無法跟 Dreamweaver 這類所見即所得的編輯器一樣，因為找不到能顯示 HTML 碼的地方。

這代表：

• 沒有修改網頁 HTML 的管道
• 只能經由後台編輯器的圖形界面來修改任何要調整的地方
• 自然也無法將網頁的 HTML 內容複製到別的地方

4. 無法匯出

除了無法複製 HTML，Wix 也不提供匯出網站內容的管道。而文章開頭找到的那篇「取得 Wix 網站 RSS 的方法」：

• 目前已經失效
• 如果在 Wix 曾建立 "部落格" 型態的網站，那些文章才能產生 RSS
• 而這個客戶所有建立的網頁都不是 "部落格" 型態，所以也不會有 RSS 內容

所以很悲慘的，這個案例的 Wix 網站，將沒有任何比較方便的管道，可以把內容搬到其他地方(或是 Blogger)。

二、使用圖形介面就能架站的平台

所謂 "使用圖形介面就能架站"，就是標榜滑鼠動一動，可以簡單將各種區塊拖來拉去做出網頁。不必寫任何程式，包含最簡單的 HTML，也就是 Wix、Weebly 這樣的平台。


1. 不輕易讓你把內容搬走

看完 Wix 的運作方式之後，大概可以瞭解這類平台的想法了：

• 他們會把操作介面做的很方便，功能包羅萬象，滿足使用者各種需求
• 但這是一個封閉系統，將來只能在這封閉系統內進行編修
• 不可能把一個網頁內容拿到其他地方編輯，例如拿去 WP 修改，甚至也不能拿去另一個封閉系統 Weebly 修改
• 若是將來想要搬家，就只能砍掉重練，所有網頁重新製作，沒別的辦法。

2. 不利於 SEO

如果一個封閉系統是世界級的，就像蘋果 Mac OS 自成一個體系，那麼果粉買單是可以理解的。但 Wix、Weebly 這些封閉系統，我覺得很難說服人把網站放在這些平台一輩子。

看完 Wix 後台後我可以理解，為了保護這些後台做出的各種網頁特效、華麗功能，你看不到產生的 HTML / Javascript，而且 Wix 是等網頁載入時，才用 JS 開始運算、產出前端的這些網頁效果，這對 SEO 有極嚴重的後果：

• 運算後產出的 HTML 碼架構很糟糕，搜尋引擎派出的機器人很難理解及索引
• 更糟糕的是，機器人不一定會對 JS 運算後產出的 HTML 進行索引
• 這代表 Wix 大部分的網頁內容，是無法被索引的，只有在後台設定的 SEO 少數內容、字串，也許可以被索引。

3. 部落格文章到底能否搬走

找到這篇 Weebly 的使用心得「在使用Weebly之前你該了解的是…」，作者提到跟 Wix 相似的狀況，如果是 "部落格文章" 的內容，還有可能搬到其他平台，如果非部落格文章，而是在這類平台製作的各種 "網頁" 內容，也就是各種具有華麗特效、圖片拼貼、輪播等等的網頁，就沒有搬走的可能。

而另一個 Weebly 官方討論串「Blog backups and exports」則有不同結論，似乎一堆使用者抱怨部落格文章無法匯出，這部分留給有相關需求的使用者來追蹤。

如果要使用這類平台的話，請做好永遠不會搬走的心理準備，也需要祈禱這類平台絕對不能倒，否則連搬到自架站的機會都沒有。

三、無法搬走程式碼

瞭解以上這些狀況後，我開始想別的辦法搬 Wix 的內容，也真正瞭解到什麼是「道高一尺，魔高一丈」。

因為 Wix 網頁內容是由 JS 運算後產生，那麼我開 Chrome 開發人員工具，找出運算後的 HTML 來複製，試試看這樣能否把 HTML 搬走，結果大開眼界：

1. 圖片

• 圖片使用不常見的 webp 格式
• 圖片放在 Wix 網域，代表若要複製到其他網域，直接從 Wix 主機就能封鎖
• 有些圖片甚至用背景圖的方式呈現，若要用程式搬比較麻煩。
• 所以真要搬圖片只能一張張重新手動上傳到新的平台。

2. Iframe

網頁的很多特效都放在 Iframe 之中，那麼直接複製到其他網站是無法運作的，直接從 Wix 主機就能封鎖 Iframe 的內容執行。

也因為如此，Wix 完全不必擔心使用者把頁面的 HTML 複製到其他地方，搬走了也不能用。


3. JS

很多特效需要載入特定 JS 才能執行，但 Wix 網頁載入了數不清的 JS，你不會知道將網頁搬走需要用到哪些 JS。

為了確保特效能執行，還得想辦法搬走正確的 JS 內容，否則可能就要載入一堆無用的 JS。

四、總結

這是路老闆在 2015 就遇到的 Wix 搬家案例「三個使用 Wix 開店平台前 你應該知道的問題」，沒想到我現在也遇到了一模一樣的慘劇，所有要搬家的頁面都得重做。

那麼本篇內容可以給所有站長作為借鏡：

• 請眼光放遠，不要使用 Wix、Weebly 這類平台
• 如果已經用了，而且想搬家，請瞭解這是多麼麻煩的一件事
• 搬家請準備大量的預算，因為這件事要花大量的時間

在架設任何網站之前，記得先想好退路，沒有不會倒的公司或平台，網頁內容能夠搬得走才是最重要的。

或許我會私心推薦「Blogger」為架站平台，因為進可攻退可守，隨時能移轉到其他平台。不過只要你的架站平台能夠編輯網頁原始 HTML 內容，至少搬家時都比 Wix、Weebly 好上太多。

更多「部落格搬家」相關文章：

----
如這篇文章對您有幫助，請順手按個 +1 或分享，謝謝！

前端操作 Apps Script 上傳檔案到 Google Drive 並取得連結﹍實作範例

March 20, 2019, 5:16 am

≫ Next: Blogger 網站如何追蹤 Google Analytics 點擊事件的成效？

≪ Previous: 千萬別用 Wix、Weebly 這一類架站平台，將來想搬家都不行

$

0

0

先前示範過「操作 Github API 上傳檔案」的作法，這次介紹如何操作 API 上傳檔案到 Google Drive。

實際上，如果真的使用 Google Drive API 來上傳檔案有些麻煩，因為需要走 oAuth2 驗證權限、每次都需取得 Access Token 金鑰，整個流程的步驟太多，說明起來複雜。

本篇找到的流程相對比較簡易，不需處理 oAuth2、Access Token，直接寫 Apps Script 就能從前端上傳檔案到 Google Drive，並取得檔案連結，以下來看如何進行。

一、指定 Google Drive 上傳資料夾

首先選定一個 Google Drive 存放檔案的路徑，進入該目錄之後，網址格式大致是這樣子：

https://drive.google.com/drive/folders/目錄 ID
請記下自己的紅字「目錄 ID」字串，之後會用到。

二、操作 Apps Script 指令碼

1. 撰寫 Apps Script 指令碼

進入「Google Drive」→ 按左上角「新增」→ 更多 → Google Apps Script

指令碼內容如下：

var folderId = "目錄 ID 字串",
folder = DriveApp.getFolderById(folderId);

function doGet(e) {
var para = e.parameter,
fileName = para.fileName,
fileType = para.fileType,
base64Data = para.base64Data;

return getFileUrl(fileName, fileType, base64Data);
}

function getFileUrl(fileName, fileType, base64Data) {
var data = Utilities.base64Decode(base64Data),
blob = Utilities.newBlob(data, fileType, fileName),
file = folder.createFile(blob),
fileUrl = file.getUrl();

return ContentService.createTextOutput(fileUrl);
}

• 紅字請替換為自己 Google Drive 存放檔案資料夾的「目錄 ID」字串
• 上傳到 Google Drive 的檔案需先將 base64 編碼格式的內容作處理，轉換為 blob 格式
• 接著使用官方提供的 DriveApp 就能非常簡單的操作上傳檔案，存放到指定路徑

2. 取得授權

儲存之後，或是第一次執行之前，系統會彈出要求授權的視窗，這個流程有好幾個步驟，詳細的圖文說明可參考「Google 試算表製作可執行 Apps Script 指令碼的按鈕」→「三、撰寫 Apps Script 指令碼」這裡的授權流程。


3. 發佈指令碼

最後要將指令碼發佈到網路上成為應用程式，供前端呼叫，操作流程如下：

• 檔案 → 管理版本
• 輸入描述內容 → 按「儲存新版本」 → 確定
• 發佈 → 部署為網路應用程式 → 選擇版本
• 將應用程式執行為：「我」
• 具有應用程式存取權的使用者：「任何人，甚至是匿名使用者」
• 按「部署」

接著視窗上會顯示「目前的網路應用程式網址」，網址格式如下：

https://script.google.com/macros/s/xxxxxxxxxxxxxxxxxxxxxx/exec
請記下自己的「網路應用程式網址」，之後會用到。

三、前端 HTML / JS 範例

接著前端使用以下範例程式碼，即可上傳檔案到 Google Drive，並立即取得檔案連結：

• 紅字請替換為自己的「網路應用程式網址」
• 操作 input 取得檔案內容的原理，可參考「HTML5 File API 讀取檔案內容」
• 重要的是利用 File API，分別取出檔案名、檔案格式、base64 格式編碼內容
• 上傳成功後，會在 #fileUrl 這個地方顯示 Google Drive 檔案路徑

更多 Google Apps Script 相關技巧：

----
如這篇文章對您有幫助，請順手按個 +1 或分享，謝謝！

Blogger 網站如何追蹤 Google Analytics 點擊事件的成效？

March 25, 2019, 9:07 pm

≫ Next: Blogger 或部落格使用 Markdown 加快寫作速度的各種方案優劣分析

≪ Previous: 前端操作 Apps Script 上傳檔案到 Google Drive 並取得連結﹍實作範例

$

0

0

之前接到一個需求，想在 Blogger 網站監測連結點擊的成效，收集不同優惠方案的點擊數據。

只要網站有安裝 Google Analytics(簡稱 GA)，那麼做到這件事很容易，為每個點擊按鈕植入 GA 追蹤碼，在 GA 後台就能撈出點擊事件的詳細報表。

但實際上做了之後才發現 Blogger 網站會遇到一些狀況，請見本篇的說明。

一、植入 GA 追蹤碼

1. 官方說明

• GA 事件跟踪

參閱 GA 官方文件後，追蹤碼的完整格式如下：

ga('send', 'event', [事件類別], [事件動作], [事件標籤], [事件價值]);

• 前兩個 send、event 都是必要參數
• 事件類別：必要參數，為該事件設定一個分類字串
• 事件動作：必要參數，紀錄該事件的執行動作
• 事件標籤：非必要參數，可為該事件進行註解說明
• 事件價值：非必要參數，只能填入數字

2. 追蹤碼範例

假設網頁上有個按鈕，會連結到行銷網頁，為了追蹤點擊的成效，追蹤碼範例如下：

ga('send', 'event', '按鈕', '點擊', '2019 最新優惠', 1000);
只要這個按鈕被點擊了，這一行 JS 就會被執行，該點擊事件會自動出現在 GA 的報表。


3. 完整 HTML 碼範例

這個按鈕的超連結語法範例如下：

<a onclick="ga('send', 'event', 'button', 'click', '2019 最新優惠', 1000);" href="行銷網頁連結" target="_blank">前往最新優惠頁面</a>
有沒有覺得奇怪上面完整的範例碼，把 '按鈕', '點擊' 這兩組中文字串，換成了英文？

我在這篇「Google analytics 事件追蹤教學」，看到作者使用的參數為中文，而且 GA 截圖也顯示中文，但很奇怪「事件類別」、「事件動作」這兩組參數，我使用中文字串時 GA 都不吃，但一用英文字串 GA 馬上就撈到數據。

所以讀者可以自行試試看，如果中文也無法被 GA 接受的話，就使用英文吧。

但「事件標籤」確定是可以使用中文字串的。

二、調閱 GA 事件報表

接著進入「GA 官網」→ 左側選單：

• 行為 → 事件 → 總覽

• 如果剛剛自行點擊按鈕，想要馬上看報表，右上角記得日期範圍要選「今天」。
• 可以看到「事件類別」抓到的資料全部都是英文，我設成中文字串的事件全部都沒撈到。

切換到「活動標籤」看看，這邊就正常了，中、英文都沒問題。

三、Blogger 如何植入事件追蹤碼

前面說明的是所有網站通用的處理狀況，Blogger 若使用相同的追蹤碼，有可能在 GA 怎麼樣都追蹤不到任何事件。

調查了很久才發現原因，可參考這篇「Google Blogger/Blogspot onclick event in link will not pass to Google Analytics」。


1. Blogger 預設的 GA 安裝碼

事情出在 Blogger 範本中的 GA 預設程式，大部分 Blogger 站長都會符合以下兩個條件：

• 後台 → 設定 → 其他 → Analytics (分析) 網站資源 ID → 填入 GA ID
• 範本中應該會看到這行字串 <b:include data='blog' name='google-analytics'/>

這樣 Blogger 不需要額外在範本中放入 GA 安裝碼，在網頁原始碼中就會看到自動產生的 GA 安裝碼，像下圖這樣：




注意上圖紅框的程式碼，這行由 Blogger 自動產生的參數，正是讓 GA 事件追蹤碼失效的原因：

ga('blogger.send', 'pageview');

正常的 GA 安裝碼參數應該是 'send' 而不是 'blogger.send'，這會導致 「GA 事件追蹤碼」跟「GA 安裝碼」彼此無法對應。

然而 Blogger 自動產生的「GA 安裝碼」我們又無法修改，所以我們得修改「GA 事件追蹤碼」的參數，讓兩邊能對應的起來。


2. Blogger 修改事件追蹤碼

請將前面提供的完整 HTML 碼範例，改成以下即可：

<a onclick="ga('blogger.send', 'event', 'button', 'click', '2019 最新優惠', 1000);" href="行銷網頁連結" target="_blank">前往最新優惠頁面</a>
只有紅字部分不同，其他都一樣，這樣 GA 報表就能看到事件的數據了。

四、總結

使用 Blogger 先檢查一下，如果使用官方範本，那麼一定會出現自動產生的 "blogger.send" 參數，那麼就需要修改 GA 事件追蹤碼。

如果使用非官方範本，那麼可開啟網頁原始碼，搜尋是否有 "blogger.send" 參數。如果沒有的話，應該當初是自行安裝 GA，那麼追蹤 GA 事件就不必特別修改參數了。

更多 Google Analytics 相關文章：

----
如這篇文章對您有幫助，請順手按個 +1 或分享，謝謝！

Blogger 或部落格使用 Markdown 加快寫作速度的各種方案優劣分析

March 27, 2019, 4:11 pm

≫ Next: Google Domains 台灣可以使用了﹍購買 + 轉移網域(Godaddy) + DNS 設定心得

≪ Previous: Blogger 網站如何追蹤 Google Analytics 點擊事件的成效？

$

0

0

前陣子有讀者在「Blogger 文章相關工具」留言，詢問 Blogger 使用 Markdown 撰寫所發生的問題。雖然以前大致瞭解過 Markdown 的用法，但沒發表過相關文章，那麼現在就藉機會整理一下相關資料。

許多 Markdown 愛用者會希望 Blogger 官方文章編輯器能支援，然而我的看法是，Markdown 功能不算大眾，官方若真的做了可能吃力又不討好，因為：

• 「Blogger 文章編輯模式只要切換, 就可能產生異常現象」，這麼多年過去了還是一樣。
• 若加入 Markdown 功能，那麼「HTML / 撰寫」模式切換後的效果更是難以預料，說不定衍生的異常引來更多民怨。
• 模式切換後，究竟要保留原本 Markdown code，還是要轉換成新的 HTML code，各自都有對應的問題：
  
  • 保留 Markdown code：可繼續從原本的 Markdown 語法編輯，但無法先知道儲存後會變成什麼 HTML 碼
  • 轉換成 HTML code：無法繼續編輯原本的 Markdown 語法
• Markdown 版面效果其實沒有統一的規範，那麼 CSS 要如何決定？是否官方要另外做教學及修改操作文件？萬一非官方範本的 CSS 覆蓋了官方的 Markdown 語法 CSS 怎麼辦？

這些問題若我是官方也很頭大，不去碰說不定還比較好，而且部落格用 Markdown 寫作還有其他多種作法，那麼就來看看本篇的整理。

一、Markdown 介紹及工具

1. Markdown 語法

會對本篇有興趣的讀者，相信已經瞭解什麼是 Markdown，那麼這裡直接提供相關連結就好：

• Markdown 說明文件台灣官網

簡單說這是一種標記語言，可以想成是 HTML 碼的壓縮檔，使用的任何 Markdown 語法都可以解壓縮為 HTML 碼，所以使用 Markdown 語法可以縮短打 HTML 碼的時間，寫文章的速度比較快一點。


2. Markdown 工具

這篇「幾款好用的Markdown編輯器」介紹了非常多 Markdown 工具，各種平台都有，以下會針對不同方案重點介紹。

二、用外掛在網頁上顯示 Markdown 效果

• 結論：這是最不推薦的方案
• 作法原理：
  
  • 直接在 Blogger 文章中使用 Markdown 語法
  • 網站安裝 Markdown 外掛(showdown)，等頁面載入後 Markdown 語法才用 JS 翻譯成 HTML 碼，在網頁上顯示效果
• 教學文章：在 blogger 貼漂亮 code 的方法（使用 markdown 和 prettyprint）

為什麼這個作法最不好呢？因為文章中都是 Markdown 語法，而不是 HTML 碼，代表 Google 無法索引真正該有的 HTML 內容，對 SEO 是非常糟糕的。例如機器人無法找到這些 HTML 碼：

• 所有的連結
• 所有的圖片連結
• 一些權重標籤例如 H2、H3 等

簡單說，這篇文章將只有純文字、無意義的符號(Markdown 語法)被索引，而重要的連結、圖片等 HTML 碼都不存在，這是非常可怕的事。

三、用瀏覽器外掛寫 Markdown

• 結論：沒有很推薦的方案
• 作法原理：
  
  • 使用瀏覽器套件(MarkdownHere)
  • 直接在 Blogger 文章編輯器就能使用，非常方便
  • 輸入 Markdown 語法後，用套件可直接轉換成 HTML 碼，SEO 問題比較小一些
• 教學文章：輕鬆地使用 Markdown 寫、編排網誌(各大網誌)文章與信件

這個作法比前一個已經好非常多了，至少文章中儲存的是 HTML 碼，不會發生 SEO 索引不到連結、圖片這樣的憾事，但還是需要深入分析這個作法優缺點：

• 缺點：
  
  • 轉換後的 HTML 碼十分可怕，有大量累贅的無用處 HTML 碼，也有大量的行內 CSS，也增加 Google 機器人索引的負擔
  • 一般使用者對 HTML 碼無感，但對前端工程師而言，會知道這對日後的閱讀、維護相當不利
  • 這些行內 CSS 會覆蓋網站原有的 CSS 設定
  • 日後也無法透過修改範本中的 CSS，來套用全部文章的相關 CSS 效果，所以只能一篇篇手動調整
• 優點：
  
  • 這個作法算是 Markdown 操作上，最便利的一個方案，不必再從別處複製 HTML 碼過來
  • 行內 CSS 很頭痛，而唯一可以安慰的優點算是，預覽的效果大致上就是網頁上呈現的效果(因為蓋掉了範本 CSS)
  • 所以對於不熟悉 HTML / CSS 的使用者，這個方案有可能是最適解。

四、用網頁服務寫 Markdown

• 結論：這是最推薦的方案
• 作法原理：
  
  • 使用線上服務，例如 Dillinger
  • 線上輸入(或貼上) Markdown 語法後，可直接預覽效果
  • 也可直接取得 HTML 碼
  • 再將產生的 HTML 碼貼到 Blogger 文章編輯器即可
• 教學文章：七款支援即時預覽的線上 Markdown 文件編輯器

為何推薦 Dillinger 這個線上服務呢？實際操作後，發現他轉換後的 HTML 碼，沒有多餘內容，也沒有行內 CSS。那麼雖然要多一道複製 HTML 碼的手續，但顯然優點遠多於複製 HTML 碼的操作時間。

不過事情沒有這麼單純，歸納一下優缺點：

• 優點：
  
  • HTML 碼乾淨，沒有行內 CSS，日後好閱讀、維護
• 缺點：
  
  • 因為沒有行內 CSS，代表預覽效果不等於網頁上看到的效果
  • 站長必須熟悉 CSS，自行在範本中新增相關的 CSS 樣式，才能重現這些 Markdown 語法的效果
  • 甚至如果範本中已有相關的 CSS，站長得知道如何修改 CSS 參數，才能覆蓋原範本的效果

看完以上說明，雖然這是最推薦的方案，但如果不具備 HTML / CSS 基本知識，也許不一定適合本方案。文章開頭提到的讀者提問表示：

轉成html再貼到blogger後引用區塊格式會跑掉

會有這情形代表，他的網站預設的 blockquote 元素 CSS 樣式，跟他看到的 Markdown 預覽效果不一樣，那麼得知道如何修改範本中 blockquote 的 CSS 才能解決這個問題。

五、用軟體寫 Markdown

• 結論：不上不下的選擇
• 作法原理：
  
  • 安裝作業系統 Windows 軟體，例如 MarkdownPad
  • 操作方法跟「四、用網頁服務寫 Markdown」差不多
• 教學文章：利用 Markdown 寫 Blogger 文章 - 使用 MarkdownPad 2

為什麼說是不上不下的選擇呢？因為不會是最好、也不會是最差。他有兩種途徑產生 HTML 碼：

• 因為無法即時產生 HTML 碼，需要從選單中選擇輸出成 HTML 檔，然後開啟檔案、選擇要複製的內容，十分麻煩：
  
  • 至少這部分產生的 HTML 碼乾淨，那麼優缺點就跟「四、用網頁服務寫 Markdown」一模一樣了
  • 但是操作步驟較不方便，所以不會是最佳選擇
• 根據教學文章，選單中有個選項，可以直接「複製即時預覽內容」到 Blogger 編輯器，很方便：
• 但這部分產生的 HTML 碼非常可怕，跟「三、用瀏覽器外掛寫 Markdown」一模一樣，所以優缺點也一模一樣
• 那麼這個途徑的作法，算是糟糕的選擇，但也許對不懂 HTML / CSS 的人而言是方便的。

六、總結

整理完所有方案後，發現不存在最佳解，只有最適解。也許站長們需要根據自己熟悉 HTML / CSS 的程度，來選擇最適合自己的作法。

或許也可以這麼說，熟悉 HTML / CSS 的站長才適合使用 Markdown。

因為我沒有使用 Markdown 編輯文章的習慣，順便分享自己比較順手的編輯文章技巧，如果你不想花時間研究 CSS 的話，那麼 Markdown 也不算寫文章加速的唯一管道：

• 快速輸入 HTML / CSS 還有其他很棒的工具，例如我會用 Emmet，可參考「前端開發神器 Emmet 快速上手教學整理」
• 常用的 HTML 語法我會使用「Hotkeyz」設定快速鍵，例如用熱鍵直接產生圖片、超連結、項目清單等語法。
• 文章中常用的大標題、副標題、其他 HTML 元素、常用格式等等，我會製作文章範本，可參考「我如何寫一篇 Blogger 文章的流程」，減少重複輸入的時間。

如果一時沒有找到 Markdown 最順手的處理方式，那麼也可參考這些不一樣的作法，說不定效率比 Markdown 更好喔。

更多網頁開發工具：

----
如這篇文章對您有幫助，請順手按個 +1 或分享，謝謝！

Google Domains 台灣可以使用了﹍購買 + 轉移網域(Godaddy) + DNS 設定心得

March 31, 2019, 8:41 pm

≫ Next: 網頁出現看不見的特殊字元或方框時，該如何處理？

≪ Previous: Blogger 或部落格使用 Markdown 加快寫作速度的各種方案優劣分析

$

0

0

幾年前在「Godaddy 購買網址」，一次買五年+隱私保護折價券，平均起來一年不到 USD 10。然而幾年過去，Godaddy 上市了，續約折價券沒了，隱私保護貴得離譜，網址續約不斷漲價。

雖說用起來滿穩定的，但續約的 CP 值低得可憐，所以近一兩年在網址到期前，我不斷觀察合適的替代品。而成為最後一根稻草的理由是操作介面，Godaddy 幾次改版以來，不變的是迷宮難度未曾降低，任何常用功能我總要點半天才能找到頁面。公司這麼大但使用體驗還這麼差的情況下，Godaddy 確定被我淘汰出局。

友站「阿力獅的教室」因長期協助客戶管理網站，經手近 20 家網域註冊商，整理一下阿力獅推薦過的可靠選擇：

• Gandi：管理大量網域方便、DNS 生效及反應速度快、隱私保護免費、中文介面
• Name.com：費用便宜、隱私保護可使用免費折價券、中文介面

如果是 Blogger 以外的平台，以上兩者都不錯，可依自己的預算、功能需求作選擇。

身為 Blogger 站長，私心的第一選擇是 Google Domains，同樣也有獲得阿力獅的認可。幾年來一直卡在台灣不能使用的困境，但這幾天突然發現問題解決了！那麼順帶說說我認為的特點：

• Google 伺服器的穩定度、反應速度絕對首屈一指
• Google 沒賺錢的服務會收起來，但有營利的產品其品質一定非常可靠。
• 跟 Blogger 都是 Google 產品，伺服器住得比較近總會有好處
• 有中文介面
• 「隱私保護」功能免費
• 一年費用固定 USD 12(.com)，買多了不會便宜，但實際上也不貴，我認為超值。
• 操作介面簡單直覺，符合 Google 一貫風格，我要的功能都可幾秒內就找到，遠勝 Godaddy

因為台灣終於能註冊了，那麼沒有意外的話，本站從此會在 Google Domains 定居下來，以下分享這陣子的操作心得。

順帶一題，更多尋找網域註冊商、比價的好工具，可參考「使用 domcomp 進行網域名稱快搜比價」。

一、購買網域

1. 中文官網

首先非常要緊的第一件事，是找到中文官網，如果直接進入 Beta 官網：

• https://domains.google/

你會發現網頁下方的語言選項，找不到中文。所以請把以下網址放入書籤，可以直接使用 Google Domains 中文介面：

• https://domains.google.com/m/registrar/

這個網址會偵測使用的語言，自動切換成中文。


2. 購買時的問題



進入官網後，上方那一行 "Google Domains 目前仍不支援您所在的國家/地區" 總是讓人怕怕的，不過先別擔心。




這行文字會在每個步驟如影隨形跟著我們，先當作沒看到，假設我買了這個網域 wfublog.net，按下「結帳」試試看。




果然，買單的時候就會要我們選邊站，雖然左側選單顯示位於「台灣」，不過現在得正式表態了，喜歡日本就選日本，我是先選擇「美國」。




雖然我沒有美國地址，不過還是對著紅框點下去吧！




好開心啊～聯絡資訊的國家可以選擇「台灣」呢，不需造假填美國地址資料，也不必委屈被當成中國一省，那麼就照實填寫吧，將來網域若引起糾紛留下的資料必須能讓 Google 聯繫上，且 Google Domains 提供隱私保護，這些資料不會被查詢到。

另外填寫比較會讓人混淆的地方說明一下：

• A：此處填寫 "縣市"，例如台北市
• B：此處填寫 "鄉鎮區"，例如松山區

接下來填寫信用卡資料，不會有什麼困難了。


3. 購買流程

如果購買流程還是有疑問，可參考這篇圖文說明「在 Google Domains 註冊購買網域名稱教學」

二、轉移網域準備動作

如果跟我一樣需要移轉網址，那麼有幾件事需要先做：

1. 解除網域鎖定
2. 移除隱私保護

請先到原本的網域註冊商後台，找到這兩個地方的選項做處理，如果沒有做這 2 件事的話，就會跟我一樣收到上圖的警告信，同時 Google Domains 的轉移流程就會終止，等我們處理完畢後，整個轉移流程要重頭再跑一次。

如果真的在 Godaddy 迷路找不到選項，也可乾脆逕行移轉，讓 Godaddy 寄警告信來，裡面會附上操作步驟，說不定還比較快。

2019.4.1 補充：重複移轉失敗的後遺症是，會進行多次結帳，然後 Google 又進行刷退，導致信用卡帳單可能會多筆刷卡、刷退紀錄，由於是「境外刷卡交易」，反覆異常的舉動導致銀行拼命打電話來確認交易、詢問是否被詐騙了..

三、轉移網域流程

1. 從 Godaddy 轉出

首先從 Godaddy 移轉網域的圖文流程，可直接參考「從 GoDaddy 轉移網域到 Google Domains 教學」→「解除鎖定、取得授權碼」這部分的內容即可。


2. 轉入 Google Domains

接下來 Goole Domains 的操作狀況，因為台灣可以使用了，所以紀錄一下圖文流程：




官網畫面選擇「轉移網域」




輸入網域後來到上圖畫面，填入 Godaddy 寄給我們的授權碼，按「繼續」。




如果跟我一樣，原本的網址設定了很多子網域，那麼有必要把 DNS 紀錄複製過來，可節省一點操作時間，選擇上圖的「複製 DNS 設定並允許 Google 管理這些設定」，按「繼續」。




免費的「隱私保護」當然要啟用啦，是否啟用自動續約就看你有沒有想要再搬家囉。

畫面上方的 "Google Domains 目前仍不支援您所在的國家/地區" 是可以解決的，勇敢地按「進行結帳」吧。




跟前面購買網域的流程一樣，隨便選個順眼的國家按下去吧，如上圖的 "美國"。

接下來系統會精神分裂一下，因為我們明明在台灣、卻選擇美國，正常的流程無法繼續執行下去，最後就炸掉了，畫面會跳回一開始的「步驟 1：準備網域」，也就是前面圖片要輸入 Godaddy 授權碼的地方。

沒關係，我們重新再跑一次流程，重新輸入授權碼，最後結帳的時候，就不會再問一次國籍問題了。




這次系統會出現上圖的填寫聯絡資訊畫面，現在可以正大光明選擇「台灣」囉，請按範例照實填寫即可，按「儲存並繼續」。




接著填寫信用卡資料，這部分只能顯示 Google Domains 支援的國籍，如上圖之前選的「美國」，但無妨，郵遞區號隨意填 5 個數字即可，按下「結帳」。




至此完成 Google Domains 所有移轉流程，還需回到 Godaddy 進行最後確認動作。


3. Godaddy 確認移轉

接下來的流程很簡單，沒有困難點，請繼續參考「從 GoDaddy 轉移網域到 Google Domains 教學」→「接受網域移轉」、「驗證 Email」的內容即可。

如果都順利的話其實很快，不用半小時就處理完了。

四、DNS 設定

最後需要把 Godaddy 的所有 DNS 複製過來，也許你會覺得奇怪，前面不是有個步驟會複製 DNS 紀錄？實際檢查之後，才發現大部分 DNS 設定 Google Domains 都抓不到。

複製 DNS 的動作必須趕快進行，否則 Godaddy 隔天會將紀錄移除，到時就麻煩了。

我在 Godaddy 的 DNS 紀錄大致像這樣：




這還只是一部份而已，在 Google Domains 選擇移轉後的網域 → 左邊選單選「DNS」，我們來看看 Google Domains 抓到幾個：



「A 類型」沒有全部抓到，而將近 20 個「CNAME」只抓到 1 個，其他全部要手動輸入。

所以移轉完網域後，趁 Godaddy 還能顯示所有的 DNS 紀錄，請立刻對照兩邊的紀錄，一一把 DNS 都複製過來。

五、其他功能

補充一些其他操作心得，依照上圖的頁面說明：

1. 註冊設定

• 網域權限：這裡可以邀請其他帳號來管理 Google Domains，但請注意，邀請來的帳號也擁有全部權限，包含剔除我們的帳號，請找信得過的人。
• 註冊 → 更新付款方式：這裡可修改信用卡號
• 註冊 → 增加年繳：這裡可以預先支付未來的費用，最多 8 年，雖然沒有優惠，但先繳也可以預防未來漲價。

2. DNS

這裡可免費啟用「DNSSEC」功能，是一種 DNS 的安全防護功能，可參考「DNSSEC安全技術簡介」。

但不是專家的話建議不要亂動，如果像我一樣不了解網路底層架構知識的話，維持關閉的狀態就好，設定沒弄好可是很麻煩，網站可能會長時間看不到。


3. 電子郵件

可以設定「電子郵件轉寄」，例如設定自訂網域的郵件：

• info@wfublog.com → 轉寄到 gmail 信箱

這樣在名片上就可以印比較專業的 info@wfublog.com，而非免費的 gmail 信箱。


4. 說明

官方中文文件滿詳細的，操作上的問題在這裡都可以找到答案。


5. 提供意見

分兩種處置方式說明：

• 時間不急的話，可以用「提供意見」留下截圖、意見、或是問題，讓官方用 email 回覆
• 如果想要立即、不同方式的回覆，從「4. 說明」→「支援服務選項」，可以找到官方的聯絡方式，提供了 24 小時的服務「Additional support in English」：
  
  • 目前立即的聯絡方式只能使用英文
  • 可以使用 Email、線上即時通、或是手機

六、補充說明

2019.4.1 補充：如果之前就買 Google Domains，但註冊資料使用其他國籍，那麼修改聯絡資料可參考「阿力師的處理流程」：

之前已註冊，但是因為系統原因導致國家是中國的，要改聯絡人資訊方式如下。
(因為已購買的個人資訊修改表單，沒有新購買的那張表單聰明，不會因為國家不同自動變更欄位)
1. 國家選 [台灣]
2. [州] ([郵遞區號]左側那一欄) 填台灣都市名稱，請填中文。
3. [城市] ([州] 左側那一欄) 填鄉鎮市區，填中文。
4. 核取 [使用這項資訊做為管理員聯絡資訊] 及 [使用這項資訊做為技術聯絡資訊]。
5. 點擊 [儲存]。
打完收工，我終於不必掛在中國下面了。

更多「網域」相關文章：

----
如這篇文章對您有幫助，請順手按個 +1 或分享，謝謝！

網頁出現看不見的特殊字元或方框時，該如何處理？

April 5, 2019, 5:15 am

≫ Next: 查詢網站所有連結的點擊成效﹍GA 事件追蹤器(免費版)

≪ Previous: Google Domains 台灣可以使用了﹍購買 + 轉移網域(Godaddy) + DNS 設定心得

$

0

0

有時我們會在網頁上看到亂碼，或是一堆方框，代表那些字元因為系統沒有對應的字型，或是字型不含這些編碼，所以無法顯示出來。

這次遇到的案例很特別，手機上會看到無法顯示字元的 "方框符號"，網頁版卻看不到，以下來看看如何找出原因及解決。

(圖片出處: pixabay.com)

一、案情分析

1. 事發經過



案主表示在 Windows 系統下用軟體檢視文章內容，會看到上圖兩個 "LSEP" 這樣的符號。




發佈文章後，用手機看網頁，會看到兩個無法顯示字元的「方框符號」，位置在上圖文字 "再來對照我的觀察。" 後面。




然而在網頁版的瀏覽器上面，不會看到這樣的方框。


2. 原因分析

從以上徵兆來看，"LSEP" 應該是一個看不見的特殊字元，網頁版的字型檔抓不到編碼，乾脆不顯示。而行動版的字型檔卻可抓到編碼，但該編碼又不在字型編碼的範圍，所以變成了 "方框符號"。

餵 Google 後找到 Wiki「Unicode控制字符」，原來 "LSEP" 屬於換行字符，也就是按「Enter」的作用：

U+2028「」LINE SEPARATOR ，HTML：
，LSEP

至於為何網頁版、行動版的效果不一樣，只能說不同的作業系統，對於不同的 Unicode 編碼有各自的解讀了。

二、從文章編輯器修改

上圖是我進入 Blogger 後台文章編輯器的畫面，將游標移到案發現場 "再來對照我的觀察。" 這段文字的後面，"LSEP" 就位於句號與換行語法「<br/ >」之間。

因為網頁版作業系統看不到這個特殊字元，所以上圖的畫面是看不到的，但是我們可以真實感受到這兩個 "LSEP" 的存在，操作方式如下：

• 游標移到圖中句點 "。" 的後面，接著按鍵盤方向鍵 "→" 向右，會發現卡住兩次，按到第三次時才能順利往右移動
• 移到到「<br/ >」右邊後，換成按 "←" 向左，直到句點的位置時，又會發現卡住兩次，第三次向左才能成功。

這代表雖然看不到，但是 "LSEP" 是實際存在的，像是三度空間與四度空間的交界，眼見不一定為真。

我們可以按 "Del" 或 "Backspace" 把這兩個看不見的字元刪除，網頁上就可以正常，不再顯示方框符號，但這麼做太慢了，因為這篇文章有好多個 "LSEP"，這該怎麼辦呢？

三、使用文書處理軟體

雖然作業系統因為字型檔的緣故，無法讀取這些特殊字元，但多數的文書處理軟體都可以看到特殊字元，因為用的不是作業系統字型，這些軟體會使用自己的字型來顯示文字。




上圖是我使用 Notepad++ 的畫面，將 Blogger 文章編輯器的內容複製過來，紅框標示處兩個 "LSEP" 無所遁形。




用同樣方式，上圖是我使用 Sublime Text 的畫面，結果可能這個軟體的字型檔不夠力，紅框標示處兩個 "LSEP" 無法正確顯示，跟行動版效果一樣變成了 "方框符號"。

但無論如何文書處理軟體只要能抓到這些特殊符號，要移除就很簡單了，使用 "全部取代" 的功能，就可一次移除所有 "LSEP"，部落格文章在網頁上就不會再顯示方框了。

四、產生特殊符號的原因

1. 蘋果軟體轉換產生

為了找出這些特殊符號產生的原因，詢問了案主是如何寫文章的，她表示操作流程為：

• 使用 Word 然後貼到 Mac 的文字編輯器
• 有個內建功能可轉成純文字格式

從這個流程看來，看不見的特殊符號看起來是這個 Mac 軟體，在轉換為純文字的過程中產生。

如果這個軟體很好用，那麼只好每次都在 windows 下文書軟體執行一次「全部刪除 "LSEP"」的動作。

不然只好想辦法找到其他替代流程，不會產生 "LSEP" 字元的轉換軟體。


2. 其他軟體轉換產生

其實這樣的現象我以前有遇過，而且狀況更難察覺。本文的案例還可在 Notepad++、Sublime Text 軟體看到這些特殊字元的存在，我以前遇到的狀況是：

• 使用某些轉換軟體產生內容後，偶爾會跑出看不到的特殊字元
• 使用 Notepad++、Sublime Text 也看不到這些特殊字元
• 為何知道有這些特殊字元呢？因為文章中明明沒有東西，但網頁上總會跑出一個奇怪符號。
• 而在 Notepad++、Sublime Text，使用方向鍵移動到特定的字元時就會卡住，跟本篇案例一樣
• 代表該軟體會自動產生特殊字元，而且不是 "LSEP"，無法知道是何方神聖。

因為以前看不出是什麼端倪，也無從 Google 原因，現在遇到本文案例後，算是解開當年的困惑，特撰本文紀錄。

更多「網頁技巧」相關文章：

----
如這篇文章對您有幫助，請順手按個 +1 或分享，謝謝！

查詢網站所有連結的點擊成效﹍GA 事件追蹤器(免費版)

April 9, 2019, 1:25 am

≫ Next: 各種「網頁失效連結」檢測工具評價分析及使用心得

≪ Previous: 網頁出現看不見的特殊字元或方框時，該如何處理？

$

0

0

我們的網站可能裝了各式各樣的小工具，例如：

• 首頁的輪播
• 側邊欄的標籤、熱門文章、精選文章...
• 文末的相關文章、延伸閱讀

這些工具的文章連結，無一不是想增加訪客的黏著度，盡量把訪客留在網站內，但我們真的有辦法可以明確瞭解所有工具的成效嗎？會不會裝了一卡車外掛結果根本沒人點擊呢？

有時後可能只是憑感覺、或是心情來決定是否安裝某個小工具，或是看別的網站有裝所以跟著裝，但若是外掛太多卻沒有對應的成效，那麼只是影響網頁載入速度而已。

這件事能用科學方法來評估的話是再好不過，如果有辦法追蹤讀者的每一個點擊，那麼在決定網站小工具配置時，就不至於瞎子摸象，可以利用實際的報表數據作為依歸。

(圖片出處: pixabay.com)

一、Chrome 外掛

最簡單的方式為安裝這個 Chrome 外掛「Page Analytics」，可以即時撈 GA 的數據，瞭解網站上大部分連結的點擊率。

不過直接說結論，這個外掛的功能有限，我也曾寫了這篇心得說明「安裝 Page Analytics 就能分析網站數據，但很多數字你必須知道如何正確解讀」，大致整理一下這個外掛做不到的事情：

• 標籤連結撈不到數據
• 頁面上有多處同一個連結時，無法判別讀者從哪裡點擊，所以無法知道這個點擊的數據是哪個小工具的功勞
• 無法掌握動態 JS 產生的連結
• 只有網站內部連結的數據，無法取得外部連結的點擊數據
• 只有連結可取得數據，"點擊" 功能沒有數據(例如提交按鈕)

二、GA 事件追蹤器

本篇製作的這個工具，只要你的網站有 Google Anaytics，就能安裝這個「GA 事件追蹤器」來分析數據。

1. 運作原理

安裝之後，會監控網站的所有連結點擊事件，擷取一些重點資訊後，主動向 GA 傳送特定格式的資訊，讓 GA 紀錄所有點擊事件，並且這些資訊有利於日後撈報表時進行分類、判讀。

以上的運作原理，可參考這篇「Blogger 網站如何追蹤 Google Analytics 點擊事件的成效？」有更詳細的說明。


2. 注意事項

基本上這個工具是根據 Blogger 平台特性所開發，其他平台直接套用的話需要修改參數，以及必須手動修改網站的部分 HTML 碼才能有比較好的效果，可參照之後的修改說明。

三、安裝程式碼

在修改範本之前，如果第一次安裝本站工具的讀者，建議先閱讀「備份範本的訣竅」系列文章。

以 Blogger 平台為例，請到後台「主題」→「編輯 HTML」，游標點進範本區塊，按 Ctrl-F 搜尋 </body>這個字串，找到後在此字串的前一行，插入以下程式碼：

參照以上程式碼行號，請見以下參數修改說明：

• 第 1 行綠字可參考「引用 jQuery 的注意事項」，檢查範本是否已安裝過 jQuery，如果已經安裝過請刪除此行，以免重複安裝。
• E 行參數：
  • 大部分的 Blogger 站長都不用修改，但建議還是先參考「Blogger 網站如何追蹤 Google Analytics 點擊事件的成效？」→「四、總結」
  • 如果你的網頁原始碼可搜尋到 "blogger.send" 字串，這一行就不用修改
  • 如果你的網頁原始碼沒有 "blogger.send" 字串，紅色字串請改成 "send"
• F 行參數：
  • Blogger 站長不用修改
  • 非 Blogger 平台，可修改此行參數，改成你的小工具 class 名稱，或將你的小工具加上這個 class 名稱
  • Blogger 平台會自動抓這個小工具的預設 ID 字串
  • 非 Blogger 平台請為你的小工具元素，設定 ID 字串，讓程式抓取

四、操作範例

以本站為例，如果有訪客點擊了側邊欄「精選文章」小工具，其中的「CC0 免費圖庫搜尋引擎」這個連結，程式會抓兩筆字串：

• 小工具的 ID 字串 "HTML10"
• 連結的文字 "CC0 免費圖庫搜尋引擎"

然後將這兩筆資料傳送到 GA，在 GA 報表中可追蹤到這個點擊事件。GA 的操作說明一樣參考「Blogger 網站如何追蹤 Google Analytics 點擊事件的成效？」→「二、調閱 GA 事件報表」




在 GA 的事件報表中，從「事件類別」可以看到各個小工具的點擊數，包括剛剛示範的 "HTML10" 這個小工具。從這些數據就能看出哪些小工具比較熱門，比較值得加入我們網站的版面配置。

我們直接點進 "HTML10" 後，再點擊「活動標籤」，可看到這個小工具的點擊事件明細。




上圖紅框就是示範的 "CC0 免費圖庫搜尋引擎" 這個點擊，從事件總數我們就能看出哪些連結是比較受歡迎的。

五、補充說明

這個免費版功能算是比較侷限：

• 無法排除自己的點擊
• 無法對小工具進行分類，例如區分為導覽列、側邊欄、頁尾等等
• 無法監測動態 JS 產生的小工具連結
• 無法指定要監測的小工具
• 無法排除不要監測的小工具

本篇的分享算是一般通用功能，且原始碼開放，如果會寫 JS 可根據需求自行修改、擴充。

之後會推出功能更豐富的版本，能夠處理以上狀況，讓 GA 報表的數據更好分類及整理。

更多 Google Analytics 相關技巧：

----
如這篇文章對您有幫助，請順手按個 +1 或分享，謝謝！

---

各種「網頁失效連結」檢測工具評價分析及使用心得

April 13, 2019, 6:06 pm

≫ Next: Blogger 無法使用 Open Live Writer 後，寫文章有什麼替代方案？

≪ Previous: 查詢網站所有連結的點擊成效﹍GA 事件追蹤器(免費版)

$

0

0

以往都是使用「Google 網站管理員」定期檢查有無索引錯誤，也就是內部有沒有 404 無效連結。由於以前覺得文章數跟大站相比不算多，不怎麼注意外部連結會失效的問題，不過最近「Google+ 關閉」、「樂多」停業後，網站會產生大量的無效連結，覺得也該是時候來檢查一下網站的外部連結，畢竟很多網站的存活時間真的不長，也許每過 2~3 年，外部連結都有可能變 404 頁面。

找了一些「網頁失效連結」工具進行測試，結果發現用起來幾乎都不太順手，也許要擴大範圍改找付費工具才能滿足我的操作設定吧！但本站久久才跑一次這樣的工具，很難為了不常用的功能付費。

那麼本篇就以免費的角度，紀錄一下檢測工具的使用心得，有線上工具也有桌面軟體，並根據實用程度進行推薦。

一、Broken Link Checker

• 官網：Online Broken Link Checker
• 教學：檢查網站的錯誤連結 Broken Link Checker
• 評價：堪用
• 優點：可免費處理最多 3000 個網頁

「Broken Link Checker」算是看到最多介紹文章的工具，實際上測試的結果，也的確是最佳的 "線上" 失效連結檢測工具。

有些其他的線上工具，經測試後，標注 404 錯誤連結的網址，點開後根本一點問題都沒有。那些功力不夠、連結誤判一堆的線上工具，本篇就不列出來評比了。

那麼為何這工具我給的評價只有「堪用」呢？




上圖是檢測結果畫面，url 那一欄是內含失效連結的文章網址，排序上並沒有集中在一起，也看不出文章網址的字串。所以這工具的缺點是：

• 修復連結的過程非常麻煩，必須一篇篇點開連結修復。
• 常常前面修復完，關閉該篇文章後，後面又跑出同一個頁面的錯誤連結
• 如果一篇文章有多個錯誤連結，你可能會重複這個流程、重新編輯同一篇文章好幾次，非常浪費時間，因為無法事先預知一篇文章是否有多個錯誤連結。

所以這個工具欠缺的，是「顯示發生錯誤連結的文章網址」，以及「針對發生錯誤連結的文章網址進行排序」。只要增加這兩項功能，就可以讓修復流程提升不少效率。

二、Dr. Link Check

• 官網：Dr. Link Check
• 評價：不推薦
• 優點：網站 UI 介面不錯
• 缺點：免費處理一次最多 2500 個連結而已

如上圖，處理一次只能免費偵測最多 2500 個連結，因為網站一個頁面都可能有幾十個、上百個連結(包含導覽列、側邊欄、頁尾)，所以 2500 個連結檢查不了幾篇文章，只適合文章極少的新網站加減用。

P.S. 上圖總共只抓到 24 個錯誤，而且檢查到的錯誤連結，幾乎都是不重要的「Blogger 留言者 Profile 頁面」，沒查到幾個真正重要的錯誤連結就結束了。

三、Dead Link Checker

• 官網：Dead Link Checker
• 評價：不推薦
• 缺點：免費處理一次最多 2000 個連結而已

如上圖，因為只能免費偵測最多 2000 個連結，實用性比前一個更低，只適合文章不多的新網站加減用。

四、Xenu

• 官網 + 下載：Xenu's Link Sleuth
• 教學：
  
  • 中文：Xenu网站死链接检测，SEO必备的链接分析工具
  • 英文：Checking Links with Xenu
• 評價：不好用
• 優點：檢測結果可依照文章網址排序
• 缺點：
  
  • 不能過濾網址參數，導致檢測結果一大堆重複網址
  • 奇怪的錯誤檢測結果很多，導致報表落落長

以下提供操作心得：



按下選單 File → Check Url 後，會開啟上圖視窗：

• A：填入檢測的網址
• B：新增要排除檢測的網址開頭字串，例如圖中的 Blogger 網址代表標籤、搜尋頁面
• C：按下「More Options」，繼續進階設定

• A：設定同時進行的連線數，預設值為 30，可根據網路連線頻寬調整。設定太大的數字雖可同時檢查多個網址，但有可能導致超過等待時間而判定為失敗。
• B：設定爬網站到第幾層，預設 999 代表爬整個網站
• C：如果是部落格平台，這裡可都不勾選。
• D：選擇報表種類
  
  • Broken Links, ordered by links：勾選的話，檢測結果依照錯誤連結進行排序
  • Broken Links, ordered by page：勾選的話，檢測結果依照網站文章連結進行排序 → 建議勾選這個，修復連結才會方便
  • Broken Links：需要檢測本地連結才勾選
  • Site Map：需要產生網站地圖才勾選
  • Statistics：產生統計報表
  • Orphan files：找出哪些檔案、圖片沒有被連結(孤兒檔案)，一般部落格用不到此功能，通常自架站才會用到。

上圖是跑完後的報表，問題很多：

• A：少部分非 wfublog.com 網域也會列進來
• B：每個網址都會出現這 2 個錯誤，Feedly 以及 empty URL，這實在不該列出來
• C：網址字串包含參數的都會列出來，例如 "?" 參數，事實上這些都是重複的網址，那麼錯誤訊息也是重複的

以上 3 點都是沒有必要的錯誤訊息，但報表中絕大多數都是這 3 點的內容，代表想找出真正的錯誤連結，得看到眼睛脫窗。

除非這個工具將來能夠有更好的篩選結果，否則評價就是個非常不好用的檢測工具。

五、LinkChecker

• 官網 + 下載：LinkChecker
• 教學：保哥──如何利用 LinkChecker 檢查網站頁面與連結是否正常
• 評價：可能是最佳工具，但 Windows 版本不能使用 HTTPS
• 優點：
  
  • 可對網址設定正規表示式(REGEX)，來進行過濾
  • 所以不會出現 Xenu 的三項大問題
  • 檢測結果可依照文章網址排序
  • 報表版面最美觀、好用
• 缺點：
  
  • 原作者已不維護，現在開源由愛用者自行維護：linkchecker on Github
  • 原作者的 Windows 版，處理 HTTPS 網站會有問題
  • 雖然後續維護者已解決 HTTPS 問題，但還沒有編譯 Windows 版本，只適合 Unix、Python 系統

來看一下報表的畫面，等級是不是跟前面的截然不同？報表順序可以先排序完再匯出，上圖已經按照出錯的文章網址排序，將來修正網址會很方便。

為了跑出報表，我特地將 WFU BLOG 先設定回 "非 HTTPS" 網址，LinkChecker 才有辦法動，但文章內的所有 HTTPS 連結，這工具還是無法處理，所以全部報錯。

很可惜最好用的軟體，目前只有 Unix、Python 工程師知道怎麼用，因為主要是這群人在進行維護。

操作說明就不詳細描述了，等將來若有一天開源維護的版本，出了 Windows 版時，再來特地寫一篇。

六、總結

很明顯的，本文提到的任何一個工具，目前都無法讓我們很順暢的進行網頁失效連結的修復。

暫時的處理方式，只能忍耐先拿「Broken Link Checker」擋著用，等幾年後看能否有幸使用更新後的 Windows 版「LinkChecker」。

更多「網站工具」相關文章：

----
如這篇文章對您有幫助，請順手按個 +1 或分享，謝謝！

Blogger 無法使用 Open Live Writer 後，寫文章有什麼替代方案？

April 18, 2019, 5:09 pm

≫ Next: 蘋果新聞訂閱制，從 SEO 觀點看背後的真正意圖為何

≪ Previous: 各種「網頁失效連結」檢測工具評價分析及使用心得

$

0

0

Open Live Writer (以下簡稱 OLW) 是很多 Blogger 站長愛用的部落格寫作軟體，主要是上傳圖片的流程比較方便。不過 Google 宣布 2019/3/15「永久關閉 Picasa 上傳圖片的 API 」之後，再也沒有管道可以用程式上傳圖片到 Picasa，那麼自然 OLW 也無法上傳圖片到 Blogger 了。

將來除非文章裡面一張圖都沒有，才適合用 OLW 寫文章，不然只好從 Blogger 後台手動一張張上傳圖片。

如果覺得使用 Blogger 文章編輯器還是太麻煩，有沒有其他可能的寫文章流程？FB 社團這則貼文「OLW 不能上傳圖片後的替代方案」有一些討論，本篇會說明原理並進行重點整理。

一、自動上傳圖片原理

幾年前寫過這篇「Windows Live Writer 無法登入 Blogger 的替代方案」，提到 Blogger 另一種可以自動上傳圖片的方法為，啟用後台「使用電子郵件發文」的功能，設定及操作流程請參考該篇文章的「三、用 Email 轉寄 Blogger」。

「使用電子郵件發文」最常見的作法，是使用 Gmail 撰寫文章。不過 Gmail 的介面比較簡單一些，不見得能滿足各種需求，後續會提供相關的配套措施，或是其他解決方式。

同時該篇文章也有提到可使用 Evernote 傳送郵件發文，除了 Evernote 有一些基本的限制，現在 Email 發文的功能也限定在付費版才能使用了。

二、Gmail 寫作方案

如果只是基本的圖文寫作，那麼 Gmail 的網頁介面算是堪用。但如果要在文章中插入一些簡單的 HTML 碼，Gmail 就做不到這件事了。

此時可參考這篇「讓 Gmail 能插入 HTML 語法」，安裝這個 Chrome 套件，就可插入 HTML 碼了。

插入 HTML 碼的功能還有很多好處，例如可以建立文章範本，把常使用的 HTML 標籤放在範本中，例如大標題、副標題、權重標籤 H2 H3、清單標籤 OL UL 等等，可節省輸入時間。

三、郵件軟體寫作方案

使用 Gmail 有個缺點，當寄出郵件時，會自動移除特定 HTML 標籤，例如 IFRAME、SCRIPT，這是基於安全性考量。

但如果文章想要插入 Youtube、Google 地圖的話，IFRAME 是不可以被移除的。

解決的方法是另外使用郵件軟體，例如常用的 Outlook、或是知名郵件軟體「Thunderbird」。

• Outlook 本身直接有選項可設定、切換為 HTML 撰寫模式
• Thunderbird 也有插入 HTML 碼的功能
• Thunderbird 要另外編輯 HTML 的話，可安裝外掛「EditHtml」

同時使用郵件軟體的話，操作環境比 Gmail 美觀、功能更多更方便。如果 Outlook 或 Thunderbird 都不合用的話，還有很多其他郵件軟體，相信可以找到一個使用順手的選擇。

四、備份文章

站長選擇 OLW 寫作的另一個原因，可能是在硬碟保有一份備份，以防各種天災、人禍、手殘誤刪等意外。

不使用 OLW 之後，其實還有很多更好的備份管道，可參考這篇「部落格文章如何全自動備份」，至少有這三種方式：

• 用 IFTTT 自動備份到另一個 Blogger 部落格
• 使用 RSS 閱讀器，例如 Feedly 訂閱自己的部落格文章
• 網站安裝官方工具「以郵件訂閱」，並訂閱自己的網站，那麼就可用 Email 備份自己的文章

只要能做好 "即時"、"多處" 異地備份，就可不用擔心部落格文章的安全。

五、郵件發文的缺點

雖然本篇提供了郵件發文的解決方案，不過還是無法完全取代 OLW 的所有功能，例如：

• 無法設定標籤
• 無法設定發文時間

我也一直在想有沒有更好的解決方式，如果有可能克服所有難題的話，乾脆開發一個工具出來也說不定，成功的話會再發表。

經測試後，某些行動裝置 APP 可以完全取代 OLW，只是 Windows 下沒辦法執行行動裝置 APP。終究這是一種方向，會另外整理一篇心得。

更多 Blogger 相關文章：

----
如這篇文章對您有幫助，請順手按個 +1 或分享，謝謝！

蘋果新聞訂閱制，從 SEO 觀點看背後的真正意圖為何

April 21, 2019, 9:58 pm

≫ Next: 在部落格側邊欄安裝 Instagram 小工具，顯示九宮格圖片

≪ Previous: Blogger 無法使用 Open Live Writer 後，寫文章有什麼替代方案？

$

0

0

前陣子蘋果網路新聞實施會員訂閱制，在網路界造成一股轟動，不過我對這件事沒太多關注，原因可參考「部落格是否要加入內容付費平台 (Medium) 的考量」。不看好的理由是，台灣目前還不具備訂閱制的成熟客觀環境，當先驅者會做的非常辛苦。

後來在 PTT 瀏覽器版看到這篇「蘋果日報台灣 免申請會員便可瀏覽新聞」，有人在教不用註冊就能看到會員內容的方法，才知道原來蘋果只是用 CSS 語法隱藏網頁內容，實際上文章都還在原地，此舉真是讓我笑得肚子都疼了~

雖然稍微懂點前端的人馬上知道是怎麼回事，也多會認為蘋果很蠢。不過靜下心思考了一下，這麼明顯的破綻似乎另有端倪，蘋果是擁有巨大資源的企業，不會事先沒找專家評估這麼做的後果，事情也許沒表面上這麼單純。

那麼仔細推敲後，發現這其中大有來頭，以下紀錄我的心得。

(圖片出處: pexels.com)

一、SEO 對隱藏內容的處罰

1. 蘋果網頁原始碼



沒特別挑，隨意選了一篇蘋果最新的網路新聞進行測試，如上圖會被要求加入會員才看得到內容。




打開網頁原始碼，會看到一大堆 display: none 的語法，將文章內容、或其他區塊隱藏。

為了證明上圖馬賽克的部分是文章內容，我必須留下一行、且與文章標題相關的文字敘述。但最下面也可看到蘋果註明不得 "部分引用"，讓我有點心驚膽戰，這一行內容露出該不會被蘋果告吧？


2. Google 會處罰隱藏內容

實際上將網頁內容隱藏是很危險的事，Google 早已公告會處罰此事，可參考這篇「您的網站被懲罰了嗎？請看Google熊貓與企鵝的懲罰重點整理」：

Google Panda 熊貓的加強懲罰重點 → Hidden Content 內容隱藏
Google Penfuin 企鵝的加強懲罰重點 → Hidden text links 隱藏的文字連結

所以在搜尋結果的 SEO 排名上，蘋果這麼做是一定會被懲罰的。


3. 隱藏內容仍會被索引

那麼我想瞭解一下，隱藏內容會被處罰到什麼程度，找到這篇「 SEO
解釋隱藏內容對 SEO 的影響」，作者讓我太佩服了，很有耐心地做了各種隱藏內容的實驗，也一一秀出搜尋結果，他的結論是：

• 隱藏內容仍會被 Google 索引

那麼處罰歸處罰，我想最多是排名下降，至少蘋果的網頁內容不會從搜尋結果消失，這也代表蘋果的 SEO 流量不會完全不見。

二、那麼蘋果的 SEO 有被處罰嗎？

1. 蘋果的搜尋結果

接著我試著搜尋一下上面那篇 "富婆網美為拍全身照爬上桌腳下..."：

• 輸入完整標題 → 搜尋排名第一
• 輸入關鍵字 "富婆 網美"，或是 "富婆 網紅" → 照樣排名第一

這是怎麼回事啊！隱藏內容對蘋果的 SEO 根本沒影響嘛~而且看官注意到了嗎？這篇文章根本被 Google 秒收，顯示的文章發佈時間為 "12 分鐘前"...

不過我想應該不會被蘋果提告了，因為 Google 搜尋結果的描述字串就是我前面沒有馬賽克掉的那幾個字，如果蘋果要對 "部分引用" 內容提告的話，應該要先告 Google，因為 Google 每篇新聞都偷看到內容了、每篇都有引用，這樣賺比較多，而告我拿不到幾毛錢的~


2. SEO 合理的解釋

試著對這現象進行揣測：

• 也許蘋果 appledaily 的網站權重太高了，假設有 1000 分吧。
• 隱藏內容雖然有扣分，就假設被 Google 扣了 10 分吧，那麼 SEO 分數就當他是 990 分
• 而排名第二的分數假設只有 500 分，蘋果分數怎麼扣都還是遙遙領先

所以隱藏內容對於 SEO 權重超高的網站，影響就沒那麼大了。


3. 蘋果的創舉

我想蘋果的 SEO 顧問也許已經衡量過結果，才敢這樣玩隱藏內容：

• 既可不影響搜尋排名太多
• 又能要求使用者加入會員、進行訂閱

要知道，真正的「訂閱制」是無法這樣玩的，我之前在「部落格是否要加入內容付費平台 (Medium) 的考量」提過：

網路、資訊類的文章，讀者已經很習慣使用 Google 搜尋相關資料，也多半都找得到。如果這類文章放入「付費才能看」的地方，根本搜尋不到，自然也沒人知道有這樣的文章，寫了等於白寫。

基本上「搜尋排名」與「訂閱制」是互相抵觸的兩件事，至少我當時這麼認為，要加入會員才能閱讀的文章內容，哪可能被搜尋得到。

但，蘋果做到了！既要求你加入會員，文章還能被搜尋到，從 SEO 的角度來看，這簡直是一大創舉！

三、蘋果害怕隱藏內容被看到嗎？

可是，現在這件事已經被知道了，而且破解隱藏內容的方法起碼一星期前就流出來，是我後知後覺太晚知道，難道蘋果不怕讀者不註冊，直接看這些隱藏內容嗎？

先說結論，我認為蘋果一點都不擔心。

1. 熟悉網路的讀者

有辦法破解隱藏內容的，幾乎都是熟悉網路使用的人，這些族群的特性：

• 很會使用網路工具，也很可能會裝擋廣告的瀏覽器外掛，網頁根本無法出現廣告
• 就算沒裝外掛，因為每天看很多網頁，多到腦中會自動內建「無視廣告」的功能
• 就算廣告出現在不常見的區塊，這族群的視神經也有辦法瞬間判讀，提醒大腦「這可能不是文章的一部份」，然後自動略過

這代表著，蘋果本來就無法從這些人獲得廣告收益，無論隱藏內容是否被破解。


2. 不熟悉網路的讀者

而不熟悉網路的使用者：

• 他們對網頁的版面架構完全不瞭解，甚至看不出什麼是廣告、什麼不是廣告
• 常常文章看一半，注意力就被某個廣告吸引走，並點擊廣告，而他們也不知道點了廣告
• 他們常常東點西點，然後忘了原本在看什麼，也不知道怎麼回去原本看的那個頁面。

這，才是蘋果要抓的客群，才是對蘋果能產生收益的族群。

四、蘋果的目的是什麼？

所以，蘋果一點都不在乎你能不能看到隱藏內容，但蘋果在乎：

• 搜尋引擎帶來的使用者
• 抓到目標客群，並誘使加入會員

你何曾看過「訂閱制」的媒體，允許隱藏內容被看到？如果隱藏內容看得到的話，代表：

• 這些內容一點都不重要，其他地方也看得到
• 這些內容很淺薄，不用花太多心思就能寫出來
• 這些內容本來就不會有人原意付費訂閱
• 這代表內容根本就不是重點，蘋果只要你加入會員而已

真正能夠讓使用者願意付費訂閱的，而且不可隨便就看到隱藏內容，起碼要是專欄等級的文章，是別處沒有的專業文章。

蘋果很明顯的，不放棄 SEO 流量，不放棄任何可以增加訂閱的機會，還花大錢舉辦「抽獎活動」，目的只有一個：

• 要你加入會員

到底為什麼「加入會員」這麼重要呢？

五、衝會員數是首要目標

如果有看過「矽谷群瞎傳」(silicon valley) ，瞭解新創企業運作模式的話，會知道「衝會員數」是多麼重要的一件事。新創企業可以 5 年沒賺錢都沒關係，但「會員數」一定要有爆炸成長，才能看到未來性。

蘋果是擁有龐大資源的企業，現在媒體面臨轉型的關鍵時間點，等於跟新創事業差不多，他們一定願意投入資源在轉型這件事，那麼網站短期損失的廣告收益，我認為長遠來看實在沒什麼。

就像 Dropbox，現在已經是「雲端儲存服務」的代名詞，但也是靠多年的免費使用來吸引註冊、衝高市場佔有率，成立 10 年後才敢限縮使用者同步的裝置數量，來誘使付費。

我認為目前蘋果的首要目標，就是盡快衝高註冊會員數，再想辦法從中獲得商業利益。可以看看 Facebook、Line，首要任務也是獲取大量註冊用戶，再逐步發展出可行的獲利模式。

六、取得會員資料是關鍵

雖然現在發現蘋果重心不在訂閱制，不過還是提一下訂閱制。

部落格站長們或許多少會幻想，使用者願意付費訂閱文章。我們應該看過，某些網站的文章有上鎖，需取得密碼才能看到隱藏內容，這其實就是訂閱制的一種型態。

本站也這麼期待過，所以利用「會員系統」功能，加入會員後，可以看免費的「會員限定文章」，或是付費的「會員加值文章」。

當然結果早有預期，真正付費的其實很少，但至少利用「免費的會員限定文章」，還是可以誘使大量的會員註冊，取得會員聯絡資訊。

同時，當網站有「加入會員才能看到的限定文章」時，代表這個網站有許多其他地方看不到的專業文章，至少可以為自己網站帶來一點識別度，而不會讓使用者覺得是，隨便 Google 一篇資訊看了就離開、沒有記憶點的網站。

而且取得會員聯絡資訊，這在行銷上是非常重要的「精準客戶名單」，運用的好就能轉換成收益。

這跟蘋果現在做的事是不是有點像？

七、蘋果模式是否能複製？

本篇都剖析地這麼明白了，那麼是不是大家也來模仿蘋果就好？恐怕很困難。

• 舉辦抽獎衝高會員數：誰有這麼多錢可以燒呢？這個大企業才玩得起
• 隱藏內容：網站不夠大真的不要亂學，至少我的網站絕對不敢。蘋果被扣 SEO 排名沒影響，一般網站被處罰可能排名掉好幾頁(不是好幾名)
• 要求註冊會員：不夠知名、經營不夠久的網站，使用者對於留下個資、或註冊都是會有疑慮的，除非是蘋果、天下這樣的網站，使用者註冊才不會想太多。

所以行文至此，其實我也滿佩服的，蘋果讓你看到了他的思維模式，但照著做也沒用。

八、決勝關鍵點在何處？

蘋果實際上要如何轉化成收益我不敢置喙，不過來揣測一下可能的獲利模式。前面提過，台灣目前還沒有適合訂閱制的客觀條件，我也不認為蘋果會把主力放在「付費訂閱制」上面，因為根本賺不了多少錢，但是可以來看看網路龍頭 Google、FB 是怎麼做的。

幾乎每個人都有 Google、FB 帳號，也幾乎決多數網站都有 Google、FB 外掛，例如 Google Analytics、讚按鈕，那麼使用者的行為幾乎都在 Google、FB 的監測中。

這篇「究竟 Blogger 會不會關閉？從 Google 商業經營的角度分析」有提到：

• Google 的核心服務，都能替 Google 蒐集到大量資訊、數據
• Google 的頂尖人才，有辦法分析、解剖這些大數據，並轉換為商業價值
• 一般公司就算拿到大數據，也不知道如何轉換為商業價值，或是缺乏有效轉換的能力，這就是與頂尖公司的差異

就像 Google 的付費服務營收，絕對遠比不上賣廣告的營收；那麼收集使用者行為來創造周邊精準的相關利益，會遠勝付費訂閱的營收。

所以，蘋果從註冊會員瀏覽網頁所蒐集的行為模式、喜好等等大數據，能夠如何運用，才是轉型的決勝關鍵點。

例如根據會員的喜好，在網頁上投放精準的自家廣告、推薦相關商品，提升轉換率，而不用被 Adsense 廣告抽一手，這一點就能大大提昇廣告收益。

或者從會員的行為模式，分析、測試出適合發展的相關產品。

不管哪種作法、獲利模式，都比「付費訂閱制」的期望值高，當然兩者也是可以並行的。無論如何，這一切都有待蘋果團隊的能耐了。

更多 SEO 相關文章：

----
如這篇文章對您有幫助，請順手按個 +1 或分享，謝謝！

在部落格側邊欄安裝 Instagram 小工具，顯示九宮格圖片

May 1, 2019, 7:10 pm

≫ Next: 網站管理員提交文章時，出現 "網址不在 Google 服務中" 訊息怎麼辦？

≪ Previous: 蘋果新聞訂閱制，從 SEO 觀點看背後的真正意圖為何

$

0

0

前陣子接到一個需求，希望在網站側邊欄擺放 Instagram 小工具，能顯示 9 張圖片這樣的版面。正常來說要做到這件事不難，已經有不少現成的外掛可以直接拿來用。





不過實際測試之後，卻發現每個都有不合用的地方，只好乾脆自己寫一個來用，以下可先看範例頁面的效果。

點此看範例網頁

(圖片出處: pixabay.com)

一、現有外掛整理

找了一些知名的 Instagram 外掛：

1. SnapWidget

• 官網：https://snapwidget.com/
• 免費版缺點：點擊圖片無法連到 Instagram
• 付費版費用：USD 6 / 月

2. Websta

• 官網：https://widgets.websta.me/
• 免費版缺點：點擊圖片無法連到 Instagram
• 付費版費用：USD 4.99 / 月

3. POWr

• 官網：https://www.powr.io/
• 免費版缺點：最多顯示 6 張圖
• 付費版費用：USD 8 / 月

4. Light Widget

• 官網：https://lightwidget.com/
• 免費版缺點：不支援 HTTPS 網站
• 付費版費用：USD 10

二、國外自製工具程式碼

另外找到這篇「How To Add An Instagram Widget for Blogger」，提供了程式碼可安裝在側邊欄，不過預設效果怪怪的，版面看起來不太實用。

如果熟悉 HTML/JS/CSS，可以直接修改原始碼，改成自己要的樣子，或者直接使用本篇修改的版本。

三、安裝程式碼

這個工具任何網站都可安裝，以 Blogger 為例，請到後台 → 版面配置 → 新增小工具 → 選擇「HTML/JavaScript」→ 填入標題、及以下程式碼：

<div id="ig_sidebar"></div><div id="ig_info"><a href="https://www.wfublog.com/2019/05/blog-sidebar-instagram-widget-9-images.html" target="_blank">ⓦ Instagram Widget</a></div>

<script src='//ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js'></script>
<link href='https://maxcdn.bootstrapcdn.com/font-awesome/4.5.0/css/font-awesome.min.css' rel='stylesheet'></link>

<script>
//<![CDATA[
(function($) {
var ig_id = xxxxxxxxxx,
ig_token = "xxxxxxxxxx.yyyyyyy.zzzzzzzzzzzzzzzzzzz",
ig_images = 9;

// Generated by CoffeeScript 1.3.3
(function(){var e,t;e=function(){function e(e,t){var n,r;this.options={target:"instafeed",get:"popular",resolution:"thumbnail",sortBy:"none",links:!0,mock:!1,useHttp:!1};if(typeof e=="object")for(n in e)r=e[n],this.options[n]=r;this.context=t!=null?t:this,this.unique=this._genKey()}return e.prototype.hasNext=function(){return typeof this.context.nextUrl=="string"&&this.context.nextUrl.length>0},e.prototype.next=function(){return this.hasNext()?this.run(this.context.nextUrl):!1},e.prototype.run=function(t){var n,r,i;if(typeof this.options.clientId!="string"&&typeof this.options.accessToken!="string")throw new Error("Missing clientId or accessToken.");if(typeof this.options.accessToken!="string"&&typeof this.options.clientId!="string")throw new Error("Missing clientId or accessToken.");return this.options.before!=null&&typeof this.options.before=="function"&&this.options.before.call(this),typeof document!="undefined"&&document!==null&&(i=document.createElement("script"),i.id="instafeed-fetcher",i.src=t||this._buildUrl(),n=document.getElementsByTagName("head"),n[0].appendChild(i),r="instafeedCache"+this.unique,window[r]=new e(this.options,this),window[r].unique=this.unique),!0},e.prototype.parse=function(e){var t,n,r,i,s,o,u,a,f,l,c,h,p,d,v,m,g,y,b,w,E,S;if(typeof e!="object"){if(this.options.error!=null&&typeof this.options.error=="function")return this.options.error.call(this,"Invalid JSON data"),!1;throw new Error("Invalid JSON response")}if(e.meta.code!==200){if(this.options.error!=null&&typeof this.options.error=="function")return this.options.error.call(this,e.meta.error_message),!1;throw new Error("Error from Instagram: "+e.meta.error_message)}if(e.data.length===0){if(this.options.error!=null&&typeof this.options.error=="function")return this.options.error.call(this,"No images were returned from Instagram"),!1;throw new Error("No images were returned from Instagram")}this.options.success!=null&&typeof this.options.success=="function"&&this.options.success.call(this,e),this.context.nextUrl="",e.pagination!=null&&(this.context.nextUrl=e.pagination.next_url);if(this.options.sortBy!=="none"){this.options.sortBy==="random"?d=["","random"]:d=this.options.sortBy.split("-"),p=d[0]==="least"?!0:!1;switch(d[1]){case"random":e.data.sort(function(){return.5-Math.random()});break;case"recent":e.data=this._sortBy(e.data,"created_time",p);break;case"liked":e.data=this._sortBy(e.data,"likes.count",p);break;case"commented":e.data=this._sortBy(e.data,"comments.count",p);break;default:throw new Error("Invalid option for sortBy: '"+this.options.sortBy+"'.")}}if(typeof document!="undefined"&&document!==null&&this.options.mock===!1){a=e.data,this.options.limit!=null&&a.length>this.options.limit&&(a=a.slice(0,this.options.limit+1||9e9)),n=document.createDocumentFragment(),this.options.filter!=null&&typeof this.options.filter=="function"&&(a=this._filter(a,this.options.filter));if(this.options.template!=null&&typeof this.options.template=="string"){i="",o="",l="",v=document.createElement("div");for(m=0,b=a.length;m<b;m++)s=a[m],u=s.images[this.options.resolution].url,this.options.useHttp||(u=u.replace("http://","//")),o=this._makeTemplate(this.options.template,{model:s,id:s.id,link:s.link,image:u,caption:this._getObjectProperty(s,"caption.text"),likes:s.likes.count,comments:s.comments.count,location:this._getObjectProperty(s,"location.name")}),i+=o;v.innerHTML=i,S=[].slice.call(v.childNodes);for(g=0,w=S.length;g<w;g++)h=S[g],n.appendChild(h)}else for(y=0,E=a.length;y<E;y++)s=a[y],f=document.createElement("img"),u=s.images[this.options.resolution].url,this.options.useHttp||(u=u.replace("http://","//")),f.src=u,this.options.links===!0?(t=document.createElement("a"),t.href=s.link,t.appendChild(f),n.appendChild(t)):n.appendChild(f);document.getElementById(this.options.target).appendChild(n),r=document.getElementsByTagName("head")[0],r.removeChild(document.getElementById("instafeed-fetcher")),c="instafeedCache"+this.unique,window[c]=void 0;try{delete window[c]}catch(x){}}return this.options.after!=null&&typeof this.options.after=="function"&&this.options.after.call(this),!0},e.prototype._buildUrl=function(){var e,t,n;e="https://api.instagram.com/v1";switch(this.options.get){case"popular":t="media/popular";break;case"tagged":if(typeof this.options.tagName!="string")throw new Error("No tag name specified. Use the 'tagName' option.");t="tags/"+this.options.tagName+"/media/recent";break;case"location":if(typeof this.options.locationId!="number")throw new Error("No location specified. Use the 'locationId' option.");t="locations/"+this.options.locationId+"/media/recent";break;case"user":if(typeof this.options.userId!="number")throw new Error("No user specified. Use the 'userId' option.");if(typeof this.options.accessToken!="string")throw new Error("No access token. Use the 'accessToken' option.");t="users/"+this.options.userId+"/media/recent";break;default:throw new Error("Invalid option for get: '"+this.options.get+"'.")}return n=""+e+"/"+t,this.options.accessToken!=null?n+="?access_token="+this.options.accessToken:n+="?client_id="+this.options.clientId,this.options.limit!=null&&(n+="&count="+this.options.limit),n+="&callback=instafeedCache"+this.unique+".parse",n},e.prototype._genKey=function(){var e;return e=function(){return((1+Math.random())*65536|0).toString(16).substring(1)},""+e()+e()+e()+e()},e.prototype._makeTemplate=function(e,t){var n,r,i,s,o;r=/(?:\{{2})([\w\[\]\.]+)(?:\}{2})/,n=e;while(r.test(n))i=n.match(r)[1],s=(o=this._getObjectProperty(t,i))!=null?o:"",n=n.replace(r,""+s);return n},e.prototype._getObjectProperty=function(e,t){var n,r;t=t.replace(/\[(\w+)\]/g,".$1"),r=t.split(".");while(r.length){n=r.shift();if(!(e!=null&&n in e))return null;e=e[n]}return e},e.prototype._sortBy=function(e,t,n){var r;return r=function(e,r){var i,s;return i=this._getObjectProperty(e,t),s=this._getObjectProperty(r,t),n?i>s?1:-1:i<s?1:-1},e.sort(r.bind(this)),e},e.prototype._filter=function(e,t){var n,r,i,s,o;n=[],i=function(e){if(t(e))return n.push(e)};for(s=0,o=e.length;s<o;s++)r=e[s],i(r);return n},e}(),t=typeof exports!="undefined"&&exports!==null?exports:window,t.Instafeed=e}).call(this);

var _0x5c1b=["\x34\x20\x7A\x3D\x57\x20\x58\x28\x7B\x56\x3A\x22\x72\x22\x2C\x55\x3A\x53\x2C\x54\x3A\x59\x2C\x5A\x3A\x31\x34\x2C\x31\x35\x3A\x31\x33\x2C\x31\x32\x3A\x68\x28\x61\x29\x7B\x71\x28\x61\x29\x7D\x7D\x29\x3B\x68\x20\x71\x28\x62\x29\x7B\x34\x20\x64\x3D\x62\x2E\x73\x5B\x30\x5D\x2E\x72\x2E\x31\x31\x2C\x63\x3D\x24\x28\x22\x23\x52\x22\x29\x2C\x61\x3D\x22\x22\x3B\x24\x2E\x51\x28\x62\x2E\x73\x2C\x68\x28\x65\x2C\x67\x29\x7B\x34\x20\x66\x3D\x67\x2E\x42\x2E\x46\x2E\x45\x3B\x61\x2B\x3D\x22\x3C\x31\x20\x32\x3D\x27\x43\x27\x3E\x22\x3B\x61\x2B\x3D\x22\x3C\x61\x20\x38\x3D\x27\x22\x2B\x67\x2E\x44\x2B\x22\x27\x20\x35\x3D\x27\x37\x27\x3E\x3C\x49\x20\x4A\x3D\x27\x22\x2B\x66\x2B\x22\x27\x2F\x3E\x22\x3B\x61\x2B\x3D\x22\x3C\x31\x20\x32\x3D\x27\x4F\x27\x3E\x3C\x31\x20\x32\x3D\x27\x50\x27\x3E\x3C\x31\x20\x32\x3D\x27\x4E\x27\x3E\x22\x3B\x61\x2B\x3D\x22\x3C\x69\x20\x32\x3D\x27\x33\x20\x33\x2D\x4D\x27\x2F\x3E\x22\x2B\x67\x2E\x4B\x2E\x70\x3B\x61\x2B\x3D\x22\x20\x3C\x69\x20\x32\x3D\x27\x33\x20\x33\x2D\x31\x37\x27\x3E\x3C\x2F\x69\x3E\x22\x2B\x67\x2E\x31\x36\x2E\x70\x3B\x61\x2B\x3D\x22\x3C\x2F\x31\x3E\x3C\x2F\x31\x3E\x3C\x2F\x31\x3E\x3C\x2F\x61\x3E\x3C\x2F\x31\x3E\x22\x7D\x29\x3B\x63\x2E\x78\x28\x61\x29\x3B\x61\x3D\x22\x3C\x31\x20\x6F\x3D\x27\x76\x27\x3E\x22\x3B\x61\x2B\x3D\x22\x3C\x61\x20\x38\x3D\x27\x74\x3A\x2F\x2F\x77\x2E\x36\x2E\x41\x2F\x22\x2B\x64\x2B\x22\x27\x20\x35\x3D\x27\x37\x27\x3E\x3C\x69\x20\x32\x3D\x27\x33\x20\x33\x2D\x36\x27\x3E\x3C\x2F\x69\x3E\x20\x31\x76\x20\x31\x74\x3C\x2F\x61\x3E\x22\x3B\x61\x2B\x3D\x22\x3C\x2F\x31\x3E\x22\x3B\x63\x2E\x75\x28\x61\x29\x3B\x31\x73\x28\x21\x24\x28\x22\x23\x6B\x22\x29\x2E\x31\x78\x29\x7B\x24\x28\x22\x23\x76\x22\x29\x2E\x75\x28\x22\x3C\x31\x20\x6F\x3D\x27\x6B\x27\x20\x6D\x3D\x27\x31\x70\x2D\x31\x64\x3A\x20\x31\x65\x3B\x6C\x2D\x31\x63\x3A\x31\x62\x3B\x27\x3E\x3C\x61\x20\x6D\x3D\x27\x6C\x2D\x31\x61\x3A\x20\x31\x66\x3B\x20\x31\x67\x3A\x20\x23\x31\x6D\x3B\x20\x6A\x2D\x31\x6E\x3A\x20\x31\x6C\x2C\x20\x31\x6B\x2C\x20\x31\x68\x2D\x31\x69\x3B\x20\x6A\x2D\x4C\x3A\x20\x31\x39\x3B\x27\x20\x31\x6F\x3D\x27\x79\x20\u5074\u908A\u6B04\u5DE5\u5177\x5C\x6E\u8A2D\u8A08\uFF1A\x48\x20\x31\x30\x27\x20\x38\x3D\x27\x74\x3A\x2F\x2F\x77\x2E\x31\x6A\x2E\x41\x2F\x31\x38\x2F\x31\x71\x2F\x31\x79\x2D\x31\x77\x2D\x36\x2D\x31\x75\x2D\x39\x2D\x42\x2E\x78\x27\x20\x35\x3D\x27\x37\x27\x3E\u24E6\x20\x79\x20\x47\x3C\x2F\x61\x3E\x3C\x2F\x31\x3E\x22\x29\x7D\x7D\x7A\x2E\x31\x72\x28\x29\x3B","\x7C","\x73\x70\x6C\x69\x74","\x7C\x64\x69\x76\x7C\x63\x6C\x61\x73\x73\x7C\x66\x61\x7C\x76\x61\x72\x7C\x74\x61\x72\x67\x65\x74\x7C\x69\x6E\x73\x74\x61\x67\x72\x61\x6D\x7C\x5F\x62\x6C\x61\x6E\x6B\x7C\x68\x72\x65\x66\x7C\x7C\x7C\x7C\x7C\x7C\x7C\x7C\x7C\x66\x75\x6E\x63\x74\x69\x6F\x6E\x7C\x7C\x66\x6F\x6E\x74\x7C\x69\x67\x5F\x69\x6E\x66\x6F\x7C\x74\x65\x78\x74\x7C\x73\x74\x79\x6C\x65\x7C\x7C\x69\x64\x7C\x63\x6F\x75\x6E\x74\x7C\x64\x69\x73\x70\x6C\x61\x79\x49\x47\x7C\x75\x73\x65\x72\x7C\x64\x61\x74\x61\x7C\x68\x74\x74\x70\x73\x7C\x61\x66\x74\x65\x72\x7C\x69\x67\x5F\x66\x6F\x6C\x6C\x6F\x77\x5F\x6D\x65\x7C\x77\x77\x77\x7C\x68\x74\x6D\x6C\x7C\x49\x6E\x73\x74\x61\x67\x72\x61\x6D\x7C\x66\x65\x65\x64\x7C\x63\x6F\x6D\x7C\x69\x6D\x61\x67\x65\x73\x7C\x69\x67\x5F\x74\x68\x75\x6D\x62\x7C\x6C\x69\x6E\x6B\x7C\x75\x72\x6C\x7C\x74\x68\x75\x6D\x62\x6E\x61\x69\x6C\x7C\x57\x69\x64\x67\x65\x74\x7C\x57\x46\x55\x7C\x69\x6D\x67\x7C\x73\x72\x63\x7C\x6C\x69\x6B\x65\x73\x7C\x73\x69\x7A\x65\x7C\x68\x65\x61\x72\x74\x7C\x69\x67\x5F\x69\x6E\x6E\x65\x72\x7C\x69\x67\x5F\x77\x72\x61\x70\x7C\x69\x67\x5F\x77\x72\x61\x70\x5F\x69\x6E\x6E\x65\x72\x7C\x65\x61\x63\x68\x7C\x69\x67\x5F\x73\x69\x64\x65\x62\x61\x72\x7C\x69\x67\x5F\x69\x64\x7C\x61\x63\x63\x65\x73\x73\x54\x6F\x6B\x65\x6E\x7C\x75\x73\x65\x72\x49\x64\x7C\x67\x65\x74\x7C\x6E\x65\x77\x7C\x49\x6E\x73\x74\x61\x66\x65\x65\x64\x7C\x69\x67\x5F\x74\x6F\x6B\x65\x6E\x7C\x6C\x69\x6D\x69\x74\x7C\x42\x4C\x4F\x47\x7C\x75\x73\x65\x72\x6E\x61\x6D\x65\x7C\x73\x75\x63\x63\x65\x73\x73\x7C\x74\x72\x75\x65\x7C\x69\x67\x5F\x69\x6D\x61\x67\x65\x73\x7C\x6D\x6F\x63\x6B\x7C\x63\x6F\x6D\x6D\x65\x6E\x74\x73\x7C\x63\x6F\x6D\x6D\x65\x6E\x74\x7C\x32\x30\x31\x39\x7C\x31\x31\x70\x78\x7C\x64\x65\x63\x6F\x72\x61\x74\x69\x6F\x6E\x7C\x72\x69\x67\x68\x74\x7C\x61\x6C\x69\x67\x6E\x7C\x74\x6F\x70\x7C\x31\x30\x70\x78\x7C\x6E\x6F\x6E\x65\x7C\x63\x6F\x6C\x6F\x72\x7C\x73\x61\x6E\x73\x7C\x73\x65\x72\x69\x66\x7C\x77\x66\x75\x62\x6C\x6F\x67\x7C\x61\x72\x69\x61\x6C\x7C\x68\x65\x6C\x76\x65\x74\x69\x63\x61\x7C\x63\x63\x63\x7C\x66\x61\x6D\x69\x6C\x79\x7C\x74\x69\x74\x6C\x65\x7C\x6D\x61\x72\x67\x69\x6E\x7C\x30\x35\x7C\x72\x75\x6E\x7C\x69\x66\x7C\x4D\x65\x7C\x77\x69\x64\x67\x65\x74\x7C\x46\x6F\x6C\x6C\x6F\x77\x7C\x73\x69\x64\x65\x62\x61\x72\x7C\x6C\x65\x6E\x67\x74\x68\x7C\x62\x6C\x6F\x67","","\x66\x72\x6F\x6D\x43\x68\x61\x72\x43\x6F\x64\x65","\x5C\x62","\x67","\x72\x65\x70\x6C\x61\x63\x65"];eval(function(_0x90dcx1,_0x90dcx2,_0x90dcx3,_0x90dcx4,_0x90dcx5,_0x90dcx6){_0x90dcx5= function(_0x90dcx3){return (_0x90dcx3< _0x90dcx2?_0x5c1b[4]:_0x90dcx5(parseInt(_0x90dcx3/ _0x90dcx2)))+ ((_0x90dcx3= _0x90dcx3% _0x90dcx2)> 35?String[_0x5c1b[5]](_0x90dcx3+ 29):_0x90dcx3.toString(36))};while(_0x90dcx3--){if(_0x90dcx4[_0x90dcx3]){_0x90dcx1= _0x90dcx1[_0x5c1b[8]]( new RegExp(_0x5c1b[6]+ _0x90dcx5(_0x90dcx3)+ _0x5c1b[6],_0x5c1b[7]),_0x90dcx4[_0x90dcx3])}};return _0x90dcx1}(_0x5c1b[0],62,97,_0x5c1b[3][_0x5c1b[2]](_0x5c1b[1])))
})(jQuery);
//]]>
</script>

<style>
#ig_sidebar { width: 100%; display: block; line-height: 0; text-align: center;overflow: auto; }
#ig_sidebar img{width:100%;height:auto;}
#ig_sidebar a{display:inline-block;position:relative;}
#ig_sidebar i{font-size:12px;color:#fff;margin:0 2px 0 0;}
.ig_thumb { width: calc(100% / 3); float: left; padding: 5px; box-sizing: border-box; }
.ig_wrap { width: 100%; height: 100%; margin-top: -100%; opacity: 0; letter-spacing: 1px; position: absolute; color: #fff; -webkit-transition: all .3s ease; -moz-transition: all .3s ease; -ms-transition: all .3s ease; -o-transition: all .3s ease; transition: all .3s ease; }
.ig_wrap:hover{opacity:1;background:rgba(0,0,0,0.3);}
.ig_wrap_inner
{display:table;vertical-align:middle; height: 100%; width: 100%;}
.ig_inner{display:table-cell;vertical-align:middle;}
#ig_follow_me{margin: 10px 0;text-align: center;}
#ig_follow_me a{display: inline-block;padding: 10px; color: #fff; background: #408bd1; width: 50%; border-radius: 4px; font-size: 16px;text-decoration: none;transition: all .1s ease-in;}
#ig_follow_me a:hover{box-shadow: inset 0 0 10px 20px #359dff;}
#ig_info{margin-top: 10px;text-align:right;}
#ig_info a{text-decoration: none; color: #ccc; font-family: helvetica, arial, sans-serif; font-size: 11px;}
</style>

• 綠色字串請檢查範本，如已安裝過 jQuery、或 Font Awesome，可移除對應的安裝碼
• 請到這個網頁 https://instagram.pixelunion.net/→ 按「Generate Access Token」→ 登入 Instagram 取得授權 → 紀錄產生的 Access Token 字串
• Token 字串的格式大致是這樣「xxxxxxxxxx.yyyyyyy.zzzzzzzzzzzzzzzzzzz」
• 紅字參數 ig_id 請填入自己的 xxxxxxxxxx 字串
• 紅字參數 ig_token 請填入自己的完整 Token 字串
• 藍字參數 ig_images 可修改顯示的圖片數

儲存後即可看到效果，如熟悉 CSS 的話，可自行修改版面參數。

點此看範例網頁

更多網站小工具：

----
如這篇文章對您有幫助，請順手按個 +1 或分享，謝謝！

網站管理員提交文章時，出現 "網址不在 Google 服務中" 訊息怎麼辦？

May 4, 2019, 5:53 pm

≫ Next: 統計歸納網站所有連結的點擊成效﹍GA 事件追蹤器(會員加值文章)

≪ Previous: 在部落格側邊欄安裝 Instagram 小工具，顯示九宮格圖片

$

0

0

最近接獲線報，表示使用 Google 網站管理員(新版 Search Console)，在上方搜尋框輸入網址查詢時，出現了訊息「網址不在 Google 服務中」。案主表示：

之前利用檢索都可以順利在Google建立索引，但從前幾天開始即使送出需求，網頁也一直無法建立索引，不曉得您的網站是否也有相同問題呢？

由於 Google 推出了 Search Console，很多操作方式、錯誤訊息會跟以前舊版網站管理員不一樣，那麼將來這個狀況也可能重複出現，因此本篇藉這機會來調查是怎麼回事。

一、新版 Search Console

雖然舊版依然可以使用，但只要操作沒幾下，八成就會被建議、指示前往新版 Search Console：

• https://search.google.com/search-console

雖然很多功能要花點時間找一下，用詞也可能不太一樣，不過新的版面我必須讚美一下：

• 網站看起來有質感多了，比較專業
• 操作介面也比較精簡，少了很多複雜、看不懂的選項

二、案情描述

1. 手動提交流程

我們知道，Google 收錄網站文章有時間差，會根據網站規模大小而不同。如果想要強制 Google 早點進行索引，使用舊版時，可以利用「檢索」→「Google 模擬器」來提交文章網址。

但現在這個功能在舊版已經無法使用，一律告知前往新版使用「新的網址檢查工具」。方法也很簡單，在新版 Search Console 上方搜尋框輸入網址即可：



一個還未被 Google 收錄的網址，可以按上圖右上方紅框處的按鈕「要求建立索引」，這就是手動提交的流程，非常簡單。

那麼這個案子到底問題在哪裡，以上流程有發現任何異狀嗎？


2. Google 遲遲未進行索引

再複習一下開頭的案情陳述：「從前幾天開始即使送出需求，網頁也一直無法建立索引，不曉得您的網站是否也有相同問題」。

意思就是說，其實已經手動提交網址好幾天了，但是幾天後在 Search Console 上方的收尋框輸入文章網址，依然出現 "網址不在 Google 服務中" 的畫面，這就比較離奇了。

於是我用 Google 搜尋案主該篇文章，事實上搜尋得到，所以當下 Line 對話大概是這樣：

• W：Google 這篇文章搜尋得到啊
• E：可以搜尋到但是沒辦法建立索引～覺得怪怪的
• W：沒有索引怎麼可能搜尋得到呢 哈哈~要先被索引，才有可能搜尋得到
• E：照理來說應該是這樣 但系統一直顯示不在索引中 所以我在想是不是系統有問題
• W：不然你回報給官方好了 我也不清楚~
• E：如果是系統有問題我就暫時不理他了 所以你的不會啊～～
• W：不是會不會耶 我不太注意這種事的 ^^

後面的對話與本文無關，當下我的直覺是，既然文章能搜尋得到就好了，並沒有很想理會 Google 網站管理員顯示的訊息。因為根據過去的經驗，當我被詢問到跟網站管理員相關的問題時，大部分的情形最終都在安撫使用者 "沒事~別理會那些訊息"，例如「在網站管理員看到 Index Coverage 問題不用擔心」。

不過為了瞭解是否為個案，還是測了一下自己網站，結果出現一模一樣的畫面，那麼還是來調查一下案情，猜猜到底 Search Console 發生什麼事。

三、網站地圖 sitemap.xml

試著從我網站最新的 3 篇文章開始調查，第 3 篇有被索引，略過。最新的 2 篇都會出現 "網址不在 Google 服務中"，其中第 2 篇就是前面那張圖，那麼再來仔細研究一下。



搜尋當天的日期為 4/19，這篇文章在 Google 是可以搜尋到的，表示一定有被 Google 索引。




但是為何在 Search Console 會出現上圖的錯誤呢，明明就有被索引啊？

檢查了一下 sitemap，上圖的意思是說，sitemap.xml 裡面沒有這篇文章，那麼我們來檢查一下 sitemap 報表資訊。




似乎找到兇手了，原來 sitemap.xml 上一次檢查的日期是 4/11 這麼久以前啊，難怪網站地圖 sitemap.xml 裡面沒有那篇文章。

注意到 atom.xml 的日期了嗎？4/18 有進行索引過。




如上圖，這篇文章的發佈日期是 4/14，所以在 4/19 的時間點，該篇文章不在 sitemap.xml 之中，但有被 atom.xml 收錄、已被 Google 索引。

這就能完美解釋，為何 Google 可以搜尋得到，但在 Search Console 卻出現 "網址不在 Google 服務中" 的錯誤訊息。

所以我的推測是，Search Console 預設讀取 sitemap.xml 的資料來顯示報表，才會發生與現實脫節的狀況，只要改掉這一點，直接讀取日期最近的一個 sitemap 提交檔案，就可解決這個 bug。

四、提交網站地圖的正確作法

雖然目前看起來已經破案了，但還是有一些事需要提醒讀者：

1. 不是只有本篇的狀況會出現 "網址不在 Google 服務中" 訊息，有些站長可能根本不知道要提交網站地圖，那麼依然會出現這個錯誤訊息。

2. 還有一些機率比較低的情況會出現此錯誤訊息，例如內容有問題、被提報導致 Google 剔除索引，或是 Google 有專人介入處理某些網址。不過這些從報表上應該都會有明確的訊息，要如何處理直接看說明就好了。

3. 從本文的內容可發現，Google 處理 sitemap.xml 這個檔案的間隔非常久，以我的網站來計算，等於隔了 10 天才檢查，那麼只提交 sitemap.xml 可能會浪費 10 天的時間。

因此強烈建議讀者，務必按照「Blogger 提供新的網站地圖(sitemap)格式﹍一勞永逸的提交方法」，同時另外提交 atom.xml，可以有效縮短索引間隔，那麼看到本篇的錯誤訊息也不必擔心，因為文章其實已經被收錄，Google 也搜尋得到文章囉~

更多 SEO 相關文章：

----
如這篇文章對您有幫助，請順手按個 +1 或分享，謝謝！