arunacharya1603/seo-engineering

SEOエンジニアリングスキル

ミッション

有用なページを、発見可能で、理解可能で、検索対象として適格で、信頼でき、技術的に信頼性が高く、ビジネス成果につなげられるものにすることで、プロジェクトが関連性のある持続可能なオーガニック（自然検索）の可視性と質の高い訪問を獲得できるように支援します。

このスキルはプロジェクトに依存しません。実際のビジネス、オーディエンス、市場、CMS/フレームワーク、ホスティング環境、検索エンジン、およびユーザーリクエストに適応させてください。調査が完了するまでは、プロジェクトがNext.js製である、ブログである、ECサイトである、ローカルビジネスである、特定のドメインであると想定しないでください。

どのような手法であっても、インデックス登録、リッチリザルト、AI引用、トラフィック、リード、またはランキングポジションを保証するものではありません。 検索エンジンは、ページのクロール、インデックス登録、ランキングを行うかどうか、その方法を選択します。テストされたことと推測されたこととを正確に区別してください。

非妥協的な運用原則

1. 編集前に監査する。 リポジトリ、可能であればデプロイされたサイトを検査します。既に機能しているものを特定します。正しい設定と既存のSEO資産（SEO equity）を維持します。
2. 人優先、証拠に基づく。 キーワード密度、恣意的なコンテンツ量、またはチェックリストの完了ではなく、訪問者のタスクとビジネス上の関連性のために最適化します。
3. 最新のドキュメントが優先される。 検索機能、スキーマの対象要件、スパムポリシー、API、クローラー、ツールの変更によって影響を受ける主張については、公式の最新検索エンジンドキュメントを確認してください。Google Search Central、Bing Webmasterドキュメント、および公式のフレームワーク/プラットフォームドキュメントを優先します。コミュニティの記事は仮説を提供するかもしれませんが、公式のガイダンスを覆すものではありません。
4. 最小限で、元に戻せる変更。 確認された問題を修正するための最小限の実装を行います。許可なく、無関係なコードのリファクタリング、ドメイン/DNS/ネームサーバーの変更、認証情報のローテーション、認証トークンの削除、ホスティングの変更、またはプロダクションへのデプロイを行わないでください。
5. 決して証拠を捏造しない。 キーワードボリューム、ランキング難易度、被リンク、トラフィック、競合他社、インデックス状態、パフォーマンス測定、著者の資格、レビュー、構造化データの事実、または成功したテスト結果をでっち上げないでください。
6. ランキング保証やスパムは禁止。 クローキング、隠しキーワードテキスト、キーワードスタッフィング、ドアウェイページ、スケール化された低品質コンテンツ、リンクスキーム、偽のレビュー、誤解を招くスキーマ、またはランキング操作を主な目的とする自動生成コンテンツを推奨しないでください。
7. 関心事を分離する。 クローラビリティ（クロール可能性）、インデクサビリティ（インデックス可能性）、ランキング、検索結果での表示、コンバージョンは別個のものです。1つの技術的変更がすべてを解決すると主張するのではなく、関連するレイヤーを修正します。
8. 機密データを安全に保つ。 レポート、コミット、ログ、または生成された例で、シークレット、APIキー、顧客情報、分析識別子、またはプライベートページを公開しないでください。
9. 既存のアーキテクチャを尊重する。 実装を選択する前に、スタック、命名規則、ルーティングモデル、デプロイプロセスを理解してください。依存関係を導入するよりも、確立されたプロジェクトパターンを優先します。
10. 不確実性を明確に報告する。 外部アクセス、認証情報、ネットワークアクセス、またはプロダクションテストが利用できない場合は、何が未検証のままかを述べ、安全な手動チェックを提供します。

ワークフロー概要

本格的なSEOタスクの場合は、以下の順序に従います。

1. サイトとビジネスを理解する。
2. ベースラインを確立し、実装を検査する。
3. 必要に応じて、最新の検索エンジン要件を調査する。
4. 優先順位付けされた診断と提案計画を作成する。
5. 承認された必要な変更のみを実装する。
6. 関連するテストを実行し、実際のレンダリング/デプロイされた動作を検査する。
7. 変更内容、証拠、残存リスク、およびモニタリング手順を報告する。

焦点を絞ったリクエスト（例：1つのタイトルタグを改善する）の場合は、このワークフローの関連部分のみを使用しますが、それでも副作用をチェックし、根拠のない主張を避けてください。

1. プロジェクトとその目標を発見する

コードを提案する前に、リポジトリとデプロイの手がかりを検査します。該当するものを特定します。

• ビジネス/サイトの目的、オーディエンス、提供物、マネタイズモデル、主要なコンバージョン、地理的/言語的ターゲット。
• サイトタイプ：情報提供、コンテンツパブリッシャー、SaaS、マーケットプレイス、EC、ローカルビジネス、ポートフォリオ、ドキュメンテーション、フォーラム、出版社、ハイブリッド。
• フレームワーク/CMSとバージョン、ルーター、レンダリング戦略、コンテンツソース、パッケージマネージャー、ビルド/リンター/テストコマンド、既存のSEOライブラリ。
• ホスティング/CDN/エッジ設定、ドメインバリアント、リダイレクト、環境設定、ステージング環境とプロダクション環境。
• ルートタイプ：ホームページ、サービス/カテゴリ、詳細ページ、ブログ/記事、著者、検索結果、タグ/カテゴリ、ページネーション、フィルター/ファセットURL、商品バリアント、ローカライズされたルート、エラーページ。
• 既存の分析および検索ツール：Google Search Console、GA4またはその他の分析ツール、Bing Webmaster Tools、ログアクセス、ランクトラッキング、クロールレポート、コンバージョントラッキング、同意管理プラットフォーム。
• 既存の技術的決定：正規ホスト、サイトマップ戦略、robotsルール、リダイレクト、構造化データ、hreflang、インデックス化ポリシー、メタデータテンプレート、内部リンク。

リポジトリや提供されたコンテキストがすでに答えている情報を要求しないでください。重要な事実が確定できない場合は、明示的な仮定を立てて続行するか、決定が本当にそれに依存する場合に限り、簡潔な質問を1つ行います。

2. ベースラインを確立し、サイトをクロールする

環境に適した利用可能なツールを使用します。ファイル名だけに基づく仮定よりも、代表的なクロールとターゲットを絞ったコード検査を優先します。

リポジトリ検査

関連するファイルとソースパスを検査します。これには以下が含まれますが、これらに限定されません。

• パッケージ/設定ファイル、フレームワーク設定、ホスティング/デプロイ設定、ミドルウェア/プロキシとリダイレクトルール。
• ルートおよびネストされたレイアウト、ルート/ページモジュール、メタデータヘルパー、コンテンツスキーマ、CMS設定、テンプレート、共有ナビゲーション/フッターコンポーネント。
• sitemap.xmlまたはサイトマップ生成コード、robots.txt、正規化ロジック、リダイレクト、URLビルディングヘルパー。
• 構造化データジェネレーター、画像/ビデオコンポーネント、分析/同意設定、404/410ハンドリング。
• 既存のテストとCIチェック。

.envの値やその他のシークレットをダンプしないでください。値を出力せずに、必要な変数が存在するかどうかを確認します。

許可された場合のライブサイト検査

代表的なURLクラスをテストし、レスポンスとレンダリングされたHTMLを検査します。以下を取得します。

• ステータスコード、リダイレクトチェーン、最終URL。
• 正規タグ、タイトル、メタディスクリプション、robotsディレクティブ、robotsヘッダー。
• raw HTMLおよびJavaScriptが関与する場合はレンダリングされたHTMLのメインコンテンツ。
• 内部リンク、サイトマップへの記載、構造化データ、明らかな重複バージョン。
• モバイルレンダリング、明らかなレンダリング失敗、利用可能なパフォーマンスデータ。

最低限、ホームページ、主要なコンバージョン/サービスページ、主要な一覧ページ、代表的な詳細ページ、ブログ記事（該当する場合）、カテゴリ/タグ/フィルターページ（該当する場合）、有効なクエリ文字列URL、および存在しないURLをサンプリングします。大規模サイトの場合は、クロールサンプルを作成し、テンプレートごとにセグメント化します。すべてのURLをクロールしたと主張しないでください。

ベースラインの証拠

変更前の利用可能なベースラインを記録します：テンプレートごとのURL数、レスポンスステータスの分布、インデクサビリティ、正規URLの一貫性、サイトマップエラー、オーガニッククリック/インプレッション/CTR/ポジション、コンバージョン、Core Web Vitals、関連するビジネス成果。不足している測定値をでっち上げないでください。

3. 問題を合理的に優先順位付けする

曖昧なSEOスコアではなく、重大度と確信度を使用します。実用的な優先度スケール：

• P0 — 重大： サイト全体のnoindex、偶発的なrobotsブロック、主要ルート全体での誤った正規URL、リダイレクトループ、プロダクション停止、広範囲にわたる5xxエラー、失われたドメイン/URL移行、セキュリティ侵害、または重要なページがアクセス/インデックス可能であることを妨げるその他の問題。
• P1 — 高： 重要な収益/コンテンツページがブロックされている、誤って正規化されている、ナビゲーション/サイトマップから除外されている、実質的なコンテンツをレンダリングしていない、誤ったステータスを返している、またはシステム的なテンプレートの欠陥がある。
• P2 — 中： 重要なメタデータ/構造化データ/内部リンク/パフォーマンスの問題、孤立したセクション、重複ページ、不十分なコンテンツカバレッジ、または重大なコンバージョン障害。
• P3 — 低/機会： マイナーなコピー改善、影響の少ない洗練、オプションの構造化データ、孤立したaltテキストのギャップ、または推測的なコンテンツ機会。

各発見事項について、以下を記載します：証拠、影響を受けるURL/テンプレート、推定されるユーザー/検索への影響、確信度、実装労力、リスク、推奨事項、検証方法。重大度と確実なランキング変更を同一視しないでください。

4. 技術的SEO：クローリング、インデックス作成、URL、ステータスコード

クローラビリティとインデクサビリティ

• クロールアクセス（robots.txt、サーバーレスポンス、到達可能なリンク）、インデックス化指示（noindex、正規化シグナル、ステータス）、正規URLの選択、およびランキングを分離します。
• 重要な公開コンテンツが、通常のクロール可能なリンクを通じて到達可能であり、正常に応答することを確認します。
• noindexは意図的にのみ使用します。robots.txtはクロールをブロックするものであり、検索結果からURLを削除する信頼性の高い方法ではなく、クローラーは通常、ページレベルのnoindexディレクティブを確認するためにページをフェッチする必要があることを忘れないでください。
• 意図的かつ検証済みでない限り、重要なコンテンツのレンダリングや理解に必要なリソースを禁止（disallow）しないでください。
• ログイン、アカウント、管理、チェックアウト、内部検索、プレビュー、ステージング、プライベートエリアは、適切に検索から除外します。プライベートコンテンツは認証で保護します。robots.txtはアクセス制御ではありません。
• 欠落しているページは、ソフト404の200を返すのではなく、適切な404または410を返すようにします。無関係な削除されたURLをホームページにリダイレクトしないでください。
• すべてのURLのインデックス化を強制しないでください。一部のフィルター、内部検索結果、薄いタグページ、重複バリアント、ユーティリティページはインデックス化に値しない場合があります。
• クロールバジェットの最適化は、非常に大規模または頻繁に更新されるサイトのための専門的な関心事として扱い、小規模サイトの儀式としては扱いません。

正規化とURL正規化

• 実際のビジネス上の決定、ドメイン設定、既存のSEO資産に一致する、優先されるプロトコル/ホスト/パス形式を選択します。wwwまたは非wwwが本質的に優れていると想定しないでください。
• 正当な重複URLについては、適切な場合、恒久的リダイレクト、正規リンク要素、内部リンク、サイトマップURL、構造化データURLを整合させます。
• インデックス可能な各ページには、正しい絶対正規URLを使用します。無関係なコンテンツやすべてのページをホームページに正規化しないでください。
• リダイレクトを強い正規化シグナル、rel="canonical"を強いシグナル、サイトマップへの記載をより弱いシグナルとして扱います。これらはシグナルであり、絶対的なコマンドではありません。
• 正規ターゲットをインデックス可能、クロール可能、正常、かつ関連性のあるものに保ちます。リダイレクトチェーンとループを避け、最終的な宛先への直接リダイレクトを使用します。
• 正当なクエリパラメータを盲目的に取り除かないでください。URLを正規化する前に、キャンペーントラッキング、フィルター、ページネーション、ソート、商品バリアント、アプリケーション機能を理解します。
• 変更する明確な理由がない限り、既存の価値のあるURLを維持します。

リダイレクトとエラー

• URLが恒久的に移動し、プラットフォームが正しくサポートしている場合は恒久的リダイレクト（301または308）を使用します。一時的な条件には一時的なリダイレクトを使用します。
• 意図されたサイトアーキテクチャに従ってのみ、HTTP/HTTPS、www/non-www、末尾スラッシュの動作をテストします。
• ホスト名またはプロトコルの正規化中に、パスと意味のあるクエリパラメータを保持します。
• APIエンドポイント、アセット、サブドメイン、無関係なパスをキャッチする広範なルールを避けます。
• URL変更の場合、実際の同等物が存在する場合は、古いURLから新しいURLへの一対一のマッピングを作成します。古いURLは、無差別にホームページにリダイレクトするのではなく、最も近い関連する代替にリダイレクトします。
• デプロイされた環境でステータスコードとリダイレクトホップを検証します。ローカル設定だけではプロダクションの動作を証明できません。

JavaScriptとレンダリング

• 主要なコンテンツ、ページタイトル、メタデータ、正規ヒント、リンク、構造化データがクロール可能/レンダリングされた出力に存在することを確認します。
• スタックとサイトに適切な場合は、サーバーサイドレンダリング、静的生成、またはプリレンダリングを使用しますが、SEOの迷信だけでフレームワークを移行しないでください。
• 重要なナビゲーションを通常の<a href="...">リンクでクロール可能にします。発見のためにクリックハンドラーやアクセス不可能なアプリシェルのインタラクションのみに依存しないでください。
• 必須のインデックス可能コンテンツを明らかにするために、ユーザーインタラクション、認証、または遅延クライアント専用エフェクトに依存しないでください。
• 初期HTMLとJavaScriptレンダリング後のHTMLとの間で、正規URLまたはrobotsの値が競合しないようにします。JavaScriptがメタデータを変更する場合は、レンダリングされた出力を検査します。
• 矛盾するメカニズム間でメタデータを重複させる代わりに、フレームワークネイティブのメタデータおよびルーティングシステムを使用します。

サイトマップXML

• 可能な場合は、実際のルート/コンテンツソースからサイトマップを生成します。
• インデックス可能であるべき優先正規URLのみを含めます。リダイレクト、noindexURL、エラー、プライベートページ、無関係なURLバリアントは除外します。
• 一貫して絶対URLと優先ホスト/プロトコルを使用します。
• 適格なコンテンツが公開、更新、または削除されるたびに、サイトマップを自動的に更新します。
• 実際の実質的な変更日によってサポートされる場合にのみ、意味のあるlastmod値を使用します。デプロイのたびにすべての日付を更新しないでください。
• サイトマッププロトコルの制限を尊重します。スケールや保守性が正当化される場合は、サイトマップインデックスとセグメント化されたサイトマップを使用します。複数のサイトマップは本質的にランキングを向上させるものではありません。
• XML構文、レスポンスステータス、コンテンツタイプ、URL数、サンプルURLを検証します。許可されている場合は、Search Consoleのサイトマップレポートを確認します。
• サイトマップの送信がクロール、インデックス作成、またはランキングを保証するものではないと主張しないでください。

robots.txtとディレクティブ

• 編集前に既存のディレクティブを検査します。ルールが間違っているか、明確に文書化された目的がない限り、ルールを維持します。
• 適切な場合にサイトマップの場所を追加し、それが正規のサイトマップURLであることを確認します。
• robots.txtのクロールディレクティブと、meta robotsおよびX-Robots-Tagのインデックス化ディレクティブを区別します。
• 特に注意してください

（以下、翻訳は省略されました）