TL;DR

  • 一天內對五個公開儲存庫和幾個私人儲存庫執行相同的 SEO + 分析檢查清單。
  • 不同的技術堆疊（Laravel、Next.js、Astro），相同的待辦事項：meta/OG、canonical、sitemap、robots、JSON-LD、由環境變數驅動的分析工具。
  • 結論：SEO 是可以移植的檢查清單，而不是每個專案都要重新發明的功能。

今天是主題日。不是單一儲存庫獲得重大功能，而是整個作品集幾乎都獲得相同的處理：搜尋引擎和分析基礎設施。連續跨不同堆疊進行讓模式變得明顯——概念是相同的，只有語法不同。

跨堆疊移植的檢查清單

每個網站都獲得相同的項目。不同的只是每個框架如何表達它們：

項目 Laravel Next.js Astro
Sitemap artisan 命令 / 路由 sitemap.ts @astrojs/sitemap
Robots 動態 /robots.txt robots.ts public/_redirects + 檔案
Canonical + OG Blade head partial layout.tsx metadata BaseLayout.astro
結構化資料 JSON-LD Blade partial <JsonLd> 元件 內嵌 <script type="ld+json">
Analytics 由環境變數驅動的 GA/GTM NEXT_PUBLIC_GA_ID 由環境變數驅動的 GA

相同的五行，三種語言。一旦你做過一次，剩下的就是翻譯。

公開儲存庫

Laravel 起始套件 Kickoff 獲得最多的變更——完整的管理員可編輯 SEO 和分析基準（我今天將其寫成獨立的文章）。它的行銷網站 kickoff-web 獲得登陸頁面重新設計以及 SEO 基礎設施、標準域名和 hreflang/schema 圖形。

在 Astro 方面，g8suite-web 新增了結構化資料圖形（WebSite / WebPage / Breadcrumb / SoftwareApplication）、OG 圖片和 sitemap 索引。gatherhub-web 獲得 sitemap、robots、canonicals、JSON-LD 和 GA——以及令人滿意的清理，刪除死掉的模板程式碼。而 DevHub 網站 發布了每路由 SEO、生成的 sitemap、環境控制的 GA4，以及新的培訓目錄，每個頁面都有適當的 FAQ schema。

私人工作（匿名化）

在一個私人 Laravel 活動平台上，我執行相同的 SEO 階段——meta/OG 基礎設施、公開頁面的 JSON-LD 結構化資料、管理員可配置的分析工具——然後是效能階段：WebP 圖片轉換、延遲載入和 LCP 優先提示。那裡的可重用想法是：透過小型可呼叫動作類別（BuildEventJsonLd、BuildSitemap）建構 JSON-LD，讓 schema 邏輯可測試且不在視圖中。

我也花時間為即將到來的培訓計畫起草課程內容和行銷圖片包——整理材料，而不是發布程式碼。

結論

將 SEO 視為可移植的檢查清單，而不是每個專案的緊急處理，將一整天的「無聊基礎設施」轉變為快速、可重複的工作。寫一次清單，將它記在腦中（或文件中），每個新專案都從三步開始。