發佈於

什麼是必備的SEO技能?

我們曾經在”台灣SEO市場是在擴大還是縮小?“提到，專業的SEO公司必須跨足其他網路行銷，才能夠滿足客戶的需求，以強化自己的生存條件。因此對於SEO人員所要求的技能，可能已經五花八門了，但是真正SEO人員必備的技能有哪些呢?

這篇”5 Must-Have SEO Skills“說到了有五大必備的技能，如下圖:

我們將五個必備的SEO技能敘述如下:

(1) Technical SEO (SEO基本技術)

(2) Social Media Marketing (社交媒體行銷)

(3) Link Building (聯結建立能力)

(4) Usability & Information Architecture (可使用性與資訊結構)

(5) Content Marketing (內容行銷)

其實如我們之前所說的: “最早以前是要網頁設計師 (Webpage Designer) 變成美工藝術設計師 (Webpage Art Designer)，要變成網站管理者 (Webmaster)、網站規劃師 (Website Architect)，後來是要網頁設計師變成搜尋優化策略師 (SEO Strategist)，現在更是要求變成全方位的Organic Web Strategist、ZMOTer，也就是「網路行銷策略規劃師」” … 也就是讓SEO的核心更加模糊了。

嚴格來說，社交媒體行銷的能力是不包含在原本的SEO技能裡面的，但是因為Social SEO的變化，使得SEO人員好像無法處理社交媒體行銷的話，已經是一個罪過了。

再者，Link Building (聯結建立能力)應該原本就在SEO基本技能裡面，因此上述的五個項目，其實可以分成:

(1) SEO Fundamentals (SEO基本技能)

那麼什麼是SEO基本技能? 就是對於on-page SEO、off-page SEO的瞭解，就是對於搜尋引擎演算法改變的敏感度，這些基本技能歸納起來簡單，但是也非常的複雜，我們的搜尋引擎研究院探討了這麼久，都還無法完全探討完畢。

(2) Content Marketing (內容行銷)

我們在”SEO工作的薪水應該是多少?“說到，文案工作的需求會越來越高，也就是內容行銷的主軸會越來越重要。

網站搜尋的主要依據還是以文字為主，沒有切中要點的內容就無法進行行銷，當搜尋引擎抓取資料時，需要抓到與關鍵字相關的文字內容，使用者閱讀時，需要讀到可以打動他們的文字內容，這些都需要內容行銷。

(3) Social Media Marketing (社交媒體行銷)

前面已經說過，要求SEO人員需要具備社交媒體行銷能力，真的是有些過份，但是時勢所逼，現在態勢是不太可能改變，所以SEO人員還是得乖乖的學習社交媒體行銷能力。

但是什麼是社交媒體行銷能力呢? 首先當然是對於社交網站的操作必須熟悉，並且最好Facebook、Google+、Twitter、Plurk、funP … 等等社交網站都多少涉獵一些。

再來就是必須瞭解如何增加你的影響力，也就是把社交圈拉大。社交圈拉大之後，才可能讓你的訊息快速擴散到目標客戶。

但是許多人操作的結果，通常有一個疑問，那就是到底目標客戶在哪裡? 如果無法快速的辨識哪些人才是目標客戶，可能在社交網路上的投入會事倍功半。

(4) User Experience Design (使用者經驗設計)

透過SEO技術吸引進來的流量，必須喜歡或是信賴這個網站，才有可能成為消費者或是成為高黏度的讀者。想到達成這個目的，就必須透過使用者經驗設計。

使用者經驗設計其實是很花錢的，其中包括了界面、流程、氛圍、內容 … 等等許多因素，並且還可能因目標客戶不同而有所差異，也就是不一樣的客層可能必須有不同的網頁樣貌呈現。

這個層次的技能，可能已經不是屬於技術的層次，已經包括了藝術與人文，甚至於包括了心理學。如我們在”什麼是Psychology Based SEO Strategy (心理學為基礎的搜尋引擎優化策略)?“說的，它是探討人類行為多過技術層面的SEO，其實就是全面性的網站優化。

(5) Information Management Fundamentals (資訊管理基夲技能)

資訊管理基夲技能是不難的項目，但是卻很繁雜。關於網站運作到管理，甚至於許多雜七雜八的設定，都要瞭解。

這個項目對於資訊相關科系的SEO人員比較沒有問題，但是對於非資訊相關科系的SEO人員，就必須多讀一些實務的網站相關書籍，才能夠逐步建立起來。

以上的五大項目，你是否都具備了呢? 或是你認為還有更多應該具備的技能，也歡迎多多反應囉。

Reference  from:

發佈於

企業創新經營模式系列之四: 網站經營四大策略~KIMO

企業網站怎麼經營? 是經常被問到的問題，並且也看過許多網站經營時掛一漏萬。因此在此提出企業網站經營四大策略: KIMO，來讓企業網站能夠很清楚的掌握到重點。

什麼啊? 企業網站經營四大策略竟然是KIMO? 是奇摩嗎? 怎麼企業網站經營會跟它扯上關係呢?

誤會了，這個KIMO不是指奇摩，而是指以下四大策略的縮寫:

(1) Knowledge sharing (知識分享) : 企業網站不應該以銷售產品為唯一目的，企業網站越大越不應該依靠網站銷售產品，而應該建置一個平台來銷售服務。

什麼樣的平台呢? 就是一個可以分享企業知識的網路平台。

依靠銷售產品無法培養具有忠誠度的消費者，但是依靠平台則可以讓消費者無法離開你的知識平台。除非別的網站提供更好的知識分享平台。

知識分享平台對於SEO有絕對的幫助，對於消費者也有絕對的幫助，當然對於企業更是可以培養消費者的忠誠度，因此是創造三贏的局面。

舉個例子來說，許多網站經常詢問我們為什麼轉換率(conversion rate)一直不好? 經過瞭解才知道，他們的網站除了產品服務之外，沒有其他內容。既然沒有相關內容，搜尋引擎當然無法給予優秀的排名，加上沒有知名度，因此需要該產品服務的 人找不到該網站，尚不需要該產品服務的人更不會來訪，當然不會有優秀的轉換率。

如果網站能夠建立企業知識的網路分享平台，就會慢慢吸引需要該知識的訪客，這些訪客也會逐漸信賴該網站，而從潛在的客戶變成真正的客戶。而需要該產品服務的人，也會因此而可以在搜尋時找到該網站。

(2) Integration of daily operations (整合每天的日常作業)

這個項目主要重點在於「整合」，一個企業活動，每天會產生很多值得分享的內容，這些內容應該透過整合而自動轉化成可以分享的內容，而不需要再加工，或是不需要太多的加工，就可以變成網路分享平台的一部分。

除了聘請寫手來產生內容之外，這些透過整合而由內部產生的內容，也是可以產生許多優秀的內容。

不過這個整合每天的日常作業的難易度，必須視企業類型而定，有些可以很容易的建構這個整合的機置，但是也有可能不太容易建構。

例如，如果你是硬體供應商，內部應該就有一定的程序來解決硬體出現的問題，有些可能因為驅動程式版本的問題，有些可能是操作產生的問題，有些可能是硬體相互搭配的問題，這些問題就可能透過整合內部作業機置，而產生可以分享的知識。

例如，如果你有電話客服，電話客服所解決的問題就可以先自動分類，然後再經過加工而成為可以分享的知識。

問題是內部員工產生了可以分享的內容，獲得了什麼好處? 這些內容是否能夠持續維護而延長其生命週期? 這就必須依靠企業建立制度，來讓內部員工樂於創造知識分享的內容。

從這篇”3 Marketing Lessons From Amazon’s Web Strategy“，我們可以看到其中說到: 亞瑪遜網站的成功，其中一個重要的關鍵就是建立了大量的內容，然後讓使用者去翻天覆地的使用之後，再由使用者習慣分析中產生了個人化的需求。

如同我們所說的，企業網站如果能夠整合內部活動，而將產生的大量知識性內容分享出來，就能夠如亞瑪遜網站一樣，逐步的過濾出消費者的個人化資訊。

(3) Multiple perception network (多層感知網路)

多層感知網路似乎聽起來很有困難度，其實意思是企業不應該以一個企業網站來面對外在環境，而必須以多個層次的感知器來接收外來的訊號，說得簡單一些 就是，Twitter、Facebook、Plurk、電子商務網站、企業部落格、企業知識分享網站 … 等等，這些都是企業網站群，都應該正視這些網站的經營，不能因為臉書只是一個外部網站，而隨便派個工讀生擋著就交差。

並且企業應視其能力，盡可能的不要將所有資源都集中到某個網路上，或是依其趨勢盡可能的彈性調配資源。

從這篇”4 Ingredients to a Successful Social Web Strategy“就說到: 許多行銷者專注在Facebook的粉絲專頁上，使用一堆生手去管理企業的社交入口，當然無法得到滿意的效果。

跟我們上面所說的一樣，企業必須多管道的進行社交網路，才可能從社交行銷上獲得成功。

(4) Off-line engagement (離線投入)

既然是談到企業網站經營，為什麼會出現「離線投入」呢? 其實在網路上虛擬分享、互動的搞半天，可能抵不上一次的實際接觸。這裡所謂「離線投入」就是指實際生活上的活動或是直接接觸。

「虛擬相依」將是未來網路的趨勢，從實體走向虛擬、從虛擬跨出到實體，將使得消費者在虛擬中享受方便，而在實體中健立忠誠，透過「離線投入」可以使得企業網站能夠培養真正的忠實客戶。

通常我們在日常實際生活中，如果有陌生人跟我們聯絡，一般通常都會浮出兩個問題: 這個人要賣什麼東西給我嗎? (對我有所求嗎?) 這個人對我有好處嗎? (能夠給予我什麼嗎?) 前者是自我防衛性質，後者是主動攻擊性質。

當企業在虛擬網路上培養了粉絲，表示這些粉絲可以從企業網路上得到東西，因此當進行「離線投入」時，粉絲的自我防衛性質會降低，因此特過企業網路而到「離線投入」，可以更加的與粉絲建立情感。

如果您有任何其他意見，也歡迎跟我們討論囉。

Reference from: http://www.dns.com.tw/?p=1737

發佈於

2012年網路行銷趨勢，不知道就落伍囉!

2012年將是一個多變的一年，面對全球各種負面經濟因素的狀況之下，企業應該如何進行網路行銷才能夠立於不敗之地呢? 2012年的網路行銷會有哪些趨勢呢?

從這篇”Marketing Methods and Trends – What’s New for 2012?“文章，作者提到了幾項網路行銷應該注意的趨勢，詳細敘述如下:

(1) Mobile Marketing (行動行銷)

我們曾經在”網路行銷的最後一哩 : Google Nexus One?“提到:如果你的網路行銷策略還沒想到Mobile這一塊的話，是時候該思考了，如果等一切都成熟就來不及了。當時的時間是2010年，如果你的企業在當時就能夠開始思考的話，現在就應該已經有了萬全的準備了。

根據這篇”It’s official: mobile devices outnumber people in the U.S.“，在美國使用行動電話的人口已經超越美國的總人口數目，而美國的上網人口才只有美國的總人口數目的75~80%。

而台灣的情況，根據這個報告”2011年6月底止台灣上網人口“，經常上網人口數於2011/6已經達到47% (當然實際上網人口數會高於這個數字)，根據這個”台灣寬頻網路使用調查報告“資料，2011年台灣地區家戶上網比例達到79.77%，曾經使用行動上網的人口已達382萬人，較去年增加2.61個百分點；此外，已有3%~9%的網友將行動上網當作固定的連網方式。

因此預計我們所說的「最後一哩」，今年將可望在台灣真正的展開。作者說到，今年將會陸續出現各種更快的行動設備、以及各種LBS (Location-based Services)整合出現，因此如果你的行銷尚未在行動行銷上著墨的話，該是時候了。

(2) Social Marketing Integration (社交行銷整合)

我們曾經在”Facebook 網路行銷“說到，現在則是所有的公司網路都是社交網路，也就是經營企業就是在經營社交。在2012年經營社交網路，不應該還停留在與消費者互動，那個是去年就應該做到的事情，除了互動之外，應該利用社交網路進行更精準的行銷。

(3) Traditional Marketing Continues to Diminishes (傳統行銷持續疲軟)

這點是無庸置疑的，因為線上行銷可以清楚的掌握各種數據，並且消費者持續增加在網路上的活動，因此各種行銷預算將會移往線上網路行銷的領域上。

(4) Consumers Will Determine Value (消費者決定價值)

在這個不景氣的年代，消費者對於他們的荷包看得很緊，因此他們只會把錢消費在最有價值的產品上面，所以不被消費者認為是有價值的東西，再怎麼行銷都 是沒有用處的，行銷者無法決定這個價值。消費者不會因為產品在促銷而去購買，因此企業必須行銷產品的價值，才能夠讓消費者掏出錢來購買。

(5) Regulations Abound (各種規則出現)

網路上的規則都是如此，剛開始的時候完全沒有規定，所有人都在黑暗中摸索，但是逐漸累積經驗之後，才會慢慢出現許多立法與規範。而現在同樣會陸續出現更多的規則，例如SOPA，為的是要更嚴格打擊線上盜版，只要是在網站上發現盜版行為，政府可以全面的封鎖該網站。

Matt Cutts的這篇文章”Progress against SOPA“就明白的指出，SOPA將會讓網際網路受到箝制，因為網路上可能出現假SOPA之名的限制言論行為。這類奇怪的規定將會陸續出現，SOPA不會是最後一個。

(6) Relationships will Drive Loyalty and Sales (關係將會驅使忠誠與銷售)

作者認為企業是否能夠順利行銷，決定在於企業與消費者的關係，這點跟我們這篇”企業創新經營模式系列之四: 網站經營四大策略~KIMO“有些類似，我們說到~依靠銷售產品無法培養具有忠誠度的消費者，但是依靠平台則可以讓消費者無法離開你的知識平台。除非別的網站提供更好的知識分享平台 … 也就是企業必須思考使用各種方式拉近與消費者的關係。

在實際的生活中，消費者可能因為方便而購買某個產品，例如習慣在某個大賣場購買日常用品，但是在網路上就很容易轉移，因此透過關係的建立，才能夠讓消費者持續消費。

以上所說的這些趨勢，你的企業是否都準備好對策了呢? 也歡迎提出你的看法來交流囉。

reference from: http://www.dns.com.tw/?p=1747

發佈於

如何在 SQL 2008 安裝 Performance Dashboard Reports

微軟在 SQL Server 2005 Service Pack 2 推出的時候也釋出了一套免費的 Performance Dashboard Reports 自訂報表，透過此報表可以很輕易的分析出整台 SQL Server 的執行效能，是一個非常非常實用的效能分析工具，幾乎是每位 DBA 必備的工具之一，可惜的是到了 SQL Server 2008 之後就不再更新，以致於無法正常安裝到 SQL Server 2008 之後的版本，本文章將說明正確的安裝步驟，讓此報表也能夠在 SQL Server 2008 上正確執行。

在我們下載完 SQL Server 2005 Performance Dashboard Reports 之後，直接點擊 *.msi 檔進行安裝，安裝到選取安裝路徑時，請記得要選取正確的 SQL Server 2008 的安裝目錄才行，如下圖示請點選 Browse 按鈕：

然後預設的安裝路徑為 C:\Program Files (x86)\Microsoft SQL Server\90\Tools\PerformanceDashboard\ 我們只要把該路徑的 90 修改成 100 即是 SQL Server 2008 的預設安裝路徑，不過其實安裝在哪裡都沒什麼關係，因為之後報表還是需要被手動載入，但基本上我不會亂裝到其他的路徑：

安裝完後在安裝目錄下會看見一個 setup.sql 指令檔，這個指令檔必須手動到 SQL Server 執行，才會在 msdb 資料庫建立起 Performance Dashboard Reports 所需的函數與預存程序：

若在 SQL Server 2005 資料庫伺服器執行這個指令檔 ( Service Pack 2 以後的更新 ) 並不會有任何問題，但是在 SQL Server 2008 的資料庫伺服器就會遇到以下錯誤：

    Msg 207, Level 16, State 1, Procedure usp_Main_GetCPUHistory, Line 6
無效的資料行名稱 ‘cpu_ticks_in_ms’。
Msg 15151, Level 16, State 1, Line 1
無法 尋找 物件 ‘usp_Main_GetCPUHistory’，因為它不存在或您沒有權限。

這個錯誤的主因出在於原本在 SQL Server 2005 裡有個 DMV (Dynamic Management Views) 叫做 sys.dm_os_sys_info，在這個版本的 DMV 有個 cpu_ticks_in_ms 欄位，但在 SQL Server 2008 之後的版本該欄位被修改成 ms_ticks，所以你必須手動修改 setup.sql 指令檔，在 第 218 行的地方將該欄位修正，修正後重新執行一次就可以建立完成。

接著就是利用 Management Studio 從伺服器層級開啟自訂報表，如下圖示：

然後切換至 Performance Dashboard Reports 的安裝目錄並選取 performance_dashboard_main.rdl 報表

按下開啟舊檔後，報表就會立即出現正確的效能分析報告，如下圖示（點圖可放大顯示）

image

這裡其實包含好幾份子報表，都是相互連動的，所分析出來的資訊之寶貴無法言寓，有心想研究的人建議可參考安裝目錄下的 PerfDash.chm 文件，這裡有每一份報表的詳細說明：

在點選進 (Drill down) 子報表之後，如果要回上一頁，可以按報表左上角的「向後巡覽」按鈕，這樣就可以不用每次重新開啟報表：

在眾多報表之中，我覺得最有用的應該就是 Missing Indexes (遺失的索引)：

這份報表可以幫我們找出有哪些表格遺失了某些「可能需要」的索引（切記：越多的索引代表資料寫入速度越慢），然而在分析出所有遺失的索引後，你可以在 Proposed Index 欄位發現他連建立索引的語法都幫你寫好了，可惜的是你無法直接從報表上複製文字下來，只能先匯出 Excel 再複製其 T-SQL 語法：

由 於你不應該把所有「可能遺失的索引」都建立起來，因此以下提供一個基本的判斷原則，幫助你選擇到底有哪些索引應該被建立，這調校原則雖然適用於許多情況， 但該原則還是僅供參考，設定不好而導致資料庫寫入速度變慢請不要找我負責，因為資料庫的效能調校不僅僅只有這樣的判斷邏輯，還有許多其他的環境因素都有可 能影響到調校的策略，像是：硬碟存取速度、應用程式特性、系統資源分配情況、…等等

  • 當 Avg Total User Cost 欄位的數值超過「個位數」以上，就算是蠻高的成本，可以考慮建立索引
  • 當 Avg User Impact 欄位的數值超過 80 以上，也算是蠻高的衝擊，也可以考慮建立該索引

不過再進一步分析 Unique Compiles、User Seeks、User Scans 數量過低的情況，其實建立索引不見得對整體執行效能有幫助（因為該索引的使用率過低），反而會導致寫入效能低落的情況，這時你也可以選擇不建立該索引：

§ 最後提醒 §

這些統計資訊的資料來源大多來自於 SQL Server 裡所謂的 動態管理檢視 ( DMV )，這些資訊是從資料庫實體 (Instance) 啟動之後所累積的動態資訊，所以 SQL Server 跑得越久，所收集到的資訊越精準，也越能找出在啟動 SQL Server 服務之後到現在所累積的效能問題有哪些。

Reference from: http://blog.miniasp.com/post/2011/08/24/Performance-Dashboard-Reports-for-SQL-Server-2008.aspx#continue

發佈於

微軟提供的網站壓力測試工具 – WAS

Microsoft Web Application Stress Tool 是由微軟的網站測試人員所開發，專門用來進行實際網站壓力測試的一套工具。透過這套功能強大的壓力測試工具，您可以使用少量的Client端計算機仿真大 量用戶上線對網站服務所可能造成的影響，在網站實際上線之前先對您所設計的網站進行如同真實環境下的測試，以找出系統潛在的問題，對系統進行進一步的調 整、設置工作。
Microsoft Web Application Stress具有以下幾個特性：
* 可以數種不同的方式建立測試指令：包含以手動、錄制瀏覽器操作步驟、或直接錄入IIS的記錄文件、錄入網站的內容及錄入其它測試程序的指令等方式。
* 支持多種客戶端接口：標準的網站應用程序C 的客戶端，使用Active Server Page 客戶端，或是使用Web Application Stress對象模型建立您自定的接口。.
* 支持多用戶利用多種不同的認證方式仿真實際的情況，包含了DPA, NTLM 及 SSL等。
* 支持使用動態的cookie仿真定制網站實際運作場景及對話（session）的支持。
* 在客戶端的計算機以NT 服務的方式執行仿真的工作，可在不中斷測試的情況下將某些客戶端的測試計算機刪除。
* 透過集中式的Microsoft Web Application Stress 治理員，您可以使用任意數目的客戶端計算機同時進行測式的工作。
* 具有Bandwidth throttling （帶寬遏流）的功能以仿真用戶使用調制解調器上線的效果。
* 內建的query-string 編輯器可幫助您建立name-value pair組合的模板，并可在不同的場景測試中重復使用。
* 可程序化的對象模式讓您可以建立您自己的測試客戶端。
* 匯總的測試報告及豐富的性能測試資料。
* 支持域名系統(DNS)讓您可以測試整個群集（Cluster）的機器。
* 使用Page group的方式來控制文件的組及測試指令的執行程序。
* 可自定的header讓您可以仿真各種不同種類的瀏覽器。
* 可自定的指令延遲讓您以更接近真實環境的方式進行測試。
網站測試概述
為了正確使用WAS進行網站的壓力測試，您需要對于網站測試的方法有一初步的了解。以下的討論將包含一些基本的概念以供參考。
網站的測試可大略分成三個主要的類別：
* 網站性能測試 (Performance testing)
* 壓力測試下的網站穩定性 (Stability or stress testing)
* 網站承受能力評估 (Capacity planning)
網站性能測試的第一件工作就是使用測試工具對網站加壓以測量網站伺服器每秒可以承受的請求(Request Per Second) 的最大值。第二件工作就是找出系統性能限制的原因所在，舉例來說，CPU、內存、或是后端系統所造成的反應延遲等。
在 許多狀況下，網站伺服器的CPU是主要的性能瓶頸。測試時您可以持續加壓直到性能表現開始下降，再慢慢的降低壓力的程度。此時您所測試出來的最大性能即為 該網站所能達到的最高值。在實際測試時，您可以通過增加壓力線程(thread)，或是增加執行WAS測試程序的客戶端來加壓。
在網站伺服器 端，您可以使用性能監視工具如Performance Monitor來監視如 \”System: % Total Processor Time\” 及 \”Web Service: Connection Attempts/sec\” 或 \”Active Server Pages: Requests Queued\”等指針。假如CPU的資源指針已達到80%到85%，則CPU的處理能力最有可能就是整個系統的瓶頸所在。若是在壓力測試的過程中CPU 所被使用的比例不高而”Requests Queued”的指針一直居高不下，可能是程序正在調用伺服器上的COM組件而這個組件無法有效的執行完所有的命令，因而造成了系統性能的降低。在這種情 形下，伺服器上的COM組件才是真正的瓶頸。
目前市場上最熱門的定制網站應用程序也會對網站的性能表現有重大的影響。WAS包含了數種特性可有 效的幫助您測試定制的網站應用程序。例如，您可以建立用戶，讓WAS可以設置并儲存每一個用戶的cookie。您也可以使用QueryString 編輯器幫助您建立并儲存數個不同的name-value pair以便在每一次執行request時進行測試。

Reference from: http://mid.lt263.com/mb/cmsjiaocheng/20082.html; How to install: http://www.yaosansi.com/post/1281.html

發佈於

Landing page load time now affects keywords’ Quality Scores

Wednesday, June 18, 2008 | 4:56 PM

Labels: , 

Google designs its products with user experience as the number one priority. Early in Google’s history, our founders, Larry and Sergey, articulated this philosophy in Ten things Google has found to be true. One of these principles is “Fast is better than slow.” We’ve found this rule to be especially applicable to the landing pages of AdWords ads. When a user clicks an ad, a landing page that loads quickly provides a better user experience than a landing page that loads slowly.

In early March, we announced that we’d soon incorporate an additional factor into Quality Score, namely landing page load time — where load time is defined as the amount of time it takes for a user to see the landing page after clicking an ad. In early May we announced that landing page load time information had become available on the Keyword Analysis page.

Starting today, this load time factor will be incorporated into your keywords’ Quality Scores. Keywords with landing pages that load slowly may get lower Quality Scores (and thus higher minimum bids). Conversely, keywords with landing pages that load very quickly may get higher Quality Scores and lower minimum bids.

Why are we doing this?
Two reasons: First, users have the best experience when they don’t have to wait a long time for landing pages to load.Interstitial pages, multiple redirects, excessively slow servers, and other things that can increase load times only keep users from getting what they want: information about your business. Second, users are more likely to abandon landing pages that load slowly, which can hurt your conversion rate.

How can I improve my load time?
The AdWords system re-evaluates landing pages on a regular basis. If you make significant improvements to your landing page’s load time, you should see a better Quality Score and lower minimum cost-per-click (CPC) bids. Note that your Quality Score may change/increase gradually over a number of weeks after you improve your load time.

To learn more about load time and landing page quality, please see this article in the AdWords Help Center.

Posted by Heather Lane, Inside AdWords crew

 

Rererence from: http://adwords.blogspot.com/2008/06/landing-page-load-time-now-affects.html

發佈於

301 Redirect for SEO

*本文章只適用於使用  Apache (多用於 Linux) 為 web server 的網站。

以友站 關鍵字廣告基地 為例，當這個網站架設好後，我們知道我們的官方網址是：http://www.clicks.com.tw

但是一般來說，我們可以以下四種方式輸入網址到達首頁：

http://www.clicks.com.tw/
http://www.clicks.com.tw/index.php 或 index.html 或 index.htm
http://clicks.com.tw/
http://clicks.com.tw/index.php

我們知道目前搜尋引擎基礎上以 backlink 連結來賦予網頁的權重，由於我們無法控制第三方採用哪一個網址來跟我們的網站進行連結，因此就可能出現 相同網頁、不同網址、不同權重的情況出現。『 相同網頁、不同網址、不同權重』這個問題，對瀏覽者來說可以說無傷大雅，但是在搜尋引擎就會造成權重分散的情形。

對搜尋引擎來說，上述四個網址代表著四個不一樣的網頁。

而對網站瀏覽者來說，對網址的具體印象也會不一。

筆者就曾經有過 http://www.xxxx.com.tw/  (PR =4) 跟 http://www.xxxx.com.tw/index.php (PR = 5) 出現不同  Page Rank 的問題。同一個網頁不同的 PageRank 代表著浪費了辛苦累積的 backlink。

這個情況在 Linux 伺服器 (準確點應該是說使用 Apache Web Server 的伺服器) 就要透過 301 redirect 來解決。所謂 301 redirect 的意思是告訴搜尋引擎這是永久性 (301) 的轉址 (redirect)。

在放置首頁  index.php 或 index.html 的目錄下，一般有一個 .htaccess 的隱藏檔案。這個 .htaccess 屬於隱藏檔案，在 FTP 軟體上也許要設定可以觀看隱藏檔案才會發現它的存在。看不到也不用驚訝，也許本來的設定就沒有。

將 .htaccess 檔案下載回來，用 notepad 或者 Editplus 這些純文字編輯軟體就可以加入，非常簡單。請注意如果本身 .htaccess 已經有其他設定，首先需要備份萬一發生問題可以將備份檔上傳，再來就是將以下的指令放到檔案最下方即可，不要刪除本來的設定。

Options +FollowSymLinks
RewriteEngine On
# 以下是將沒有www 的網址加上有 www
RewriteCond %{HTTP_HOST} ^clicks.com.tw$ [NC]
RewriteRule ^(.*)$ http://www.clicks.com.tw/$1 [R=301,L]
# 以下是將有 index.php 的網址轉成沒有
rewriteCond %{THE_REQUEST} ^[A-Z]{3,9} /index.php HTTP/
rewriteRule ^index.php$ http://www.clicks.com.tw/ [R=301,L]

請將 clicks.com.tw 網址換成您自己的網址。

新的 .htaccess 檔案上傳後，不論輸入四個當中哪一個網址，都會自動轉成官方的http://www.clicks.com.tw/ ，而搜尋引擎也會將權重全部集中在這個網址上。

由於這個情形幾乎每個網站都會出現，所以應該出現在每個網站完成的 check list 上，視為標準動作。

參考：How To Redirect index.php to directory
http://www.webmasterworld.com/apache/3495904.htm

Reference from: http://seo.list.tw/301-redirect/

 

 

 

 

 

 

 

發佈於

Google site speed

我們都知道 Google 已經將網站的載入速度納入搜尋引擎排名 以及 Google Adwords 網頁品質的計算因素裡面。我們又如何得知 Google 那邊對我們的網站測出了什麼樣的速度？

Google 上個禮拜在 Google Analytics 發布了一個新的功能 – Site Speed (網站速度)。網站管理者需要在原有的 tracking code 上面加入 _gaq.push([‘_trackPageLoadTime’]); 這段程式碼，數個小時後，進入 Google Analytics 的新 Beta 版本就可以看到網頁載入時間的統計資訊。

這段程式碼目前並沒有預設在 tracking code 裡面，就算你是 Google Analytics 的新用家，還是需要在Google Analytics介面提供的tracking code 上面額外再加上 _gaq.push([‘_trackPageLoadTime’]); 這一段。

Reference from: http://seo.list.tw/google-analytics-site-speed/

 

 

 

 

 

 

 

發佈於

RAID-10

RAID 10/01其實可細分為RAID 1+0或RAID 0+1。

RAID 1+0是先鏡射再分割資料。是將所有硬碟分為兩組，視為是RAID 0的最低組合，然後將這兩組各自視為RAID 1運作。RAID 1+0有著不錯的讀取速度，而且擁有比RAID 0更高的資料保護性。

RAID 0+1則是跟RAID 1+0的程式相反，是先分割再將資料鏡射到兩組硬碟。它將所有的硬碟分為兩組，變成RAID 1的最低組合，而將兩組硬碟各自視為RAID 0運作。RAID 0+1比起RAID 1+0有著更快的讀寫速度，不過也多了一些會讓整個硬碟組停止運轉的機率；因為只要同一組的硬碟全部損毀，RAID 0+1就會停止運作，而RAID 1+0則可以在犧牲RAID 0的優勢下正常運作。

RAID 10巧妙的利用了RAID 0的速度以及RAID 1的保護兩種特性，不過它的缺點是需要的硬碟數較多，因為至少必須擁有四個以上的偶數硬碟才能使用。

 

 

 

 

 

 

Reference from: http://zh.wikipedia.org/wiki/RAID