上一篇列了我在挑短網址工具時會確認的幾件事，其中一件是「數字準不準」。我在那裡用一句話帶過，短網址的轉址有 301 和 302 兩種做法，用 301，第二次點的人不會回到服務端，你的計數器就少算了。

這個差別還有另一面，每次要發一條連結出去的時候，你都會遇到一個選擇，這條，我要貼原本的長網址，還是縮一條短的？

多數人大概是這樣決定的，太長、太醜、後面拖著一串參數，就縮網址；本來就短的，直接貼。但這個選擇會影響兩件事：

• 這一頁在 Google 搜尋結果的表現
• 你到底知不知道有多少人點了那條連結

而且這兩件事會往相反的方向拉。要其中一件，就得放掉另一件，沒有兩者兼顧的選項。

決定它的東西，藏在一個平常看不到的地方，你點下去的那一瞬間，短網址服務回了一個狀態碼，301 或 302。這個狀態碼不是你選的，是你用的那家服務選的，而各家選的不一樣。同一個目的地，換一家服務縮短網址，你拿到的東西就不一樣。

你點一條短連結的時候，其實跑了兩趟

那兩件事為什麼會互斥，要從點擊當下發生的事情來解釋。

短網址的服務端不會把目標網頁送到你面前。你的瀏覽器問它「這條連結是什麼」，它只回一句「東西不在我這裡，去那邊拿」，然後就沒它的事了。真正把網頁抓回來的，是瀏覽器自己跑的第二趟。

所以一次點擊會產生兩個請求，第一趟到短網址服務，第二趟到目的地。短網址之所以算得出「這條被點了幾次」，靠的完全是第一趟，每一次點擊都經過它，它才數得到。而這一趟也要花時間，一家短網址服務快不快，差的就是它。

而「東西不在我這裡，去那邊拿」這句話有兩種講法，上一篇文末列過，301 是「以後都去那邊，不用再問我」，302 是「這次去那邊，下次記得再問我一次」。兩種回答決定的是日後還會不會再來問短網址服務。

Google 自己是怎麼說的

Google Search Central 有一頁專門講轉址。它把轉址分成永久與暫時兩種，狀態碼落在哪一種，索引行為就不一樣：

• 永久轉址（301、308）：「Show the new redirect target in search results.」——在搜尋結果顯示轉址後的目的地。
• 暫時轉址（302、303、307）：「Show the source page in search results.」——在搜尋結果顯示原本那一頁。

還有更關鍵的一句，講的是 canonical 訊號：

「Googlebot follows the redirect, but the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical.」
（Googlebot 會跟著轉址走，但索引流程不會把這個轉址當成「目的地才是正版」的訊號。）

—— Google Search Central，Redirects and Google Search

也就是說，你用 302 縮出來的那條短連結，Google 跟著點進去看得到目的地，但它不會把這條短連結累積到的東西歸給目的地。要讓權重過去，轉址得是永久的那種。

這對所有用 302 的短網址服務都成立。302 說的本來就是「這次去那邊，下次記得再問我一次」，Google 只是照這句話辦事。

也有短網址服務回的是 301，權重確實會過去，代價是點擊數。不過你要的如果只是讓某一頁排前面，直接連原網址就好，什麼都不必拿去換。

所以只要這條連結的工作是讓某一頁在搜尋結果排前面——你自己寫的文章、要衝排名的產品頁、投稿到別的網站時放的那條回連——就不要縮它。

另一半：301 會把你的點擊吃掉

反過來，如果你要的是數字，該避開的就是另一個狀態碼。

301 轉址說的是「以後都不用再問我」，而瀏覽器真的會照做。這不是它自作主張，是 HTTP 的快取規格給它的權利，伺服器沒有交代一個回應可以存多久的時候，瀏覽器可以自己決定要不要把 301 記起來。302 則沒有這個待遇。

於是：

• 用 301，連一個快取標頭都不必下，瀏覽器就可以把這條轉址記住。同一個人第二次、第三次點同一條短連結，他的瀏覽器直接跳到目的地，服務端完全不知道這件事發生過。三次點擊，後台顯示一次。
• 用 302，瀏覽器沒有那個權利，每一次點擊都會回到服務端。

所以上一篇那句「第二次點的人不會回到服務端」不是某個瀏覽器的行為，是規格層的必然。短網址服務能決定的只有一開始要回 301 還是 302，回答出去之後就管不到了。

你正在用的那家短網址服務回的是哪一個，可以自己測，用同一台裝置、同一個瀏覽器，把同一條短連結點兩次，然後回後台看那條連結的點擊數。統計多半不是即時更新的，等一下再看，如果只加了一，那家回的就是 301，你的第二次點擊沒有再回到它那裡。

而且 301 影響的還不只是次數。瀏覽器記住的是「這條短連結等於那個目的地」這件事本身，所以你之後在後台把目的地換掉，對已經記住的人是無效的，他的瀏覽器根本不會再來問你。反過來說，印出去的 QR code 之後還能不能換目的地，靠的也是同一件事，每一次掃描都還會回到服務端問一次。

所以問題不是哪個比較好，是這條連結要做什麼工作

把兩半並排：

• 要讓搜尋引擎把權重算給目的地，轉址得是永久的（301）。
• 要算得到每一次點擊、要保留隨時改目的地的權力，轉址就不能被記住（302）。

沒有一個狀態碼能同時做到這兩件事。所以要決定的不是「哪個比較好」，而是這條連結被派去做什麼工作。

我自己替 toui 做行銷的時候有一條規則，寫在內部文件裡，執行了很久，要 SEO 的連結直接連原網址、後面帶 UTM 參數；要算點擊歸因的才作短網址。 你現在看到的這篇文章裡的連結，就是照這條規則放的。

實際分下來大概是這樣：

• 寫在文章裡、投稿到別的網站、放在自己網站上的連結 → 直連原網址，帶 UTM。
• 發在社群、電子報、簡訊，或印在文宣、名片、QR code 上的連結 → 縮短網址。

分界不是「站內站外」，也不是「重不重要」，是這條連結有沒有要幫某一頁累積搜尋排名。有，就別縮網址；沒有，那你能拿到的東西只剩點擊數，那就該用短網址。

那我全部直連＋UTM 不就好了？

我也被問過，但 UTM 算的是「落地」，短連結算的是「點擊」，這兩個不是同一個數字。

UTM 是掛在網址後面的一串參數，它要等人真的到達目的地、目的地那邊的分析工具跑起來，才會被記成一筆。中間網路斷掉、頁面太慢關閉、擋追蹤的瀏覽器把參數清掉，這些情況下那一筆就漏掉了。短連結不一樣，它是在轉址發生的那一刻數的，人只要點了，第一趟就到短網址服務，那一筆就記下來了，跟目的地那邊後來發生什麼事無關。

還有一個更現實的情況，目的地根本不是你的。

你在社群上發一條連向新聞報導、別人家官網、外部活動報名頁的連結，那個網站的分析後台你沒有帳號，看不到。這時候 UTM 對你毫無用處，你放的那串參數是給對方的分析工具看的。想知道自己發出去的東西被點了幾次，只剩短連結這一條路。

只有短連結的數字不必經過別人的後台。

快取放在哪一端，決定數字準不準

短網址服務都在拚的就是這一趟的速度，而讓東西變快最有效的手段就是快取。既然 302 不讓瀏覽器快取，那不就變慢了？

事實上不會，因為快取可以放在別的地方。toui 的做法是在自己這一端快取，不讓瀏覽器快取。

哪個短碼對應到哪個目的地，這份對照放在 Cloudflare 的邊緣節點上，請求進來就近查詢、就近回答，不必每次都問資料庫。所以轉址很快，但每一次點擊仍然是一個真的到達我這裡的請求。快的是回答的速度，不是「你不用來問我」。

同樣一句「用快取讓它變快」，放在瀏覽器那端，是拿你的點擊換速度；放在服務端這端，是速度跟數字都留著。從外面看不出一家服務把快取放在哪一端，但上面那個點兩次的測試會告訴你。

還沒發出去的連結，該用哪一種

兩種轉址的差別，一張圖對得完：

301 和 302 沒有哪一個比較好，它們是兩種不同的工作。網站搬家用 301，你就是要把舊網址的一切都交給新網址，包括搜尋引擎那一份，而且你不希望再收到那些請求。短連結、活動連結用 302，你要的是每一次點擊都算得到，以及目的地隨時改得動。

回到你手上那條還沒發出去的連結，這是長網址與短網址的選用法。要被搜尋引擎算進去的，直接給長網址、後面帶 UTM；要知道被點了幾次的就使用縮短網址。同一檔活動裡兩種連結並存是很正常的事，它們本來就在做不同的工作。

想看看點擊是怎麼被數到的，縮一條、然後自己點幾下，可以把上面那個測試做一遍。