文章專區

SEO與搜尋行銷相關

 本站介紹過一般多種常用的轉址方法,而先前也提到過關於安全憑證SSL的安全連線防護,礙於申裝憑證其實工序繁瑣,所以希望能夠正確有效的進行申裝與移轉而盡可能的不影響網站排名、頁面權重,本次要探討的是,可能會在伺服器上的轉址時機與在多個網站上進行聯合發佈的轉址時機,我們能透過以下這些方法來針對幾個狀況進行網站上的調整,能使我們的網站更正確的被搜尋引擎收錄,達到SEO的最佳化。   先前發文也提到過伺服器上的轉址,我們可以透過伺服器上的設定來進行www子網域的轉址及https安全協定的設置,提供連線資訊的完整度及使用者的安全連線,就能在這些額外服務建立時盡可能不影響網站排名與權重,以下可參考網址範例:   主網域網址:http://yuordomain.com/green-dresses   加入安全協定網址:https://yuordomain.com/blue-glass   加入子網域網址:http://www.yuordomain.com/blue-glass   由主網域進行延伸的轉址,隨著網際網路的演進,使用子網域及加入安全協定的網址,不僅能加以保護網站本身和客戶的安全連線,也能使網站取得搜尋引擎與新使用者較高的信賴度,而其兩項合併延伸將不會互相衝突,因此便可將上述三種網址進行轉,指向參考合併延伸後的網址:https://www.yuordomain.com/blue-glass 進行積分與權重的累積。   資訊平台的普及與友善的相互性,使得不同平台的資訊內容逐漸走向共享化,從自己的網誌聯合發佈至其他網域中網站的內容,與原始內容有部分或全部是重複的時候,我們也會遇到不同網址入口所看見相同的內容,如以下參考:   原始文章網址:https://blog.yuordomain.com/blue-glass/   聯合發佈文章網址:https://news.yuordomain.com/blue-glass.html   此方法可以散播較多窗口,但在頁面轉址導向時可協助搜尋引擎將每個網址的資訊彙整到單一偏好網址。不過,這也表示從其他網 站連至原網址的網址會連結合併。  
      本站介紹過一般常用的的301轉址(永久)與302轉址(暫時)及IIS轉址(進階)和DNS轉址(網域),主要都是在說明轉址的方法,目的就是希望大家在網站改版或是更換網址時能夠正確有效的進行移轉而盡可能的不影響網站排名、頁面權重,明白多種轉址方法後,本次要探討的是,先前介紹的這些功能其實不單單只能用在改版與更換網址,我們還能透過以上這些方法來針對幾個狀況進行網站上的挑整,能使我們的網站更正確的被搜尋引擎收錄,達到SEO的最佳化。          網站網址呈現的方式有許多種,但我們常見的大分類為"靜態網址"與"動態網址",已常見靜態網址來說,網址是固定的沒有帶入參數變動的問題,而動態網址會因為不同的主題規則及需求而帶入不同的資訊,若在不同的規則下也有可能會帶出相同的頁面,因此為了避免不同規則的網址產生相同動態內容而分散積分,這時便可以使用301轉址將不同動態網址的內容統一指向統一網址即可。 可參考以下範例:   動態產生網址:https://www.yuordomain.com/products?category=glass&color=blue   動態產生網址:https://yuordomain.com/glass/cocktail?gclid=ABCD    靜態固定網址:https://www.yuordomain.com/glass/blue/blueglass.html   以上三個網址雖為不同,但頁面呈現的內容卻是一樣的,為了避免同樣產品分數因為網址的呈現方式被分散,可以使用301轉址將其他兩個網址轉址為其一網址。     在部落格發佈文章時可能會遇到不同主題頁面會放置相同的文章,因此也會面臨網站自動生成多個網址,此時我們也可以使用301轉址進行調整。   可參考以下範例:   發佈網址一:https://blog.yuordomain.com/glass/blue-glass-prd-chesome/   發佈網址二::https://blog.yuordomain.com/blue-things/blue-glass-prd-chesome/    
      在維護網站長久經營的積分與排名時,我們瞭解了先前所介紹一般常用的的301轉址(永久)與302轉址(暫時)及IIS轉址(進階),主要是在較基礎與程式的層面上著墨,而網站的組成中,除了內容的製作與程式上的開發外,網域名稱就是我們一直在討論轉址的部分,但在伺服器管理網址名稱時,也有著可以直接透過最高層伺服器進行轉址,就是在管理網域資訊的DNS中進行轉址設定。         比起以往要管理網站伺服器需要繁瑣的動作與設定,現行業界中多了許多代管網址資訊的廠商,而在這些代管的服務中,也提供了友善的操作介面,更重要的是,也整合了以往較複雜的功能並且簡易化了操作流程,已範例:CloudFlare、GoDaddy等代管廠商來說,可以在代管設定上透過記錄類型A類,進行網址來源及目標的設定,再經由伺服器上的更新,便能在最高層級的網域區段直接進行轉址,不過在進行這類的設定中,也伴隨著網站DNS與國際伺服器連結的穩定和安全性,因此,在這部份上的調整建議經由瞭解網域設定的人員操作較為妥善。由於每間廠商所開發介面不同,因此以下已CloudFlare為例,提供範例。      
       在先前談到關於301轉址,除了可以使用單頁面上的永久轉址轉址及302暫時性轉址外,我們也可以適時的使用更進階的IIS URL rewrite來進行設定,談到IIS在發行了7.0版本後便加入了URL rewrite的多項功能,一般人一開始不熟悉時,面對多樣性功能強大的圖形化界面可能辦法這麼快熟悉全部功能,因此,IIS URL rewrite在這我們也只針對301轉址進行簡易的相關說明。          回歸程式上的開發,我們可以透過瞭解web.config的設定檔來簡單的進行控制修改IIS上的設定,它可以針對單一網站或單一網路程式來儲存程式面上的修改,也可以輕鬆的根據修改及上傳web.config檔來設定改變網站程式的設定,不需要再依靠IIS操作介面繁複的設定或是重新啟動IIS,而且網站內所有網頁,子層都會按照web.config的設定來執行運作,因此在這邊我們也舉出範例讓大家來瞭解參考如何使用程式化快速的設定IIS URL rewrite,請參考以下。     <configuration>     <system.webServer>         <rewrite>             <rules>                 <rule name="Canonical Host Name" stopProcessing="true">                   <match url="(.*)" />                   <conditions>                     <add input="{HTTP_HOST}" pattern="^yuordomain\.com$" />                   </conditions>                   <action type="Redirect" url="http://www.yuordomain.com/{R:1}" redirectType="Permanent" />                 </rule>              </rules>         </rewrite>     </system.webServer> </configuration>   我們將原先http://yuordomain.com/導向至http://www.yuordomain.com/  
     在先前我們分享了瞭解網站轉址與301轉址後,可以知道網站在進行更新甚至要改版的狀況時,如果要將網站更換至新網址,我們可以透過301轉址的語法來進行,將舊有的網站頁面權重進行轉移到將要使用的新網址頁面,就能保留以往所努力經營的頁面權重及搜尋引擎排名,但301轉址的轉址其實代表的是將舊網站權重"永久轉移"至新的網頁,如果您是要捨去舊有的網站與網址時,這是適合的做法。但如果是要暫時修改及保全舊有網站與網址的同時,要另外使用替代網址與網站狀況下,就並不適用301轉址。       要在維持舊有網站與網址的頁面權重時,也能使替代網站不失重要流量的方法便是使用302轉址,有別於先前介紹的301轉址,同樣都是會將頁面權重進行轉移,但是302轉址主要為"暫時性轉移",用於舊網站進行更新與改版時將頁面內容與權重轉至替代的網站與網址來提供瀏覽服務與維持原有排名及權重,於轉址後舊有網站並不會失去原有的頁面權重和排名,舊網站進行更新與改版後便可以同時取回替代網站所持續經營舊有的頁面權重。302轉址的語法放置在要轉址的頁面文件中,常見語法請參考以下:   HTML 302轉址   <head> <meta http-equiv=refresh content="0;url=http://host.yourdomain.tld/path/to/"> </head>       JavaScript 302轉址   <script language="JavaScript"> <!--   window.location.href = "http://host.yourdomain.tld/path/to/"; //--> </script>       PHP 302轉址   <?php   header("Location: http://host.yourdomain.tld/path/to/"); ?>     ASP 302轉址   <% Response.Redirect("http://www.yourdomain.com") %>  
     瞭解網站轉址與301轉址,在網站經營與維護中,相信大家能瞭解一個用心經營,內容豐富、時常更新資訊的網站來說,網站頁面對搜尋引擎的權重比例越高與排名越好就是一個很好的肯定,而已長期經營的網站來說我們將可能會遇到網站更新甚至改版的狀況,要如何在穩定網站排名且不失去搜尋引擎積分權重下的方式讓我們將網站更進一步的提升呢?這時候就需要用到"網站轉址或301轉址"。       網站轉址的技術層面其實包含非常的廣泛,在此將以本議題的基礎篇301轉址開始介紹起,由單一頁面來說,在開方網頁時應用不同的程式語言,所以撰寫的方式也有些許的不同,舉例來講,我們可以將301轉址的語法放置在要轉址的頁面文件中,常見語法請參考以下:     HTML 301轉址 <meta http-equiv="refresh" content="0;url=http://yuordomain.com" />     PHP 301轉址  <? Header( “HTTP/1.1 301 Moved Permanently" ); Header( “Location: http://yuordomain.com" ); ?>   Javascript 301轉址 <script>document.location.href="http://yuordomain.com";</script>     ASP 301轉址 <%@ Language=VBScript %> <% Response.Status="301 Moved Permanently" Response.AddHeader “Location","http://yuordomain.com/" %>       ASP.NET 301轉址 <script runat="server"> private void Page_Load(object sender, System.EventArgs e) { Response.Status = “301 Moved Permanently"; Response.AddHeader(“Location","http://www.yuordomain.com"); } </script>       JSP 301轉址 <% response.setStatus(301); response.setHeader( “Location", “http://www.yuordomain.com/" ); response.setHeader( “Connection", “close" ); %>
     根據資策會及許多具有公信力的網路平台、廣告公司等,都發表了關於行動裝置在網路中實際測量所佔有流量比例逐年攀升的相關文獻,在眾多數據下的舉證中,我們能明白,使用行動裝置漸漸地已經占據了我們每日生活的一部分,甚至超越了看電視、使用傳統電腦的2至3倍時間。       從使用習慣和數據統計上的改變可以瞭解到,現今人們人手一支的智慧型裝置能隨身、快速、方便的在網路上進行即時通訊、社群網站服務、收發電子郵件、地圖導航、行動搜尋、訂票、遊戲暢遊等等其他功能,其中了也包含了網站的搜尋與瀏覽,先前本站說明了許多關於網頁與智慧裝置配合的"響應式網頁設計(RWD)技術",而本技術便是因應行動裝置的網路使用量超越了傳統桌上型電腦時我們該注意的進步。       經由多方的數據下,我們其實可以清楚的瞭解到行動裝置已經取代傳統桌上型電腦大部分的流量,因此傳統網頁將面臨的考驗便是行動裝置的趨勢,會由使用者、搜尋引擎等使用條件因素開啟新的挑戰。       面對這項全新的挑戰與趨勢,您所設想建置的網站,甚至您目前已經擁有的網站是否能具備了這項優勢呢?這是所有網站擁有者該面臨的問題。關於設計一個具有競爭力符合趨勢的網站或是想闊斧改造傳統頁面都歡迎您與本站諮詢,本站擁有許多創新網站的開發,也服務過許多傳統網站改造,是您值得信賴的平台。    
      PageSpeed(網站速度),面對廣大使用者的使用習慣與青睞性,眾家搜尋引擎越來越重視每個網站的實用內容與流暢性和讀取執行速度,隨著行動裝置的普及化,如今行動裝置瀏覽網站的頻率已經大幅超越傳統桌上型裝置,讓我們瞭解到大多數人在上網時都仰賴著手機或是平板等行動裝置,而在行動裝置上又受限於行動網路的頻寬與傳輸效率未能達到實體線路的穩定性,因此網站的執行讀取速度就成了搜尋引擎SEO重視的依據。         從大眾較常使用的搜尋引擎Google來觀察可以得知,Google針對網站優化SEO推出了許多實用的工具,其中就有針對網站執行速度做測試與建議的PageSpeed Tools工具,透過輸入網站的網址,我們可以經由測速工具來分析網站在面對使用者讀取執行時的友善性,分析方向一開始最大的類別就分成了行動版與電腦版的分類,由此我們可以得知,網站功能是否貼近行動裝置也是一項重大指標,而因應行動裝置瀏覽,網站使用RWD技術較偏向頁面設計技術,可以參考本站什麼是RWD (響應式網頁設計、回應式網頁設計)?文章,在這就不多加闡述。            回到側速工具測驗與建議的項目,其中包含有圖片最佳化、頁面傳送前的壓縮、減少伺服器回應時間、網站版面效果JavaScript與CSS和HTML技術壓縮等條件,在以上這些項目及未列出細項的檢測後,測速工具會針對還有改善空間及通過的檢核項目來告知我們如何改善與維持良好的連線品質。           在網際網路上其實不單只有Google有推出網頁測速工具,還有許多不同的測速工具,而眾多的側速工具開發的目的其實很單純,就是希望能回歸瞭解如何改善網站的執行讀取速度,進而提升使用者與搜尋引擎的青睞與信任,便是SEO的重要基礎之一。        
 Google Tag Manager(標記管理工具),在剛接觸網站行銷或網頁流量控管的人員來說,常會搞不清楚Google Analytics(網站分析)與其的差異,本站先前介紹過"GA分析是什麼? (Google Analytics- Google分析)-看見網站績效",可以透過Google Analytics進行網站的流量統計、分析來瞭解網站的經營績效,而標記管理工具其實就是一個整合網站分析及其他統計功能程式碼的簡易管理介面。   Google在網頁上不僅提供了網站分析的功能,也包含了關鍵字廣告等其他能有效協助我們管理行銷網站的好產品,這些功能產品大多都需要將相關對應的程式代碼植入網站內才能正確的執行或追蹤資訊,當管理人員希望越能完整掌握網站資訊及增加經營績效時,就必須將越多的對應程式碼給植入網站,隨著程式碼的增加,網站被瀏覽器與使用者和搜尋引擎讀取的流量及資訊就顯得逐漸龐大與緩慢。     為了改善管理者不會因為使用了較多的行銷管理工具而造成網站讀取的負擔,Google推出了Tag Manager(標記管理工具),目的除了可以減少以往多次植入或植入錯誤不同程式碼的繁雜步驟,也提供了操作介面,讓我們能在方便快速的狀況下調整網站的行銷工具,最重要是能改善以往瀏覽和收錄頁面時需要的大量讀取多組程式代碼,改由讀取一組Tag Manager代碼便會自動支援帶入其他代碼的優化服務。   透過Google Tag Manager(標記管理工具)造福了管理者以往冗長的代碼植入動作,也能同時整合多項服務功能,減少行銷工具相容性的疑慮,更優化了網站程式讀取的流程,因此使用Google Tag Manager(標記管理工具)將是網站行銷管理的新趨勢。
  早期瀏覽網頁主要是以一般家用電腦或筆記型電腦為主,在製作網頁時會以固定寬度來設計頁面的大小,然而隨著平板電腦與智慧型手機的普及,以及新裝置的出現,響應式網頁設計的觀念被引進,讓網站能夠針對不同裝置的螢幕顯示適合其尺寸的網站內容。   由於新裝置的出現改變了上網的習慣,根據調查顯示,現今約有80%的網路使用者都使用智慧型手機上網,此數據證明行動搜尋超過桌上型搜尋了!     目前Google有近半數的搜尋是透過行動裝置進行,Google宣布改變全球手機版搜尋結果的排序方式-若網站所提供的介面是能夠針對裝置的螢幕作出回應,並且以適合於該螢幕尺寸的方式顯示其網站內容,其被搜尋到的機率將比非行動版的傳統網站更高、排名更前面。在這樣的調整之下,無法針對裝置作出回應的網站曝光率與訪客流量將受到大幅影響,其網站在搜尋結果的排名將大幅下跌。    而為什麼搜尋引擎會對響應式網站(RWD)給予較高的分數?   1.使用單一網址,集中流量,提升排名 響應式網頁設計的好處在於不管是手機還是平板都是使用一樣的網址,集中網站流量,提升搜尋引擎的排名,與手機版網站不同。以Google來說,網址不同但內容相同的情況下,雖不會將該網站列為惡意連結,但仍會影響評價(Page Ranking)。   2.絕佳的瀏覽動線,降低網頁跳出率 若是用手機看一般網站的話,必須放大縮小才能看到自己想要的資訊,很容易造成使用者跳出率增高,進而被認為該網站不是最佳的搜尋效果,排名也會跟著降低。而RWD對於SEO的優勢除了增加流量以外,還降低了網頁的跳出率,不論是哪種螢幕尺寸皆有最佳的瀏覽動線,不會因為瀏覽畫面的不方便而直接跳出。   3.電腦和手機資料同步更新 由於RWD使用的是同一個後台,因此更新時亦會同步更新,而手機版與電腦版因為是不同的後台,因此更新時須更新兩次。若只更新其中一方,如此一來電腦版用戶與手機版用戶所看到的資訊是不同的,也會造成消費者的困擾。