AI SEO 實測：新網域上線第 5 天，ChatGPT 拒絕開啟

TL;DR

• 同一台伺服器、同一個出口 IP、一模一樣的 robots.txt，兩個網站一個能被 ChatGPT 的內建網頁工具讀取，另一個回「URL is not safe to open」
• 差別只有一個：被拒絕的那個網域，公開運作只有 5 天
• 用六種 AI 爬蟲的 User-Agent 直接測，兩站全部回 200——不是伺服器擋、不是 robots.txt、不是爬蟲政策
• 同一個網域 Google 已經正常收錄並給出排名，AI 工具卻在讀取內容之前就拒絕
• 同一個助理的三條存取路徑中，只有「需要使用者手動授權」的那條連得上——一般使用者不會做這個動作
• 這代表被 AI 引用之前還有一道抓取准入的門，而那道門看的不是內容品質

目錄

實測環境：兩個同架構網站的對照
robots.txt 與 AI 爬蟲存取的排除測試
Google 收錄狀況與 AI 工具讀取的落差
三條存取路徑的實際結果
AI 引用之前的抓取准入判定
本次實測的限制
後續追蹤的指標與方法

引言

多數談 AI SEO 的內容，起點都是「怎麼把內容寫得讓 AI 願意引用」——結構化資料、清楚的段落、可摘錄的主張。這些沒有錯，但它們都預設了一件事：AI 讀得到你的網站。

這篇記錄一次沒有預期的觀察。同一套架構、同一個機房、同樣的技術設定，兩個網站在 AI 工具面前得到相反的待遇，而被拒絕的那一個，技術層面並無異常。

實測環境：兩個同架構網站的對照

觀察是在一次與 ChatGPT 的對話中出現的。請它讀取本站 seobar.dev，內建網頁工具回：

URL https://seobar.dev/ is not safe to open (non-retryable error)

請它讀取另一個站 wanderlane.blog，正常抓取、正常摘要，還把內容整理了一遍。接著回頭再試 seobar.dev，仍然是同一個錯誤。

這兩個站都是我自己的，架在同一個平台上：

兩站的 DNS 解析出來是同一組 IP——這不是伺服器、不是網路、不是防火牆設定的差異，請求打到的是同一個地方。

robots.txt 與 AI 爬蟲存取的排除測試

在將原因歸於「網域過新」之前，先逐項測試，排除可能造成誤判的變數。以六種實際的 AI 爬蟲 User-Agent 直接請求兩個網站：

for ua in \
  "Mozilla/5.0 (compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot)" \
  "Mozilla/5.0 (compatible; GPTBot/1.2; +https://openai.com/gptbot)" \
  "Mozilla/5.0 (compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)" \
  "Mozilla/5.0 (compatible; ClaudeBot/1.0; +claudebot@anthropic.com)" ; do
  curl -s -o /dev/null -w "%{http_code}\n" -A "$ua" https://example.com/
done

結果：OAI-SearchBot、ChatGPT-User、GPTBot、PerplexityBot、ClaudeBot、curl，兩個網站全部回 200。

以下全部排除：

• robots.txt——兩站內容一字不差，都是全站允許
• 伺服器或 CDN 阻擋——同一個出口 IP，同樣的 UA 都通過
• 爬蟲政策——沒有任何一個 AI 爬蟲被擋
• HTTPS 或憑證問題——兩站都是有效憑證，連線正常

剩下能解釋差異的變數只有網域本身，以及它存在多久。

Google 收錄狀況與 AI 工具讀取的落差

同一期間，seobar.dev 在 Google 那一側完全正常。Search Console 的資料顯示，網站上線後的四天內已經有 6 個頁面產生曝光、涵蓋 4 個查詢、累計 55 次曝光，其中一篇文章在發布隔天就進入排名（雖然名次還在很後面）。

Google 已經抓取、索引、並開始給予排名的網域，AI 工具在讀取階段就拒絕了。

傳統搜尋引擎的收錄門檻，跟 AI 工具的抓取准入門檻，是兩套獨立的判斷。前者過了不代表後者會過。

三條存取路徑的實際結果

同一個對話裡，那個 AI 助理實際上有三條不同的路徑可以連到網站，三條的結果不一樣。

內建網頁讀取工具——由服務商代管的抓取服務，不是使用者電腦上的瀏覽器。結果是拒絕，URL is not safe to open。

直接網路連線——從工作環境直接對網站發出請求。這條需要使用者明確授權：助理送出一個「允許網路存取」的請求，人按下同意之後才成立。結果是 HTTP 200，網站正常回應。

瀏覽器控制——操作內建瀏覽器或已連接的 Chrome。該次任務中此介面未完整載入，沒有結果。

通得過的只有第二條，而第二條需要一個人在旁邊按同意。

這對品牌的實際影響比技術結論更值得留意：一般使用者在對話中詢問某個品牌時，不會去開任何網路權限。他拿到的就是預設路徑的結果——讀不到。

還有一個細節。工具第一次失敗時，助理給出的說法是「這個網站無法讀取」；經過追問，才更正為「是我的工具擋的，網站本身沒有問題」。第一版的說法已經送到使用者面前了，而那個說法聽起來像是網站有問題。

AI 引用之前的抓取准入判定

錯誤訊息說的是 not safe to open，不是「內容有問題」也不是「抓取失敗」。拒絕發生在打開之前。

這不是一次內容品質的評估，是一次網址層級的准入判定。可能參考的因素包括網域註冊時間、公開運作長度、第三方信譽資料庫的收錄狀況、TLD 的整體風險評級。這些全部與你在網站上寫了什麼無關。

技術基礎與內容品質是必要條件，但它們作用在門後面。門本身只看網域的來歷。而新網域唯一能做的事，是讓時間過去。

這也連帶說明了一個常見的判斷失誤——網站架好、結構化資料做滿、內容也寫了，AI 就是不引用，於是回頭一直修內容。如果卡點在准入層，修內容不會有任何反應，因為那些內容根本沒有被讀到。

本次實測的限制

這是單一觀察，不是研究。

樣本是 1。 一個新網域、一個舊網域，各一次。沒有辦法排除偶然。

只測了一個工具。 ChatGPT 的內建網頁讀取工具。同一時間 Perplexity、Claude、Gemini 是否也拒絕，這次沒有測。

看不到判定原因。 錯誤訊息沒有給代碼，所以「網域太新」是推論，不是查證出來的結論。也可能是 TLD 分類、第三方黑名單誤判，或其他完全不同的規則。

時間點只有一個。 這是第 5 天的狀態。它明天可能就通了，也可能三個月後還是同樣結果——目前無從得知。

在這些限制之下，能安全講的只有一句：技術完備的新網域，仍可能在 AI 工具的讀取階段被拒絕，而 Google 那一側可以完全正常。

後續追蹤的指標與方法

這次觀察的價值不在結論，而在於它可被持續追蹤。

要記錄的是一個日期：這個網域從被拒絕變成可讀取的那一天。從公開上線起算，中間隔了多久。

這個數字目前沒有公開資料，因為要取得它，得有人願意從零開一個新網域、把技術基礎一次做對、然後每天量同一件事。多數人在建站當下不會想到要記錄這件事，等到需要時，網域已不再是新網域。

之後的結果會更新在這篇。如果你手上剛好也有新網域，用上面那段 curl 測一次抓取層，再請 AI 工具讀一次你的網址——兩個結果不一致的話，你遇到的可能就是同一道門。