Search Console 權限設定教學：三級權限、廠商開通與存取權回收

Search Console 的權限要開多大，答案可以先給：只看報表的人給「受限」，要動手做事的人給「完整」，只有需要管理這個資源本身、包含決定誰能進來的人，才給「擁有者」。實際的協作場景裡，外部 SEO 廠商多半到「完整」就夠了，擁有者應該留給公司內部真正對網站負責的人。把這個判斷先記住，後面所有的操作細節都圍繞著它展開。

動手設定前，還有三件事會直接影響結果。權限是掛在「資源」上的，你開哪個資源，對方就只看得到那個範圍的資料，範圍給錯，後面做什麼都白工。能夠進到「設定＞使用者和權限」管理名單的只有擁有者，所以新增使用者這件事，一開始就得由對的人來做。每個資源至少要保留一位已驗證擁有者，這個位置空掉，其餘使用者會在一段寬限期後失去存取權，等於整個資源被鎖上。理解這三條邊界，比記住任何按鈕位置都重要。

介面用詞與流程，以 Google 官方的使用者與權限說明頁在 2026 年 10 月的內容為準，官方的繁中用語是「擁有完整權限的使用者」與「權限受限的使用者」，介面選單裡顯示為「完整」與「受限」，有些教學寫成「限制」，指的是同一級。下文先釐清資源與權限的結構，再說明新增使用者、排除狀況與回收存取權的實際操作。

權限掛在資源上：先確認你開的是哪一個範圍

Search Console 裡的「資源」是權限的基本單位，它定義了資料被收集與檢視的邊界。常見的兩種網站資源，範圍差很多。網域資源以整個網域為單位，涵蓋所有子網域與多種通訊協定，m.、www.、http、https 都算在裡面；網址前置字元資源則只包含你指定的前綴，協定或 www 有一個字不同，就是另一個資源。Google 的資源類型說明給了一個直觀的對照：網域資源 example.com 會收進 http://www.example.com/ 與 https://support.m.example.com/ 這類網址，而網址前置字元資源只收完全符合前綴的頁面。

這個差別直接決定開權限的對象會看到什麼。你把 https://www.example.com/ 這個網址前置字元資源開給同事，而公司實際的主力站流量在 example.com 的網域資源裡，對方登入後看到的就是一份資料不全的報表，再怎麼疑神疑鬼檢查帳號也找不到原因。交接前先打開資源選取器，核對畫面左上角顯示的資源名稱，與對方要分析的範圍一致，才繼續往下做。多網域、多語系或前後台分離的網站，常常同時存在好幾個資源，這個核對動作別省。

資源與帳號之間也有數量界線。一個 Search Console 帳戶最多可以管理 1,000 個資源，對多品牌、多子網域經營的團隊來說，這個數字提醒了一件事：與其讓每個子網域各自為政，不如用網域資源統一管理，再依團隊分工去開權限。網站還沒完成驗證的話，先把安裝與驗證流程走完，驗證是擁有權的證明，沒有它，連談權限分配的資格都沒有。

兩種資源在治理上的含意也不一樣。自行架設的網站，網域資源須以 DNS 記錄驗證，只有網站放在 Blogger、Google 協作平台等 Google 代管平台時例外，鑰匙多半握在管 DNS 的人手上，控制權集中，但這個人離職時的交接就格外關鍵；網址前置字元資源的驗證方法多，HTML 檔案、meta 標記、Google Analytics、代碼管理工具都能用，門票的種類多，殘留的風險也跟著分散。選擇資源類型時，除了資料範圍，把「將來要怎麼收回這些驗證」一起想進去，配置才走得遠。附帶一提，Search Console 也支援平台資源，給在 YouTube、Instagram 這類平台經營的創作者追蹤成效，官方註明這項功能正逐步推出、部分使用者可能還無法使用，驗證可透過現有網站資源自動連結或直接登入平台完成，本文聚焦網站資源的權限管理，平台資源不展開。

還有一種結構值得單獨認識：上層資源與子資源的繼承關係。網域資源之於其下的子網域前置字元資源，就是父與子的關係。擁有上層資源擁有權的人，自然具備子資源的擁有者身分，這個設計稍後在新增使用者的段落會回來咬人，先記住有這層結構存在。

三級權限的真實差異：從官方對照表挑出關鍵幾行

官方說明頁附了一張功能對照表，逐項列出三種權限等級各能做什麼。整張表很長，實務上真正會影響判斷的是表中這幾行。

↔ 左右捲動檢視完整表格

功能	擁有者	完整	受限
新增／移除使用者與擁有者	可以	不能	不能
提交 Sitemap	可以	可以	不能
網址檢查	完整功能	完整功能	只能擷取資訊
驗證修正結果、提出重審要求	可以	可以	不能
移除網址、資源設定（檢索頻率）、Merchant Center 連結	完整操作	完整操作	僅供檢視
連結 Google Analytics 帳戶	可以	不能	不能
成效報表、查看所有報表	可以	可以	可以
分享報表連結	可以	可以	不能
接收郵件通知	可以	可以	僅與自身相關的實質訊息

幾個容易被看漏的細節，往往就是日後摩擦的來源。受限權限看得到成效報表，也能查看所有報表，所以「只出月報」的需求它完全勝任。留意官方對這一級的定義是「大多數資料的簡易檢視」，完整權限才明載「查看所有資料」，兩者在資料視野上的差距官方文字並未抹平，不過實務上最容易卡住協作的差別，仍在做不做得了動作。但它不能提交 Sitemap、不能要求索引、不能驗證修正結果，一旦對方的工作內容從看報表變成修網站，這個等級就會綁手綁腳。網址檢查工具對受限使用者開放的是「只能擷取」，能查單一網址的狀態，卻按不下要求索引那個動作。郵件通知那一欄有個但書：受限使用者只會收到對自己有實質影響的訊息，所以團隊裡最重要的索引異常或人工判決通知，不要指望受限帳號會看到，那個責任在擁有者身上。

對照表之外，有一個觀念能避免大部分的誤配：權限等級決定的是「能做什麼」，資料的範圍則由資源本身決定。受限使用者打開的是同一批報表，成效、連結、索引涵蓋範圍都看得到，官方只是以「大多數資料的簡易檢視」定義這一級，並未保證與完整權限逐欄相同。所以「給低權限怕對方看不懂報表」的顧慮大可放下，真正該問的是對方要不要動手做事。把這兩個變數拆開看，等級的選擇就單純了：範圍問題回資源層解決，能力問題才回權限層解決。

「完整」與「擁有者」的界線，畫在使用者管理、執行變更網址與連結 Google Analytics 帳戶這幾件事上。完整權限可以執行絕大多數 SEO 操作，包含提交 Sitemap、驗證修正結果、提出重審要求，也能使用封鎖網址的工具、要求暫時移除特定網址，資源設定裡的檢索頻率也調得動，但不能新增或移除任何人，不能連結 Google Analytics 帳戶，執行變更網址對它也只開放檢視。反過來說，公司內部只要有一兩位擁有者負責管名單與設定，其餘協作者全用完整或受限，這種金字塔結構是值得優先考慮的配置。真要發生誤刪使用者、誤改設定的狀況，能犯那個錯的人越少，災情越可控。

官方文件還定義了第四種身分：相關聯使用者。這是給特定夥伴服務使用的，例如 Chrome 線上應用程式商店的開發者帳號連結，它不代表對方能打開你的 Search Console 看資料，能做什麼取決於關聯類型。一般網站團隊不太會碰到，知道有這個分類、別把它跟三種權限等級混為一談即可。

給同事或 SEO 廠商：用「對方要做的事」反推權限等級

選權限級別有一個好用的思考順序：先寫下對方在這個資源上要執行的具體動作，再回頭對照表格。動作清單裡全是「看」，給受限；出現「提交」「驗證」「要求」，給完整；出現「管理使用者」「變更網址」「連結 Analytics」，才動用擁有者。下表把幾種常見的協作對象直接對應進去，可以當快速查答用。

↔ 左右捲動檢視完整表格

協作對象	典型動作	建議等級	判斷理由
老闆或客戶	看月報、追蹤成效趨勢	受限	只需讀取報表，無須任何操作權
內部行銷同事	分析報表並執行優化	完整	需要提交 Sitemap、驗證修正結果
外部 SEO 顧問	診斷、建議並執行修正	完整	操作需求與內部同事相同
接手代管的廠商	全面管理網站搜尋事務	委派擁有者	需要管理使用者等擁有者功能，但權杖仍留在我方
內部技術負責人	管網站與 DNS，對資源負全責	已驗證擁有者	握有驗證權杖，資源的最終保險

前兩種情境不需要多解釋，後面三種各有值得展開的判斷。給外部顧問完整權限時，契約裡講好交付什麼報表、動到哪些設定要先報備，權限等級配合契約走，治理才有依據。代管型廠商確實會碰到需要擁有者等級的時刻，例如管理使用者或連結 Analytics，委派擁有者讓他做到擁有者能做的一切，但身分是我方授予的，隨時可收回，比起教對方自己驗證一組權杖，主動權留在自己手上。已驗證擁有者則是整個資源的錨，人數不用多，一兩位足以，重點是這個人能完成其中一種適用的驗證方式，HTML 檔案、meta 標記、DNS 之外，Google Analytics 或代碼管理工具的服務權限也能當鑰匙，權杖甚至可由他人代放，關鍵是相關權杖與驗證服務的權限最終掌握在公司手裡。

一個容易被輕忽的通則：不要開共用帳號，更不要把自己帳號的密碼交給廠商。每個人用自己公司的 Google 帳號進來，名單上每個身分都對得到特定的人，出事的時候對照現有名單有帳可查，帳號交接的時候也才有明確的切入點。密碼共用把「人」這個可管理的單位直接抹掉，是權限治理裡最不划算的捷徑。

有一類「使用者」特別容易漏掉：自動化與 AI 工具用的服務帳號。把 Search Console 的資料接進腳本、儀表板或 AI 助理時，站上既有的串接教學採服務帳號方式：建立服務帳號，把它的電子郵件當成一位使用者加進資源，唯讀的伺服器給受限，部分要求完整權限的伺服器才開完整，實際等級依各工具文件的說明為準。它會跟真人一起出現在使用者清單裡，離職交接或廠商輪替時，記得這些機器身分也要一併清點，詳細的接線步驟可以參考站上把 Search Console 接給 AI 工具的服務帳號設定。

擁有者的兩種身分：已驗證與委派，權限相同、命運不同

擁有者看似是最高等級，實際上內部分成兩種身分，權限一模一樣，移除的方式卻天差地遠。已驗證擁有者靠「驗證權杖」證明自己擁有這個網站，權杖的形式包含上傳到網站根目錄的 HTML 檔案、埋在首頁原始碼的 meta 標記、網域供應商那裡的 DNS 記錄，以及透過 Google Analytics 或 Google 代碼管理工具的帳號權限自動驗證。委派擁有者則沒有自己的權杖，身分完全來自現有擁有者在介面裡的授予。

這套設計背後的邏輯值得想通：Google 判斷擁有權的方式，是看驗證權杖能不能放到網站的某個關鍵位置，根目錄的檔案、網域的 DNS 記錄、Google Analytics 的帳號設定都在此列；權杖也可以由他人代放，所以真正要追的不是誰的手放上去，而是權杖與這些位置的權限最終由誰掌握。即使網站或 DNS 的管理權後來交回公司，只要對方個人的驗證權杖仍留在驗證位置，他走重新驗證這條路的資格就還在，這也是權杖清理為什麼不能只做半套的原因；對方若仍保有寫入驗證位置的存取權，那項權限也要一併收回，否則 Google 隨時會再次承認他。

這個差別在平常看不出來，在移除的時候全面爆發。移除一位委派擁有者，在清單上按掉就結束；移除一位已驗證擁有者，等於只刪掉他在清單上的名字，他留在網站上的權杖還在，只要權杖不被清除，他隨時可以重新驗證、把存取權拿回來。所以「合作結束把對方移除」這件事，對委派擁有者是句號，對已驗證擁有者只是逗號，後面的權杖清理才是真正的收尾。

另一個結構性的規則：已驗證擁有者不能被降級。在清單上對一位已驗證擁有者按「變更權限」，選項會是停用的，官方的設計是你只能移除他，無法把他降到完整或受限。反過來，一般使用者與委派擁有者的等級隨時可以調整。每個資源還必須永遠保有至少一位已驗證擁有者，這個位置一空，其餘使用者會在寬限期後被鎖在門外，所以永遠先確保公司自己的人握有驗證權杖，再考慮發權限給外人。

人數上限是規劃大型團隊時的硬約束。完整、受限與相關聯使用者加起來，每個資源最多 100 位；委派擁有者可以一直加，直到已驗證與委派擁有者合計 500 位為止；已驗證擁有者完全沒有上限。官方文件還給了一個具體例子：資源裡已經有 200 位已驗證擁有者加 300 位委派擁有者，就無法再新增委派。對絕大多數網站這些數字用不滿，但單一資源協作人數多的團隊，確實可能把非擁有者加到接近 100 位，屆時得回頭清理名單，與其到時候救火，平常就該維持最小名單。

想把某人變成已驗證擁有者，流程跟一般新增使用者不同：請對方自己發起驗證流程，取得他個人的權杖，由能管網站或 DNS 的人把權杖放到對應位置，再請對方回到資源按驗證。換句話說，已驗證擁有者的身分不是「給」的，是對方「證明」來的，這也是它比委派更穩固的原因。各種權杖的取得與放置細節，在安裝與驗證教學有逐步說明。

權杖還有一個常被誤解的性質：它是使用者專屬的。每個人在驗證流程拿到的 HTML 檔名、meta 標記內容、DNS 記錄值都不一樣，對應回特定的帳號。這代表清理時認錯人等於白做，你刪掉同事 A 的標記，離職的同事 B 依然留著他的回頭路。官方文件因此在每個清理步驟都提醒要核對權杖屬於哪位使用者，寧可多花一分鐘確認，也不要刪完才發現門沒鎖上。

沒有上下層繼承關係的資源，同一個人的身分可以各自設定。他在 A 資源是擁有者，在 B 資源可能只是完整權限的使用者，兩邊互不影響；但兩個資源一旦有父項與子項的繼承關係，擁有上層資源的人就自然具備子資源的擁有者身分，繼承規則優先於個別設定。這個設計對多網站團隊很實用，同事可以在主力站拿完整權限做事，在實驗性的子站被授予擁有者全權管理，職位與權限不必綁死。相對地，盤點時就得逐資源檢查，並回頭確認每個資源有沒有上層資源的繼承，某人在這個資源被降級，不代表他在別的資源或上層資源也失去了權限。

新增使用者：正確流程與當下驗收

實際把一個人加進來，操作本身只要五個動作：

• 用具備擁有者身分的 Google 帳號登入，從資源選取器打開要分享的那個資源。
• 在左側導覽列點「設定」，進入「使用者和權限」，這個頁面只有擁有者看得到。
• 按「新增使用者」，在欄位填入對方的 Google 帳戶電子郵件地址。
• 從權限選單選擇等級，這裡只會出現完整、受限與擁有者的選項，選之前回到前文「給同事或 SEO 廠商」一節的判斷順序想一遍。
• 確認地址與等級無誤後儲存，變更很快就會生效。

電子郵件地址是很容易出錯的欄位，規則只有兩條，但兩條都是官方明文。第一，對方必須有有效的 Google 帳戶；帳號不一定要是 Gmail，公司網域的信箱也能拿去註冊成 Google 帳戶，重點是那個地址真的登入得了 Google。第二，電子郵件群組不能被新增為使用者，一群人共用的群組信箱就算能收信，也不是合法的帳號單位。這兩條規則合起來的實務版：開權限前，直接請對方用那個地址登入任何 Google 服務給你看一眼，比事後來回排查快得多。

新增完成不等於交接完成，驗收要兩邊各做一次。你這邊回到「使用者和權限」清單，確認地址沒拼錯、等級正確；對方那邊用同一個帳號開啟 Search Console，確認資源選得到、需要的報表打得開。判斷成敗以這兩邊的核對為準，不要只等通知信，信件遞送的因素太多。對方第一次進來時，請他念出畫面左上角的資源名稱與類型，跟你這邊逐字核對，再一起打開網頁索引報表比對數字；資源名稱與類型吻合才是範圍正確的依據，數字一致只當輔助確認，不同範圍偶爾會出現相近的數字。

有一種特殊的系統訊息需要先打預防針。新增使用者時若看到「只能將這位使用者新增為擁有者」，不是系統故障，是對方已經擁有上層資源，因此自然具備這個子資源的擁有者身分。你在子資源把他加成完整或受限，實際效果是把他既有的權限降級，系統不允許這種操作。遇到這個訊息，回頭釐清上層資源的擁有權結構才是正解，在子資源反覆重試沒有意義。

還有兩個小動作能讓交接更乾淨。新增前先講好對方要用的帳號，並請他確認公司信箱已經綁成 Google 帳戶，避免開到一半才發現資格不符。新增後如果對方反映畫面沒有變化，請他重新整理瀏覽器頁面，官方文件對權限變更的說明就是這麼建議的，跨資源切換時也一樣，權限身分跟著資源走，停在錯的資源裡永遠看不到正確的結果。

要一次加入多位使用者也別急著連發。先加一位走完整個流程，從填地址到對方實際登入驗收，確認這條路是通的，再批次處理其餘名單。不過第一位驗收成功，只代表這個資源範圍與操作流程是通的，後面每一位仍要各自核對帳號地址、目標資源與權限等級，出問題時先查那個人自己的帳號狀態，再回頭檢查共用的資源設定，排查起來快得多。團隊超過十人的導入，這個節奏尤其值得守住。

四種開不通的情境，各自怎麼排除

第一種，找不到「使用者和權限」頁面。官方明說這個頁面只有資源擁有者能瀏覽，頁面不出現時先確認兩件事：左上角選的資源是不是正確，因為在不同資源間切換，權限身分是跟著資源走的；以及你這個帳號在該資源的身分，打開「設定」找到「擁有權驗證」那一列，上面會標示目前的權限等級。如果顯示完整，就代表你不是擁有者，請現有擁有者出手新增，與其讓對方反覆登出登入，直接找對人快得多。若是看得到清單卻沒有新增按鈕，先核對實際畫面與系統提示，再用同樣的方法確認身分與資源是否相符。

第二種，電子郵件地址填了卻加不進去。回到上一節的兩條規則檢查：那個地址是不是有效 Google 帳戶，是不是群組信箱。實務上還有一個更尷尬的變體，對方給的是名片上的聯絡信箱，實際登入 Google 的是另一個地址，填錯的那個看起來完全正常，結果可能新增失敗，更糟的是那個地址恰好是別人的有效帳號，權限就開給了錯的人。請對方明確回覆「登入 Search Console 時輸入的完整地址」，儲存前再逐字核對一次，這兩個動作能省掉大部分的猜謎。

第三種，清單上有對方，對方登入後卻什麼都看不到。先檢查兩件事：對方瀏覽器是不是登在正確的 Google 帳號上，同時登入多個帳號時點錯人是家常便飯；再來核對資源範圍，若使用網址前置字元資源，逐項核對協定、www 與路徑前綴，任何一個不同就是不同的資源；若使用網域資源，則核對網域名稱與資源類型。都確認過還不行，請對方重新整理頁面，官方文件明說權限變更後若沒有立即反映，重新整理即可。

第四種，就是上一節提過的「只能新增為擁有者」訊息。這裡補一個決策觀點：如果對方是公司內部的人，擁有上層資源本來就合理，直接以擁有者身分加入即可；如果對方是外部廠商，他擁有你家上層資源這件事本身就值得追問，很可能是前一個世代的授權沒收乾淨，先處理那個歷史帳，再談新的權限安排。排查的順序固定：先確認人對不對，再確認帳號對不對，接著確認資源對不對，三關都過還卡住，才往繼承關係與系統訊息去查，這個順序能避免繞遠路。

三種團隊規模的配置範本

小型網站，老闆加一位外包的人：老闆當已驗證擁有者，外包給完整權限就收工。這種結構的好處是分工乾淨，老闆握權杖與名單，外包者做事，月底看報表對帳。要注意的反而是權杖落點，如果網站當初是主機商或架站服務的人員用自己的帳號與權杖完成驗證，該帳號可能至今仍保有已驗證擁有者身分，除非後來有人把它移除；名單上是否多出一個你看不到操作面的身分，盤點時實際打開清單與驗證詳細資料核對，別漏掉它。

中型團隊，行銷部門加外部顧問：建議公司內部保留一到兩位已驗證擁有者，行銷同事全數給完整，顧問給完整，需要看數據的主管給受限。這個配置對應的維運節奏是每季盤點一次名單，行銷流動率高的公司改成每月。成員異動時走後文的離職與解約交接清單，服務帳號與真人都照同一套程序處理，不因為身分是機器就跳過。

代理商全面代管：客戶端的網站負責人當已驗證擁有者，代理商的專案成員以委派擁有者或完整權限進入，雙方約定資源層設定變更的事前告知。這種結構裡，客戶最需要守住的東西有兩個：可登入且有效的擁有者帳號，以及使用者名單。公司自己保有已驗證擁有者帳號，適用的驗證方式與相關服務權限也掌握在自己手裡，換代理商時資源的主控權就不會跟著對方走；名單在，目前誰握有存取權隨時可查。合約談判時把這兩項寫進交付條款，比事後爭執有用得多。

合作結束不是按掉移除就好：存取權回收的完整程序

回收權限有兩種強度。合作內容改變但關係還在，用「變更權限」把完整降為受限，或把受限升為完整，這個選項對所有非已驗證擁有者都可用。合作結束或人員離開，用「移除存取權」，一按下去對方很快就失去這個資源的存取。兩個動作都在「使用者和權限」清單的選單圖示裡，做完後回頭看一次清單，確認狀態符合預期，這一步別省。

真正的深水區在已驗證擁有者。移除他的時候，系統可能跳出警告，指出這位使用者可能重新取得存取權，意思是他還留著一個以上的驗證權杖在網站上。清單頁面有一個「未使用的擁有權權杖」入口，列出自擁有者被移除後殘留的所有權杖，以及它們對應的使用者。只要權杖還在，被移除的人隨時可以重新驗證把門再推開，而且他真的這麼做的時候，現有的所有擁有者都會收到通知。換句話說，這封通知是重要的警訊，收到後應立即查核，別讓它響起後沒有人處理。

權杖的清理方式因驗證方法而異，動手前務必確認你刪的是要移除的那位使用者的權杖：

↔ 左右捲動檢視完整表格

驗證方法	權杖位置	清理方式
HTML 檔案	網站根目錄，一長串英數字元檔名的檔案	刪除該檔案，內容含 google-site-verification 字串可核對
HTML 標記	首頁原始碼的 meta 標記	從原始碼移除該使用者對應的標記
DNS 記錄	網域供應商的驗證用 DNS 記錄	到供應商後台，依該使用者的驗證詳細資料移除對應記錄
Google Analytics	網站所連的 GA 帳號編輯權限	切換網站使用的 GA 帳號，或撤銷對方在該帳號的編輯權限
Google 代碼管理工具	網站所連的 GTM 帳號權限	切換 GTM 帳號，或移除對方的發布或管理員權限
協作平台或 Blogger	平台本身的擁有者身分	只能切換網站擁有者，這類平台僅能有一位擁有者

看懂這張表，還能倒推一個常見的隱患：透過 Google Analytics 驗證的擁有者，他的鑰匙其實放在 GA 帳號裡。你在 Search Console 清單上把他移除，只要他在那個 GA 帳號裡還保有編輯權限，重新驗證的路就還開著。判斷網站接的是哪個 GA 帳號，官方給的方法是用瀏覽器的開發人員工具檢查轉譯後的原始碼，搜尋 UA- 或 G- 開頭的資料串。代碼管理工具同理，對方在那個 GTM 容器裡保有發布或管理員權限，等於間接握著一條回頭路。所以清理權杖時，把度量工具的帳號權限一起盤點，才算做完整。

刪權杖之前有一個不能跳過的確認：同一個權杖可能同時被其他 Google 服務拿來驗證擁有權，Merchant Center、Google Workspace 都在名單上。拔掉一根正在供電的線，斷電的說不定是別台機器。官方文件對此有明確提醒，實務上對應的做法是刪之前先盤點這個權杖還養著哪些服務，或者趁合約交接的機會，把整組驗證換成新的所有權杖，切斷以舊權杖重新驗證的路；上層資源的繼承、GA 與 GTM 的服務權限這些其他授權，仍要逐項確認，換權杖不是一刀兩斷的萬靈藥。

廠商輪替有一套值得照做的標準劇本。舊廠商還在線上時，先把新廠商加進來並讓他熟悉資源現況，重疊期抓一兩週通常夠用，依交接複雜度調整；接著由擁有者移除舊廠商的所有帳號，一般使用者直接移除，已驗證擁有者走權杖清理；服務帳號與 API 憑證在這個時候一併輪替，避免舊憑證持續有效；輪替完成後調出擁有權記錄，核對擁有者的新增移除與驗證嘗試。順序的關鍵在「先上後下」，新的人先就位，舊的授權再收，網站的搜尋監測才不會出現真空期。

收尾用「擁有權記錄」做內部稽核。這個頁面保存的是擁有權層級的事件：擁有者的新增與移除、成功與失敗的驗證嘗試、先前已知的權杖移除情形，全部有案可查；一般使用者的增刪與權限變更不在其中，內部要留軌跡得自行記錄。大型交接做完後把擁有權記錄調出來核對一遍，替擁有者層級的異動留下存證，日後有爭議，這份記錄比任何人的記憶都可靠。

三個資安訊號，出現就該提高警覺

第一個訊號：清單裡出現你不認識的擁有者。官方文件對此寫得直白，這代表你的帳號或網站可能遭駭，就算你移除駭客的權杖，他們還是可能把權杖重新加回去，所以官方建議照著 web.dev 的網站安全指南做全面性的安全強化，或找網站安全的專業人士協助。發現陌生擁有者的當下，重點已經不是清名單，是把整個網站的防線重新檢視一遍，從主機、CMS 到 DNS 的存取控制都過一次。

第二個訊號：收到某位已移除的使用者重新完成驗證的通知。可能是移除時留下的權杖沒清乾淨，也可能是對方重新植入了新的權杖。處理順序是先查看目前的擁有者名單與驗證詳細資料，確認他是用哪個方法重新驗證，移除該身分並清理對應權杖；若對方仍握有網站檔案、DNS 或度量服務的控制權，還要回到第一個訊號的資安層級一併處理。是殘留還是重新植入，依驗證詳細資料與網站的存取狀況判斷，兩種情況對應的後續處理強度並不相同。

第三個訊號：名單裡躺著早已離職的同事、結案的廠商、或沒人認領的服務帳號。這種情節的風險相對安靜，未必立即顯現問題，但每一個閒置帳號都是多開的一扇窗，也是盤點時應留意的情況。養成定期盤點的習慣，每季把使用者清單拉出來對一次在職名單與現行合約，順便看一眼擁有權記錄有沒有陌生的驗證嘗試，有助於減少閒置帳號的累積。

把通知當成監控設備來經營，也是擁有者的責任之一。官方權限表保證的是擁有者與完整權限使用者具備接收郵件通知的能力，受限使用者只收到與自己直接相關的實質訊息；各類事件的通知對象，文件明確點名的只有一件事：有人重新驗證成功時，目前所有擁有者都會收到通知。實務上建議擁有者使用公司管理、對應明確負責人的個人帳號，並由該負責人定期查看通知，避免通知進了離職者的私人信箱，形同整個警報系統失靈。通知來了要行動，收到重新驗證的通知卻沒有人處理，等於看著警報響起而無所作為，這在交接不清的團隊裡是真實上演過的劇本。

離職與解約的交接，可以照一份固定清單走：

• 盤點：列出此人觸及的所有資源，包含他用什麼身分進入，一般使用者、委派擁有者，還是已驗證擁有者。
• 降級或移除：一般使用者與委派擁有者直接移除存取權；已驗證擁有者走移除加權杖清理的完整路。
• 權杖清理：對照未使用的擁有權權杖清單，把屬於他的權杖逐一拆除，並確認沒有其他服務依賴。
• 服務帳號：檢查自動化與 AI 工具的服務帳號是否也該一併輪替或移除。
• 核對記錄：打開擁有權記錄核對擁有者異動與驗證嘗試，一般使用者的增刪另留內部紀錄。

把權限當資產管理：最小授權與可回收性

所有細節收攏成兩個軸，就能內化成判斷。橫軸是最小授權：預設給最低的等級，工作內容變了再升級，升級通常比降級容易，因為降級碰上已驗證擁有者是根本走不通的路。縱軸是可回收性：發出去的權限，將來要用什麼程序收回，發出去之前就想好。群組信箱是官方明文不支援的單位，服務帳號則常在交接時被遺忘，把兩者都納入盤點，回收才不會留下模糊地帶。

格局放大一點，權限管理就是網站資產治理的一環。誰能看資料、誰能動設定、誰能把別人請出場，這三層權力分清楚，團隊協作才不會變成人人有鑰匙、沒人鎖門的狀態。工具層面的基礎，例如 GSC 還能看哪些報表、怎麼判讀，站上的Search Console 功能導讀有完整整理；如果是 WordPress 架站想一次把驗證與權限的基礎打好，WordPress 站的串接攻略把網站端的設定一起講清楚了。權限發出去的每一刻都該有期限感，合約會結束、同事會離職，名單的乾淨程度，決定了網站資料到頭來由誰說了算。