透過集合功能整理內容
你可以依據偏好儲存及分類內容。
將 Google 搜尋中的 A/B 測試影響降到最低
本頁說明該如何在測試不同版本的網頁內容或網址時，盡量減少對 Google 搜尋排名造成的影響。本文不提供建立或設計測試的操作說明，不過您可以在本頁底部查看更多測試相關資源。
測試作業總覽
所謂的網站測試，就是要嘗試推出網站的不同版本 (或網站的一部分)，然後收集使用者對各版本反應的資料。
-
A/B 測試可以針對同一項變更內容，測試兩種以上的不同版本。舉例來說，您可以在同個按鈕上測試不同字型，看看是否能提高按鈕的點擊次數。
-
多變數測試能夠一次測試多種變更，以及瞭解各項變更可能的影響，以及不同變更之間相互配合的可能。舉例來說，您可能想在某個按鈕上試用多種字型，同時試著變更 (或不變更) 網頁其他部分的字型，藉此瞭解新字型是否易於閱讀，以及是否應擴大運用到所有文字？或者瞭解當按鈕字型與網頁的其他部分看起來不同時，是否有助於吸引目光？
您可以使用軟體來比較不同版本網頁 (或者比較網頁的一部分、整個網頁或多網頁的整體流程) 中的使用者行為，並追蹤哪個版本對使用者最有效。
進行測試時，您可以為單一網頁建立多個版本，並讓每個版本都有各自的網址。
當使用者嘗試存取原始網址時，您將部分使用者重新導向至各變化版本的網址，然後比較使用者的行為，判斷哪個網頁版本成效最佳。
您也可以在網頁上動態插入變化版本，這樣無須變更網址也能進行測試。採用這種做法時，您可以使用 JavaScript 來決定要顯示哪個變化版本。
依測試內容類型而定，Google 甚至可以在您測試期間檢索部分內容的變化版本或建立索引，而不會造成明顯影響。只是微幅調整按鈕、圖片或「行動號召」文字 (例如「加入購物車」和「立即購買！」) 等元素的大小、顏色或擺放位置，就可能會讓使用者與網頁互動的方式有出人意料的變化，但對搜尋結果摘要或排名的影響不大，甚至毫無影響。
此外，如果我們檢索網站的頻率足以偵測到您的測試內容並建立索引，結束實驗後，系統可能很快就會將網站最終更新版本編入索引。
測試期間的最佳做法
您可以參考以下列出的最佳做法，避免在測試不同版本的過程中，對網站在 Google 搜尋中的呈現方式造成負面影響：
不要偽裝測試網頁
請勿對 Googlebot 和使用者顯示不同的網址組。這種行為稱為偽裝，已違反垃圾內容政策，無論您是否在執行測試都不可使用。提醒您，違反垃圾內容政策可能導致網站在搜尋結果中遭到降級或移除，這恐怕不是您想看到的測試結果。
無論是利用伺服器邏輯、robots.txt 還是其他方法，只要涉及偽裝行為就不可行，
請改用後續介紹的連結方式或重新導向。
如果您使用 Cookie 來控制測試，請記得，Googlebot 通常不支援 Cookie。這表示，Googlebot 看到的內容，只會是使用者的瀏覽器不支援 Cookie 時所能存取的版本。
使用 rel="canonical" 連結
如果您運用多個網址進行測試，可以在所有替代網址上使用 rel="canonical" 連結屬性，指明原始網址為偏好版本。我們之所以建議使用 rel="canonical" 而不是 noindex meta 標記，是因為前者更有助於達成測試目的。舉例來說，在測試首頁的不同版本時，您不是要避免搜尋引擎將首頁編入索引，只是想讓搜尋引擎瞭解所有測試網址都非常類似原始網址，或者只是變化版本，因此該歸納為同一組，並以原始網址為標準版本。在這種情況下，使用 noindex 可能會帶來不可預期的負面影響，因此建議使用 rel="canonical"。
使用 302 重新導向，而非 301 重新導向
如果您進行的測試會將使用者從來源網址重新導向至其他版本的網址，請使用 302 (temporary) 重新導向，而非 301 (permanent) 重新導向。這樣一來，搜尋引擎就會知道這只是測試期間的暫時性重新導向，應該將本來的網址保留在索引中，不要替換成重新導向目標的測試網頁。您也可以使用 JavaScript 進行重新導向，不會造成違規。
在收集足夠資料後結束測試
取得可信測試結果所需要的時間會因各種條件而異，例如您的轉換率，還有網站獲得的流量多寡；一款優質的測試工具會在收集的資料足以做出可信結論時通知您。測試完成後，請以最滿意的內容版本更新您的網站，並盡快移除所有測試元素，包括替代網址、測試版指令碼和標記。如果發現網站的測試時間過長，我們可能會認為這是有意欺騙搜尋引擎，並據此採取相應行動。如果您將其中一個內容版本提供給相當高比例的使用者，我們更有可能判定為這種情況。
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2025-08-04 (世界標準時間)。
[null,null,["上次更新時間：2025-08-04 (世界標準時間)。"],[[["\u003cp\u003eWebsite testing involves comparing different versions of a website or page to see how users react.\u003c/p\u003e\n"],["\u003cp\u003eTo minimize search impact during testing, use \u003ccode\u003erel="canonical"\u003c/code\u003e for alternate URLs, 302 redirects for temporary variations, and avoid cloaking.\u003c/p\u003e\n"],["\u003cp\u003eConclude tests promptly after gathering sufficient data and update your site with the winning variation to prevent potential search engine penalties.\u003c/p\u003e\n"],["\u003cp\u003eWhile testing can impact Google Search results, following best practices ensures minimal disruption and accurate indexing.\u003c/p\u003e\n"]]],["To minimize the impact of A/B testing on Google Search, avoid cloaking and use `rel=\"canonical\"` links on alternate URLs to indicate the original as preferred. Employ `302` redirects for temporary URL variations instead of `301`. Run tests only as long as necessary and promptly remove testing elements afterward. Small content variations generally don't significantly affect search performance. If tests run excessively, Google may consider it deceptive.\n"],null,["# A/B Testing Best Practices for Search | Google Search Central\n\nMinimize A/B testing impact in Google Search\n============================================\n\n\nThis page covers how to ensure that testing variations in page content or page URLs has\nminimal impact on your Google Search performance. It does not give instructions on how to\nbuild or design tests, but you can find more resources about testing at the end of this page.\n\nOverview of testing\n-------------------\n\n\nWebsite testing is when you try out different versions of your website (or a part of your\nwebsite) and collect data about how users react to each version.\n\n- **A/B testing** is where you test two (or more) variations of a change. For example, you may test different fonts on a button to see if you can increase button clicks.\n- **Multivariate testing** is where you test more than one type of change at a time, looking for the impact of each change as well as potential synergies between the changes. For example, you might try several fonts for a button, but also try changing (and not changing) the font of the rest of the page at the same time. Is a new font easier to read and so should be used everywhere? Or is the benefit that the button font looks different to the rest of the page, helping it draw attention?\n\n\nYou can use software to compare behavior with different variations of your pages\n(parts of a page, entire pages, or entire multi-page flows), and track which version is most\neffective with your users.\n\n\nYou can run tests by creating multiple versions of a page, each with its own URL.\nWhen users try to access the original URL, you redirect some of them to\neach of the variation URLs and then compare users' behavior to see which page is most\neffective.\n\n\nYou can also run tests without changing the URL by inserting variations dynamically on the\npage. You can use JavaScript to decide which variation to display.\n\n\nDepending on what types of content you're testing, it may not even matter much if Google\ncrawls or indexes some of your content variations while you're testing. Small changes, such as\nthe size, color, or placement of a button or image, or the text of your \"call to action\" (\"Add\nto cart\" vs. \"Buy now!\"), can have a surprising impact on users' interactions with your page,\nbut often have little or no impact on that page's search result snippet or ranking.\n\n\nIn addition, if we crawl your site often enough to detect and index your experiment, we'll\nprobably index the eventual updates you make to your site fairly quickly after you've\nconcluded the experiment.\n\nBest practices when testing\n---------------------------\n\n\nHere is a list of best practices to avoid any bad effects on your Google Search behavior while\ntesting site variations:\n\n### Don't cloak your test pages\n\n\nDon't show one set of URLs to Googlebot, and a different set to humans. This is called\n[cloaking](/search/docs/essentials/spam-policies#cloaking),\nand is against our\n[spam policies](/search/docs/essentials/spam-policies),\nwhether you're running a test or not. Remember that infringing our spam policies can get your\nsite demoted or removed from Google search results---probably not the desired outcome of your\ntest.\n\n\nCloaking counts whether you do it by server logic or by robots.txt, or any other method.\nInstead, use links or redirects as described next.\n\n\nIf you're using cookies to control the test, keep in mind that Googlebot generally doesn't\nsupport cookies. This means it will only see the content version that's accessible to users\nwith browsers that don't accept cookies.\n\n### Use `rel=\"canonical\"` links\n\n\nIf you're running a test with multiple URLs, you can use the\n[`rel=\"canonical\"` link attribute](https://support.google.com/webmasters/answer/139394)\non all of your alternate URLs to indicate that the original URL is the preferred version. We\nrecommend using `rel=\"canonical\"` rather than a `noindex` `meta` tag\nbecause it more closely matches your intent in this situation. For instance, if you are\ntesting variations of your home page, you don't want search engines not to index your\nhome page; you just want them to understand that all the test URLs are close duplicates or\nvariations on the original URL and should be grouped together, with the original URL as the\ncanonical. Using `noindex` rather than `rel=\"canonical\"` in such a\nsituation can sometimes have unexpected bad effects.\n\n### Use `302` redirects, not `301` redirects\n\n\nIf you're running a test that redirects users from the original URL to a variation URL,\nuse a [`302 (temporary)` redirect](/search/docs/crawling-indexing/301-redirects#temporary),\nnot a `301 (permanent)` redirect. This tells search engines that\nthis redirect is temporary---it will only be in place as long as you're running the experiment---\nand that they should keep the original URL in their index rather than replacing it with the\ntarget of the redirect (the test page).\n[JavaScript-based redirects](/search/docs/crawling-indexing/301-redirects#jslocation)\nare also fine.\n\n### Run the experiment only as long as necessary\n\n\nThe amount of time required for a reliable test will vary depending on factors like your\nconversion rates, and how much traffic your website gets; a good testing tool tells you\nwhen you've gathered enough data to draw a reliable conclusion. Once you've concluded the\ntest, update your site with the desired content variation(s) and remove all\nelements of the test as soon as possible, such as alternate URLs or testing scripts and\nmarkup. If we discover a site running an experiment for an unnecessarily long time, we may\ninterpret this as an attempt to deceive search engines and take action accordingly. This is\nespecially true if you're serving one content variant to a large percentage of your users.\n\nMore information about testing\n------------------------------\n\n- [Google Analytics article](https://support.google.com/analytics/answer/9366791) on content experiments\n- [Google Analytics content testing tools](https://marketingplatform.google.com/about/analytics/)\n- Ask questions about testing on the [Analytics Help Forum](https://support.google.com/analytics/community)\n- Ask questions about impact on search results in the [Google Search Central Help Forum](https://support.google.com/webmasters/community)."]]
