攝影網站把照片放上網後，人類一眼就能看出畫面裡是教堂、山岳、湖泊或城市街景，但搜尋引擎最初看到的，可能只是一張圖片檔案、一個共用的照片頁面，以及等待瀏覽器載入的內容。Google 能找到圖片，不代表它知道照片拍攝於哪裡、屬於哪一本相簿、由誰拍攝，又應該用哪一個網址出現在搜尋結果中。
我的攝影網站運行在 Synology NAS 上，從早期單純顯示相簿，逐步增加照片標題、說明、GPS、主題 Tag、網站地圖、圖片資料、授權資訊與搜尋引擎可讀的頁面內容。這篇文章整理的不是幾個 SEO 外掛設定，而是我如何把一個「人類看得懂的照片網站」，逐步改造成「搜尋引擎也比較容易理解的攝影資料庫」。
一、Google 打開照片頁時，實際會讀取什麼
如果使用 WordPress，一般 SEO 外掛通常已經會協助產生頁面標題、正式網址、網站地圖和部分結構化資料；自行開發攝影網站時，這些事情不會自動發生。開始修改以前，我認為最重要的不是先研究一大串 SEO 名詞，而是先分清楚「圖片檔案」、「照片頁面」和「照片的瀏覽狀態」是三件不同的事。
圖片檔案只是 JPEG、WebP 或其他格式的照片，可能同時存在縮圖、一般尺寸、Full HD 和原始檔。照片頁面則是用來說明這張圖片的公開網頁，裡面才有照片名稱、說明、所屬相簿、拍攝日期、地點、作者及授權資訊。至於瀏覽狀態，是訪客從相簿、主題、地圖或滿版模式進入照片時，網站為了方便操作所保存的來源與位置。搜尋引擎真正應該收錄的是內容完整而且網址穩定的照片頁，不是每一種圖片尺寸，也不是每一種觀看模式。
另一個容易忽略的差異，是「瀏覽器最後顯示的內容」不一定等於「搜尋引擎第一次取得的內容」。動態網站可以等頁面開啟後，再由瀏覽器讀取資料並更換標題與照片；人類只看到最後完成的畫面，容易以為沒有問題。但實作 SEO 時，我會先確認伺服器最初送出的頁面是否已經包含目前照片的標題、說明和主要圖片，再確認切換照片後，畫面、網址與頁面資料是否同步。這兩個階段都正確，才不會出現訪客看到新照片，搜尋引擎卻仍讀到共用標題或上一張照片資料的情況。
最後還要先決定每張照片的身分。我的網站以照片 ID 辨識單張照片，相簿名稱則提供內容背景。這樣即使兩張照片標題相同，仍然可以有各自的頁面；相簿改名時，也必須同步處理網址、麵包屑、網站地圖及站內連結。若等網站累積數千張照片後才決定正式網址規則，後續重新導向和重複頁面會比一開始先規畫更麻煩。
Google 讀取一個照片頁並不是只看圖片，也不是像人類一樣打開 Chrome、等畫面出現後看一眼。整個過程大致可以分成幾個階段。首先，Google 要從站內連結、其他網站或 Sitemap 發現照片網址；接著向伺服器要求該網址，確認頁面是否存在、是否允許收錄，以及伺服器回傳的是正常頁面、重新導向還是找不到。然後才會分析最初收到的 HTML，包括頁面標題、說明、正式網址、可點擊連結、圖片標記和正文。若頁面依賴 JavaScript，Google 還可能把它排入另一個處理階段，等待瀏覽器環境執行程式後再分析最後畫面。
Google 確實能執行 JavaScript，但「能執行」不代表所有內容都應該只依賴 JavaScript。程式檔可能載入失敗、資料請求可能逾時，頁面也可能需要等待後續處理。Google 官方將 JavaScript 網站的處理分成檢索、轉譯與建立索引幾個階段，並指出初始 HTML 沒有實際內容的網站，需要等待 JavaScript 執行後才能看見內容。因此我不是另外做一個只給 Google 的版本，而是讓訪客和搜尋引擎取得相同的照片內容，只是重要資訊在伺服器第一次回應時就已經存在。可參考 Google JavaScript SEO 基礎說明。
以目前的奧蒂塞伊照片頁為例，Google 第一次要求網址時，可以直接取得以下幾類資訊：
- 伺服器結果：頁面正常存在並可公開讀取；若照片不存在，則不應假裝成正常照片頁。
- 頁面身分：獨立標題、內容說明、正式網址、繁體中文語系，以及供社群分享使用的標題和圖片。
- 人類看得到的內容：照片、相簿名稱、照片標題、拍攝日期、相機與鏡頭、地點、Tag、麵包屑及上一張／下一張連結。
- 搜尋引擎使用的照片資料：主要圖片、作者、版權、尺寸、格式、拍攝日期、可用地點和授權頁。
- 內容關係：這張照片屬於多洛米堤相簿，也能透過「小鎮、巷弄、教堂」等 Tag 與其他照片產生關聯。
這些資料不代表 Google 一定照單全收。Google 仍會自行判斷頁面品質、重複內容和正式網址，也可能重新組合搜尋結果中的標題與摘要。但至少網站提供的是一份內容完整、彼此沒有矛盾的照片頁，而不是要求 Google 從圖片檔名和空白框架自行猜測。
二、從共用框架到完整照片頁：改造前後差在哪裡
早期的動態照片網站，很容易先送出一個共用頁面，再由瀏覽器讀取照片資料、放入圖片、標題和說明。這種方式對訪客通常沒有問題，但搜尋引擎第一次取得頁面時，可能只看到「Skypray Photography」和一個尚未填入內容的照片框架。可以把它想成以前是先交給 Google 一個空相框，再請瀏覽器把照片裝進去；後來則改成相框送出去以前，照片、標題、說明和拍攝資訊都已經放好。
改造前後真正的差異，不只是多放幾個 SEO 標籤，而是網站交給 Google 的第一份資料已經不同。以下是依照網站修改歷程整理的對照：
| Google 取得的項目 | 改造前的動態架構 | 改造後的照片頁 |
|---|---|---|
| 頁面標題 | 不同照片可能先取得相同或偏通用的網站標題，需等瀏覽器載入資料後才改變。 | 第一次回應就包含照片名稱、所屬相簿與網站名稱。 |
| 頁面說明 | 最初 HTML 缺少單張照片說明，或只能提供共用介紹。 | 直接包含相簿、拍攝地點、日期、相機及照片內容摘要。 |
| 主要圖片 | 圖片網址可能要等 JavaScript 讀取相簿資料後才出現。 | 初始頁面已指出主要照片，圖片 Sitemap 也把照片頁和圖片網址配對。 |
| 頁面內容 | 人類最後看得到完整資料，但搜尋引擎最初可能只取得載入框架。 | 照片標題、說明、拍攝資訊、地點和導覽在初始 HTML 就存在。 |
| 照片關係 | 相簿卡片、上一張與下一張等連結較依賴瀏覽器產生。 | 首頁先輸出相簿入口，相簿頁先輸出首批照片，照片頁也有可讀取的相鄰照片和麵包屑。 |
| 重複網址 | 相簿、主題、滿版和不同操作狀態可能留下多個相近入口。 | 每張照片指定正式網址；滿版及受保護頁面不和一般照片頁競爭收錄。 |
| 圖片背景資料 | Google 主要只能從頁面文字、圖片檔名及一般圖片標記推測。 | 另外提供作者、版權、尺寸、格式、日期、地點與授權資訊。 |
| 網站地圖 | 網站地圖著重頁面網址，照片頁和實際圖片的對應不夠明確。 | 分成頁面 Sitemap 與圖片 Sitemap，再由 Sitemap index 統一管理。 |
以我的「奧蒂塞伊街景與洋蔥頂教堂」照片頁為例，伺服器目前直接輸出的頁面標題是：
奧蒂塞伊街景與洋蔥頂教堂｜2026/06 阿爾卑斯山脈之多洛米堤｜Skypray Photography
頁面說明則包含所屬相簿、義大利奧蒂塞伊、拍攝日期、相機型號和照片內容。即使瀏覽器尚未執行後續程式，搜尋引擎仍能知道這是一張在義大利奧蒂塞伊拍攝的街景與教堂照片，而不是另一個只有相同網站名稱的空白照片頁。
如果把現在的內容換回改造前的思路，Google 第一次取得的可能只是「照片｜Skypray Photography」一類通用標題，以及等待載入的照片區域。等 JavaScript 成功讀取相簿資料後，人類才看到「奧蒂塞伊街景與洋蔥頂教堂」。改造後，這個名稱在伺服器回傳的原始頁面裡就已存在，所屬相簿、日期、地點和主要圖片也能一起被讀取。兩個版本在人類眼中最後可能長得幾乎一樣，但對搜尋引擎而言，理解內容所需的步驟與失敗風險並不相同。
相簿頁也做了相同調整。Google 進入「2026/06 阿爾卑斯山脈之多洛米堤」時，不再只取得相簿頁外框，而能直接看到相簿名稱、介紹、封面、照片數和首批 24 張照片的入口。這個數量是一項取捨：完全不輸出照片，搜尋引擎不容易發現內容；一次把整本相簿全部放進最初 HTML，又會讓大型相簿頁過度膨脹。先提供具有代表性的首批照片，其餘內容再交給互動介面載入，可以同時保留可發現性與頁面負擔。
同樣地，首頁也直接提供首批相簿封面、相簿名稱、說明和可點擊網址。因為搜尋引擎發現內容不只靠 Sitemap，也會沿著網頁中的一般連結前進。若所有相簿入口都必須按下按鈕、等待程式執行後才出現，網站雖然看起來功能正常，內容之間的連結卻會更依賴轉譯階段。
這些文字不是為了反覆塞入「義大利旅遊、奧蒂塞伊景點、多洛米堤攝影」等關鍵字，而是把照片原本就具有的資訊整理清楚。標題負責辨識照片，說明補充拍攝地點與畫面內容，相簿名稱則提供整段旅程的背景。Google 官方的圖片 SEO 建議也指出，圖片所在頁面的標題與說明，會影響搜尋結果如何理解和呈現圖片。可參考 Google 圖片 SEO 官方說明。
三、用正式網址、相簿與 Tag 整理照片關係
我的照片可能從相簿、主題 Tag、地圖、搜尋結果、「歷史上的今天」或相關照片推薦被打開。訪客從不同入口進入時，網址有時會帶著主題或返回位置等資訊，但對 Google 而言，這些入口可能仍然指向同一張照片。因此，每張照片頁都會標示一個正式網址，也就是 canonical。它可以理解成網站主動告訴搜尋引擎：「不論訪客從哪一條路進來，這張照片最主要的地址是這一個。」
開始實作時要注意，canonical 不能只在第一張照片載入時正確。我的照片頁可以不重新載入整頁就切換上一張或下一張，所以每次切換都必須同步更新照片、網址、標題、相簿名稱和相關資料。滿版模式、投影片模式與帶有主題來源的網址可以服務訪客操作，但正式搜尋結果仍應集中到一般照片頁。canonical 是提供給 Google 的偏好訊號，而不是強迫 Google 接受的命令；搜尋引擎還會參考頁面內容、重新導向及 Sitemap 等資料。相關原則可參考 Google canonical 官方說明。
照片頁上方的麵包屑則負責說明目前內容位於網站哪裡，例如：
首頁 › 2026/06 阿爾卑斯山脈之多洛米堤 › 奧蒂塞伊街景與洋蔥頂教堂
對訪客而言，它可以快速返回相簿；對搜尋引擎而言，它說明目前頁面是一張照片，照片屬於多洛米堤相簿，而相簿又是整個攝影網站的一部分。Google 也支援 BreadcrumbList 麵包屑資料，讓網站用固定方式表達這種層級關係。
麵包屑改造前後的差異
改造前，照片頁雖然有「返回相簿」按鈕，也能從網址中的相簿名稱推測照片來源，但畫面上沒有一條固定路徑清楚說明「首頁、相簿、照片」三者的關係。對訪客而言，他知道可以按返回按鈕，卻不一定能立刻確認目前照片屬於哪一段旅程；對搜尋引擎而言，網址參數和返回按鈕也不等於一份明確的內容階層。
改造後，我同時加入兩種麵包屑。第一種是讀者在照片上方直接看得到、也能點擊返回的導覽路徑；第二種是放在頁面資料中，讓搜尋引擎以固定格式理解相同階層的 BreadcrumbList。兩者使用同一份相簿與照片資料，不能畫面寫多洛米堤，搜尋引擎資料卻指向另一個相簿。
| 比較項目 | 麵包屑改造前 | 麵包屑改造後 |
|---|---|---|
| 訪客看到的路徑 | 主要依靠返回相簿按鈕，頁面階層不夠直觀。 | 直接顯示「首頁 › 相簿 › 照片」，每一層意義更清楚。 |
| 搜尋引擎理解方式 | 主要從網址、站內連結和頁面內容自行推測。 | 除了可見文字，另提供 BreadcrumbList 說明內容階層。 |
| 照片切換 | 只要照片畫面切換成功，容易忽略相簿名稱和導覽仍停在舊資料。 | 照片、網址、相簿、麵包屑、返回連結和 SEO 資料一起更新。 |
| 跨相簿主題 | 從 Tag 瀏覽下一張時可能已進入其他相簿，但上方仍保留第一張的分類。 | 每次依目前照片的相簿資料重新建立路徑，跨相簿後仍保持正確。 |
| 上一張與下一張 | 搜尋引擎和輔助工具較難從按鈕判斷相鄰照片內容。 | 相鄰照片連結帶有照片名稱，導覽目的更具體。 |
麵包屑第一次加入後，事情仍然沒有完全結束。當訪客從「教堂」主題進入照片頁，按下一張後可能跨到另一個相簿；如果程式只替換照片，麵包屑卻仍保留第一張照片的相簿名稱，就會出現照片已經到了另一個國家，上方仍顯示原相簿的矛盾。這個問題後來才修正為每次依目前照片重新取得相簿資料，並同步更新網址、照片標題、相簿名稱、返回連結、圖片說明及頁面 SEO。這段演進讓我理解，新增麵包屑只是第一步，真正困難的是動態切換內容後仍然保持正確。
相簿和 Tag 在這裡扮演不同角色。相簿保存一次旅程的時間與故事，例如「2026/06 阿爾卑斯山脈之多洛米堤」；Tag 則把不同旅程裡相同主題的照片重新串起來。奧蒂塞伊這張照片具有「小鎮、巷弄、教堂」等 Tag，訪客看完後可以繼續探索其他國家和年份拍攝的教堂。照片頁底部的「探索更多照片」也會利用 Tag、地點、GPS、日期與相簿資料尋找相關內容，同時避開連拍和前後相鄰照片。這些連結不是單純增加 SEO 數量，而是替訪客和搜尋引擎建立合理的內容關係。
四、用 Sitemap 和照片資料幫助 Google 發現內容
當網站只有十幾張照片時，首頁和相簿連結可能已足以讓搜尋引擎找到內容；但照片增加到數千張後，不能只期待 Google 自己一路點完所有相簿。因此，我把原本單一的網站地圖改成一個總目錄，再分成頁面 Sitemap 與圖片 Sitemap。
截至本文整理時，我的 sitemap.xml 是總入口，裡面連到兩份資料：
- sitemap-pages.xml：目前列出 4,434 個正式頁面網址，包括首頁、相簿、照片、主題與授權頁。
- sitemap-images.xml：目前列出 4,280 個照片頁與對應的公開圖片。
Sitemap 改造前後的差異
改造前，網站使用單一 sitemap.xml 作為搜尋引擎入口，重點放在列出公開頁面。這對首頁、相簿和一般資訊頁已經有幫助，但攝影網站最重要的是「哪一個照片頁對應哪一張公開圖片」。如果 Sitemap 只有照片頁網址，而圖片又要等瀏覽器載入相簿資料後才出現，Google 需要自行進入頁面、等待轉譯，再設法找出實際圖片；網站也不容易分別觀察一般頁面和圖片的發現情況。
改造後，原本提交給 Search Console 的 sitemap.xml 網址沒有更換，而是變成 Sitemap index，也就是網站地圖的總目錄。它再分別指向頁面 Sitemap 和圖片 Sitemap。這樣做的好處是 Search Console 原來的提交設定可以繼續使用，網站內部卻能增加更完整的分類；未來若再拆分其他 Sitemap，也不必要求搜尋引擎改用新的總入口。
| 比較項目 | Sitemap 改造前 | Sitemap 改造後 |
|---|---|---|
| 整體架構 | 單一 sitemap.xml 主要列出網站公開頁面。 | sitemap.xml 改為總目錄，再分成頁面與圖片兩份 Sitemap。 |
| 照片與圖片關係 | 列出照片頁不等於明確告知頁面使用哪一張主要圖片。 | 圖片 Sitemap 直接把每個照片頁和公開圖片網址配對。 |
| 收錄網址選擇 | 動態參數、觀看模式和正式頁面的界線較不集中。 | 頁面 Sitemap 只列希望出現在搜尋結果中的 canonical 正式網址。 |
| 內容更新 | 若靠人工或不完整流程維護，照片新增、改名和刪除容易不同步。 | 公開資料重建時同步產生 Sitemap，並保存可信的更新時間。 |
| 主題頁 | Tag 是否具有足夠內容，不容易和一般頁面分開判斷。 | 至少累積五張照片的主題才加入頁面 Sitemap，避免大量內容單薄的頁面。 |
| 錯誤與受保護內容 | 若只依頁面清單產生，可能留下已不存在或不希望曝光的網址。 | 管理頁、滿版重複頁、受保護原圖及不存在內容都不列入 Sitemap。 |
| Search Console | 所有內容集中在同一入口，較難分開查看頁面與圖片問題。 | 總入口不變，但可以分別檢查頁面 Sitemap 與圖片 Sitemap。 |
更新時間也是實作時容易做錯的地方。Sitemap 的 lastmod 應該反映內容真正更新的時間，而不是伺服器每次重新啟動、重新輸出檔案或管理者打開後台的時間。否則幾千張從未修改的照片可能每天都被標示為剛更新，搜尋引擎就無法從日期判斷哪些內容真的有變化。我的做法是由照片、相簿和主題本身的可靠日期產生更新資訊，而不是單純使用 Sitemap 檔案的建立時間。
實作上，這些 Sitemap 不適合人工維護，而應在照片新增、刪除、改名或重新整理公開資料時自動產生。頁面 Sitemap 像網站的文章目錄，圖片 Sitemap 則說明每一張圖片屬於哪個照片頁。Sitemap 中只放正式網址，不把滿版模式、排序狀態或其他重複入口全部列進去；照片刪除後也要從 Sitemap 移除，避免網站地圖長期指向不存在的內容。
Google 官方說明，圖片 Sitemap 特別適合協助發現透過 JavaScript 或其他動態方式載入、搜尋引擎不一定容易找到的圖片。不過，Sitemap 只是告訴 Google「這些是我希望被找到的正式網址」，並不保證每一頁都會建立索引，也不代表提交後一定提高排名。可參考 Google 圖片 Sitemap 說明及 Sitemap 建立原則。
除了列出圖片網址，我也在照片頁提供搜尋引擎可以讀懂的照片資料，包括照片名稱、作者、拍攝日期、拍攝地點、所屬相簿、圖片尺寸、主要圖片網址、版權聲明和授權資訊。這些資料會以 ImageObject 等固定格式放進頁面。讀者不會在畫面上看到這段資料，但搜尋引擎可以用它理解這是一件攝影作品，而不只是網頁裝飾圖片。
網站同時提供照片授權說明，照片頁也帶有作者、版權及授權連結。Google 官方文件說明，提供圖片創作者、出處和授權資訊，有機會讓 Google 圖片呈現更完整的使用資訊；提供授權管道並不代表任何人都可以自由使用原圖。可參考 Google 圖片授權資料說明。
五、SEO 不是收錄愈多愈好
攝影網站有很多頁面適合訪客操作，卻不一定適合出現在搜尋結果，例如管理後台、管理 API、登入頁、滿版照片瀏覽器、受密碼保護的原圖，以及不存在的相簿或照片。如果這些頁面全部開放收錄，Google 可能同時找到一般照片頁與內容相同的滿版頁，不知道哪一個才是主要版本；管理頁被收錄也不會對搜尋者產生價值。
因此，我的 SEO 調整不只是增加 Sitemap 和照片資料，也包括排除不應收錄的內容。一般照片頁保留索引，重複的滿版觀看頁、管理資源與受保護原圖則加入 noindex 或相對應的搜尋引擎指示。不存在的照片不能只顯示「找不到」文字卻仍回傳正常頁面，而應讓伺服器明確表示內容不存在。Google 官方文件也說明，robots meta tag 可以針對個別頁面控制是否建立索引、是否顯示圖片及預覽大小。可參考 Google robots meta tag 說明。
主題頁也不是出現一個 Tag 就立即送進 Sitemap。AI 或人工可能替照片建立很多標籤，如果只有一張照片的 Tag 也生成獨立頁面，網站很快會出現大量內容單薄的主題頁。目前我的做法是主題累積至少五張照片後，才加入頁面 Sitemap，並以該主題最新照片的日期更新資料。這讓「教堂、山岳、湖泊、小鎮、街景」等真正有內容可探索的主題成為獨立入口，也避免產生太多只有名稱、沒有實質內容的頁面。
公開照片頁則允許 Google 使用較大的圖片預覽。這項設定只是允許搜尋結果在適合的版位顯示大型預覽，不代表必須公開相機原始檔；網站仍可提供適合網頁觀看的尺寸，並保護原始照片。搜尋曝光、網頁觀看畫質與原始檔授權，是三個應分開處理的問題。
六、SEO 修改完成後，還要持續觀察什麼
完成這些調整後，不能只提交 Sitemap 就認為工作結束。Search Console 還需要持續觀察 Sitemap 是否成功讀取、Google 發現多少頁面、哪些照片已建立索引、哪些頁面被排除，以及 Google 選擇的正式網址是否與網站設定一致。若某些照片沒有被收錄，也不能只重複提交網址，而應先檢查照片頁是否有足夠內容、圖片能否公開讀取、站內是否有入口，以及頁面是否和其他照片過度相似。
實際檢查時，我會特別注意相簿與照片標題是否正確、Google 是否選擇預期的 canonical、圖片 Sitemap 能否正常讀取、Google 圖片搜尋是否帶來曝光、不存在或受保護頁面是否確實被排除，以及更新照片標題後搜尋結果是否逐步重新整理。另一個不能忽略的步驟，是抽查不同類型的頁面，而不只測試首頁：至少要分別檢查一般相簿、單張照片、跨相簿主題、找不到的照片、滿版觀看頁和授權頁。
這次實際重新讀取奧蒂塞伊照片頁的原始內容時，也發現一個仍可繼續改善的細節：頁面說明目前為了控制長度，會在固定字數後結束，結果最後一句可能變成「午後陽光灑落在一側的。」這種文法完整卻語意中斷的句子。一般訪客在照片頁看到的是完整描述，不一定會注意這個問題，但搜尋引擎取得的 meta description 確實可能被截在不自然的位置。下一步應改成優先保留完整句子，若超過預定長度，再從前一個句號或逗號附近收尾。這也說明 SEO 不能只檢查畫面，還要查看伺服器送出的原始標題、說明與正式網址。
SEO 最終不是讓每張照片都塞滿關鍵字，也不是保證每張照片一定排到搜尋結果前面。它首先要解決的是資料一致性：同一張照片應有穩定的正式網址，頁面上的標題、相簿、地點、圖片與麵包屑必須互相符合，不應收錄的頁面則應清楚排除。
結語：Google 沒有參加我的旅行
人類看到一張照片時，可以從教堂、山勢、街道和建築風格理解畫面，也可能因為曾經去過同一個地方而產生記憶；Google 沒有參加我的旅行，它只能根據網站提供的線索判斷照片內容。
因此，攝影網站 SEO 真正要做的，不是迎合搜尋引擎堆入大量文字，而是把照片本來就具有的資訊整理清楚：這張照片叫什麼、在哪裡拍攝、屬於哪次旅程、和哪些主題有關、由誰創作、正式網址是哪一個，以及如何取得授權。當這些資料在人類看到的頁面、網站內部導覽、Sitemap 和搜尋引擎讀取的資訊中保持一致，Google 才更有機會正確理解每張照片。
這次改造最大的心得是：Google 看得到圖片，只代表圖片可以下載；Google 能讀懂相簿與照片之間的關係，才是攝影網站 SEO 真正的開始。
延伸閱讀：攝影網站建置學習順序
- WordPress 能做攝影網站，我為什麼還要在 Synology NAS 自己架一套？
- Synology NAS 多網站架構：Docker、Caddy、反向代理與 Umami
- AI 自動整理 5,000 張照片：Gemini、GPT、GPS 與 Tag 實戰
- Google Maps API 應用於照片 GPS 地點管理與費用優化
- 攝影網站 SEO 實戰：如何讓 Google 讀懂相簿與照片
這篇文章已有 30 次瀏覽
發佈留言