SWAG / Profile SEO 執行規格 本機 完成 0 / 0
執行規格書 · 2026-06-22 · 基於線上實測 + 5 月 GSC 數據

Creator Profile
SEO 改版執行清單

每一項獨立、可分開做、可打勾追蹤 — 不必一口氣全做

/user 創作者頁月點擊 54,018 主頁 noindex 已移除 · 要保住收錄
/category/ 月點擊 9,284 在排名的標籤頁
/user-feed-grid/ 月點擊 777 profile 標籤現在連這裡
/u 創作者頁月點擊 49 幾乎還沒被收錄
這份文件怎麼用
  1. 點任一張卡片標題 會展開,裡面有「現況 / 為什麼 / 怎麼做 / 怎麼算完成」。
  2. 做完一項就勾左邊大方框 — 卡片會變灰、進度條前進。進度自動存在這台電腦的瀏覽器,關掉再開還在。
  3. 卡片裡的小方框是 該項的驗收細項,可以一條一條勾。
  4. 第 1 區(止血)三項必須一起上線,其餘各區可獨立排程、分開做。不必一口氣全做。
  5. 每張卡片右上角有 急 / 高效益 / 後做 與工程量標示,照這個排順序。
已驗證完成 / 進行中 · 線上實測

這些已經處理了(不列入待辦)

以下為實測確認已完成或團隊正在修復的項目,從待辦清單獨立出來,讓下面的卡片只剩真正要做的事。

✓
URL 翻轉:/user/<uuid> → 301 → /u/<handle> 已生效
⟳
/u H1 已 SSR 但偏短:實測 H1=顯示名(GSC 後台也抓得到),但不是完整 meta 標題、也無區塊 H2 — 需改完整 meta 標題 + 補 H2,見 Task 4.6
✓
hreflang:raw + rendered 都正確指向各語言 profile URL(非語言首頁)
✓
robots.txt:200、只擋 settings/archive/revenue,無 Disallow: /,整站可爬
✓
榜單雙向連結:榜單→創作者、創作者→榜單都已實作(= Task 4.3)
✓
Profile 標籤:已是可點擊連結(惟現指 feed-grid,改連 /category 見 Task 2.1)
✓
/u 主頁 noindex 已移除:/u/<handle> raw HTML 已無 noindex、可索引;/u/<tab> 子頁仍 noindex,見 Task 4.4
✓
og:image 已用創作者頭像(= Task 3.2,抽樣驗證即可)
✓
Tab 子頁:保留並修復(28k clicks 依據,見 Task 4.4)
⟳
/u 已有 1 組 JSON-LD,但 @id/url 仍指舊 /user/<uuid> — identity 待統一,見 Task 1.3
01 Batch 1 · 止血 · 最高優先

把代表頁的收錄訊號一次對齊

/user/<uuid> 已全部 301 到 /u/<handle>、主頁 noindex 也已移除。剩下要把收錄訊號收齊:sitemap 換成 /u、JSON-LD identity 統一到 /u、robots 指向新版 sitemap。這些只要還矛盾,5 月有 5.4 萬點擊的創作者頁仍可能因「代表 URL 訊號不一致」掉收錄。

⚠ 這幾項建議「同一次發版」一起上線,讓代表 URL 的訊號一次對齊
P1.1 · 止血
移除 /u/<handle> 的 noindex
🔴 急工程量 小
▶
主頁 noindex 已移除、可索引,此項主頁部分可勾完成。 剩下 /u/<tab> 子頁仍 noindex,移到 Task 4.4 處理。
現況

主 profile /u/<handle> 原始 HTML 已無 noindex。要確保的是「只 index 有效、可公開、有 handle」的 profile,其餘維持 noindex。

為什麼

sitemap 提交的 /user 全部 301 到這頁,Google 跟過來若看到 noindex 就會放棄收錄,是最直接的流量風險 —— 所以主頁必須維持可索引。

怎麼做

把 /u/<handle> profile 頁的 robots meta 從 noindex, nofollow 改成 index, follow(或直接移除這個 meta,預設就是可索引)。

只改「有效、可公開、有 handle」的 profile。沒有 handle 或被停權的帳號維持 noindex,且不要進 sitemap。
怎麼算完成
P1.2 · 止血
創作者 sitemap 換成 /u/<handle> 網址
🔴 急工程量 小
▶
現況

實測 /sitemaps/creators-0.xml…creators-5.xml 裡全是舊的 /user/<uuid> 網址 — 這些現在每一個都會 301。

為什麼

sitemap 不該放會跳轉的網址。應該直接提交最終的 canonical 網址 /u/<handle>,Google 才不用多繞一層,GSC 也不會報「Sitemap 含跳轉」。

怎麼做

產生 sitemap 時,把每筆 <loc> 從 https://swag.live/user/<uuid> 改成 https://swag.live/u/<handle>(沒有 handle 的創作者不要放進 sitemap)。

怎麼算完成
P1.3 · 止血
統一 JSON-LD identity 到 /u(目前 schema 仍指 /user)
🔴 急工程量 中
▶
重點:不是缺 schema,是 schema 的 URL 指錯。 /u/<handle> 已有 1 組 JSON-LD(Person/ProfilePage),但 entity URL 還停在舊 /user/<uuid>,和 canonical /u 不一致。要做的是把 identity URL 統一過來,不是重新補 schema。
現況

head 的 canonical 與 og:url 都是 /u/olivia__,但 JSON-LD 裡:

canonical = https://swag.live/u/olivia__ Person.@id / url = https://swag.live/user/696796d4e776f36fd9dd11b9 ProfilePage.url = https://swag.live/user/696796d4e776f36fd9dd11b9 Breadcrumb item = https://swag.live/user/696796d4e776f36fd9dd11b9
為什麼

canonical 說代表頁是 /u,schema 卻把 entity 綁在會 301 的舊 /user 上,Google / AI 對「這個創作者的正式 URL 是哪個」收到互相矛盾的訊號,會稀釋 entity 的辨識度。

怎麼做

把 profile JSON-LD 裡所有 @id、url、sameAs、breadcrumb item、significantLink 全部統一到 canonical /u/<handle>;舊 /user 只當 301 redirect,不再當 schema identity。維持下列結構:

<!-- 伺服器端直接渲染在 <head> 或 <body> --> <script type="application/ld+json"> { "@context":"https://schema.org", "@type":"ProfilePage", "mainEntity":{ "@type":"Person", "name":"榛果", "alternateName":"olivia__", "url":"https://swag.live/u/olivia__", "image":"https://.../olivia-avatar.jpg", "interactionStatistic":[ {"@type":"InteractionCounter","interactionType":"https://schema.org/FollowAction","userInteractionCount":16500} ] } } </script>
只宣告畫面上真的看得到的東西(visible-content parity)。例如 schema 寫了粉絲數,頁面上也要顯示粉絲數。
怎麼算完成
P1.4 · 止血
robots.txt 的 Sitemap: 改指新版 /sitemap.xml
🔴 急工程量 小
▶
現況

robots.txt 本身 200、可爬(見已完成區),但裡面 Sitemap: 仍宣告舊的 /sitemaps/* group,沒有指向新版入口 https://swag.live/sitemap.xml。

Sitemap: https://swag.live/sitemaps/index.xml Sitemap: https://swag.live/sitemaps/creators-index.xml ← 6 shard 共 4,667 筆,全是 /user/<uuid>,0 筆 /u Sitemap: https://swag.live/sitemaps/shorts-index.xml Sitemap: https://swag.live/sitemaps/posts-index.xml
為什麼

新版入口 /sitemap.xml 是語系 sitemap index(en / zh-tw / cn / ja / th / vi / ko)。robots 還把 Google 指向舊 group,會讓 Google 與審核者誤以為舊 creators sitemap(全是會 301 的 /user)還是正式入口。應和 Task 1.2 一起:robots 指新版、新版 sitemap 收 canonical /u。

怎麼做
    1. robots.txt 的 Sitemap: 只留新版 https://swag.live/sitemap.xml,移除舊 /sitemaps/* group
    2. 確認新版 sitemap 是否「刻意不收 profile」;若 profile 仍要靠 sitemap 推收錄,新版 loc 必須用 canonical /u/<handle>(接 Task 1.2)
怎麼算完成
02 Batch 2 · Profile 內鏈 · 高效益

把 profile 接上會排名的分類頁

方案:保留現有標籤不動,另外在 profile 上加一排「創作者分類按鈕」,連到既有、已經在排名的 /category/ 頁。資料現成(創作者內容本來就掛在分類上),不用建新頁、不用對照表。

P2.1 · 內鏈核心
Profile 加「創作者分類按鈕」,連既有 /category/
🟠 高效益工程量 中
▶
一句話

巨乳的主播,profile 上就放一顆寫著「巨乳」的按鈕,點了連到巨乳分類頁 /category/big_tits。 每個創作者依他自己的內容分類,放對應的幾顆按鈕。

為什麼這樣做

實測:同一個詞「巨乳」,/category/big_tits 月點擊 134(排第 3),profile 標籤現在連的 /user-feed-grid/... 只有 28(排第 5)。整個 /category/ 有 9,284 點擊、feed-grid 只有 777。把 30 萬個 profile 的內鏈導向會排名的 /category/,等於把內鏈接到真正有效的頁。

怎麼做 — 三個一定要做對的點

① 連對網址:一定是 /category/,不是 /user-feed-grid/

同一個「巨乳」分類站上有兩個網址,按鈕的連結要填會排名的那個:

用途網址月點擊
✅ 要連這個/category/big_tits134
❌ 不要連這個/user-feed-grid/user_hashtag_big_tits28

② 必須是「真的連結」而且伺服器就先寫好(SSR)

「SSR」= 伺服器送出的原始 HTML 裡就要有這個 <a> 標籤,不是等網頁在瀏覽器跑完 JavaScript 才生出來。因為 Google 和 AI 爬蟲讀的是原始 HTML;如果按鈕是 JS 點擊跳轉、或載入後才出現,爬蟲看不到這條連結,內鏈分數就傳不過去。

③ 按鈕上看得到的文字 = 中文分類名(「巨乳」),不要寫「看更多」

連結文字(anchor text)本身就是排名信號。用「巨乳」當文字連到巨乳分類頁,等於告訴 Google「那頁是講巨乳的」,幫它衝這個關鍵字。寫成「看更多」「探索」或只放 icon 就浪費了。

✅ 正確 — 真 <a>、伺服器渲染、文字是中文分類名、連 /category/
<a href="/category/big_tits">巨乳</a> <a href="/category/legs">美腿</a> <a href="/category/uniform">制服</a>
❌ 這幾種都會讓 SEO 效果歸零
<!-- 不是 <a>,是 JS 點擊 → 爬蟲看不到連結 --> <div onclick="go('big_tits')">巨乳</div> <!-- 文字不是分類名 → 浪費 anchor text --> <a href="/category/big_tits">看更多 ›</a> <!-- 連到排不動的 feed-grid --> <a href="/user-feed-grid/user_hashtag_big_tits">巨乳</a>
只連「白名單內的真分類」。 注意:/category/<任何字串> 都會回 200(catch-all),所以連到不存在的 slug 不會 404,反而生出垃圾頁。按鈕只能用「創作者實際所屬、且在 74 個真分類白名單內」的分類。例:美腿用 /category/legs(真分類),不要用 /category/long_legs(不存在、catch-all 假頁)。personality 詞(lovely 等)目前無對應真分類 → 先不放按鈕。
怎麼算完成
03 Batch 3 · Metadata 修正 · 高效益、工程量都很小

讓 SERP 顯示正確的創作者身分

三項都很小,可以一起做。目標:搜尋結果裡每個 profile 都穩定顯示同一個創作者(名字 + handle + 頭像),不出現空模板。

P3.1 · Metadata
Title 改成 顯示名稱 (@handle) 格式
🟠 高效益工程量 小
▶
現況

實測 title = olivia__ 直播、影片及限時動態 — 只有 handle,沒有顯示名稱「榛果」。但 H1 已顯示「榛果」。

怎麼做

改成:<顯示名稱> (@<handle>)｜SWAG 創作者直播、短影音與照片

範例 榛果 Olivia (@olivia__)｜SWAG 創作者直播、短影音與照片
有的資料Title 用
名稱 + handle<名稱> (@<handle>)｜SWAG 創作者…
只有 handle@<handle>｜SWAG 創作者…
兩者都沒有不要 index,也不要放進 sitemap

og:title 用同一份資料來源。

怎麼算完成
P3.2 · Metadata
og:image 改用創作者頭像
🟠 高效益工程量 小
▶
已修復、可勾完成。 抽樣 profile 的 og:image 已是創作者頭像,不是全站通用分享圖,後續只需做 50 個 profile 抽樣驗證。
背景

早期 og:image 曾是 static/img/share.c190bf8a.jpg(全站通用分享圖),現已改為創作者頭像。

為什麼

分享到社群、出現在預覽卡時,每個創作者都用同一張通用圖,辨識度與點擊率都差。

怎麼做

og:image 用該創作者的頭像或 profile 專屬公開圖。只有當創作者完全沒有圖、且該頁 noindex 時,才允許退回通用圖。

怎麼算完成
P3.3 · Metadata · 重點
Meta description 改用創作者資料拼接(不再同一模板)
🟠 高效益工程量 小
▶
範圍:meta description 只放在使用者首頁 /u/<handle>。 tab 子頁(flix/image/short/story)不放 meta description(見 Task 4.4)。
現況

實測每個 profile 的 description 是同一句模板,只換 handle:

發掘更多 olivia__ 限時私密影片,和 olivia__ 進行更深入的交流!立即註冊與追蹤,和 olivia__ 1 對 1 私訊!還有機會與創作者當面約會!

問題:30 萬頁描述幾乎一樣,Google 視為 boilerplate 重複描述;且沒有任何 creator-specific 事實、還有雙空格殘留。

抽多個 handle 都一樣。 hitomibabe / swag / zi_zi 的 title/description 都還是「<handle> 直播、影片及限時動態」同一句模板,只換 handle。
為什麼這個做法「最小改動、最大成效」

標題用到的那幾個數字(貼文、粉絲、內容類型)畫面上 / stats card 裡本來就有,連創作者自己寫的自介也是現成欄位。description 只要把這些現成資料 + 自介拼成一份,不需要新後端、不需要 AI,就讓每頁描述天然不同、還帶創作者本人語氣。一個字串組裝函式 + 缺值整段省略即可。

怎麼做 — 事實段先行,自介段墊後

順序 = ① 事實段 → ② 自介段 → ③ CTA。事實段放最前:它是確定性的、含 name/handle/stats/內容類型,SERP 只顯示前 ~155 字,要讓看得到的那段永遠 keyword 對、即使創作者沒寫自介也不會空白。自介段接在事實後作為「本人語氣」深度;CTA 每頁都一樣、應排在最後(超出顯示範圍也無妨)。目前不限制字元數。

全份用創作者第一人稱口吻:事實段開頭「這裡是…我有…」,接自介(本人口吻),CTA 也用第一人稱(追蹤我…),三段語氣統一、不要混「追蹤她」。「這裡是」會把名字推到第 4 字,仍很前面、SERP 看得到。

段來源 / 模板
① 事實段(模板)這裡是<名稱>(@<handle>)的 SWAG 主頁,我有 <posts> 則貼文、<followers> 粉絲,內容有<content_types>。<固定直播句>(第一人稱)
② 自介段創作者自己寫的 bio 第一段(原話;去換行、去連續空白;取前 1~2 句、約 150 字內,過長才截)。沒填 bio → 整段省略
③ CTA 段(模板)3~5 個變種輪用,依內容類型 / id 雜湊穩定指派(同創作者每次同一句)。第一人稱統一,例:追蹤我,看限時私密內容與 1 對 1 私訊。 / 訂閱我,解鎖完整影片與限時動態。 / 追蹤我,第一時間看新貼文與直播。
✅ 拼出來的範例(事實 → 自介 → CTA)
這裡是榛果 Olivia(@olivia__)的 SWAG 主頁,我有 6 則貼文、16.5k 粉絲,內容有限時動態、短影音、照片。我固定 21:00–22:00 直播。我是榛果,喜歡在深夜陪你聊天的鄰家女孩。追蹤我,看限時私密內容與 1 對 1 私訊。
✅ CTA 變種(直接複製用,工程不用再想)
適用類型CTA 句(第一人稱)
通用 / 預設追蹤我,看限時私密內容與 1 對 1 私訊。
直播為主追蹤我,第一時間看我的新貼文與直播。
直播為主來追蹤我,陪我直播、一起私訊聊天。
影片為主訂閱我,解鎖完整影片與限時動態。
影片 / 照片為主訂閱我,看更多獨家照片與短影音。
互動為主追蹤我,我們 1 對 1 私訊、面對面約會。

指派規則(穩定、不用思考): 取創作者「內容最多的類型」對應的 CTA;同類型有多句時用 creator_id 雜湊固定挑一句(同一創作者每次重整都一樣)。判斷不出主類型 → 直接用「通用 / 預設」那句。

三個 fallback 模板(依資料完整度自動選,確保永遠不出空白):
· A 資料齊全 = ① + ② + ③
· B 無自介 = ① + ③
· C 連 stats 都缺 = <名稱>(@<handle>) + ③
缺值規則照舊:沒粉絲省粉絲句、沒直播省直播句,不填 0、不留雙空格,最後做一次連續空白清理。自介若含外站連結 / 聯絡方式要先濾掉。
CTA 多變種 + 自介加長的兩個護欄:
· CTA 變種要穩定指派:用內容類型或 creator id 雜湊決定拿哪一句,不要每次載入隨機換(描述頻繁變動對 Google 評價不利)。3~5 版即可。
· 自介加長要留上限:拉到第一段 ~150 字可接受,但設硬上限避免內容過長;先濾掉外站連結 / 聯絡方式 / 過多 emoji。事實段固定在最前,SERP 看得到的那段不受影響。
說明:Google SERP 仍只顯示前 ~155 字,超出的部分主要對 AI 引用與長尾比對有幫助;不限制字元數是可行的,僅需留意 SERP 顯示端會截斷。
怎麼算完成
04 Batch 4 · Profile 結構化 · 接著做

把 profile 從孤島變成節點

補上 breadcrumb、相關創作者、榜單回連、子頁處理。讓 profile 跟分類、其他創作者、榜單互相連起來。

P4.1 · 結構化
加 Breadcrumb(麵包屑)+ schema
🟢 後做工程量 小
▶
現況

實測 profile 無 breadcrumb。

怎麼做

頁面上方加:首頁 › 探索 › <主分類> › <創作者>。主分類取「該創作者擁有 creator 數最多」的那個分類(不是隨機第一個),語意最準。每層都是真 <a>,再配 BreadcrumbList schema。

怎麼算完成
P4.2 · 結構化
加「相關創作者」區塊(第一版用同分類抽樣)
🟢 後做工程量 中
▶
現況

實測 profile 上 0 個其他創作者連結 — 每頁都是孤島。

怎麼做

第一版不要做複雜演算法。 直接抓「該創作者主分類 hub 底下的 top 8~12 個其他創作者」做成卡片,每張卡是 <a href="/u/<handle>">。這就補上了創作者之間的互鏈。之後再升級成多因子推薦。

怎麼算完成
P4.3 · 結構化
Profile 回連它上榜的榜單(spoke → hub)
✅ 已實作工程量 小
▶
已實作(2026-06-16 確認)。 profile 原始 HTML 已含 /leaderboard/... 回連;榜單頁 → 創作者(hub→spoke)原本就有。雙向都通了,此項可勾完成。
現況

榜單頁 → 連到創作者(hub→spoke)已經做好了(實測 /leaderboard/asia/... 原始 HTML 有 10 個創作者連結)。反方向:創作者 → 連回榜單,也已實作。

怎麼做

若創作者出現在某榜單(如「亞洲熱門」),profile 上就放一個連到 /leaderboard/asia/livestream/24h 的真連結。

怎麼算完成
P4.4 · 結構化 · 已確認保留
Tab 子頁(flix/short/story…)— 救回收錄,不要放棄
✅ 保留🔧 noindex 修復中工程量 中
▶
保留 tab 子頁,noindex 修復中(與主頁同批)。 依據:GSC 實測 tab 子頁 5 月 = 28,284 clicks / 249,122 曝光(1,650 URL)— 比整個 /category/ 還多,屬獨立搜尋需求。
/user/<id>/flix 已 301 到 /u/<handle>/flix,後者目前仍 noindex(修復中)。修復完成前這 28k 持續暴露於 deindex,故與 Batch 1 同批處理。
現況(實測)
/user/<id>/flix → 301 → /u/<handle>/flix /u/olivia__/story → 200 · noindex,nofollow /u/olivia__/flix → 200 · noindex,nofollow · title「olivia__ | 色情影片」 /u/olivia__/short → 200 · noindex,nofollow · title 卻跟主頁一樣(錯) /u/olivia__/image → 200 · 無 noindex · self-canonical ← 和其他 tab 不一致
注意:這是 URL 翻轉後的新問題,不是「已處理完成」。 舊 /user/<uuid>/(story|flix|short) 原本沒有 noindex;翻到新版 /u 後才被加上 noindex,nofollow,等於把原本可能有收錄的 tab 子頁關掉。更糟的是 /image 又沒被 noindex、self-canonical,形成「部分 tab noindex、部分 tab indexable」的混合狀態。先用 GSC 分 /user/*/(tab) 與 /u/*/(tab) 查 impressions/clicks,再決定保留哪些 tab indexable;/image 要嘛補 noindex 對齊,要嘛補完整獨立頁 SEO。
為什麼保留

這些 tab 子頁 5 月有 28k 點擊,是「創作者名 + 短影音/flix」這類獨立搜尋需求,不是 cannibalize 主頁,值得保留收錄。

怎麼做
    1. 跟 Batch 1 一起,把 /u/<handle>/<tab> 的 noindex 移除
    2. 維持 self-canonical(指自己)— 不要 canonical 回主 profile,否則會被刪
    3. tab 子頁進 sitemap(用 /u/<handle>/<tab>)
    4. 每個 tab 子頁 <title> = 長版、含 SWAG(例「榛果 Olivia 的影片｜SWAG 創作者短影音與照片」);H1 直接調用該 title(同 Task 4.6);子頁不放 meta description(只首頁放,見 Task 3.3)
✅ 每個 tab 子頁:title 長版含 SWAG、H1 = 該 title、無 meta description
子頁<title> = H1(長版、含 SWAG)meta desc
/u/<handle>/flix榛果 Olivia 的影片｜SWAG 創作者直播、短影音與照片無
/u/<handle>/image榛果 Olivia 的照片｜SWAG 創作者直播、短影音與照片無
/u/<handle>/short榛果 Olivia 的短影音｜SWAG 創作者直播、短影音與照片無
/u/<handle>/story榛果 Olivia 的限時動態｜SWAG 創作者直播、短影音與照片無

H1 直接調用上面那條 title(每頁一個、SSR);meta description 只放使用者首頁 /u/<handle>,這 4 個子頁都不放。

怎麼算完成
P4.5 · 結構化
Rendered DOM 只留 1 個 profile H1(移除泛站行銷 H1)
🟢 後做工程量 小
▶
現況(rendered DOM 實測)

profile 載入後,DOM 同時出現兩個 H1:

H1 榛果🌰 ← creator,正確 H1 亞洲最大成人品牌 ← 來自註冊/登入行銷區塊,泛站

另外初始畫面會先出現 Loading...,creator 名稱/stats/自介/tags 要等 CSR 後才進 DOM。

為什麼

profile 頁的 rendered DOM 不應讓泛站 marketing H1 和 creator H1 同級競爭,會稀釋這頁「是講這個創作者」的主題訊號。低渲染 / AI crawler 也可能只吃 head + JSON-LD + 初始 app state,entity 訊號不該只活在 CSR 後的 DOM。

怎麼做
    1. profile route 載入後,第一個也是唯一的 H1 = creator display name
    2. footer / modal / login wall 的大標題改 H2/div,或在 modal 未開啟時不要進可索引 DOM
怎麼算完成
P4.6 · 結構化
H1 改用完整 meta 標題 + 主頁內容區塊補 H2(帶創作者名)
🟠 高效益工程量 小
▶
現況(實測)

profile 主頁已有 SSR H1(實測 <h1>榛果🌰</h1>,GSC 後台也抓得到),但 H1 只是短名稱(部分創作者只有 handle),不是完整 meta 標題;頁面也沒有內容區塊 H2。

為什麼

H1 帶完整描述 = 爬蟲 / AI 在頁面最高層級就拿到完整主題;再用每個內容區塊的 H2「顯示名+內容類型」補出階層、重複強化「創作者 × 內容類型」實體訊號,吃「榛果 照片 / 榛果 短影音」長尾。

怎麼做

① H1 改成完整 meta 標題(= 該頁 <title> 同一份,每頁一個、SSR):

/u/<handle> → <h1>榛果 Olivia (@olivia__)｜SWAG 創作者直播、短影音與照片</h1>

② 主頁內容區塊補 H2(對應截圖那排 tab,用乾淨字):

<h2>榛果的首頁</h2> <h2>榛果的限時動態</h2> <h2>榛果的影片</h2> <h2>榛果的短影音</h2> <h2>榛果的照片</h2>
區塊標題用創作者顯示名(例「榛果」),不用 handle。 內容類型一律乾淨字(影片/照片/短影音/限時動態),不要露骨字。只渲染有內容的區塊(沒照片就不要出現「榛果的照片」)。導覽 tab 標籤維持短的(首頁/影片),帶名字的是區塊 H2。每頁只一個 H1(配合 Task 4.5)。
怎麼算完成
05 Batch 5 · 分類路由修復 · 可獨立排程

堵住 catch-all soft-404

這區跟 Batch 2 解耦,可另外排程。實測重大發現:/category/<任何字串> 都回 200 — 連 /category/asdfqwerty12345 都回 200、H1 印 category_asdfqwerty12345。所以 /category/lovely 這類「不是分類」,只是路由不會 404。真正的分類是 sitemap 裡那 74 個。

P5.1 · 分類路由
未知分類 slug 應回 404 / noindex,不要 soft-200
🟢 後做工程量 小
▶
現況(實測)

/category/<不存在的slug> 一律回 200,H1/title 顯示原始 key category_<slug>。

/category/asdfqwerty12345 → 200 · H1「category_asdfqwerty12345」 /category/lovely → 200 · H1「category_lovely」 ← 不是真分類 /category/big_tits → 200 · H1「巨乳」 ← 真分類
為什麼要修

任何打錯字的內部連結、外部亂連、或猜測式爬取,都會生出一個可索引的 category_xxx 垃圾頁(soft-404 / index bloat)。Google 會浪費 crawl budget 在不存在的分類上。

怎麼做

分類路由先比對「合法分類白名單」(就是那 74 個 + 任何已上線的真分類):

    1. slug 在白名單 → 正常渲染分類頁
    2. slug 不在白名單 → 回 HTTP 404(最好),或至少 noindex + 不在 sitemap
    3. 絕對不要再把 category_<slug> 這種原始 key 當標題印出來
怎麼算完成
P5.2 · 未來方向
分類組合頁(如 巨乳 + 熟女 = 新分類)
🅿️ 之後做工程量 中
▶
未來方向(roadmap)。 「分類組合頁」:把兩個既有分類交集成一個新分類,例如 巨乳 × 熟女,擴充長尾覆蓋。待正式規劃時再展開細節與護欄。
06 Batch 6 · 加值大工程 · 後期

結構化深化 ·具體實現方案

前面做完已能解除風險 + 接上排名;這區是把 profile 變成完整 entity document。執行順序:6.2(純查詢,馬上能上)→ 6.3(加一個欄位)→ 6.1 階段 2(加多個欄位)。先做 6.2。

P6.1 · 大工程
Attribute table(結構化屬性表)
🟢 後做工程量 大
▶
分兩階段,不要一次到位

階段 1(現在、零後台): 只渲染「已經是結構化欄位」的屬性(如地區、語言若本來就有 column)。不要去 parse 自介散文(易出錯、不可靠)。

階段 2(要排程): 後台加 dropdown / number / multi-select 欄位 — 星座(12 下拉)、身高(number)、地區、語言、體型 tag — 由創作者填。

前台 + Schema

前台:兩欄屬性表;自介散文(情緒/故事)另放一個 block,不混進結構化 facts。Schema 對應 Person 欄位:

"height":"164 cm", "knowsLanguage":["zh-TW","en"], "homeLocation":{"@type":"Place","name":"台灣"}
鐵則:visible parity — schema 只宣告畫面上那張表真的顯示的列。沒顯示的不要寫進 schema。
怎麼算完成
P6.2 · 大工程
Stats card 強化(從既有資料 aggregate,零 AI)
🟢 後做工程量 中
▶
為什麼先做這個

全部用既有資料表 aggregate,零後台 schema 改動、零 AI,卻直接補滿 stats card + JSON-LD 的 InteractionCounter。投報率最高,建議在 Batch 6 內優先做。

資料來源(SQL 範例)
影片數 = COUNT(*) FROM contents WHERE creator_id=? AND type='video' AND is_public 照片數 = COUNT(*) FROM contents WHERE creator_id=? AND type='photo' AND is_public 限時動態數 = COUNT(*) FROM contents WHERE creator_id=? AND type='story' 加入日期 = users.created_at 最近上線 = MAX(streams.started_at) WHERE creator_id=? 平均週直播 = COUNT(streams) / weeks_since_join 固定直播日 = MODE(day_of_week) FROM streams (近 90 天)
畫面 + Schema

畫面:6–12 格 stat grid。Schema 只放真有的數據(沒有評分就不要放 AggregateRating):

<script type="application/ld+json"> "interactionStatistic":[ {"@type":"InteractionCounter","interactionType":"https://schema.org/FollowAction","userInteractionCount":16500}, {"@type":"InteractionCounter","interactionType":"https://schema.org/WatchAction","userInteractionCount":<影片數>} ]
怎麼算完成
P6.3 · 大工程
直播時間改成結構化 schedule
🟢 後做工程量 中
▶
現況

直播時間目前是自介裡的一句散文(如「本月固定 21:00-22:00」),機器無法抽取。

怎麼做

後台加「週一～週日 × 時段 × 類型」結構化欄位(取代散文)。前台用週表呈現,每個時段一個 BroadcastEvent:

{"@type":"BroadcastEvent","name":"榛果固定直播", "startDate":"2026-06-22T21:00+08:00","endDate":"2026-06-22T22:00+08:00", "isAccessibleForFree":false}
順序很重要: 若目前只有散文、還沒有結構化欄位,先別硬塞 schema(會與畫面不一致)。等後台欄位上線、畫面真的顯示週表,再加 schema。
怎麼算完成
P6.4 · 大工程
Template entropy(不同類型創作者不同版面)
🟢 後做工程量 大
▶
內容

新人/高人氣/直播型/內容型/退役 用不同的 block 順序與強調,避免 30 萬頁完全同模板。後台規則引擎判斷類型,前端依類型套版。

怎麼算完成
P6.5 · 大工程
Image sitemap title/caption 驗證強化
🟢 後做工程量 中
▶
內容

image sitemap 已有 image:image。驗證 image:title/image:caption 是否 entity-real(含創作者名 + 內容類型),若是模板填充就改成動態生成。

怎麼算完成