apache/tomcat的JSP對URL重寫的SEO最佳化/次層網域的要點

apache|js|seo|次層網域|最佳化 Apache是用了很長時間，但也只是用了很長時間，要說精通還談不上。所以這四五天存在著補課的味道在裡面：既然公司不能提供好的系統管理員，也只能是自已兼任了。經過對Apache和tomcat結合後的進行SEO最佳化的處理，四五天后，對這幾件工具的基本邏輯架構有了統一的認識。

對URL重寫的瞭解需要是針對這樣的需求：偏向於HTML的SEO搜尋引擎最佳化，以及提供不定量的次層網域便於模組管理和推廣。搜尋引擎不能識雖動態網頁面在技術上是不可能的；我認為最大的可能在於對於靜態hardlink，如果不存在搜尋引擎會得到一個404標識；而對於動態網頁面，反應就不一定了。這樣就不便於搜尋引擎對索引維護和分目。

對Apache mod_rewrite的深入瞭解後，發現在它的文檔和介紹文章中常常缺少幾個關鍵性的導引；而過快地涉及到具體的細節。要理解mod_rewrite的工作，首先是要理解，mod_rewite是針對目錄進行工作的。換言之，每一個目錄的RewriteRule是各自獨立的，每個目錄的重寫既是最高層的容器同時也是最低層的容器，因此，RewriteRule定義的地方是在各個目錄所在的位置，<Directory $dir/> 或者是所在目錄的.htaccess中。

其次，mod_rewrite是缺乏邏輯功能的平面型規則集合，因此每一個目錄設定中都是每一條規則地進行重複性轉換，[L]僅僅是表明一次匹配結束，它還需要重新匹配，直接沒有任何條目與之匹配後才會輸出請求，這樣，如果規則稍多不但效能會直線下降，而且還很容易陷入混亂，所以 mod_rewrite要慎用，使用mod_rewrite來匹配次層網域要小心。對此，mod_rewrite設計者是期望使用Regex匹配，或允許使用者調用perlShell作為複雜匹配邏輯上的應用。但這樣就令開發變得複雜起來了。

由於 mod_rewrite是基於目錄級的，所以它的優先順序低於虛擬機器主機設定；而VirtualHost主機的優先順序也低於 VirtualDocumentRoot的泛虛擬機器主機設定。由於VirtualHost的ServerName基於IP頭的匹配不能使用Regex，因此，使用VirtualDocumentRoot設定多級網域名稱存在著非常大的限制,應用稍微多元化就會面臨著難以克服的衝突。因此，單純使用虛擬機器主機或者是URL 重寫都是不太有效率的，這時侯主要路徑應該是使用html導引，這樣既可以滿足SEO喜歡hardlink的要求，也不會影響到使用者的瀏覽；最重要的是，可以把主要解決方案集中到一個應用程式的範籌，簡化了項目技術，也就降低了項目的成本。

使用mod_rewrite和次層網域的網站基本上使用php大概是基於這樣的原因：會話的一致性維護。當mod_rewrite應用到jsp網站時存在著很大的複雜性。由於mod_rewrite是針對目錄進行的，它必然幹擾到目錄的運作；而jsp的上下文由於根據基礎目錄作為應用程式的判斷的；這樣，在目錄清晰的情況下，jsp在不同的網域名稱和虛擬機器主機下面都能正常識別到所維護的會話，但一旦目錄不齊全，象使用次層網域，無論這個目錄解釋是來源於 URL重寫還是虛擬機器主機設設定，瀏覽器都會把它看作是兩個會話請求，從而造成混亂。因此，在jsp網站使用次層網域，除了使用硬的html串連導引外，別無它法。當然，使用Redirect方式可以解決問題的，表面上，但這樣的話就失去了SEO的意義；而URL重寫本來就是為了SEO而進行的；那麼又何必搞重寫呢？

而且，這種網域名稱/路徑和會話的關係，不同的瀏覽器表現還不一樣。IE僅與上下文路徑相關，而firefox/mozila/netscape卻與網域名稱（次層網域）也有關係。這樣，如果不想引起混亂的話，最好定好改寫的界限，在某處就停下來，僅僅把改寫作為一個入口，而其他，以完整的主網域名稱為主要網域名稱。同時也意味著相對路徑無論對於圖片還是靜態動態檔案都是不可靠的。關於由於路徑變化造成的會話丟失，無論是那一種瀏覽器，都會自動把會話清除掉，從而造成會話的丟失。

綜上所術，在/.htaccess中的URL次層網域重寫，最好還是從一開始就寫成重新導向到標準主機和路徑，這樣可以省卻後面的許多麻煩，同時，對於SEO來說，並不影響蜮名本身受到賦值。