LinkedIn Scraper GitHub: อะไรใช้ได้ในปี 2026 (และอะไรใช้ไม่ได้)

การค้นหา "linkedin scraper" บน GitHub ณ เดือนเมษายน 2026 จะเจอประมาณ และส่วนใหญ่ก็คือเสียเวลาเปล่า

ฟังดูแรงไปไหม? อาจจะใช่ แต่หลังจากผมไล่ดูรีโพที่เด่นที่สุด 8 อัน อ่านเธรดปัญหาใน GitHub หลายสิบเธรด และเทียบกับรายงานจากชุมชนใน Reddit กับฟอรัมสแครปข้อมูล ผมก็เจอแพตเทิร์นเดิมซ้ำแล้วซ้ำอีก: รีโพที่มีดาวเยอะดึงความสนใจ ทีมป้องกันบอทของ LinkedIn ก็ศึกษาวิธีการ แล้วกลไกตรวจจับก็ถูกปรับตาม สุดท้ายผู้ใช้ได้แต่ตัวเลือกที่พัง วน CAPTCHA ไม่จบ หรือไม่ก็โดนแบนบัญชีไปตรงๆ ผู้ใช้ Reddit คนหนึ่งสรุปสถานการณ์ตอนนี้แบบตรงไปตรงมาว่า LinkedIn ได้เพิ่ม "การจำกัดอัตราที่เข้มงวดขึ้น การตรวจจับบอทที่ดีขึ้น การติดตามเซสชัน และการเปลี่ยนแปลงบ่อยครั้ง" และเครื่องมือเก่าๆ ตอนนี้ "พังเร็ว หรือไม่ก็ทำให้บัญชี/IP ถูกตั้งค่าสถานะ" ถ้าคุณเป็นเซลส์ รีครูตเตอร์ หรือผู้จัดการฝ่ายปฏิบัติการที่ต้องการข้อมูล LinkedIn ลงสเปรดชีต รีโพที่คุณโคลนเมื่อเดือนที่แล้วอาจตายไปแล้วก็ได้ คู่มือนี้ออกแบบมาเพื่อช่วยคุณแยกให้ออกว่าโปรเจ็กต์ GitHub ไหนคุ้มเวลาจริงๆ จะเลี่ยงไม่ให้บัญชีโดนเผาได้ยังไง และเมื่อไหร่ที่ควรข้ามโค้ดไปเลยจะคุ้มกว่า

LinkedIn Scraper บน GitHub คืออะไร?

โปรเจ็กต์ LinkedIn scraper บน GitHub คือสคริปต์โอเพนซอร์ส — ส่วนใหญ่เป็น Python บางครั้งก็เป็น Node.js — ที่ใช้ดึงข้อมูลแบบมีโครงสร้างจากหน้า LinkedIn อัตโนมัติ เป้าหมายที่พบบ่อยได้แก่:

• โปรไฟล์บุคคล: ชื่อ ตำแหน่ง บริษัท ที่ตั้ง ทักษะ ประสบการณ์
• ประกาศงาน: ชื่อตำแหน่ง บริษัท ที่ตั้ง วันที่โพสต์ URL งาน
• หน้าบริษัท: ภาพรวม จำนวนพนักงาน อุตสาหกรรม จำนวนผู้ติดตาม
• โพสต์และการมีส่วนร่วม: ข้อความเนื้อหา ไลก์ คอมเมนต์ แชร์

เบื้องหลัง รีโพส่วนใหญ่ใช้หนึ่งในสองแนวทาง สแครปที่ขับด้วยเบราว์เซอร์อาศัย Selenium, Playwright หรือ Puppeteer เพื่อเรนเดอร์หน้า คลิกไล่ไปตามโฟลว์ และดึงข้อมูลผ่าน CSS selector หรือ XPath ส่วนอีกกลุ่มที่มีจำนวนน้อยกว่าจะพยายามเรียก endpoint API ภายในของ LinkedIn โดยตรงแบบไม่มีเอกสาร และคลื่นใหม่ที่ยังพบไม่บ่อยบน GitHub แต่กำลังโตขึ้น คือการจับคู่ระบบอัตโนมัติในเบราว์เซอร์กับ LLM อย่าง GPT-4o mini เพื่อแปลงข้อความบนหน้าให้เป็นฟิลด์ที่มีโครงสร้างโดยไม่ต้องพึ่ง selector ที่เปราะบาง

แต่กลุ่มผู้ใช้งานจริงไม่ตรงกันอย่างชัดเจน เครื่องมือเหล่านี้ถูกสร้างโดยนักพัฒนาที่คุ้นกับ virtual environment, dependency ของเบราว์เซอร์ และการตั้งค่า proxy แต่คนจำนวนมากที่ค้นหา "linkedin scraper github" คือรีครูตเตอร์ SDR ผู้จัดการ RevOps และผู้ก่อตั้งที่แค่อยากได้แถวข้อมูลลงสเปรดชีต

ช่องว่างนี้แหละที่อธิบายความหงุดหงิดส่วนใหญ่ในเธรดปัญหา

ทำไมคนถึงหันไปหา GitHub เพื่อสแครป LinkedIn

เหตุผลมันชัดเจน: ฟรี ปรับแต่งได้ ไม่ล็อกกับผู้ขาย ควบคุมท่อข้อมูลได้เต็มที่ ถ้าเครื่องมือ SaaS เปลี่ยนราคา หรือปิดตัว โค้ดของคุณก็ยังอยู่

แต่คำว่า "ฟรี" เป็นแค่ป้ายเรื่องลิขสิทธิ์ ไม่ใช่ต้นทุนการใช้งาน ต้นทุนจริงคือ:

• เวลาตั้งค่า: ต่อให้เป็นรีโพที่ค่อนข้างเป็นมิตร ก็มักต้องใช้เวลา 30 นาทีถึงมากกว่า 2 ชั่วโมงสำหรับการตั้งค่าสภาพแวดล้อม dependency ของเบราว์เซอร์ การดึงคุกกี้ และการตั้งค่า proxy
• การดูแลต่อเนื่อง: LinkedIn เปลี่ยน DOM และระบบป้องกันบอทอยู่เรื่อยๆ — สแครปที่ใช้ได้วันนี้ อาทิตย์หน้าก็อาจพัง
• พร็อกซี: แบนด์วิดท์ residential proxy มีราคาประมาณ แล้วแต่ผู้ให้บริการและแพ็กเกจ
• ความเสี่ยงต่อบัญชี: บัญชี LinkedIn ของคุณคือทรัพย์สินที่แพงที่สุดที่เสี่ยงอยู่ และมันแทนกันไม่ได้เหมือน IP ของ proxy

เช็กลิสต์สุขภาพรีโพ: ประเมิน LinkedIn Scraper บน GitHub ยังไง

รายการ "best LinkedIn scraper" ส่วนใหญ่มักจัดอันดับรีโพจากจำนวนดาว ดาววัดความสนใจในอดีต ไม่ได้วัดว่าตอนนี้ยังใช้งานได้ไหม รีโพที่มี 3,000 ดาวแต่ไม่มีคอมมิตตั้งแต่ปี 2022 คือของจัดแสดงในพิพิธภัณฑ์ ไม่ใช่เครื่องมือ production

ก่อนจะรัน git clone กับอะไรก็ตาม ให้ใช้กรอบนี้:

ทริกที่ช่วยประหยัดเวลาสุด: ก่อนจะฝากความหวังกับรีโพไหน ให้ค้นในแท็บ Issues ด้วยคำว่า "blocked," "banned," "CAPTCHA," หรือ "not working" ถ้า issues ล่าสุดเต็มไปด้วยคำพวกนี้และไม่มีคำตอบจากผู้ดูแล ให้ไปต่อเลย รีโพนั้นแพ้ไปแล้ว

ผลการตรวจสอบในปี 2026 เป็นยังไงจริงๆ

ผมนำเช็กลิสต์นี้ไปใช้กับ 8 รีโพ LinkedIn scraper ที่เด่นที่สุดบน GitHub ผลที่ได้ไม่ค่อยน่าดีใจนัก

มีแค่ 2 จาก 8 รีโพที่ดูน่าใช้จริงสำหรับคนอ่านในปี 2026 โดยไม่ต้องเขียนคำเตือนยาวเหยียด อัตราแบบนี้ไม่ใช่เรื่องแปลก — มันคือมาตรฐานของการสแครป LinkedIn บน GitHub

แผนป้องกันการโดนแบน: พร็อกซี, Rate Limit และความปลอดภัยของบัญชี

การโดนแบนบัญชีคือความเสี่ยงเชิงปฏิบัติการที่ใหญ่ที่สุด ต่อให้สแครปเปอร์เก่งทางเทคนิคก็ยังพังตรงนี้ได้ โค้ดใช้ได้ แต่บัญชีใช้ไม่ได้ ผู้ใช้รายงานว่าถูกตั้งค่าสถานะหลังจากแค่ แม้จะใช้ proxy และหน่วงเวลานาน

การจำกัดอัตรา: สิ่งที่ชุมชนรายงาน

ไม่มีตัวเลขที่ปลอดภัยแบบรับประกันได้ LinkedIn ประเมินอายุเซสชัน จังหวะการคลิก รูปแบบการยิงถี่ ความน่าเชื่อถือของ IP และพฤติกรรมบัญชี ไม่ใช่แค่ปริมาณดิบๆ ข้อมูลจากชุมชนมักกระจุกอยู่ในช่วงเหล่านี้:

• ผู้ใช้รายหนึ่งรายงานว่าถูกตรวจจับหลัง 40–80 โปรไฟล์ ทั้งที่ใช้ proxy และหน่วงแบบ 33 วินาที
• อีกรายแนะนำให้คุมไว้ประมาณ 30 โปรไฟล์/วัน/บัญชี
• ผู้ปฏิบัติการที่กล้าได้กล้าเสียกว่าระบุว่า โดยกระจายตลอดทั้งวัน
• บันทึกคำเตือน rate limit ภายในหลังจากราว 900 requests ในหนึ่งชั่วโมง

ข้อสรุปเชิงปฏิบัติ: ต่ำกว่า 50 การเข้าดูโปรไฟล์/วัน/บัญชี ถือว่าเสี่ยงน้อยกว่า ช่วง 50–100/วัน คือความเสี่ยงระดับกลางที่คุณภาพของเซสชันสำคัญมาก เกิน 100/วัน/บัญชี คือโซนที่เริ่ม aggressive ขึ้นเรื่อยๆ

กลยุทธ์พร็อกซี: Residential เทียบกับ Datacenter

Residential proxy ยังเป็นมาตรฐานสำหรับ LinkedIn เพราะมันดูเหมือนทราฟฟิกของผู้ใช้จริง Datacenter IP ราคาถูกกว่า แต่โดนตั้งค่าสถานะเร็วกว่าในเว็บที่มีระบบป้องกันซับซ้อน — และ LinkedIn ก็คือเว็บประเภทนั้นพอดีที่ทราฟฟิกราคาถูกถูกจับตาได้ง่าย

บริบทด้านราคาปัจจุบัน:

• : $3.00–$4.00/GB แล้วแต่แพ็กเกจ
• : $4.00–$6.00/GB แล้วแต่แพ็กเกจ

ให้หมุนตามเซสชัน ไม่ใช่ตาม request การหมุนทุก request จะสร้างลายนิ้วมือที่บอกว่าเป็น "โครงสร้างพื้นฐาน proxy" ชัดกว่าการใช้ IP เดียวซ้ำๆ เสียอีก

โปรโตคอลบัญชีสำรอง

คำแนะนำจากชุมชนค่อนข้างตรงไปตรงมา: อย่าใช้บัญชี LinkedIn หลักของคุณเป็นโครงสร้างพื้นฐานสแครปที่ใช้แล้วทิ้ง

ถ้าคุณยืนยันจะใช้การสแครปที่ผูกกับบัญชี:

• ใช้บัญชีแยกจากตัวตนมืออาชีพหลักของคุณ
• กรอกโปรไฟล์ให้ครบ และปล่อยให้มันมีพฤติกรรมเหมือนคนจริงอยู่หลายวันก่อนจะเริ่มสแครป
• อย่าผูกเบอร์โทรจริงของคุณกับบัญชีที่ใช้สแครป
• แยก session สแครปออกจากการ outreach และส่งข้อความจริงแบบขาดจากกันโดยสิ้นเชิง

ควรรู้ไว้ว่า ของ LinkedIn (มีผลตั้งแต่ 3 พฤศจิกายน 2025) ระบุชัดเจนว่าห้ามใช้ตัวตนปลอมและแชร์บัญชี แม้กลยุทธ์บัญชีสำรองจะพบใช้กันทั่วไปในเชิงปฏิบัติ แต่ในเชิงสัญญายังยุ่งอยู่มาก

การรับมือ CAPTCHA

CAPTCHA ไม่ใช่แค่เรื่องน่ารำคาญ แต่มันเป็นสัญญาณว่า session ของคุณกำลังถูกจับตา ตัวเลือกมีดังนี้:

• แก้ด้วยคนเพื่อเดินต่อใน session นั้น
• ใช้คุกกี้ซ้ำแทนการรัน flow ล็อกอินใหม่
• ใช้บริการแก้ captcha เช่น (~$0.50–$1.00 ต่อ 1,000 image CAPTCHA, ~$1.00–$2.99 ต่อ 1,000 การแก้ reCAPTCHA v2)

แต่ถ้าเวิร์กโฟลว์ของคุณกระตุ้น CAPTCHA เป็นประจำ ต้นทุนของบริการแก้ captcha ยังไม่ใช่ปัญหาใหญ่สุด ระบบของคุณกำลังแพ้ศึกเรื่องการหลบตรวจจับอยู่

สเปกตรัมความเสี่ยง

พาราด็อกซ์ของโอเพนซอร์ส: ทำไมรีโพ LinkedIn Scraper ยอดนิยมถึงพังเร็วกว่า

ผู้ใช้ตั้งข้อสังเกตที่สมเหตุสมผล: "พอทำโอเพนซอร์ส LinkedIn ก็แค่มองดูว่าคุณทำอะไร แล้วป้องกันมันได้" ความกังวลนี้ไม่ใช่ความระแวงเกินเหตุ แต่มันถูกต้องในเชิงโครงสร้าง

ปัญหาความมองเห็น

จำนวนดาวสูงสร้างสัญญาณสองแบบพร้อมกัน: สร้างความน่าเชื่อถือให้ผู้ใช้ และทำให้ทีมความปลอดภัยของ LinkedIn เล็งเป้าได้มากขึ้น ยิ่งรีโพดังเท่าไหร่ LinkedIn ก็ยิ่งมีโอกาสตอบโต้เทคนิคของมันโดยตรงมากขึ้น

คุณเห็นวงจรชีวิตนี้ได้จากข้อมูลตรวจสอบ linkedtales/scrapedin เคยโดดเด่นพอที่จะประกาศว่าใช้ได้กับเว็บไซต์ใหม่ของ LinkedIn ในปี 2020 แต่รีโพไม่ได้ตามการยืนยันตัวตนและการเปลี่ยนเลย์เอาต์ในช่วงหลัง nsandman/linkedin-api เคยบันทึกทริกที่ใช้ได้จริง แต่คอมมิตล่าสุดก็เกิดขึ้นหลายปีก่อนสภาพแวดล้อมป้องกันบอทในปัจจุบัน

ข้อดีของการแพตช์จากชุมชน

โอเพนซอร์สยังมีข้อดีจริงอยู่ข้อหนึ่ง: ผู้ดูแลและผู้ร่วมพัฒนาที่แอ็กทีฟสามารถแพตช์ได้เร็วเมื่อ LinkedIn เปลี่ยนการป้องกัน joeyism/linkedin_scraper เป็นตัวอย่างหลักจากการตรวจสอบครั้งนี้ — มันยังเจอ issues เรื่อง auth ถูกบล็อกและการค้นหาพังอยู่ แต่ก็ยังเคลื่อนไหวอยู่ Fork มักจะนำเทคนิคหลบใหม่ๆ มาใช้เร็วกว่าต้นฉบับ

แล้วควรทำยังไงกับมัน

• อย่าพึ่งพารีโพสาธารณะตัวเดียวเป็นโครงสร้างพื้นฐานถาวร
• มองหา fork ที่ยังแอ็กทีฟและใส่เทคนิคหลบใหม่ๆ
• พิจารณาดูแล private fork สำหรับใช้งานจริง (เพื่อให้การปรับแต่งเฉพาะของคุณไม่ถูกเปิดเผย)
• คาดว่าจะต้องเปลี่ยนวิธีทำเมื่อ LinkedIn เปลี่ยนการตรวจจับหรือพฤติกรรม UI
• กระจายวิธีการ อย่าเดิมพันทุกอย่างกับเครื่องมือเดียว

การดึงข้อมูลด้วย AI เทียบกับ CSS Selector: เปรียบเทียบแบบใช้งานจริง

ความแตกต่างเชิงเทคนิคที่น่าสนใจกว่าในปี 2026 ไม่ใช่ GitHub กับ no-code แต่มันคือ การดึงข้อมูลแบบอิง selector เทียบกับ การดึงเชิงความหมาย — และความต่างนี้สำคัญกว่าที่สรุปหลายชิ้นยอมรับ

CSS Selector ทำงานยังไง (และพังยังไง)

สแครปแบบดั้งเดิมจะอ่าน DOM ของ LinkedIn แล้วแมปแต่ละฟิลด์กับ CSS selector หรือ XPath เมื่อโครงสร้างหน้าเสถียร วิธีนี้ยอดเยี่ยม: แม่นสูง ต้นทุนส่วนเพิ่มต่ำ แยกข้อความได้เร็วมาก

แต่โหมดล้มเหลวก็ชัดเจนเหมือนกัน LinkedIn เปลี่ยนชื่อ class การซ้อนขององค์ประกอบ พฤติกรรม lazy-load หรือกันเนื้อหาด้วย auth wall แบบอื่น แล้วสแครปก็พังทันที ชื่อ issue ในรีโพที่ตรวจดูบอกเรื่องนี้หมด: "changed HTML," "broken job search," "missing values," "authwall blocks"

AI/LLM Extraction ทำงานยังไง

แพตเทิร์นใหม่เรียบง่ายกว่าในเชิงแนวคิด: เรนเดอร์หน้า เก็บข้อความที่มองเห็น ส่งให้โมเดลสร้างฟิลด์ที่มีโครงสร้าง นั่นคือเหตุผลเบื้องหลัง AI scraper แบบ no-code จำนวนมาก และเวิร์กโฟลว์ custom รุ่นใหม่บางส่วน

ถ้าใช้ ($0.15/1M input tokens, $0.60/1M output tokens) การดึงแบบข้อความล้วนหนึ่งโปรไฟล์มักมีต้นทุน $0.0006–$0.0018 ต่อโปรไฟล์ ซึ่งเล็กพอที่จะไม่สำคัญสำหรับเวิร์กโฟลว์ปริมาณกลาง

เทียบกันแบบตัวต่อตัว

แล้วควรเลือกแบบไหน?

ถ้าคุณทำ pipeline ปริมาณสูงมาก เสถียร และทีมวิศวกรรมเป็นคนดูแล การ parse แบบ selector ยังชนะเรื่องต้นทุนได้อยู่ แต่สำหรับผู้ใช้ส่วนใหญ่ในตลาดเล็กและกลางที่สแครปหลักร้อยโปรไฟล์ ไม่ใช่หลักล้าน การดึงด้วย AI เป็นการลงทุนระยะยาวที่ดีกว่า เพราะการที่ LinkedIn เปลี่ยนเลย์เอาต์ทำให้เสียเวลา developer มากกว่าโทเคนที่คุณประหยัดได้

เมื่อรีโพ GitHub เกินความจำเป็น: เส้นทางแบบไม่ต้องเขียนโค้ด

คนส่วนใหญ่ที่ค้นหา "linkedin scraper github" ไม่ได้อยากกลายเป็นผู้ดูแลระบบอัตโนมัติในเบราว์เซอร์

พวกเขาอยากได้แถวข้อมูลในตาราง

ผู้ใช้บ่นเรื่องความใช้งานของสแครปเปอร์ GitHub ในเธรดปัญหาแบบชัดเจน: "It does not handle 2FA and it is not easy to use since there is no UI." กลุ่มผู้ใช้มีทั้งรีครูตเตอร์ SDR และผู้จัดการฝ่ายปฏิบัติการ — ไม่ใช่แค่นักพัฒนา Python

การตัดสินใจระหว่างสร้างเองกับซื้อ

Thunderbit จัดการการสแครป LinkedIn แบบไม่ต้องเขียนโค้ดยังไง

รับมือปัญหานี้ต่างจากรีโพ GitHub แทนที่จะเขียน selector หรือคอนฟิกเบราว์เซอร์อัตโนมัติ คุณแค่:

1. ติดตั้ง
2. ไปยังหน้า LinkedIn ใดก็ได้ (ผลการค้นหา โปรไฟล์ หน้าบริษัท)
3. คลิก "AI Suggest Fields" — AI ของ Thunderbit จะอ่านหน้าและเสนอคอลัมน์ที่มีโครงสร้างให้ (ชื่อ ตำแหน่ง บริษัท ที่ตั้ง ฯลฯ)
4. ปรับคอลัมน์ถ้าจำเป็น แล้วคลิกเพื่อดึงข้อมูล
5. ส่งออกตรงไปยัง Excel, Google Sheets, หรือ Notion

เพราะ Thunderbit ใช้ AI อ่านหน้าแบบเชิงความหมายทุกครั้ง มันจึงไม่พังตอน LinkedIn เปลี่ยน DOM นั่นคือข้อได้เปรียบเดียวกับแนวทางที่ผสาน GPT ในสคริปต์ Python แบบ custom แต่ถูกบรรจุมาในส่วนขยาย no-code แทนที่จะเป็นโค้ดเบสที่คุณต้องดูแลเอง

สำหรับ — คลิกเข้าโปรไฟล์ย่อยจากลิสต์ผลการค้นหาเพื่อเพิ่มความสมบูรณ์ให้ตารางข้อมูลของคุณ — Thunderbit จัดการให้โดยอัตโนมัติ โหมดเบราว์เซอร์ใช้ได้กับหน้าที่ต้องล็อกอิน โดยไม่ต้องตั้งค่า proxy แยกต่างหาก

ใครยังควรใช้รีโพ GitHub อยู่?

รีโพ GitHub ยังมีเหตุผลสำหรับ:

• นักพัฒนาที่ต้องการปรับแต่งลึกหรือใช้ชนิดข้อมูลแปลกๆ
• ทีมที่สแครปปริมาณสูงมากจนต้นทุนต่อเครดิตสำคัญ
• ผู้ใช้ที่ต้องรันการสแครปใน CI/CD pipeline หรือบนเซิร์ฟเวอร์
• คนที่ต้องการนำข้อมูล LinkedIn ไปผนวกรวมใน workflow อัตโนมัติที่ใหญ่กว่า

สำหรับคนอื่นๆ — โดยเฉพาะทีมเซลส์ รีครูต และปฏิบัติการ — ช่วยตัดวงจรตั้งค่าและดูแลทั้งหมดทิ้งไป

ขั้นตอนทีละสเต็ป: วิธีประเมินและใช้ LinkedIn Scraper จาก GitHub

ถ้าคุณตัดสินใจแล้วว่า GitHub คือทางที่ใช่ นี่คือเวิร์กโฟลว์เป็นขั้นๆ ที่ลดการเสียเวลาและความเสี่ยงต่อบัญชี

ขั้นที่ 1: ค้นหาและคัดรีโพเบื้องต้น

ค้น GitHub ด้วยคำว่า "linkedin scraper" แล้วกรองตาม:

• อัปเดตล่าสุดเมื่อไม่นานนี้ (6 เดือนล่าสุด)
• ภาษาให้ตรงกับสแต็กของคุณ (Python พบบ่อยที่สุด)
• ขอบเขตตรงกับสิ่งที่ต้องการจริง (โปรไฟล์ vs งาน vs บริษัท)

คัดเหลือ 3–5 รีโพที่ดูยังมีชีวิต

ขั้นที่ 2: ใช้เช็กลิสต์สุขภาพรีโพ

รันแต่ละรีโพผ่าน scorecard ที่กล่าวไปก่อนหน้า ตัดทิ้งทันทีถ้ามี:

• ไม่มีคอมมิตในปีที่ผ่านมา
• issues เรื่อง "blocked" หรือ "CAPTCHA" ที่ยังไม่ปิด
• ยืนยันตัวตนแบบใช้แต่รหัสผ่าน
• ไม่พูดถึง session, คุกกี้ หรือ proxy เลย

ขั้นที่ 3: ตั้งค่าสภาพแวดล้อม

คำสั่งตั้งค่าที่พบซ้ำในรีโพที่ตรวจสอบมีเช่น:

1pip install linkedin-scraper
2playwright install chromium
3pip install linkedin-jobs-scraper
4LI_AT_COOKIE=<cookie> python your_app.py
5scrapy crawl linkedin_people_profile

จุดติดขัดที่เจอซ้ำ:

• ไฟล์ session.json หาย
• เวอร์ชัน browser driver ไม่ตรงกัน (Chromium/Playwright)
• การดึงคุกกี้จาก browser DevTools
• timeout ตอน auth กับ proxy

ขั้นที่ 4: ทดลองสแครปขนาดเล็ก

เริ่มจาก 10–20 โปรไฟล์ เช็กว่า:

• ฟิลด์ถูก parse ถูกต้องไหม?
• ข้อมูลครบไหม?
• เจอด่านความปลอดภัยหรือเปล่า?
• รูปแบบเอาต์พุตใช้งานได้ หรือเป็น raw JSON ที่รกไปหมด?

ขั้นที่ 5: ขยายอย่างระมัดระวัง

เพิ่ม delay แบบสุ่ม (5–15 วินาทีระหว่าง requests), ลด concurrency, ใช้ session reuse และ residential proxies อย่ากระโดดไปหลักร้อยโปรไฟล์/วันบนบัญชีใหม่

ขั้นที่ 6: ส่งออกและจัดโครงสร้างข้อมูล

รีโพ GitHub ส่วนใหญ่จะส่งออก raw JSON หรือ CSV คุณยังต้อง:

• ลบข้อมูลซ้ำ
• ทำให้ชื่อตำแหน่งและชื่อบริษัทเป็นมาตรฐานเดียวกัน
• แมปฟิลด์เข้ากับ CRM หรือ ATS ของคุณ
• บันทึกแหล่งที่มาของข้อมูลเพื่อการปฏิบัติตามข้อกำหนด

(Thunderbit จัดการการจัดโครงสร้างและส่งออกให้อัตโนมัติถ้าคุณอยากข้ามขั้นนี้)

LinkedIn Scraper GitHub เทียบกับเครื่องมือ No-Code: เปรียบเทียบครบถ้วน

ข้อพิจารณาด้านกฎหมายและจริยธรรม

ผมจะพูดสั้นๆ แต่ข้ามไม่ได้

ของ LinkedIn (มีผลตั้งแต่ 3 พฤศจิกายน 2025) ห้ามใช้ซอฟต์แวร์ สคริปต์ หุ่นยนต์ crawlers หรือปลั๊กอินเบราว์เซอร์เพื่อสแครปบริการอย่างชัดเจน LinkedIn ก็มีการบังคับใช้อย่างจริงจัง:

• : LinkedIn ประกาศดำเนินการทางกฎหมายต่อ Proxycurl
• : LinkedIn ระบุว่าคดีนั้นถูกยุติแล้ว
• : Law360 รายงานว่า LinkedIn ฟ้องจำเลยเพิ่มจากการสแครปข้อมูลในระดับอุตสาหกรรม

แนวคดี hiQ v. LinkedIn เคยสร้างความละเอียดอ่อนบางอย่างเกี่ยวกับการเข้าถึงข้อมูลสาธารณะ แต่ เอียงเข้าข้าง LinkedIn ในประเด็นการละเมิดสัญญา "มองเห็นได้สาธารณะ" ไม่ได้แปลว่า "ปลอดภัยแน่ๆ ที่จะสแครปในระดับใหญ่เพื่อใช้เชิงพาณิชย์"

สำหรับ workflow ที่เกี่ยวข้องกับ EU การบังคับใช้คดี โดยหน่วยงานคุ้มครองข้อมูลของฝรั่งเศสเป็นตัวอย่างที่ชัดเจนว่าหน่วยงานกำกับดูแลมองข้อมูล LinkedIn ที่สแครปมาเป็นข้อมูลส่วนบุคคลซึ่งอยู่ภายใต้กฎคุ้มครองข้อมูล

การใช้เครื่องมือที่มีการดูแลต่อเนื่องอย่าง Thunderbit ไม่ได้เปลี่ยนภาระทางกฎหมายของคุณ แต่ช่วยลดความเสี่ยงที่จะไปกระตุ้นระบบความปลอดภัยโดยไม่ตั้งใจ หรือฝ่าฝืน rate limit จนดึงความสนใจของ LinkedIn

อะไรใช้ได้และอะไรใช้ไม่ได้ในปี 2026

อะไรใช้ได้

• ใช้ Repo Health Scorecard ก่อนผูกตัวกับรีโพใดๆ
• ใช้คุกกี้/เซสชันซ้ำ แทนการล็อกอินอัตโนมัติซ้ำๆ
• ใช้ residential proxy เมื่อจำเป็นต้องสแครปที่ผูกกับบัญชี
• ใช้เวิร์กโฟลว์ที่เล็กลง ช้าลง และดูเป็นมนุษย์มากขึ้น
• ใช้การดึงด้วย AI เมื่อคุณให้ความสำคัญกับความยืดหยุ่นมากกว่าต้นทุนโทเคนส่วนเพิ่ม
• เมื่อสิ่งที่ต้องการจริงๆ คือเอาต์พุตเป็นสเปรดชีต ไม่ใช่การเป็นเจ้าของสแครปเปอร์
• กระจายวิธีการ แทนที่จะเดิมพันกับรีโพสาธารณะตัวเดียว

อะไรใช้ไม่ได้

• โคลนรีโพที่มีดาวเยอะโดยไม่เช็กสถานะการดูแลหรือ issues ล่าสุด
• ใช้ datacenter proxy หรือรายการ proxy ฟรีกับ LinkedIn
• ขยายไปหลักร้อยโปรไฟล์/วันโดยไม่คุม rate limit หรือการหลบตรวจจับ
• พึ่ง CSS selector ระยะยาวโดยไม่มีแผนบำรุงรักษา
• มองบัญชี LinkedIn จริงของคุณเป็นโครงสร้างพื้นฐานที่ทิ้งได้
• สับสนระหว่าง "เข้าถึงได้สาธารณะ" กับ "ไม่มีปัญหาทางสัญญาหรือกฎหมาย"

คำถามที่พบบ่อย

รีโพ LinkedIn scraper บน GitHub ยังใช้ได้อยู่ไหมในปี 2026?

มีบางอันใช้ได้ แต่มีเพียงส่วนน้อยเท่านั้น จากการตรวจสอบรีโพที่มองเห็นได้ 8 อัน มีแค่ 2 อันที่ดูใช้งานได้จริงสำหรับผู้อ่านในปี 2026 โดยไม่ต้องมีคำเตือนยาวเหยียด สิ่งสำคัญคือประเมินรีโพจากกิจกรรมการดูแลและสุขภาพของ issues ไม่ใช่จำนวนดาว ใช้ Repo Health Scorecard ก่อนจะลงทุนตั้งค่ากับโปรเจ็กต์ใดๆ

ฉันสแครป LinkedIn ได้กี่โปรไฟล์ต่อวันถึงจะไม่โดนแบน?

ไม่มีตัวเลขปลอดภัยที่การันตีได้ เพราะ LinkedIn ประเมินพฤติกรรมของ session ไม่ใช่แค่ปริมาณอย่างเดียว รายงานจากชุมชนชี้ว่าต่ำกว่า 50 โปรไฟล์/วัน/บัญชีคือโซนเสี่ยงต่ำ ช่วง 50–100/วันเป็นความเสี่ยงปานกลางที่คุณภาพโครงสร้างพื้นฐานสำคัญ และเกิน 100/วันเริ่ม aggressive มากขึ้น Delay แบบสุ่ม 5–15 วินาทีและ residential proxy ช่วยได้ แต่ไม่มีอะไรลบความเสี่ยงได้ทั้งหมด

มีทางเลือกแบบ no-code แทนโปรเจ็กต์ LinkedIn scraper บน GitHub ไหม?

มี ให้คุณสแครปหน้า LinkedIn ได้ในไม่กี่คลิกด้วยการตรวจจับฟิลด์ด้วย AI, การยืนยันตัวตนผ่านเบราว์เซอร์ (ไม่ต้องตั้งค่า proxy) และส่งออกไป Excel, Google Sheets, Airtable หรือ Notion ได้ในคลิกเดียว ออกแบบมาสำหรับทีมเซลส์ รีครูต และปฏิบัติการที่ต้องการข้อมูลโดยไม่อยากดูแลโค้ด คุณลองใช้ได้ผ่าน

การสแครปข้อมูล LinkedIn ถูกกฎหมายไหม?

อยู่ในพื้นที่สีเทาที่เส้นขอบคมขึ้นเรื่อยๆ ของ LinkedIn ห้ามสแครปอย่างชัดเจน และ LinkedIn ก็เคยดำเนินการทางกฎหมายกับสแครปเปอร์ใน บรรทัดฐาน hiQ v. LinkedIn เรื่องการเข้าถึงข้อมูลสาธารณะก็ถูกจำกัดลงด้วยคำพิพากษาล่าสุด GDPR ใช้กับข้อมูลส่วนบุคคลของผู้อยู่อาศัยใน EU ไม่ว่าข้อมูลนั้นจะถูกรวบรวมมาอย่างไร สำหรับการใช้งานเชิงพาณิชย์ทุกกรณี ควรปรึกษาทนายที่เข้าใจบริบทของคุณโดยเฉพาะ

ดึงข้อมูลด้วย AI หรือ CSS selectors — ควรใช้อะไรกับการสแครป LinkedIn?

CSS selector เร็วกว่าและต้นทุนต่อเรคคอร์ดถูกกว่าตอนมันใช้งานได้ แต่ก็สร้างงานดูแลต่อเนื่อง เพราะ LinkedIn เปลี่ยน DOM อยู่เรื่อยๆ การดึงด้วย AI/LLM มีต้นทุนต่อโปรไฟล์สูงกว่านิดหน่อย (~$0.001–$0.002 ตาม ) แต่ปรับตามเลย์เอาต์ที่เปลี่ยนไปได้อัตโนมัติ สำหรับผู้ใช้ที่ไม่ใช่องค์กรขนาดใหญ่ส่วนมากที่สแครปแค่หลักร้อย ไม่ใช่หลักล้าน การดึงด้วย AI คือลงทุนระยะยาวที่ดีกว่า Thunderbit มีเอ็นจิน AI ในตัวที่ให้ข้อดีนี้โดยที่คุณไม่ต้องเขียนหรือดูแลโค้ดเลย

เรียนรู้เพิ่มเติม