SEO มักถูกย่อให้เหลือเพียง keyword, title และคะแนนจาก plugin แต่สิ่งที่นักพัฒนาเว็บควบคุมได้มากกว่านั้นคือ search system ค้นพบ URL ได้หรือไม่ ได้รับ HTML ที่มีประโยชน์หรือไม่ เข้าใจจุดประสงค์ของหน้า เลือก canonical ถูกต้อง เชื่อมโยงหน้าหลายภาษาได้ และส่งผู้ใช้ไปยังประสบการณ์ที่ใช้งานได้จริงหรือไม่
บทความนี้สรุปบทเรียนจากการสร้าง audit แก้ไข deploy และ crawl ซ้ำบน DJAI Academy ซึ่งมี 205 URL ใน sitemap ครอบคลุมเครื่องมือสองภาษา บทความ product portfolio course และ web application หลายชุด หลายหน้าดูถูกต้องใน browser แต่ crawler เปิดเผยว่า contract เบื้องหลังยังไม่สมบูรณ์
ผล audit รอบสุดท้ายได้ technical SEO baseline ที่แข็งแรง: 205 จาก 205 URL ตอบ HTTP 200 และ indexable ไม่พบ title, description, H1 หรือ canonical ที่หายหรือซ้ำ ไม่พบ hreflang return link หรือ x-default ที่ขาด และไม่พบ sitemap URL ที่ตอบ 4xx หรือ 5xx นี่คือหลักฐานทางวิศวกรรมที่มีความหมาย แต่ไม่ใช่คำรับประกัน ranking, indexing, traffic หรือการถูก AI อ้างอิง
SEO คือส่วนหนึ่งของ software quality
โดยทั่วไป search engine ทำงานผ่าน discovery, crawling, rendering, indexing, ranking และการนำเสนอผลลัพธ์ หากขั้นต้นมีปัญหา การปรับขั้นหลังแทบไม่มีความหมาย
- ไม่ถูกค้นพบ มักเกี่ยวกับ internal link, sitemap หรือ external discovery
- ถูกค้นพบแต่ไม่ถูก crawl อาจเกิดจาก access rule, server error หรือข้อจำกัดการ crawl
- ถูก crawl แต่ไม่ index อาจเกี่ยวกับ duplicate, canonical conflict, คุณภาพต่ำ หรือ indexing directive
- index แล้วแต่ไม่ rank อาจเกี่ยวกับ relevance, usefulness, authority, competition หรือ experience
- rank แต่ไม่มีคนคลิก อาจเกี่ยวกับ title, snippet, ความน่าเชื่อถือ หรือ search intent ไม่ตรงกัน
Developer เป็นผู้กำหนด HTTP response, HTML, route, redirect, metadata, JavaScript behavior, performance, accessibility และ deployment ดังนั้น SEO ไม่ใช่เครื่องประดับที่ติดหลังพัฒนา แต่เป็นส่วนหนึ่งของ product contract
เริ่มจาก search intent ไม่ใช่รายการ keyword
URL ที่ต้องการให้ index ควรมี workflow, input/output, preset หรือผลลัพธ์ที่แตกต่างจริง หน้า PNG to PDF และ PDF to PNG แก้โจทย์คนละทิศทาง Delete PDF pages และ Reorder PDF pages มี operation คนละแบบ Wi-Fi QR generator ต้องมีข้อมูล network, password และ security ขณะที่ vCard QR generator ต้องมีข้อมูลผู้ติดต่อ
ในทางกลับกัน JPG กับ JPEG คือ format เดียวกัน ส่วน Word to PDF กับ DOCX to PDF มักเป็น workflow เดียวกัน การสร้างหลายหน้าที่ต่างกันเพียงคำหนึ่งคำเพิ่มภาระดูแลโดยไม่เพิ่มคุณค่าให้ผู้ใช้
ก่อนสร้างหน้าใหม่ให้ถามว่า:
- หน้านี้แก้ปัญหาที่แตกต่างจริงหรือไม่
- interface เปิดมาในสถานะที่ title สัญญาไว้หรือไม่
- เนื้อหาอธิบาย input, output, limitation, privacy และ troubleshooting ของจริงหรือไม่
- ผู้ใช้ทำงานเสร็จใน URL นี้ได้หรือไม่
- หน้านี้ยังควรมีอยู่ไหมหากไม่มี traffic จาก search engine
กฎ intent-first ช่วยป้องกัน keyword cannibalization, thin template, doorway page และ scaled content ที่สร้างเพื่อควบคุม search system มากกว่าช่วยคน แนวทางล่าสุดของ Google สำหรับ generative search ก็เตือนไม่ให้สร้างหน้าสำหรับทุก query variation คุณภาพและความแตกต่างจริงยังเป็นกลยุทธ์ระยะยาว อ่านแนวทาง AI search ของ Google
Contract ของหน้าที่ต้องการให้ index
หน้า indexable โดยทั่วไปควรมี:
- HTTP 200 ที่ URL ปลายทาง
- main content ที่มีประโยชน์ใน initial HTML เมื่อทำได้
- H1 ที่ชัดเจน มองเห็นได้ และตรงกับจุดประสงค์
- title ที่เฉพาะเจาะจงและไม่ซ้ำ
- meta description ที่ช่วยอธิบายหน้า
- absolute self-referencing canonical
- crawlable internal link จาก hub ที่เกี่ยวข้อง
- index directive ที่ถูกต้อง
- ความสัมพันธ์ระหว่างภาษาที่ครบถ้วน
- alt text สำหรับภาพที่ให้ข้อมูล
- control ที่รองรับ mobile และ accessibility
- sitemap entry หลัง production ใช้งานได้จริงเท่านั้น
รายการนี้เป็น contract ไม่ใช่สูตร ranking หน้าอาจผ่านทุกข้อแต่ยังไม่สำเร็จหากเนื้อหาไม่ช่วยผู้ใช้ ไม่ original ทำให้เข้าใจผิด หรือด้อยกว่าผลลัพธ์อื่น
ความผิดพลาดที่พบบ่อยและผลต่อ SEO
Title หายหรือซ้ำ
Title ช่วยแยกความหมายของแต่ละหน้าและมีผลต่อการนำเสนอใน search result หากหลาย URL ใช้ title เดียวกัน ระบบจะเห็นหน้าเหล่านั้นคล้ายกันมาก Title ที่กว้างเกินไปซ่อนจุดประสงค์ และ search engine อาจ rewrite ควรแก้ template หรือ data source ต้นเหตุ ไม่แก้ไฟล์ generated ทีละร้อยหน้า
Meta description อ่อนหรือซ้ำ
Meta description ไม่ใช่ ranking boost ที่รับประกัน และระบบอาจเลือกข้อความอื่นมาทำ snippet แต่ description ที่ดีช่วยสรุปหน้าให้ตรง query การไม่มีหรือคัดลอกซ้ำลดการควบคุมของ publisher และอาจทำให้ผลลัพธ์ไม่น่าคลิก
H1 หาย ซ้ำ หรืออยู่เฉพาะหลัง JavaScript ทำงาน
Browser อาจแสดง heading หลัง JavaScript run แล้ว ขณะที่ HTML-only client ได้เอกสารแทบว่าง H1 และ intro ที่ server ส่งมาตั้งแต่แรกช่วย semantic structure, accessibility และ crawler compatibility การมีหลาย H1 ไม่ได้แปลว่าพังเสมอ แต่ primary heading เดียวที่ชัดเจนเป็น convention ที่ตรวจสอบง่าย
Canonical ขัดแย้งกัน
Canonical บอกว่าควรใช้ URL ใดแทนชุดเนื้อหาที่ซ้ำหรือใกล้เคียง ปัญหาเกิดเมื่อ HTML ชี้ URL หนึ่ง sitemap ใส่อีก URL internal link ใช้อีกแบบ และ redirect ไปอีกปลายทาง สัญญาณจึงกระจายและระบบอาจเลือกหน้าผิด
ให้ preferred page มี self-referencing canonical ใช้ URL เดียวกันใน internal links และ sitemap และ permanent redirect duplicate ที่เลิกใช้ อย่าใช้ robots.txt เป็นเครื่องมือ canonicalization Google อธิบายว่า redirect และ canonical link เป็น strong signal ส่วน sitemap อ่อนกว่า ดูเอกสาร canonical ของ Google
Hreflang ไม่ reciprocal
หน้าหลายภาษาเป็นความสัมพันธ์ ไม่ใช่ link ทางเดียว ถ้า English ระบุ Thai เป็น alternate หน้า Thai ก็ควร return ความสัมพันธ์ ทุกหน้าควร canonical มาหาตัวเอง และ alternate ทุก URL ต้องเป็นปลายทาง indexable ส่วน x-default ระบุ fallback เมื่อไม่มีภาษาที่ตรง
Mapping ผิดอาจทำให้ระบบ ignore cluster หรือแสดงภาษาที่ไม่คาดคิด และมักเป็นสัญญาณว่า translation data, routing และ metadata generation ไม่ตรงกัน
Broken link, redirect chain และ orphan page
Broken link สร้างทางตัน Redirect chain เพิ่ม request และทำให้ navigation ช้า Orphan page อาจอยู่ใน sitemap แต่ไม่มี contextual link จากเว็บไซต์ Sitemap ช่วย discovery แต่แทน architecture ไม่ได้ หน้าที่มีคุณค่าควร link จาก category hub และเชื่อมกับหน้าที่เกี่ยวข้องจริง
Alt text ว่างบนภาพที่มีความหมาย
Alt ว่างเหมาะกับ decorative image แต่ไม่เหมาะกับ product screenshot, diagram หรือภาพ interface ที่ส่งสาร Descriptive alt text ช่วย accessibility และให้ context แก่ image system ควรบอกบทบาทของภาพโดยไม่ keyword stuffing
Structured data ที่กล่าวเกินจริง
Structured data ต้องอธิบายสิ่งที่ผู้ใช้มองเห็นจริง ห้ามสร้าง review, rating, price, availability, credential หรือ feature ที่ไม่มี JSON-LD ถูก syntax ไม่ได้รับประกัน rich result และ schema ช่วย thin content ไม่ได้ ใช้มันเพื่อระบุ entity และ relationship เช่น Organization, Article, SoftwareApplication, Course และ BreadcrumbList
คิดว่าคะแนนคือหลักฐานว่า SEO เสร็จแล้ว
Lighthouse SEO score ตรวจเพียง technical subset ไม่ได้วัด search demand, originality, backlinks, index coverage, intent satisfaction หรือ conversion เช่นเดียวกับ clean crawl ที่พิสูจน์ไม่ได้ว่า Google index ทุกหน้า ต้องใช้ Search Console ตรวจ indexing และ search performance ไม่ใช่พึ่ง site: query
SEO crawler คืออะไร
SEO crawler เข้า URL ตาม link อ่าน response และสร้าง dataset ของทั้งเว็บไซต์ แทนการเปิด browser ตรวจทีละหน้า Developer สามารถเปรียบเทียบหลายร้อยหน้าใน field เดียวกัน:
- Status code และ redirect target
- Title, description, heading และ word count
- Canonical และ robots directive
- Internal link, anchor text, crawl depth และ orphan candidate
- Image URL และ alt text
- Hreflang และ return link
- Duplicate หรือ near-duplicate content
- Structured data เมื่อเปิด validation
- Performance data เมื่อเชื่อม API
Crawler เปลี่ยนอาการรายหน้าให้กลายเป็น pattern ถ้า 40 หน้าขาด title ต้นเหตุน่าจะอยู่ที่ template ถ้าเฉพาะ blog เก่าสามหน้ามี language link ผิด ต้นเหตุน่าจะเป็น stored data ที่สำคัญ crawler สร้าง baseline ที่ทำซ้ำได้: crawl ก่อนแก้ deploy แล้ว crawl ซ้ำเพื่อเปรียบเทียบ
เราใช้ Screaming Frog กับ DJAI Academy อย่างไร
เราใช้ Screaming Frog SEO Spider 24.3 แบบ local กับ production Standard Spider crawl ครั้งแรกชนเพดาน 500 URL ของ free edition เพราะ page, script, image และ resource อื่นถูกนับทั้งหมด แต่ crawl นั้นยังพบปัญหาสี่กลุ่ม
- Bio page แบบ client-rendered สองหน้าขาด crawlable H1 ใน initial response
- Blog translation เก่าสามคู่ขาด reciprocal hreflang
- QR page family หนึ่งชุดขาด x-default
- Product image ที่มีความหมายใช้ alt ว่าง
เราแก้ source implementation และ build ระบบเต็มใหม่ จากนั้น production เปิดเผยปัญหาที่ลึกกว่า: persistent blog file ใช้ data shape เก่ากว่า seed ใน repository ทำให้ English metadata หา Thai partner จริงไม่ได้เสมอ วิธีแก้จึงต้องรองรับ legacy production data ไม่ใช่สมมติว่า schema ใหม่มีอยู่ทุกที่
Compatibility fix รอบแรกเพิ่ม asynchronous lookup อีกหนึ่งชั้น Next.js สร้าง metadata ได้ แต่ standard HTML crawl ได้ canonical และ language annotation ช้าเกินไปเพราะ metadata ถูก stream เราจึงเปลี่ยนเป็น synchronous seeded lookup เพื่อให้ critical metadata อยู่ใน initial document head
บทเรียนสำคัญคือ:
Framework สร้าง metadata ได้ ยังไม่ถือว่า verify จนกว่าจะตรวจ deployed response จริงด้วย client ประเภทเดียวกับที่จะใช้งานข้อมูลนั้น
สุดท้ายเรา download URL ทั้ง 205 รายการจาก live sitemap แล้วใช้ List Mode วิธีนี้ใช้ free allowance กับ submitted-page set โดยตรงแทน resource ทุกชนิด Spider Mode บอกว่า architecture เปิดเผยอะไร ส่วน List Mode บอกว่า submitted URL ทุกหน้าผ่าน release contract หรือไม่
Screaming Frog MCP และสิ่งที่เราใช้จริง
Screaming Frog version 24 เพิ่ม MCP server ให้ AI assistant ที่รองรับสามารถเริ่ม crawl, ดู progress, query crawl data, run analysis และ export report ผ่าน natural-language tool call เป็น paid-licence feature ต้องใช้ database storage mode และสามารถเปิด Node.js กับ filesystem capability แบบควบคุมได้ อ่านคู่มือ MCP อย่างเป็นทางการ
สำหรับ DJAI audit ครั้งนี้เราใช้ local CLI ไม่ได้ใช้ MCP server Free edition และ List Mode เพียงพอต่อการ verify 205 หน้า บทความ case study ที่น่าเชื่อถือต้องบอกความแตกต่างนี้ตรงไปตรงมา
MCP มีคุณค่ามากใน workflow ที่ทำซ้ำ Agent สามารถสั่ง crawl production, export canonical target ที่ไม่ใช่ 200, group missing heading ตาม template, หา English page ที่ไม่มี Thai return link, compare crawl database และ re-crawl URL ที่แก้แล้ว Human ยังเป็นผู้รับผิดชอบ priority, business context, security และ final judgment
AI search optimization เริ่มจาก SEO ปกติ
Google ระบุว่า generative search experience ยังอาศัย core Search indexing และ ranking system พื้นฐานจึงเหมือนเดิม: crawlable content, canonical ที่ถูกต้อง, internal link, original information, entity ที่ชัดเจน และหน้าที่ตอบโจทย์ผู้ใช้
เนื้อหาจะ retrieve และ cite ได้ง่ายขึ้นเมื่อ:
- ตอบคำถามหลักตั้งแต่ต้น
- ใช้ heading ที่อธิบายหัวข้อจริง
- นิยาม technical term โดยตรง
- มีตัวอย่าง ประสบการณ์ ตัวเลข และ limitation
- ระบุ author, publisher, product และ organization อย่างสม่ำเสมอ
- ใช้ diagram หรือ media เมื่อช่วยให้เข้าใจ
- link authoritative source สำหรับข้อมูลที่เปลี่ยนตามเวลา
- ใช้ structured data ที่ตรงกับ visible content
DJAI เพิ่ม llms.txt ซึ่งรวม canonical link ของ organization, product, course, community และ tools แต่ต้องอธิบายอย่างถูกต้องว่า llms.txt เป็น emerging proposal ไม่ใช่มาตรฐานสากลหรือ ranking mechanism และไม่แทน HTML, robots.txt, XML sitemap, structured data หรือ internal link ดูข้อเสนอ llms.txt
หลีกเลี่ยง GEO hack เช่นผลิต Q-and-A จำนวนมาก สร้าง citation ปลอม ยัด query ในทุก heading หรือ publish AI text โดยไม่ review AI system ต้องการ source material ที่น่าเชื่อถือ การถูกค้นพบที่ดีขึ้นเริ่มจากการ publish ที่ดีขึ้น
Performance และ accessibility ต้องอยู่ใน review เดียวกัน
หน้า mobile ตัวแทนของ DJAI ได้ Lighthouse performance 98 ถึง 100, accessibility 100 และ SEO category 100 เราแก้ accessible name ทดสอบ layout ที่ 390 pixel ป้องกัน horizontal overflow และเปลี่ยน AdSense ที่ไม่ critical จาก beforeInteractive เป็น afterInteractive
การแก้เหล่านี้ช่วยผู้ใช้จริงก่อน Semantic heading, accessible control, stable layout, primary content ที่เร็ว และ nonblocking script ทำให้หน้าประมวลผลง่ายและใช้งานดีขึ้น แต่ Lighthouse เป็น lab evidence ส่วน real-user performance ต้องใช้ field data เช่น CrUX เมื่อมี eligible traffic เพียงพอ
Release workflow ที่ developer ควรใช้
- กำหนด intent และ outcome ที่แตกต่างจริง
- สร้างหน้าที่ใช้งานได้ครบ
- ทดสอบ application และ production build
- ตรวจ raw HTML และ rendered behavior
- Crawl local หรือ staging
- ตรวจ redirect, canonical, hreflang, robots, link และ sitemap
- Deploy ผ่าน release path ที่ได้รับอนุญาต
- ตรวจ production response ตัวแทน
- Run production Spider crawl
- Run sitemap List crawl เพื่อ coverage ที่แน่นอน
- แก้ root cause, rebuild, redeploy และ re-crawl
- Submit sitemap และ inspect URL ใน Search Console
- Monitor impression, click, engagement, conversion, indexing และ field performance
SEO fix ยังไม่เสร็จเมื่อ code เปลี่ยน แต่เสร็จเมื่อ deployed response ถูก verify อย่างอิสระ
บทเรียนสุดท้าย
DJAI audit ไม่ได้เพียงลบ warning แต่แสดงว่า SEO metadata คือ application data, legacy production state ทำให้ language relationship พังได้, JavaScript timing เปลี่ยนสิ่งที่ crawler ได้รับ และ crawler configuration เปลี่ยนขอบเขตของสิ่งที่ audit พิสูจน์ได้
Clean crawl รอบสุดท้ายสร้าง technical SEO baseline ที่ highly optimized ในขอบเขต sitemap ที่ตรวจ แต่ไม่ได้รับประกัน ranking เส้นแบ่งนี้สำคัญ: engineering ต้องสร้างหลักฐานที่น่าเชื่อถือ content ต้องสร้างคุณค่าจริง และ Search Console ต้องแสดงว่า search system ตอบสนองอย่างไรเมื่อเวลาผ่านไป
สร้างเพื่อคน อธิบายความหมายให้ machine เข้าใจ Verify ผ่านสายตาของ crawler แล้ววัดผลในโลกจริง