人材獲得競争が激化する昨今、多くの企業が「Indeed（インディード）」の活用を最優先課題としています。CMでの知名度もさることながら、求職者の大半がまず検索を行うプラットフォームとしての地位は揺るぎないものがあるからです。しかし、自社の採用サイト（リクルートページ）を作ったにもかかわらず、「Indeedに掲載されない」「掲載されても情報が古い」「応募ボタンが機能していない」といったトラブルを抱えるWeb担当者や経営者が後を絶ちません。
Indeedは、インターネット上のあらゆる求人情報を収集する「求人検索エンジン」です。GoogleがWebサイトを巡回するように、IndeedのクローラーもWeb上の求人情報を巡回しています。しかし、そこには明確な「ルール（読み込み条件）」が存在します。ただ漫然と採用ページを作るだけでは、Indeedはこの巡回（クローリング）の対象として認識してくれません。本記事では、Indeedに自動掲載され、かつ継続的に連携させるために必須となる「クローリング条件」と「サイト構造の要件」について、技術的・実務的な観点から解説します。
Indeed連携の基本「クローリング」と「直接投稿」の違い
まず前提として、Indeedへの掲載には大きく分けて2つの方法があります。一つはIndeedの管理画面に直接求人情報を入力する「直接投稿型」。もう一つが、自社の採用サイトをIndeedのシステムに読み込ませる「クローリング型」です。
小規模な店舗で1〜2名のアルバイトを募集する程度であれば「直接投稿」でも事足ります。しかし、企業として本格的に採用ブランディングを行い、複数の職種や拠点で募集をかけるのであれば、断然「クローリング型」を目指すべきです。自社サイトを更新するだけでIndeedにも自動反映されるため、管理コストが大幅に削減でき、かつ自社独自のドメインパワーを育てることにも繋がるからです。
しかし、このクローリング型を実現するためには、Indeedが定める「6つの掲載基準」と「技術的要件」をクリアしたサイト構造になっている必要があります。
絶対条件となる「1職種1URL」の原則
Web制作の現場で最も頻繁に見られるミスが、この「1職種1URL」の違反です。
多くの企業サイトでは、採用情報ページに「営業職」「事務職」「エンジニア」の募集要項を1つのページ内に羅列してしまっています。人間が見れば理解できますが、Indeedのクローラーはこれを「1つの求人」として正しく認識できません、あるいは「複数の情報が混ざった不明瞭なページ」として弾いてしまいます。
Indeedにクローリングさせるためには、必ず「営業職のページ（URL-A）」「事務職のページ（URL-B）」というように、職種ごとに固有のURL（詳細ページ）が存在する階層構造にする必要があります。一覧ページだけでは不十分なのです。この構造設計ができていない時点で、クローリング連携の道は閉ざされます。
応募プロセスはシンプルかつ完結しているか
Indeedは「求職者ファースト」を掲げるプラットフォームです。そのため、応募までの導線が複雑なサイトは嫌われます。
求人詳細ページを見たユーザーが、「応募する」ボタンを押した際、すぐにエントリーフォームへ移動できる構造になっていることが必須条件です。
よくあるNG例として、応募ボタンを押すと「会員登録」を求められたり、PDFの募集要項が開くだけだったり、あるいは「電話してください」としか書いていないケースがあります。Indeedは「Web上で応募が完結すること（または明確な連絡先への導線があること）」を求めています。特に、応募のためにユーザー登録（ログイン）を強制する仕様は、クローリング審査で落ちる最大の要因の一つです。
モバイル対応（スマホ最適化）は不可欠
現在、求職者の8割以上がスマートフォンで仕事を探しています。そのため、Indeedもモバイルフレンドリーでないサイトを評価しません。
画面サイズに合わせてレイアウトが最適化されていることはもちろん、文字サイズが読みやすいか、タップ要素（ボタンなど）が押しやすい配置になっているかどうかも重要です。PCで見れば綺麗なサイトでも、スマホで見た時に崩れていたり、文字が小さすぎたりすれば、掲載対象外となるリスクが高まります。
画像ではなく「テキスト」で情報を記述する
デザイン性を重視するあまり、募集要項のすべてを「画像」で作っているサイトを見かけます。オシャレなチラシのような画像を一枚貼り付けているパターンです。
しかし、Indeedのクローラーは画像を「文字情報」として読み取ることができません。つまり、どんなに素晴らしい待遇や条件が書かれていても、システム上は「白紙のページ」と同じ扱いになります。
職種名、仕事内容、勤務地、給与、条件などの必須項目は、必ずHTMLテキストとして記述する必要があります。デザインとしての画像はあくまで補助的な要素であり、情報の本体はテキストデータとして構築しなければなりません。これはGoogleしごと検索（Google for Jobs）への対応においても同様に重要となるポイントです。
構造化データ（JobPosting）の実装
ここからは少し技術的な話になりますが、確実に連携させるための「切り札」となるのが「構造化データ」の実装です。
構造化データとは、検索エンジンのロボットに対して「このページは求人情報であり、給与はいくらで、勤務地はここです」と、機械が理解できる言語（JSON-LDなど）でタグ付けを行う技術です。
Schema.orgという規格に基づいた「JobPosting」という構造化データを各求人ページに埋め込むことで、IndeedやGoogleのクローラーは瞬時に内容を理解し、正確にインデックスします。見た目のデザインには影響しませんが、この裏側の記述があるかないかで、掲載の確実性とスピードは劇的に変わります。CagraPROが構築する採用サイトでは、この構造化データを標準仕様として実装しています。
採用コストを下げるための「資産」としてのWebサイト
Indeedにクローリングされる仕様で自社サイトを作ることは、単なる技術的な対応以上の意味を持ちます。それは、採用活動を「フロー（掛け捨て）」から「ストック（資産）」へと転換させる経営判断です。
多くの企業は、採用のたびに求人媒体に数十万円の掲載費を支払っています。しかし、掲載期間が終われば情報は消え、またゼロからのスタートです。
一方で、Indeed連携型の自社サイトを持っていれば、求人が発生した瞬間に自社サイトに記事をアップするだけで、無料でIndeed上に掲載が開始されます（有料オプションを使えばさらに露出を増やせますが、基本掲載は無料です）。
また、自社サイトであれば、文字数制限やフォーマットの制約もありません。自社のカルチャー、先輩社員の声、オフィスの雰囲気などを十分に伝え、ミスマッチのない質の高い応募者を集めることが可能です。
掲載後の運用と「鮮度」の管理
無事にIndeedに掲載された後も、放置は厳禁です。募集が終了した求人は速やかに非公開にする、あるいは削除する必要があります。
終了した求人がいつまでも掲載され続けていると、応募者に迷惑をかけるだけでなく、Indeedからの信頼スコア（ドメイン評価）が下がり、他の求人まで表示されにくくなる「ペナルティ」を受ける可能性があります。
正しいWeb制作パートナーであれば、こうした運用フェーズまで見越して、「募集終了ボタンを押せば自動的に404（非公開）扱いになり、Indeedのフィードからも消える」といったCMSの挙動を設計します。手動での連携解除が必要なシステムでは、現場の運用ミスが必ず発生するからです。
採用サイトは「攻め」の拠点である
「とりあえず採用ページがあればいい」という時代は終わりました。これからの採用サイトは、検索エンジンや求人プラットフォームと有機的に連携し、自動的に求職者を連れてくる「集客装置」として機能しなければなりません。
Indeedのクローリング条件を満たすことは、Webサイトとしての「品質証明」でもあります。使いやすく、情報が整理され、技術的にも正しいサイトであることの証だからです。
もし現在の採用サイトからの応募が少ない、あるいは媒体費ばかりがかさんでいるとお悩みであれば、一度サイトの「構造」を見直すべきタイミングかもしれません。デザインのリニューアルの前に、まずは「つながる構造」への改修を。CagraPROは、採用に強いWebサイト構築で、御社の人材戦略を足元から支えます。
著者：清宮 雄（株式会社カグラ 代表取締役） マーケティング、ブランディングおよび企業経営の領域において20年以上の実務経験を有する。国内外にてIT事業および教育事業を展開。