สืบสวน Log File: 7 Pattern ที่เราเจอในทุกการตรวจสอบ

การตั้งค่า: จะได้ log ที่ใช้งานได้อย่างไร

บน Hostinger, AWS Lightsail และ managed WordPress host ส่วนใหญ่ raw access log มักอยู่ที่ประมาณ /var/log/nginx/access.log หรือดาวน์โหลดได้จาก cPanel ภายใต้ "Raw Access" Cloudflare เพิ่มเลเยอร์เฉพาะของตัวเองเข้ามา คุณจะต้องการ log ทั้งจาก origin ของคุณ และจาก Logpush ของ Cloudflare (แพ็กเกจ Enterprise) หรือ Logpull (Pro+ ขึ้นไป) ถ้า origin ของคุณอยู่หลัง Cloudflare

สำหรับ snippet ด้านล่าง เราสมมติว่าใช้ Apache/Nginx combined log format:

66.249.66.1 - - [18/Feb/2026:08:14:22 +0700] "GET /products/shoes?color=red&sort=price HTTP/1.1" 200 8423 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

ถ้า format ของคุณแตกต่างออกไป ให้สลับตำแหน่ง field ใน snippet ของ awk ให้เหมาะสม ตลอดบทความนี้ $1 คือ IP, $7 คือ request URI, $9 คือ status code, $10 คือ bytes และ user-agent เริ่มที่ $12

ขั้นตอนแรก: กรองหา Googlebot ที่ยืนยันแล้ว

User-agent string โกหกได้ Googlebot ตัวจริง reverse-resolve ไปที่ googlebot.com หรือ google.com วิธีกรองแบบง่ายและถูกต้องเกือบทุกครั้ง:

# Quick filter — UA-only (good enough for triage)
awk '/Googlebot/' access.log > gbot.log

# Verified — reverse DNS check (Python)
import socket
def is_verified_googlebot(ip):
    try:
        host = socket.gethostbyaddr(ip)[0]
        if not host.endswith(('.googlebot.com', '.google.com')):
            return False
        return socket.gethostbyname(host) == ip
    except: return False

สำหรับ ~1.4% ของ hit ที่อ้างว่าเป็น "Googlebot" ใน dataset ของเรา การเช็ก reverse-DNS ล้มเหลว นั่นคือ traffic ปลอมที่คุณควร block ที่ firewall ด้วยเช่นกัน

Pattern 1: การสูญเสีย crawl budget จากการรวม parameter

Faceted navigation (สี × ขนาด × ราคา × การเรียงลำดับ) สร้างจำนวน URL แบบ exponential เราเคยเห็นเว็บไซต์ e-commerce ที่ Googlebot ใช้ 74% ของ crawl budget ไปกับ URL ที่มี parameter ซึ่งไม่ควรถูก index เลย

การตรวจจับ

# Top 20 parameterized URLs Googlebot is hammering
awk '/Googlebot/ && $7 ~ /\?/ {print $7}' access.log | \
  sort | uniq -c | sort -rn | head -20

วิธีแก้

สามชั้น: (1) robots.txt Disallow สำหรับ parameter ที่รู้อยู่แล้วว่าไร้ประโยชน์; (2) rel="canonical" บนหน้าที่มี parameter ชี้ไปยัง URL สะอาด; (3) เครื่องมือ URL Parameters ใน Search Console (ถ้ายังใช้ได้) การรวมทั้งสามชั้นเข้าด้วยกันคือสิ่งที่ได้ผล — ใช้แค่อันเดียวก็ยังรั่วไหล crawl budget อยู่ดี

Pattern 2: soft-404 ระเบิดจำนวนจาก internal search

หน้า internal search ที่ return 200 OK พร้อมเนื้อหา "ไม่พบผลลัพธ์" คือ soft-404 ในที่สุด Google จะจับได้และเริ่มเพิกเฉยต่อ URL เหล่านั้น แต่ระหว่างช่วงที่ Google กำลังหาคำตอบ crawl budget ของคุณจะไหลออกไปเรื่อย ๆ

การตรวจจับ

# Bytes-served distribution for /search/ URLs
# Empty result pages tend to cluster at low byte counts
awk '/Googlebot/ && $7 ~ /\/search/ {print $10}' access.log | \
  sort -n | uniq -c | head -20

ถ้าคุณเห็นการกระจายแบบ bimodal — request จำนวนมากอยู่ที่ ~12KB และหางยาวที่ ~28KB — ตัวที่เล็กมักเป็นหน้าที่ผลลัพธ์ว่างเปล่า

วิธีแก้

Return HTTP 404 (หรือ 410) เมื่อการค้นหาไม่พบผลลัพธ์เลย ใส่ noindex บนหน้า search ทั้งหมดไว้ก่อนเช่นกัน block /search/ ใน robots.txt เพื่อความปลอดภัยสูงสุด แต่ทำหลังจากยืนยันแล้วว่าคุณไม่ได้ block หน้า landing page ที่เกี่ยวข้องกับ organic traffic

Pattern 3: parameter loop (กับดัก spider ไม่รู้จบ)

กรณีคลาสสิก: widget ปฏิทินที่ให้ผู้ใช้เลื่อนไปข้างหน้าได้ไม่รู้จบ (?date=2099-04-22) หรือลิงก์ "ดูรายการถัดไป" ที่ไม่มีหน้าสุดท้าย Googlebot จะตามลิงก์เหล่านี้ไปเป็นพัน URL ก่อนจะยอมแพ้

การตรวจจับ

# Find URL patterns where Googlebot has hit >500 distinct values
import re
from collections import Counter

patterns = Counter()
with open('gbot.log') as f:
    for line in f:
        m = re.search(r'GET (\S+)', line)
        if not m: continue
        url = m.group(1)
        # strip the parameter VALUE, keep the parameter NAME
        normalized = re.sub(r'=[^&]+', '=*', url)
        patterns[normalized] += 1

for url, count in patterns.most_common(20):
    if count > 500:
        print(f"{count:6d}  {url}")

วิธีแก้

ใส่ nofollow บนลิงก์ที่เป็นปัญหา บวกกับ robots.txt Disallow บน pattern ของ parameter นั้น widget ปฏิทิน/navigation ควรมีขอบเขตบนที่ชัดเจน — ไม่มีลิงก์ "เดือนถัดไป" เกิน +12 จากวันนี้

Pattern 4: การหมด render budget (SPA ที่หนัก JS)

Googlebot มี "render budget" แยกต่างหากที่เล็กกว่า สำหรับหน้าที่ต้องรัน JS เราเจอ SPA เป็นประจำที่ HTML ส่งกลับมาเร็ว แต่เวอร์ชันที่ render แล้วใช้เวลา 4-8 วินาที กว่าจะนิ่ง Googlebot crawl HTML, เข้าคิวรอ render และมีเปอร์เซ็นต์หนึ่งของหน้าที่ไม่เคย render สำเร็จก่อนคิวจะหมุนเวียนไปหน้าถัดไป

การตรวจจับ

# Compare crawl frequency between known-rendered URLs (have unique content
# in HTML) vs known-JS-rendered URLs (content only after JS)
# A working render pipeline shows similar crawl freq; a broken one shows
# JS pages crawled 2-4x less often.
awk '/Googlebot/ {print $7}' access.log | sort | uniq -c | \
  sort -rn > crawl_freq.txt

ตรวจสอบไขว้กับ sitemap ของคุณ URL ที่อยู่ใน sitemap แต่มี Googlebot เข้ามาน้อยกว่า 1 ครั้งต่อสัปดาห์ ในขณะที่ URL ใกล้เคียงมี 5-10 ครั้ง มักเป็นสัญญาณว่า render ค้าง

วิธีแก้

Server-side render หรือ static-generate เนื้อหาสำคัญ Hydration ทำได้ไม่มีปัญหา แต่ markup ที่ first-paint ต้องมี title, meta และเนื้อหาหลักอยู่แล้ว เราย้าย SPA ของลูกค้า 4 ราย จาก CSR ไปเป็น Next.js SSG/ISR ในปี 2025 และความถี่ในการ crawl บน URL ที่เคยค้างเพิ่มขึ้น 4-9 เท่า ภายใน 2 สัปดาห์ เราจัดการงาน migration แบบนี้เองในบริษัทเมื่องาน SEO ต้องการการ rebuild

Pattern 5: redirect chain และ 301 ที่ไร้ปลายทาง

301 ทุกตัวใน chain มีค่าใช้จ่ายทั้ง link equity และประสิทธิภาพการ crawl หลังจาก migration เว็บไซต์มาพอสมควร เว็บไซต์ขนาดใหญ่ส่วนใหญ่จะสะสม chain ยาว 5-7 hop สำหรับ URL ที่คาดไม่ถึง

การตรวจจับ

# All 301s, sorted by frequency
awk '/Googlebot/ && $9 == 301 {print $7}' access.log | \
  sort | uniq -c | sort -rn > redirects.txt

# Then for each top redirect, follow the chain manually:
curl -sIL https://yoursite.com/path/that/redirects | grep -i "^location\|^http"

วิธีแก้

301 ทุกตัวควรชี้ตรงไปยังปลายทางสุดท้าย ตรวจสอบทุกไตรมาส หลังการ migration ทุกครั้ง รัน script หา chain บน redirect map เพื่อจับสถานการณ์ A → B → C แล้วเขียนใหม่เป็น A → C

Pattern 6: การ crawl ที่เสียเปล่าบน staging, dev และ subdomain ที่ถูกลืม

Staging environment ที่ถูก index โดยไม่ตั้งใจ หน้า admin ของ Drupal ที่ถูกลืม /wp-json/ ที่ถูกสำรวจหา API endpoint /feed/ ที่ถูก crawl 200 ครั้งต่อวัน

การตรวจจับ

# Top hosts in Googlebot traffic — should ONLY be your canonical
awk '/Googlebot/ {print $2}' access.log | sort | uniq -c | sort -rn

# (If you log Host header — adjust field number for your log format)

วิธีแก้

Staging ต้องมี HTTP basic auth หรือ header X-Robots-Tag: noindex อย่างชัดเจน /wp-json/ ควรถูก block เว้นแต่คุณใช้ REST API แบบสาธารณะจริง ๆ subdomain ที่ตายแล้วควร redirect ไปยัง canonical หรือ return 410

Pattern 7: อัตราการ crawl ที่ดิ่งลงโดยไม่มีใครสังเกต

Pattern ที่อันตรายที่สุด: Googlebot เคย crawl เว็บไซต์ของคุณ 8,000 ครั้งต่อวัน ตอนนี้เหลือ 2,000 และคุณไม่ทันสังเกตเพราะอันดับยังโอเคอยู่ชั่วคราว พอถึงตอนที่อันดับตก คุณจะช้ากว่าการวินิจฉัยไปแล้ว 6 สัปดาห์

การตรวจจับ

# Daily Googlebot hit count over 30 days
awk '/Googlebot/ {
  match($4, /\[([0-9]+)\/([A-Za-z]+)\/([0-9]+)/, d);
  print d[3]"-"d[2]"-"d[1]
}' access.log | sort | uniq -c | tail -30

ลองพล็อตกราฟดู ถ้าเส้นกราฟราบเรียบ คุณสบายใจได้ ถ้ามันค่อย ๆ ลดลงเป็นขั้นบันได ให้ขุดหาสาเหตุทันที — ทุกขั้นที่ลดลงคือ signal ด้านคุณภาพจาก Google ที่คุณพลาดไป

วิธีแก้

วิธีแก้ขึ้นอยู่กับสาเหตุ แต่ flow การวินิจฉัยคือ: (1) เช็ก Search Console หา crawl error; (2) เช็กประวัติ robots.txt หา Disallow ที่เพิ่มเข้ามาโดยไม่ตั้งใจ; (3) เช็กแนวโน้ม response rate ของ 5xx; (4) เช็ก Core Web Vitals ทั้งเว็บไซต์; (5) ตรวจสอบการเปลี่ยนแปลงเนื้อหาใหญ่ ๆ ใน 8 สัปดาห์ที่ผ่านมา INP ที่แย่ลง มักมีความสัมพันธ์กับ crawl rate ที่ตกด้วยเช่นกัน — Google ลดความสำคัญของเว็บไซต์ที่ช้า

"Server log คือสิ่งที่เทียบเท่ากับผลตรวจเลือดของหมอในโลก SEO ส่วน Search Console คือคนไข้ที่บรรยายอาการ ทั้งสองอย่างสำคัญ แต่มีแค่อันเดียวที่บอกคุณว่าเกิดอะไรขึ้นจริง ๆ"

Python pipeline ที่เรารันให้ลูกค้าทุกราย

สำหรับลูกค้าที่ทำงานต่อเนื่อง เรา automate ทั้ง 7 pattern ให้เป็นการตรวจสอบทุกคืน นี่คือโครงร่าง:

import re
from collections import Counter, defaultdict
from datetime import datetime

GBOT_RE = re.compile(r'^(\S+) .* \[([^\]]+)\] "(\w+) (\S+) HTTP/[\d.]+" (\d+) (\d+) ".*" "([^"]+)"')

class LogAuditor:
    def __init__(self):
        self.daily_count = Counter()
        self.param_loops = Counter()
        self.status_dist = Counter()
        self.redirects = Counter()
        self.search_pages = []

    def ingest(self, line):
        m = GBOT_RE.match(line)
        if not m or 'Googlebot' not in m.group(7): return
        ip, ts, method, url, status, bytes_, ua = m.groups()
        date = datetime.strptime(ts.split()[0], '%d/%b/%Y:%H:%M:%S').date()
        self.daily_count[date] += 1
        self.status_dist[int(status)] += 1
        if int(status) == 301: self.redirects[url] += 1
        if '/search' in url: self.search_pages.append((url, int(bytes_)))
        normalized = re.sub(r'=[^&]+', '=*', url)
        self.param_loops[normalized] += 1

    def report(self):
        # ... emit slack/email summary
        pass

script ตัวเดียวกันนี้ขับเคลื่อนระบบตรวจจับความผิดปกติทุกคืนที่ทำงานคู่ขนานไปกับscraper ที่รัน 10,000 คำค้นหาทุกคืนของเรา เมื่ออัตรา crawl ของลูกค้าลดลงมากกว่า 20% เทียบสัปดาห์ต่อสัปดาห์ เราจะได้รับการแจ้งเตือนก่อนที่พวกเขาจะสังเกตเห็นว่ามีอะไรผิดปกติ

สิ่งที่ log บอกคุณไม่ได้

Log ทรงพลังแต่ก็มีข้อจำกัด มันบอกไม่ได้ว่า Googlebot index สิ่งที่มัน crawl ไปหรือเปล่า — มีแค่ Search Console เท่านั้นที่รู้ มันยังบอกไม่ได้ว่าคีย์เวิร์ดไหนที่นำ traffic เข้ามา สำหรับเรื่องนั้นคุณต้องใช้ Performance API ของ GSC stack การวินิจฉัยที่ครบถ้วนคือ log + Search Console + SERP scraper + JavaScript-rendering crawler ข้ามอันใดอันหนึ่งไป คุณจะขาดเลเยอร์หนึ่งไปทันที

บริการ technical SEO ของเรารวม log analysis ไว้เป็น deliverable มาตรฐานในทุก retainer มันคือจุดแรกที่เรามองหาเมื่อลูกค้าบอกว่า "อันดับตกและเราไม่รู้ว่าทำไม" สำหรับลูกค้าที่มี log อยู่แล้วแต่ไม่รู้จะทำอะไรกับมัน เรารับตรวจ log audit แบบครั้งเดียวในราคาคงที่ — ปกติจะพบ 3-6 pattern จากที่กล่าวมาข้างต้น

อ่านเพิ่มเติม

การสืบสวน log file เป็นจุดเริ่มต้นหนึ่งเข้าสู่ technical surface ทั้งหมด จุดเริ่มต้นอื่น ๆ ได้แก่ คุณภาพของ schema graph (สิ่งที่ AI engine มองเห็น), การเพิ่มประสิทธิภาพ INP (สิ่งที่ผู้ใช้รู้สึกได้), pattern การอ้างอิงจาก AEO (สิ่งที่ถูกนำขึ้นมาแสดง) และquality gate สำหรับ programmatic (สิ่งที่ขยายขนาดได้โดยไม่พัง) รวมกันแล้วสิ่งเหล่านี้ครอบคลุมงานวิศวกรรมส่วนใหญ่ที่ขยับอันดับได้จริงในปี 2026 งาน editorial, CRO และเลเยอร์เทคนิคทั้งหมดถูกจัดการโดยทีมในบริษัททีมเดียวกัน