Screaming Frog คู่มือใช้งานฉบับจับมือทำ — ตั้งค่า crawl, หา 404, เชื่อม GSC และส่งรายงานให้ลูกค้า ปี 2026

เมื่อต้นปีที่ผ่านมา เจ้าของรีสอร์ตแห่งหนึ่งแถวเขาหลักส่งข้อความมาถามด้วยประโยคที่เราได้ยินบ่อยมาก — “เว็บเราทำมา 4 ปีแล้ว ลง content ก็เยอะ แต่ทำไมอันดับนิ่งสนิท” พอเปิดเว็บดูด้วยตาเปล่า ทุกอย่างดูปกติดี หน้าแรกสวย เมนูครบ โหลดก็ไม่ช้า

แต่พอเอา Screaming Frog ไล่ crawl ทั้งเว็บ ภาพที่ออกมาคนละเรื่องกันเลย — ลิงก์ภายในที่ชี้ไปหน้า 404 มีเป็นสิบจุด (ส่วนใหญ่มาจากเมนูแพ็กเกจเก่าที่ถูกลบไปแล้ว), หน้าห้องพัก 11 หน้าใช้ title เดียวกันเป๊ะ ๆ เพราะ template ไม่ได้ดึงชื่อห้องมาใส่, และรูปหน้าแรกใบเดียวหนัก 3.8 MB

ทั้งหมดนี้ตาเปล่ามองไม่เห็น ต้องมีเครื่องมือที่เดินตามลิงก์ทุกเส้นเหมือนที่ Googlebot ทำ แล้วเอาทุกอย่างมากางเป็นตาราง — และนั่นคืองานที่ Screaming Frog ทำได้ดีที่สุดในราคาที่ธุรกิจ SME จ่ายไหว

Screaming Frog คืออะไร และมันต่างจากเครื่องมือ SEO ทั่วไปยังไง

Screaming Frog SEO Spider คือโปรแกรม desktop (มีทั้ง Windows, macOS, Ubuntu) ที่ทำหน้าที่เป็น “crawler” — มันเริ่มจาก URL ที่คุณป้อน แล้วเดินตามลิงก์ทุกเส้นในเว็บ เก็บข้อมูลทุกหน้า ทุกรูป ทุกไฟล์ CSS/JS แล้วเอามาแสดงเป็นตารางที่กรอง เรียง และ export ได้

จุดที่ทำให้มันต่างจากเครื่องมือ SEO ทั่วไปคือ มันรันบนเครื่องคุณเอง ไม่ใช่บนคลาวด์ของใคร ผลที่ตามมามีสามข้อ:

1. ข้อมูลสดเสมอ — กด crawl ตอนไหน ได้ข้อมูลนาทีนั้น ไม่ต้องรอ schedule รายสัปดาห์เหมือน cloud crawler
2. ไม่มีลิมิตจำนวนโปรเจกต์ — จะ crawl เว็บลูกค้ากี่รายก็ได้ในค่าไลเซนส์ก้อนเดียว
3. ความเร็วขึ้นกับเครื่องคุณ — RAM 8 GB กับ 32 GB ให้ประสบการณ์คนละโลก โดยเฉพาะเว็บที่มีเกิน 50,000 URL

พูดให้เห็นภาพ: Ahrefs หรือ Google Search Console บอกคุณว่า “เกิดอะไรขึ้นแล้ว” (มีคนคลิกกี่ครั้ง ติดอันดับไหม ลิงก์เข้ากี่เส้น) แต่ Screaming Frog บอกว่า “โครงสร้างเว็บคุณตอนนี้เป็นยังไง” ซึ่งเป็นคนละคำถามกัน และการทำ Technical SEO ที่ดีต้องใช้ทั้งสองอย่างประกอบกัน

รุ่นฟรี 500 URL — พอไหมสำหรับธุรกิจของคุณ

คำถามนี้ตอบได้ตรง ๆ ว่า “พอ ถ้าเว็บคุณเล็กจริง และคุณยอมรับข้อจำกัดสามข้อ”

รุ่นฟรี crawl ได้ 500 URL ต่อหนึ่งครั้ง — ตัวเลขนี้นับรวม ทุกอย่าง ไม่ใช่แค่หน้าเว็บ คือรวมรูปภาพ, ไฟล์ CSS, ไฟล์ JavaScript, PDF ด้วย เพราะฉะนั้นเว็บที่มี 60 หน้าจริง ๆ อาจกิน quota ไป 400+ URL แล้วก็ได้ ถ้าไม่ตั้งค่ากรองให้ดี

สรุปแบบใช้งานได้จริง: ถ้าคุณเป็นเจ้าของร้านอาหารหรือโฮมสเตย์ที่มีเว็บ 20–40 หน้า และแค่อยากรู้ว่ามี 404 ไหม title ซ้ำไหม — รุ่นฟรีเพียงพอ ใช้ปีละ 2–3 ครั้งก็ดูแลเว็บได้แล้ว

แต่ถ้าคุณเป็นฟรีแลนซ์หรือเอเจนซี ที่ต้องส่งรายงานให้ลูกค้า, ต้องดู redirect chain, หรือทำเว็บที่มีบทความเกิน 100 ชิ้น — ค่าไลเซนส์ปีละไม่กี่พันบาทคือต้นทุนที่คืนทุนตั้งแต่ลูกค้ารายแรก เพราะฟีเจอร์ที่ล็อกไว้ล้วนเป็นฟีเจอร์ที่ประหยัดเวลาคุณเป็นชั่วโมง ๆ

ตั้งค่า crawl ครั้งแรกให้ไม่พังและไม่โดนบล็อก

คนส่วนใหญ่เปิดโปรแกรมมา พิมพ์ URL แล้วกด Start ทันที — แล้วเจอปัญหาสามอย่าง: crawl ไม่จบสักที, กิน RAM จนเครื่องค้าง, หรือเลวร้ายที่สุดคือโดนโฮสต์บล็อก IP เพราะยิงเร็วเกินไป

ทำตามลำดับนี้แทน

1. ตั้ง Mode และ Storage ให้ถูก

ค่าเริ่มต้นคือ Memory Storage (เก็บข้อมูล crawl ไว้ใน RAM) ซึ่งเร็วแต่รับได้จำกัด ถ้าเว็บคุณเกิน 5,000 URL ให้เปลี่ยนเป็น Database Storage ใน Configuration ก่อน — ข้อมูลจะเขียนลง SSD แทน ทำให้ crawl เว็บใหญ่ได้โดยเครื่องไม่ตาย และยังเปิด crawl เก่ากลับมาดูได้ด้วย

2. ลดความเร็วลงก่อนเสมอ

ไปที่ Configuration แล้วตั้ง Speed ให้อยู่ราว 2–5 threads และจำกัดที่ประมาณ 3–5 URL ต่อวินาที โดยเฉพาะเว็บที่อยู่บน shared hosting ราคาถูก — โฮสต์ไทยหลายเจ้ามี rate limit ที่จะเด้ง 429 หรือ 503 ใส่คุณทันทีถ้ายิงแรง แล้วคุณจะได้รายงานที่เต็มไปด้วย error ปลอม ๆ ที่ไม่มีอยู่จริง

3. ตัดสินใจว่าจะ crawl อะไรบ้าง

ในการ crawl ครั้งแรกเพื่อดูภาพรวม แนะนำให้ เปิดทุกอย่างไว้ (รูป, CSS, JS) เพราะคุณอยากเห็นว่ารูปหนักแค่ไหน แต่ถ้าใช้รุ่นฟรีที่มีเพดาน 500 URL ให้ปิด CSS/JS ออกก่อน เพื่อสงวน quota ไว้ให้หน้าเว็บจริง

4. ตั้ง User-Agent และเคารพ robots.txt

ค่าเริ่มต้นจะเป็น Screaming Frog SEO Spider ซึ่งดีอยู่แล้วเพราะแอดมินระบบมองเห็นได้ว่าใครกำลัง crawl แต่ถ้าอยากรู้ว่า Googlebot เห็นอะไร ให้สลับ User-Agent เป็น Googlebot แล้ว crawl ซ้ำ — ผลที่ต่างกันคือสัญญาณว่าเว็บคุณอาจกำลังเสิร์ฟเนื้อหาคนละชุดให้บอทโดยไม่ตั้งใจ หรือมี rule แปลก ๆ ใน server

ส่วน robots.txt ให้เปิด “Respect robots.txt” ไว้ในการ crawl ครั้งแรก เพื่อดูว่า Google เข้าถึงอะไรได้บ้างจริง ๆ แล้วค่อย crawl รอบสองแบบเพิกเฉย robots.txt เพื่อดูว่ามีหน้าสำคัญอะไรถูกบล็อกอยู่หรือเปล่า การเทียบสองรอบนี้คือวิธีจับ “หน้าที่หายไปจาก Google อย่างลึกลับ” ที่ได้ผลที่สุด

5. เว็บที่ต้องใช้ JavaScript ต้องเปิด Rendering

ถ้าเว็บคุณเป็น React, Vue, Next.js หรืออะไรก็ตามที่เนื้อหาโผล่มาหลัง JS ทำงาน — ต้องไปเปลี่ยน Rendering เป็น JavaScript ไม่งั้นคุณจะเห็นหน้าเปล่า ๆ ทุกหน้าแล้วตกใจฟรี ข้อควรรู้คือโหมดนี้ช้ากว่าปกติราว 5–10 เท่า เพราะต้องเปิด headless browser จริง ๆ ทุกหน้า

หา 404 และ redirect chain — สิ่งแรกที่ควรดูหลัง crawl เสร็จ

พอ crawl เสร็จ อย่าเพิ่งไล่ดูทีละแท็บ ให้เริ่มจากสองอย่างนี้ก่อน เพราะมันแก้ง่ายและเห็นผลเร็วที่สุด

หา 404 ที่มาจากลิงก์ภายในเว็บตัวเอง

ไปที่แท็บ Response Codes แล้วกรอง Client Error (4xx) คุณจะได้รายการ URL ที่พัง แต่ข้อมูลที่มีค่าจริง ๆ อยู่ที่แผง Inlinks ด้านล่าง — มันบอกว่า “หน้าไหนบ้างที่ลิงก์มาหา URL พังนี้” ซึ่งคือจุดที่คุณต้องไปแก้จริง

ลำดับความสำคัญในการแก้:

1. 404 ที่ถูกลิงก์จากเมนูหรือ footer — แก้ก่อนเลย เพราะมันพังทุกหน้าในเว็บพร้อมกัน
2. 404 ที่มี backlink จากภายนอกชี้เข้ามา — อันนี้คือ traffic ที่คุณทิ้งฟรี ๆ ทำ 301 redirect ไปหน้าที่ใกล้เคียงที่สุด
3. 404 ในเนื้อหาบทความ — แก้ตอนมีเวลา แต่อย่าปล่อยทิ้งเพราะมันกินความน่าเชื่อถือ

รายละเอียดวิธีจัดการหน้าที่หายไปทั้งระบบ อ่านต่อได้ที่ แก้ปัญหา 404 Not Found

จับ redirect chain ที่กิน crawl budget

Redirect chain คือสถานการณ์ที่ URL A เด้งไป B แล้ว B เด้งไป C กว่าจะถึงหน้าจริง — ทุก hop คือเวลาที่เสียไป และ Googlebot จะเลิกตามหลังจากประมาณ 5 hop

ใน Screaming Frog รุ่นเสียเงิน ให้ไปที่ Reports แล้วเลือก Redirects แล้วต่อด้วย Redirect Chains จะได้ไฟล์ที่บอกครบว่าเส้นทางแต่ละสายวิ่งผ่านอะไรบ้าง กี่ hop และปลายทางสุดท้ายคือ 200 หรือ 404

สาเหตุที่พบบ่อยที่สุดในเว็บไทยคือ HTTP เด้งไป HTTPS แล้วเด้งไป www แล้วเด้งไป URL ที่มี trailing slash — สามชั้นซ้อนกันโดยไม่มีใครสังเกต วิธีแก้คือแก้ที่ต้นทางให้ลิงก์ภายในชี้ไป URL สุดท้ายโดยตรง แล้วรวม redirect rule ให้เหลือ hop เดียว ผลพลอยได้คือ crawl budget ที่คืนกลับมาให้หน้าใหม่ ๆ ได้ใช้

Title ซ้ำ, meta หาย, heading พัง — งานที่ Screaming Frog เก่งที่สุด

นี่คือส่วนที่แม้แต่รุ่นฟรีก็ใช้ได้เต็มที่ และเป็นส่วนที่ให้ผลลัพธ์ต่อ CTR เร็วที่สุด

แท็บ Page Titles — กรองดูทีละอัน:

• Missing — หน้าที่ไม่มี title เลย Google จะเดาเอาเองจากเนื้อหา ซึ่งมักได้ผลแย่กว่าที่คุณเขียนเอง
• Duplicate — สัญญาณคลาสสิกว่า template มีปัญหา เช่น หน้าห้องพักทุกห้องใช้ title เดียวกัน หรือหน้าแบ่งหน้า (pagination) ซ้ำกันหมด
• Over 561 Pixels — ยาวเกินจนโดนตัดใน SERP (Screaming Frog วัดเป็นพิกเซลไม่ใช่ตัวอักษร ซึ่งแม่นกว่า) หลักการเขียนที่ดีอ่านได้ที่ คู่มือ Title Tag
• Same as H1 — ไม่ผิดเสมอไป แต่แปลว่าคุณเสียโอกาสใส่คำค้นเพิ่มอีกชุด

แท็บ Meta Description — ดูเหมือนกัน โดยเฉพาะ Missing ซึ่งพบบ่อยมากในเว็บที่ทำด้วย page builder เพราะคนทำลืมกรอกช่อง SEO ทีละหน้า ถ้าคุณมีหน้าที่ meta หายเกิน 30% ของเว็บ นั่นคือปัญหาระดับ template ไม่ใช่ปัญหาราย ๆ หน้า — และควรแก้ที่ต้นทางตามแนวทางใน Meta Description ที่ดีเขียนยังไง

แท็บ H1 / H2 — สิ่งที่ต้องจับคือ Missing (ไม่มี H1) และ Multiple (มี H1 หลายอันในหน้าเดียว) ซึ่งมักเกิดจากธีมที่ใส่ H1 ให้โลโก้ในเฮดเดอร์ แล้วหน้าเนื้อหาก็มี H1 ของตัวเองอีก กลายเป็นสองอัน

รูปใหญ่เกิน — ตัวการอันดับหนึ่งของเว็บท่องเที่ยวไทย

เว็บรีสอร์ต ทัวร์ ร้านอาหาร และคลินิกในบ้านเรา มักตายเพราะเรื่องเดียวกัน คือรูปสวยแต่หนักเกินไป

ไปที่แท็บ Images แล้วกรอง Over 100 KB (ปรับเกณฑ์ได้ใน Configuration) คุณจะเห็นรายการรูปเรียงตามขนาด พร้อมคอลัมน์ที่บอกว่ารูปนี้ถูกใช้ในหน้าไหนบ้าง

สิ่งที่ควรทำหลังเห็นรายการ:

1. เรียงจากใหญ่ไปเล็ก แล้วจัดการ 20 ใบแรกก่อน — กฎ 80/20 ใช้ได้ดีมากกับเรื่องนี้
2. เช็กว่ารูปที่หนักที่สุดอยู่ในหน้าแรกหรือหน้า landing หรือเปล่า — ถ้าใช่ นั่นคือตัวถ่วง LCP ของคุณโดยตรง
3. แปลงเป็น WebP หรือ AVIF แล้วย่อขนาดจริงให้พอดีกับพื้นที่แสดงผล — อย่าอัปโหลดรูป 4000px มาแสดงในกรอบ 800px

แท็บเดียวกันยังมีตัวกรอง Missing Alt Text ซึ่งเป็นทั้งเรื่อง SEO และเรื่องการเข้าถึงของผู้พิการ ควรไล่เติมให้ครบโดยเขียนบรรยายสิ่งที่อยู่ในรูปจริง ๆ ไม่ใช่ยัดคีย์เวิร์ด

เชื่อม Google Search Console และ PageSpeed Insights API

ฟีเจอร์นี้อยู่ในรุ่นเสียเงิน และเป็นเหตุผลหลักที่เราแนะนำให้คนทำงานจริงจ่ายค่าไลเซนส์

เชื่อม Google Search Console

ไปที่ Configuration แล้วเข้า API Access เลือก Google Search Console แล้วล็อกอินด้วยบัญชีที่มีสิทธิ์ในพร็อพเพอร์ตี้นั้น เมื่อเชื่อมแล้ว crawl รอบถัดไปจะมีคอลัมน์ Clicks, Impressions, CTR และ Position ต่อท้ายทุก URL

พลังที่แท้จริงอยู่ที่การกรองแบบไขว้ ตัวอย่างคำถามที่ตอบได้ทันทีเมื่อมีข้อมูลสองชุดในตารางเดียว:

• หน้าไหนมี impression เยอะแต่ CTR ต่ำ — แปลว่า title กับ meta ไม่จูงใจ แก้ข้อความอย่างเดียวก็ได้คลิกเพิ่ม
• หน้าไหน ไม่มีข้อมูลใน GSC เลย ทั้งที่ crawl เจอ — แปลว่า Google อาจยังไม่ index หน้านั้น (ใช้ฟิลเตอร์ Search Console แล้วดู URLs Not in Search Console)
• หน้าไหน อันดับอยู่ 8–15 — นี่คือกองสมบัติ เพราะดันขึ้นหน้าแรกใช้แรงน้อยกว่าเขียนใหม่จากศูนย์มาก

เชื่อม PageSpeed Insights API

ในหน้า API Access เดียวกัน เลือก PageSpeed Insights แล้วใส่ Google API Key (สร้างฟรีจาก Google Cloud Console) จากนั้น Screaming Frog จะดึงค่า LCP, CLS, INP, TTFB และคำแนะนำการแก้ไขมาแสดงเป็นคอลัมน์ให้ทุก URL

ข้อดีมหาศาลคือ คุณได้ดูความเร็วทั้งเว็บพร้อมกัน แทนที่จะต้องนั่งเปิด PageSpeed Insights ทีละหน้า ทำให้เห็นทันทีว่าปัญหาความเร็วเป็นปัญหาเฉพาะบางหน้า หรือเป็นปัญหาทั้งระบบ (เช่น เซิร์ฟเวอร์ช้า ซึ่งจะเห็นว่า TTFB สูงเท่ากันหมดทุกหน้า) เกณฑ์ที่ควรยึดคือ LCP ต่ำกว่า 2.5 วินาที, CLS ต่ำกว่า 0.1 และ INP ต่ำกว่า 200 มิลลิวินาที

ข้อควรระวัง: API มีโควตาต่อวัน ถ้าเว็บใหญ่มากให้เลือกดึงเฉพาะ URL กลุ่มสำคัญ ไม่ต้องดึงทั้งเว็บ

ส่งออกรายงานให้ลูกค้าอ่านรู้เรื่อง

นี่คือจุดที่แยก “คนที่ใช้เครื่องมือเป็น” ออกจาก “คนที่ทำงานให้ลูกค้าได้จริง”

สิ่งที่ห้ามทำเด็ดขาด: export ทุกแท็บเป็น CSV แล้วส่งไฟล์ 40,000 แถวให้ลูกค้าทางไลน์ พร้อมข้อความว่า “รายงาน audit ครับ” — ลูกค้าจะเปิดไม่ออก อ่านไม่รู้เรื่อง และสรุปว่าคุณไม่ได้ทำอะไรเลย

สิ่งที่ควรทำ คือแปลงข้อมูลดิบให้เป็นเอกสารที่คนไม่ใช่สายเทคนิคตัดสินใจได้:

1. เริ่มจากตัวเลขสรุป 4–5 ตัว — จำนวนหน้าทั้งหมด, หน้าที่พัง (4xx/5xx), หน้าที่ meta ไม่ครบ, จำนวนรูปที่หนักเกินเกณฑ์, จำนวน redirect chain
2. จัดกลุ่มปัญหาตามความรุนแรง ไม่ใช่ตามแท็บของโปรแกรม — ลูกค้าไม่สนใจว่าปัญหาอยู่แท็บไหน เขาสนใจว่าอันไหนต้องรีบ
3. ทุกปัญหาต้องมีสามช่อง คือ “มันคืออะไร (ภาษาคน)”, “กระทบธุรกิจยังไง”, “ใครต้องแก้และใช้เวลาเท่าไร”
4. แนบ CSV ดิบเป็นภาคผนวก ให้ทีมเทคนิคของลูกค้าเอาไปทำงานต่อ แต่อย่าให้มันเป็นตัวรายงานหลัก

ตัวอย่างการเขียนที่ลูกค้าอ่านแล้วอนุมัติงบให้:

Screaming Frog รุ่นเสียเงินยังมีเมนู Reports แล้วเลือก Crawl Overview ที่สรุปทุกหมวดในไฟล์เดียว ใช้เป็นวัตถุดิบตั้งต้นได้ดี แล้วคุณค่อยเรียบเรียงเป็นภาษาลูกค้าอีกที ถ้าอยากได้โครงรายงานที่ครบกว่านี้ ดูได้จาก SEO Audit Checklist ของเรา

Screaming Frog vs Ahrefs Site Audit — เลือกอันไหน (หรือใช้ทั้งคู่)

คำถามนี้ถูกถามบ่อยมาก และคำตอบสั้น ๆ คือ “มันไม่ได้แทนกัน”

วิธีที่เราใช้จริงกับงานลูกค้า: ใช้ Screaming Frog ตอน “เข้างานครั้งแรก” เพื่อขุดหาปัญหาเชิงลึกและตอนที่ต้องเช็กหลัง deploy ทันที ส่วน Ahrefs Site Audit ตั้ง schedule ไว้เป็นระบบเฝ้าระวังระยะยาว ให้มันเตือนเราเมื่อมีอะไรพังใหม่ระหว่างเดือน

ถ้ามีงบจำกัดและต้องเลือกอย่างเดียว: ธุรกิจเจ้าของเว็บเดียว เลือก Screaming Frog เพราะถูกกว่าและตรงจุดกว่า ส่วน คนที่ต้องทำ SEO แข่งกับคู่แข่ง เลือก Ahrefs เพราะคุณต้องการข้อมูลนอกเว็บด้วย ไม่ใช่แค่ข้อมูลในเว็บตัวเอง

ตัวอย่างการใช้งานจริงกับธุรกิจภาคใต้

รีสอร์ตในกระบี่ที่เปลี่ยนระบบจอง — หลังเปลี่ยน booking engine ใหม่ URL ของหน้าห้องพักเปลี่ยนหมด ทีมเดิมทำ redirect ไว้แต่ไม่ได้ตรวจ ผลคือ crawl แล้วเจอ chain สามชั้นเกือบทุกหน้า พอแก้ให้เหลือ hop เดียวและอัปเดตลิงก์ในเมนู หน้าจองก็กลับเข้าสู่ index ครบภายในไม่กี่สัปดาห์

ทัวร์ดำน้ำหลายภาษาที่พังเงียบ ๆ — เว็บมีสี่ภาษา ใช้โครงสร้างโฟลเดอร์แยก แต่ตอน crawl พบว่าหน้าภาษาจีนกับเวียดนามจำนวนมากลิงก์กลับไปหาหน้าไทยที่ถูกลบไปแล้ว การเจอปัญหานี้ตั้งแต่แรกช่วยประหยัดเวลาไล่แก้ทีละหน้าไปได้มาก และเป็นปัญหาที่เว็บหลายภาษาแทบทุกเว็บมี แต่แทบไม่มีใครตรวจ

คลินิกในหาดใหญ่ที่รูปหนักทั้งเว็บ — crawl แล้วพบว่ารูปก่อน-หลังการรักษาถูกอัปโหลดตรงจากกล้อง ใบละ 5–8 MB รวมทั้งเว็บเกิน 400 MB การเห็นตัวเลขรวมนี้ในตารางเดียวทำให้เจ้าของตัดสินใจอนุมัติงานแปลงรูปทั้งชุดได้ในวันเดียว — ซึ่งถ้าไม่มีข้อมูลรวม ก็คงเถียงกันไปมาว่า “รูปมันหนักจริงหรือเปล่า”

ที่ Southern Whale เราใช้ Screaming Frog เป็นด่านแรกของทุกโปรเจกต์ บริการ SEO — ก่อนจะเสนอแผนหรือคิดราคาใด ๆ เรา crawl เว็บลูกค้าให้ครบก่อน เพราะเราเชื่อว่าการบอกลูกค้าว่า “เว็บคุณมีปัญหา 4 เรื่อง แต่ละเรื่องกระทบยอดจองยังไง” มีค่ากว่าการขายแพ็กเกจที่ลูกค้าไม่รู้ว่าซื้ออะไร

6 ข้อผิดพลาดที่พบบ่อยเวลาใช้ Screaming Frog

1. ตกใจกับตัวเลขโดยไม่ดูบริบท — เจอ 404 สองร้อยรายการแล้วแตกตื่น ทั้งที่ทั้งหมดเป็นลิงก์เก่าจากภายนอกที่ไม่มีใครคลิกมาสามปีแล้ว ดูคอลัมน์ Inlinks ก่อนเสมอ
2. ลืมว่ากำลัง crawl เว็บ staging — แล้วรายงานปัญหาที่ไม่มีอยู่ในเว็บจริงให้ลูกค้า เช็ก URL ต้นทางทุกครั้งก่อนส่งงาน
3. crawl แรงเกินจนโดนบล็อก แล้วเข้าใจว่าเว็บลูกค้าล่ม — ถ้าเจอ 429/503 กระจายเต็มไปหมด ให้ลด thread แล้ว crawl ใหม่ก่อนสรุป
4. ไม่เปิด JavaScript rendering กับเว็บที่ต้องใช้ — แล้วสรุปว่าเว็บลูกค้าไม่มีเนื้อหาเลย ซึ่งเป็นความผิดของการตั้งค่า ไม่ใช่ของเว็บ
5. แก้ทุกอย่างที่โปรแกรมขึ้นสีแดง — Screaming Frog รายงาน “ข้อเท็จจริง” ไม่ใช่ “ปัญหา” คนต้องเป็นคนตัดสินว่าอะไรสำคัญ เช่น title ยาวเกิน 561px ในหน้านโยบายความเป็นส่วนตัว ไม่ใช่เรื่องที่ต้องเสียเวลาแก้
6. crawl ครั้งเดียวแล้วจบ — ควร crawl ซ้ำหลัง deploy ทุกครั้งที่มีการเปลี่ยนโครงสร้าง เพราะปัญหาส่วนใหญ่เกิดตอนแก้เว็บ ไม่ได้เกิดเองระหว่างทาง

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

Screaming Frog ใช้ฟรีได้ตลอดไปไหม ได้ รุ่นฟรีไม่มีวันหมดอายุ แต่จำกัด 500 URL ต่อ crawl และปิดฟีเจอร์เชื่อม API ไว้ทั้งหมด

crawl เว็บคู่แข่งได้ไหม ได้ และเป็นวิธีดูโครงสร้างเว็บกับ title ของคู่แข่งที่เร็วที่สุด แต่ควร crawl ช้า ๆ ด้วยมารยาท และเข้าถึงได้เฉพาะข้อมูลสาธารณะเท่านั้น

ต้องใช้เครื่องแรงแค่ไหน เว็บต่ำกว่า 10,000 URL ใช้โน้ตบุ๊กทั่วไป RAM 8 GB ก็พอ ถ้าเกินแสน URL ควรมี RAM 16–32 GB และตั้งเป็น Database Storage บน SSD

Screaming Frog แทน Google Search Console ได้ไหม ไม่ได้ คนละหน้าที่กัน Screaming Frog บอกว่าเว็บคุณ “เป็นยังไง” ส่วน GSC บอกว่า Google “คิดยังไง” กับเว็บคุณ ควรใช้คู่กันเสมอ

มีแบบภาษาไทยไหม ตัวโปรแกรมเป็นภาษาอังกฤษ แต่ crawl เว็บภาษาไทยและอ่านค่าภาษาไทยได้ปกติ ระวังแค่ตอน export CSV ให้เลือก encoding แบบ UTF-8 ไม่งั้นตัวอักษรไทยจะเพี้ยนตอนเปิดใน Excel

สรุป

Screaming Frog ไม่ใช่เครื่องมือที่กด Start แล้วได้คำตอบสำเร็จรูป — มันคือกล้องส่องที่ให้ข้อมูลดิบมหาศาล และคุณค่าทั้งหมดอยู่ที่ว่าคุณรู้ไหมว่าจะมองคอลัมน์ไหน

ถ้าจะจำแค่สี่อย่างจากบทความนี้: หนึ่ง — ตั้งค่าความเร็วให้ช้าไว้ก่อนเสมอ สอง — เริ่มดูจาก 4xx และ redirect chain เพราะแก้ง่ายและเห็นผลไว สาม — เชื่อม GSC เพื่อให้ข้อมูลโครงสร้างมาเจอกับข้อมูลผลลัพธ์จริง และสี่ — รายงานที่ดีคือรายงานที่ลูกค้าอ่านแล้วรู้ว่าต้องทำอะไรต่อ ไม่ใช่ไฟล์ CSV สี่หมื่นแถว

เว็บส่วนใหญ่ที่ “ทำ SEO แล้วไม่ขึ้น” ไม่ได้ขาดบทความเพิ่ม แต่มีรอยรั่วทางเทคนิคที่ไม่มีใครเคยไล่ดูอย่างเป็นระบบ ลอง crawl เว็บตัวเองด้วยรุ่นฟรีสักครั้งในสัปดาห์นี้ แล้วคุณอาจแปลกใจว่าปัญหาที่ค้างคาใจมานาน จริง ๆ แล้วซ่อนอยู่ในตารางเดียวมาตลอด