入力は1社の雇用主のレビューページであり、実行の規模は見つけ出すものではなく、あなたが決めるものです。
クエリは企業です。Indeedの企業ページの完全なURL - https://www.indeed.com/cmp/TEKsystems - を渡すこともできますし、そこに含まれる識別子だけ、TEKsystems でも構いません。公開リファレンスは1リクエストあたり 1000 クエリを上限としているので、雇用主のリストは千件の仕事ではなく1件の仕事になります。
何件のレビューが返るかはあなたが選びます。文書化された limit は既定で1クエリあたり 100 件で、料金は行単位なので、これが請求額を決めるパラメータです。他の2つは規模ではなく切り取り方を左右します。sort は helpfulness または rating_desc を取り、cutoff は対象としたい最も古いタイムスタンプを取ります。リファレンスは、cutoff を使うと sort が無効になり、最新のレコードが先頭に来ると注記しています。
この違いが効いてくるのは、企業のレビューページがたいてい、書き出したい分量よりはるかに長いからです。私たちが取得したどの行にも review_count --Indeedがその雇用主について保持しているレビューの総数--が、実際に依頼したひと握りの件数と並んで入っていました。そして2つの数字はまるでかけ離れていました。深さは意識して決めてください。エクスポートが代わりに決めてはくれません。
組み立てる検索も、再現するフィルタもありません。雇用主を指名し、どこまで深く取るかを伝えるだけです。
/cmp/ に続く識別子だけでも構いません。複数社を一度に扱っても同じ1件の仕事です--リファレンスは1リクエストあたり最大1000クエリを認めています。
私たちが測定したヘッダーを、この順に並べたものです。説明が充足率に触れている箇所は、1社の雇用主に対する実際の40件のレビューから数えた数字です。列が存在することとその形を確かめるには十分で、その企業以外でどれくらいの頻度で埋まるかを述べるには足りません。
July 1, 2026 - であって、ISO形式ではありません。並べ替える前に解析してください。rating と違って文字列として届きます。?id= でもあり、url の末尾に付いていました。40件すべてが異なる値でした。5つのカテゴリ別評価は、5つの項目ではなく1つの項目です。 私たちの40行では、comp_benefits_rating、culture_rating、management_rating、job_security_rating、worklife_rating がちょうど同じ17行で埋まり、同じ23行で空でした。一部だけということは一度もありません。Indeedはこれらを任意のまとまりとして尋ねるので、列ごとに確かめるのではなく、5つ全部かゼロかで設計してください。さらに、これらは文字列として届く一方 rating は数値として届きます。表計算ソフトが隠し、スクリプトが隠してくれない類の違いです。
いずれも手元にある40件のレビューから測定したものです。Indeedのレビューフォームとエクスポートの性質であって、それらへの意見ではありません。
どのレビューも16文字の review_id を持ち、私たちの40行すべてで、それはちょうど ?id= の値であり、そのレビューの url の末尾に付いているものでした。40件すべてが異なっていました。同じ雇用主を再取得したときに重複排除すべき列はこれです。さらに、IDからリンクを組み立てることも、誰かに送られてきたリンクからIDを取り出すことも、照会なしにできるということでもあります。
date は July 1, 2026 という形で届きます--Indeedがレビュー上に印字している言い回しそのままで、私たちのどの行もこの形に一致しました。アルファベット順に並べれば無意味になり、解析するまで月ごとの集計もできません。取り込み時に済ませてください。レビュー自体は2回の実行のどちらでも新しい順で届きましたが、それは便利なだけで、本物の日付列の代わりにはなりません。
aggregate_rating と review_count は雇用主単位の事実が各行に繰り返されたものです--企業全体のスコアと、Indeedがその企業について保持しているレビュー数。aggregate_rating を行全体で平均しても同じ値が返るだけですし、行を数えることはレビューを数えることではありません。私たちのエクスポートでは、review_count が示す母集団は、依頼した切り取りの何倍もの大きさでした。どちらを使うにも、まず企業でグループ化してください。
Indeedは投稿者がどちらも省略することを許しており、実際に多くが省略します。私たちの40行では job_title が32行、location が29行にありました。入っているのは自由記述で、勤務地には「市, 州」の組、州名だけ、小文字での入力が含まれていました。どちらの列も、整形なしに結合キーやファセットに使うのは危険で、存在を前提にするのも危険です。location で絞り込めば、そこを一度も埋めなかった投稿者が黙って落ちます。
ある企業のレビューが、終わりのないスクロールよりも表として役立つ場面。
自社のIndeedページは、候補者が最初に確認するものであり、社内の誰もが最後まで体系的に読まないものです。書き出せば、実際に作業できるものになります。current_employee で退職者と在籍者を分け、job_title でグループ化してどの職能が不満を抱えているかを見て、5つのカテゴリ別スコアが残されているところではそれを読む--どれが平均を押し下げているのかを当て推量しなくて済みます。
人材を争っている企業のリストをまとめ--リファレンスは1リクエストで最大千件を認めています--それぞれについて同じ深さのレビューを取得します。aggregate_rating は見出しレベルの比較を無償で与え、レビュー本文はその数字が何でできているかを語ります。誰もあなたのために書いたわけではないぶん、給与調査よりはるかに正直な指標です。
同じ企業を一定の間隔で取得し、review_id で重複を排除する。積み上がるのは新しいレビューだけです。それは静的なページを信号に変えます--同じ職種から続く低評価や、組織再編後の急な増加は、他の誰もが見ている平均値が動くよりずっと早く、差分の中に見えます。
サブスクリプションなし、最低利用額なし、席数ライセンスなし。最初の500行は当社負担、その後は従量課金です。
新規アカウントごとに1回限り。クレジットカード不要。すべてのスクレイパーが利用できます。文書化された既定値である1社あたり100件のレビューなら、何も支払う前に5社を丸ごと取得できる計算です。
レビュー1,000件でおよそ2ドル。limit が1社あたり何件返るかを決めるので、請求額はあとから判明するものではなく、前もって選ぶものです。100社を各50件でも、50社を各100件でも、支払いは同じです。
多数の企業にまたがる雇用主評価を繰り返し追うチーム向けに、ボリューム料金、SLA、専用ワーカー、個別のオンボーディングをご用意しています。数量をお知らせいただければお見積もりします。
LIVESCRAPER10 をご利用ください。働く人は勤め先を複数の場所で評価しており、サイトごとに集まる層も少しずつ違います。この2つはIndeedが覆わない範囲を埋めます。
短い答えはイエスです。ただし、当社の大半のスクレイパーには当てはまらない注意点が1つあります。
Indeedの企業レビューページは公開されています。アカウントなしで誰でも読むことができ、公に見えるページを調査目的で収集することは長く確立された慣行です。データが公開されており、その処理がサイトの動作を妨げない限り、これを禁じる連邦法はありません。
注意が必要なのは、レビューを書くのが人であり、求人と違ってレビューは人について語りうるからです。Indeedは名前を付けません--このエクスポートに投稿者名の列はありません--が、job_title、location、date を組み合わせれば小さなチームを1人にまで絞り込めますし、本文が上司の名前に触れていることもあります。ここから導いたものを公開したり共有したりするなら、集計してください。保存するなら、ファイルに名前がなくても個人データとして扱ってください。
Indeedの利用規約は自動化されたアクセスを制限しているため、これは依然として規約上の問題です。当社はログインの先にあるものには一切触れず、データ層でサードパーティのトラッカーを動かすこともなく、エクスポートは30日後に自動削除されます。
最も多くいただく質問です。ほかにご不明な点があればお問い合わせください。回答を書いているのはボットではなく人間です。
https://www.indeed.com/cmp/TEKsystems のようなIndeedの企業ページの完全なURLか、そこに含まれる識別子だけ、TEKsystems を受け付けます。1リクエストあたり最大 1000 クエリのバッチ処理に対応しているので、雇用主のリストは1件の仕事で済みます。query、company、aggregate_rating、review_count、rating、title、review、job_title、location、date、current_employee、helpful、unhelpful、comp_benefits_rating、culture_rating、management_rating、job_security_rating、worklife_rating、url、review_id、status。レビュー1件につき1行です。このヘッダーは、この形を持つ私たちのどの実行でも--データが入っていてもいなくても--同一でした。limit は既定で1クエリあたり 100 件で、料金が行単位である以上、これが請求額を決めるパラメータになります。各行の review_count は、Indeedがその雇用主について保持しているレビューの総数を示しており、通常は取得した切り取りよりずっと大きな数です。両者を取り違えないでください。sort は helpfulness か rating_desc を受け付け、cutoff は対象としたい最も古いタイムスタンプを取ります。リファレンスによれば後者は sort を無効にし、最新のレコードを先に返します。fields は列を絞ります。私たちの2回の実行では、並び順を設定しない状態でレビューは新しい順に届きました。comp_benefits_rating、culture_rating、management_rating、job_security_rating、worklife_rating がちょうど同じ17行で埋まり、同じ23行で空でした。一部だけ入っていることはありません。ですから5つではなく1つを判定すれば足りますし、相当な割合のレビューが全体の rating しか持たないと見込んでください。もう1つの罠として、5つは文字列で届く一方 rating は数値で届きます。review_id で重複を排除してください。これはそのレビューに対するIndeed独自の16文字の識別子で、私たちの40行すべてで異なっており、そのいずれの行でも同時に ?id= であって、そのレビューの url の末尾に付いていました。本文や日付で突き合わせると、本来別のレビューを1つにまとめてしまいます。短い本文は重複しますし、日付を共有するレビューも多いからです。job_title、location、date の組み合わせは、小規模な雇用主では依然として個人を特定しうる点にご注意ください。公開する前に集計してください。Indeedは非常に多くの雇用主について従業員レビューを蓄えており、多くの企業にとってそこは、候補者が面接前に読み、競合が引き抜きを仕掛ける前に読むレビューページです。ページ自体は1件ずつ読むために作られています。星評価、見出し、1〜2段落、投稿者が記入していれば職種、そして参考になった数。読んでいるあいだはうまく機能します。問いがページ全体に及ぶと、うまく機能しません。どの職能が不満を抱えているのか、スコアは動いているのか、退職者が語ることと在籍者が語ることはどう違うのか。Indeedレビュースクレイパーは、ある企業のレビューページを表に変えることでそれに答えます。レビュー1件につき1行、21列、そして取得をまたいで1件のレビューを追える安定した識別子つきです。
入力が検索ではなく雇用主であるため、このサービスは驚くほど扱いやすくなっています。公開リファレンスは企業ページの完全なURLか、そこに現れる識別子だけのどちらかを受け付け、1リクエストあたり最大千件のクエリを認めています。競合各社をまとめて比較することが、百件ではなく1件の仕事になるということです。1回の取得の深さはパラメータであり--文書化されたlimitは1社あたり既定で百件です--料金が行単位である以上、そのパラメータはそのまま請求額でもあります。他の2つの設定は件数ではなく、どのレビューを受け取るかを決めます。参考度順か評価の降順を受け付ける並び替えと、リファレンスによれば並び替えを無効にして最新のレコードを先に返す打ち切りタイムスタンプです。
このデータの上に何かを作る前に知っておく価値のある性質が3つあり、いずれも私たちが測定したエクスポートに現れています。1つ目は、21列のうち2列がレビューについてまったく語っていないことです。aggregate_ratingとreview_countは雇用主を表し、各行に変わらず繰り返されます。前者を行全体で平均しても同じ値が返るだけですし、後者が示す母集団は通常、書き出した切り取りよりはるかに大きなものです。2つ目は、5つのカテゴリ別評価--給与と福利厚生、企業文化、マネジメント、雇用の安定性、ワークライフバランス--が単一の任意ブロックとして振る舞うことです。私たちの行では、同じ17件のレビューでまとめて埋まり、残る23件でまとめて欠けており、一部だけということはありませんでした。さらにこれらは文字列として届く一方、全体の評価は数値として届きます。3つ目は、日付がIndeedの印字どおりJuly 1, 2026という形で書かれ、ISO形式ではないことです。並べ替えたり集計したりする前に解析が要ります。
このページの根拠について、正直な留保が2つあります。上で数えたものはすべて、1社の雇用主に対する40件のレビューから得たものです。列が何であり、その値がどんな形を取るかを確かめるには十分ですが、その企業以外でどの列がどれくらいの頻度で埋まるかを述べるには足りません。充足率は例示であって予測ではありません。そしてこのスクレイパーはIndeedのアンチボット防御に直面します。私たち自身の試行のほとんどは何も返さず、理由はステータス列に記録され、このサービスは社内でレジデンシャルプロキシが必要なものとして扱われています。実行は失敗しうるものであり、再試行は普通のことです。変わらないのはエクスポートの形で、それを持つどの実行でも同一でした。無料で始めてください。最初の500行に費用はかからず、クレジットカードも不要です。