TL;DR
- 1日で5つの公開リポジトリと数件のプライベートリポジトリに対して同じSEO + アナリティクスチェックリストを実行。
- 異なるスタック(Laravel、Next.js、Astro)で同じ作業内容:meta/OG、canonical、sitemap、robots、JSON-LD、環境変数駆動のアナリティクス。
- 教訓:SEOは移植可能なチェックリストであり、プロジェクトごとに発明する機能ではない。
今日はテーマデーでした。1つのリポジトリに大きな機能を追加する代わりに、ポートフォリオ全体に同じ処理を適用しました:検索エンジンとアナリティクスの基盤整備。異なるスタックで連続して行ったことで、パターンが明確になりました — 概念は同一で、構文のみが異なるのです。
チェックリストを異なるスタックに移植
すべてのサイトで同じ項目を適用しました。違いは各フレームワークでの表現方法だけでした:
| 項目 | 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">
|
| アナリティクス | 環境変数駆動のGA/GTM | NEXT_PUBLIC_GA_ID |
環境変数駆動のGA |
同じ5行、3つの言語。一度行えば、あとは翻訳するだけです。
公開リポジトリ
Laravelスターターキット Kickoff で最も大きな変更がありました — 管理者編集可能なSEO & アナリティクスのベースライン全体(今日別の投稿でこれについて書きました)。そのマーケティングサイト kickoff-web はランディングページの再設計に加え、SEO基盤、正規ドメイン、hreflang/schemaグラフを取得しました。
Astro側では、g8suite-web が構造化データグラフ(WebSite / WebPage / Breadcrumb / SoftwareApplication)、OG画像、サイトマップインデックスを取得しました。gatherhub-web はsitemap、robots、canonicals、JSON-LD、GAを取得し — さらに不要なテンプレートコードを削除する満足のいくクリーンアップパスも実施しました。そして DevHubウェブサイト はルートごとのSEO、生成されたsitemap、環境変数制御のGA4、新しいトレーニングカタログ、各ページの適切なFAQスキーマをリリースしました。
プライベート作業(匿名化)
プライベートのLaravelイベントプラットフォームで同じSEOフェーズを実行しました — meta/OG基盤整備、パブリックページのJSON-LD構造化データ、管理者設定可能なアナリティクス — その後パフォーマンスフェーズ:WebP画像変換、レイジーローディング、LCP優先ヒント。そこでの再利用可能なアイデア:小さな呼び出し可能なアクションクラス(BuildEventJsonLd、BuildSitemap)でJSON-LDを構築することで、スキーマロジックをテスト可能にし、ビューから分離することです。
また、近日開催予定のトレーニングプログラム向けにコースコンテンツとマーケティング画像パックのドラフト作成にも時間を費やしました — 資料の整理であり、コードの出荷ではありません。
まとめ
SEOをプロジェクトごとの大騒ぎではなく移植可能なチェックリストとして扱うことで、「退屈なインフラ」の1日を高速で反復可能な作業に変えることができました。リストを一度書き、頭の中(または文書)に保持すれば、新しいプロジェクトは3歩先から始まります。
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.