Adobe Experience Manager as a Cloud Service 的 SEO 和 URL 管理最佳作法 seo-and-url-management-best-practices-for-aem

搜尋引擎最佳化 (SEO) 已成為許多行銷人員的重點考量。因此，在許多 Adobe Experience Manager (AEM) as a Cloud Service 專案中，SEO 考量都是需要解決的問題。

本文件首先會說明在 AEM as a Cloud Service 實作中達成上述目標的幾項 SEO 最佳作法與建議。接著，本文件會於第一節中再深入探討幾項更複雜的實作步驟。

SEO 最佳做法 seo-best-practices

本節說明幾項一般 SEO 最佳做法。

URL urls

URL 中有一些公認的最佳做法。

在評估 AEM 專案的 URL 時，請先自問以下問題：

「使用者能在尚未過目任何網頁內容之下，光是看到此 URL 就能描述頁面內容嗎？」

如果答案是可以，則此 URL 在搜尋引擎中很可能成效良好。

以下為幾項針對 SEO 建構 URL 的常見訣竅：

伺服器設定 server-configuration

進行伺服器設定時，您可以執行下列步驟，確保系統只對正確的內容進行編目：

AEM 設定 aem-configurations

本節說明設定 AEM 的所需實作步驟，以便遵循上述 SEO 建議。

使用 Sling 選擇器 using-sling-selectors

過去，業界在建置企業 Web 應用程式時普遍使用查詢參數。

近年來的趨勢是移除這些查詢參數，以便 URL 更具可讀性。在許多平台上，這種趨勢包括在網頁伺服器或內容傳遞網路 (CDN) 上實作重新導向，但 Sling 可讓這項作業變得簡單明瞭。Sling 選擇器：

針對 servlet 使用選擇器 using-selectors-for-servlets

AEM 提供兩種編寫 servlet 的選項：

下列範例說明如何註冊同時符合以下兩種模式的 servlet，以及使用 Sling servlet 所獲的益處。

Bin servlet (向下一個層級) bin-servlets-one-level-down

Bin servlet 符合許多開發人員在 J2EE 程式設計中慣用的模式。Servlet 會註冊於特定路徑，這種情況下 AEM 通常位於 /bin 下，而您必須從查詢字串擷取所需要求參數。

此類 servlet 的 SCR 注釋如下所示：

@SlingServlet(paths = "/bin/myApp/myServlet", extensions = "json", methods = "GET")

您接著會透過 doGet 方法中所包含的 SlingHttpServletRequest 物件從查詢字串中擷取參數；舉例來說：

String myParam = req.getParameter("myParam");

最後產生的所用 URL 如下所示：

https://www.mydomain.com/bin/myApp/myServlet.json?myParam=myValue

採用這種方法需要考量以下幾點：

Sling servlet (向下一個層級) sling-servlets-one-level-down

Sling servlet 可讓您以相反的方式註冊 servlet。您不需要指定 servlet 位址並指定要讓 servlet 根據查詢參數轉譯的內容，僅需指出您想要的內容，並指定應根據 Sling 選擇器轉譯內容的 servlet。

此類 servlet 的 SCR 注釋如下所示：

@SlingServlet(resourceTypes = "myBrand/components/pages/myPageType", selectors = "myRenderer", extensions = "json", methods="GET")

在這種情況下，URL 所處理的資源 (myPageType 資源的執行個體) 可在 servlet 中自動供訪客存取。如要存取該資源，請呼叫：

Resource myPage = req.getResource();

最後產生的所用 URL 如下所示：

https://www.mydomain.com/content/my-brand/my-page.myRenderer.json

此方法的優點包括：

URL 重新寫入 url-rewriting

在 AEM 中，所有網頁都儲存在下方 /content/my-brand/my-content。雖然從存放庫資料管理的角度來看，這樣的設定很實用，但卻未必是您希望客戶看到網站的方式，而且可能與 SEO 指導方針有衝突，不符合盡可能縮短 URL 的原則。此外，您可能會從同一個 AEM 執行個體及不同網域名稱為多個網站供應內容。

本節將說明在 AEM 管理這些 URL 並且以更容易從字面理解的 SEO 建議方法向使用者呈現的可用選項。

虛名 URL vanity-urls

如果作者為了推銷目的而想要讓某個網頁可從第二個位置存取，採用以逐頁方式定義的 AEM 虛名 URL 也許是個好方法。若要新增網頁的虛名 URL，請在​ 網站 ​控制台導覽至該頁面，並編輯頁面屬性。在​ 基本 ​標籤底部，您會看到可新增虛名 URL 的區段。別忘了，如果某個網頁可透過多個 URL 存取，該頁的 SEO 值就會遭到分割，因此您應將標準 URL 標記新增至該頁才能避免此問題。

本地化的網頁名稱 localized-page-names

建議向翻譯內容的使用者顯示本地化的網頁名稱。例如：

本地化網頁名稱時會面對的困難是，許多 AEM 平台上可用的本地化工具都需要不同位置的網頁有相符的名稱，才能讓內容保持同步。

sling:alias 屬性讓您不僅看得到好處，也享用得到。您可以在任何資源中將 sling:alias 新增為屬性，允許資源使用別名。在上一個範例中：

這樣一來，AEM 翻譯工具 (例如多網站管理員) 就能繼續維護以下兩者的關聯性：

同時允許使用者以自己的原生語言與網頁名稱互動。

/etc/map etc-map

在標準的 AEM 配置中：

您可以在此位置新增對應定義，以便對應傳入要求、重新寫入 AEM 中的網頁 URL，或兩者皆執行。

如要建立對應，則在此位置的 sling:Mapping 或 /http 之下建立 /https 節點。AEM 會根據設定在此節點上的 sling:match 和 sling:internalRedirect 屬性，將相符 URL 的所有流量重新導向至在 internalRedirect 屬性指定的值。

雖然上述方法已記錄在官方 AEM 和 Sling 文件中，但與直接使用 SlingResourceResolver 時的可用選項相比，這種實作方法支援的規則運算式卻範圍有限。此外，以這種方式實作對應可能會導致 Dispatcher 快取失效的問題。

以下是此問題發生的例子：

有些方法可以設定自訂發送排清規則，針對快取失效將較短的 URL 對應至較長的 URL。

不過，另外也有更簡單的方法可用於管理這個問題：

Apache HTTP Server mod_rewrite apache-http-server-mod-rewrite

至此，您已與元件中的邏輯一併實作完成對應，以便在將 URL 輸出至頁面時使用這些對應。

最後一個步驟，就是在這些縮短的 URL 進入 mod_rewrite 會發揮作用的 Dispatcher 時處理這些 URL。使用 mod_rewrite 的最大優點，就是 URL 在傳送到 Dispatcher 模組​ 之前 ​會先重新對應到原本的較長格式。也就是說，Dispatcher 會從發佈伺服器要求長 URL 並加以進行快取。因此，任何來自發佈伺服器的 Dispatcher 排清都可以成功使該內容無效。

要實作這些規則，您可以在 Apache HTTP 伺服器設定的虛擬主機下新增 RewriteRule 元素。如果您想要拉長上個範例中縮短的 URL，則可實作如下規則：

<VirtualHost *:80>
  ServerName www.mydomain.com
  RewriteEngine on
  RewriteRule ^/(.*)$ /content/my-brand/$1 [PT,L]
  …
</VirtualHost>

標準 URL 標記 canonical-url-tags

標準 URL 標記是放置在 HTML 文件開頭的連結標記，可釐清搜尋引擎在建立內容索引時應如何處理網頁。它們可帶來的好處是，即使連向網頁的 URL 可能有些差異，也可確保系統對其他版本的網頁建立相同索引。

舉例來說，如果網站想要提供適合列印的網頁版本，搜尋引擎可能會對此版本與一般版本分開建立索引。但標準標記會告訴搜尋引擎兩者是相同版本。

範例：

兩者都會在網頁開頭套用下列標籤：

<link rel="canonical" href="my-brand/my-page.html"/>

href 可以是相對或絕對的值。程式碼應包含在網頁標記中，以便判斷網頁的標準 URL 並輸出此標籤。

將 Dispatcher 設定為不區分大小寫 configuring-the-dispatcher-for-case-insensitivity

使用小寫字母來提供所有網頁是建議的最佳作法。但是，您也不應讓使用者在 URL 中輸入大寫字母來存取網站時，收到 404 錯誤訊息。因此，Adobe 建議您在 Apache HTTP 伺服器設定中新增重新寫入規則，以便將所有傳入的 URL 對應至小寫。此外，內容作者必須接受訓練以小寫名稱建立網頁。

如要設定 Apache 以強制所有轉入流量都轉換為小寫，請將以下內容新增到 vhost 設定中：

RewriteEngine On
RewriteMap lowercase int:tolower

此外，將下列內容新增至 htaccess 檔案的最上方：

RewriteCond $1 [A-Z]
RewriteRule ^(.*)$ /${lowercase:$1} [R=301,L]

實作 robots.txt 以保護開發環境 implementing-robots-txt-to-protect-development-environments

搜尋引擎在對網站進行編目之前，必須 ​先檢查網站根中是否有 robots.txt 檔案。雖然 Google、Yahoo 或 Bing 等主流搜尋引擎都會這麼做，但有些外國搜尋引擎卻並不如此。

封鎖使用者存取整個網站的最簡單方式，是將名為 robots.txt 的檔案置於網站根中，且含有以下內容：

User-agent: *
Disallow: /

或者，您可以在即時環境中選擇不允許某些不希望建立索引的路徑。

將 robots.txt 檔案置於網站根時應注意，Dispatcher 排清要求可能會清除此檔案，且 URL 對應可能會將網站根置於與 Apache HTTP 伺服器設定中已定義的 DOCROOT 不同之處。因此，常見的方式是將此檔案放置在網站根目的編寫執行個體上，並複製到發佈執行個體。

在 AEM 上建置 XML Sitemap building-an-xml-sitemap-on-aem

編目程式可透過 XML Sitemap 加強瞭解網站的結構。雖然提供 Sitemap 並不保證可改善 SEO 排名，但這是一項普遍採用的最佳做法。您可以手動在網頁伺服器上維護 XML 檔案，以便將它當作 Sitemap 使用，但建議以程式設計方式產生 Sitemap，確保當作者建立內容時，Sitemap 會自動反映變更。

AEM 使用 Apache Sling Sitemap 模組產生 XML Sitemap，這為開發人員和編輯人員提供了廣泛的選項，使網站 XML Sitemap 保持最新。

Apache Sling Sitemap 模組會區分頂層 Sitemap 和巢狀 Sitemap，這兩者都是為將 sling:sitemapRoot 屬性設為 true 的任何資源產生的。通常，Sitemap 是使用樹狀頂層 Sitemap 路徑上的選擇器呈現的，這是沒有其他 Sitemap 根上階的資源。此頂層 Sitemap 根也會公開了 Sitemap 索引，這通常是網站所有者在搜索引擎的設定入口網站中設定，或新增到網站的 robots.txt 的 Sitemap 索引。

例如，假設有一個網站，將頂層 Sitemap 根定義在 my-page，將巢狀 Sitemap 根定義在 my-page/news，為新聞子樹狀結構中的頁面產生專用 Sitemap。由此產生的相關 URL 將是

在預設設定中，頁面屬性對話框提供了一個選項來將頁面標記為 Sitemap 根，因此，如上所述，產生它本身 Sitemap 和其子系。此行為由 SitemapGenerator 的實作來實作，並且可以透過新增替代實作來擴展。但是，由於重新產生 XML Sitemap 的頻率高度依賴內容編寫工作流程和工作負載，因此該產品不提供任何 SitemapScheduler 設定。這使得該功能有效率地選擇加入。

為了啟用產生 XML Sitemap 的背景作業，必須設定 SitemapScheduler。若要這麼做，請為 PID org.apache.sling.sitemap.impl.SitemapScheduler 建立 OSGI 設定。排程器運算式 0 0 0 * * ? 可作為每天午夜一次重新產生所有 XML Sitemap 的起點。

Sitemap 產生工作可以在編寫層和發佈層執行個體上執行。在大多數情況下，建議在發佈層執行個體上執行產生工作，因為只能在那裡產成標準 URL (由於 Sling 資源對應規則通常僅存在於發佈層執行個體上)。但是，可以透過實作 SitemapLinkExternalizer 執行個體來插入用於產生標準 URL 的具體化機制的自訂實作。如果自訂實作可以在編寫層執行個體上產生 Sitemap 標準 URL，可以針對作者執行模式設定 SitemapScheduler，XML Sitemap 產生工作負載可以分配給編寫服務叢集的多個執行個體。在這種情況下，必須特別注意處理尚未發佈、已修改或只有一組受限的使用者可見的內容。

AEM Sites 包含 SitemapGenerator 的預設實作，它周遊頁面樹以產生 Sitemap。它被預先設定為僅輸出網站的標準 URL 和任何可用的語言替代選項。如果需要，也可設定為包含頁面的上次修改日期。為此，啟用​ Adobe AEM SEO - 頁面樹 Sitemap 產生器 ​設定的​ 新增上次修改日期，並選取​ 上次修改的來源。在發佈層產生 Sitemap 時，建議使用 cq:lastModified 日期。

若要限制 Sitemap 的內容，可以在需要時實作以下服務介面：

如果預設實作在特定使用案例無法作用或者擴充點不夠靈活，則可以實作自訂 SitemapGenerator 以完全控制產生之 Sitemap 的內容。以下範例展示如何使用 AEM Sites 的預設實作邏輯來完成此操作。它使用 ResourceTreeSitemapGenerator 作為周遊頁面樹的起點：

import java.util.Optional;

import org.apache.sling.api.resource.Resource;
import org.apache.sling.sitemap.SitemapException;
import org.apache.sling.sitemap.builder.Sitemap;
import org.apache.sling.sitemap.builder.Url;
import org.apache.sling.sitemap.spi.common.SitemapLinkExternalizer;
import org.apache.sling.sitemap.spi.generator.ResourceTreeSitemapGenerator;
import org.apache.sling.sitemap.spi.generator.SitemapGenerator;
import org.jetbrains.annotations.NotNull;
import org.osgi.service.component.annotations.Component;
import org.osgi.service.component.annotations.Reference;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import com.adobe.aem.wcm.seo.sitemap.PageTreeSitemapGenerator;
import com.day.cq.wcm.api.Page;

@Component(
    service = SitemapGenerator.class,
    property = { "service.ranking:Integer=20" }
)
public class SitemapGeneratorImpl extends ResourceTreeSitemapGenerator {

    private static final Logger LOG = LoggerFactory.getLogger(SitemapGeneratorImpl.class);

    @Reference
    private SitemapLinkExternalizer externalizer;
    @Reference
    private PageTreeSitemapGenerator defaultGenerator;

    @Override
    protected void addResource(@NotNull String name, @NotNull Sitemap sitemap, Resource resource) throws SitemapException {
        Page page = resource.adaptTo(Page.class);
        if (page == null) {
            LOG.debug("Skipping resource at {}: not a page", resource.getPath());
            return;
        }
        String location = externalizer.externalize(resource);
        Url url = sitemap.addUrl(location + ".html");
        // add any additional content to the Url like lastmod, change frequency, and so on
    }

    @Override
    protected final boolean shouldFollow(@NotNull Resource resource) {
        return super.shouldFollow(resource)
            && Optional.ofNullable(resource.adaptTo(Page.class)).map(this::shouldFollow).orElse(Boolean.TRUE);
    }

    private boolean shouldFollow(Page page) {
        // add additional conditions to stop traversing some pages
        return !defaultGenerator.isProtected(page);
    }

    @Override
    protected final boolean shouldInclude(@NotNull Resource resource) {
        return super.shouldInclude(resource)
            && Optional.ofNullable(resource.adaptTo(Page.class)).map(this::shouldInclude).orElse(Boolean.FALSE);
    }

    private boolean shouldInclude(Page page) {
        // add additional conditions to stop including some pages
        return defaultGenerator.isPublished(page)
            && !defaultGenerator.isNoIndex(page)
            && !defaultGenerator.isRedirect(page)
            && !defaultGenerator.isProtected(page);
    }
}

此外，為 XML Sitemap 實作的功能也可以用於不同的使用案例，例如將標準連結或語言替代項新增到頁面的頁首。如需詳細資訊，請參閱 SEO 標記介面。

為舊版 URL 建立 301 重新導向 creating-redirects-for-legacy-urls

以新結構啟動網站時，務必在 Apache HTTP 伺服器中實作並測試 301 重新導向，理由有二：

請務必參閱下方的其他資源章節，瞭解實作 301 重新導向的操作指示，並以工具測試重新導向是否如期運作。

其他資源 additional-resources

如需詳細資訊，請參閱下列其他資源：