robots.txt ของ WordPress ปี 2026 ควรใส่อะไรลงไปบ้าง

robots.txt ที่ดีของ WordPress ยาวประมาณห้าบรรทัด บล็อก /wp-admin/ อนุญาต admin-ajax.php ชี้ crawler ไปที่ไซต์แมปของคุณ แล้วจบแค่นั้น รายการบล็อกยาวสี่สิบบรรทัดที่เจอตามเว็บบอร์ดส่วนใหญ่ทำให้การเรนเดอร์พังหรือไม่ก็ไม่ได้ทำอะไรเลย ทั้งไฟล์มีแค่นี้

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/wp-sitemap.xml

เปลี่ยนโดเมนให้เป็นของคุณ และถ้าคุณใช้ปลั๊กอิน SEO ที่เข้ามาจัดการไซต์แมปแทน ให้ชี้บรรทัด Sitemap ไปที่ดัชนีของปลั๊กอินตัวนั้น เท่านี้ก็จบ ถ้าไฟล์ของคุณยาวกว่านี้ บรรทัดส่วนเกินเหล่านั้นน่าจะกำลังทำให้คุณเสียอะไรบางอย่างอยู่

WordPress สร้างให้อยู่แล้ว จนกว่าคุณจะสร้างไฟล์จริง

WordPress มี robots.txt แบบเสมือนมาให้ เมื่อมีคำขอเข้ามาที่ /robots.txt และไม่มีไฟล์จริงอยู่ที่ web root ของคุณ WordPress จะดักคำขอนั้นแล้วพิมพ์การตอบกลับออกมาในหน่วยความจำ โดยไม่มีการเขียนลงดิสก์ ผลลัพธ์เริ่มต้นคือบล็อก wp-admin ข้างบน บวกกับบรรทัด Sitemap: สำหรับ wp-sitemap.xml ที่ core ส่งออกมาให้ตั้งแต่ WordPress 5.5

มีสองสิ่งที่เปลี่ยนผลลัพธ์นั้นได้ ถ้า การตั้งค่า → การอ่าน → ห้ามให้เครื่องมือค้นหาทำดัชนีเว็บไซต์นี้ ถูกติ๊กไว้ WordPress จะแทนที่ทั้งหมดด้วย Disallow: / ซึ่งบล็อกทุกอย่าง ช่องติ๊กนั้นคือสาเหตุอันดับหนึ่งที่ทำให้เว็บหายไปจากการค้นหาหลังเปิดตัว อย่างที่สอง ปลั๊กอินและธีมสามารถแก้ผลลัพธ์เสมือนนี้ผ่านตัวกรอง robots_txt ซึ่งเป็นวิธีที่ปลั๊กอิน SEO ใช้แทรกบรรทัดไซต์แมปและกฎของตัวเองเข้ามา

ทีนี้มาถึงส่วนที่กินเวลาคนทั้งบ่าย ไฟล์ robots.txt จริงใน web root จะเขียนทับทุกอย่างข้างบนแบบเงียบ ๆ เว็บเซิร์ฟเวอร์เจอไฟล์จริงบนดิสก์ ก็เสิร์ฟไฟล์นั้น และ WordPress ไม่ถูกโหลดเลย ตัวสร้างแบบเสมือนไม่ทำงาน ตัวกรอง robots_txt ไม่ถูกเรียก หน้าแก้ไข robots.txt ของปลั๊กอิน SEO อาจยังโชว์อินเทอร์เฟซสวย ๆ พร้อมกฎที่ถูกต้องให้คุณดู แต่ไม่มีอะไรในนั้นไปถึง crawler เลย

กฎอยู่ที่ไหน	แก้ได้จากหน้าแอดมิน WordPress	ชนะเมื่อมีคำขอจริง
แบบเสมือน (ไม่มีไฟล์บนดิสก์)	ได้ ผ่านตัวกรอง robots_txt หรือปลั๊กอิน	เฉพาะตอนที่ไม่มีไฟล์จริงเท่านั้น
ไฟล์จริงใน web root	ได้เฉพาะถ้าปลั๊กอินเขียนลงดิสก์	ชนะเสมอ

ดังนั้นก่อนจะไล่แก้อะไร ให้เปิด https://yoursite.com/robots.txt ในเบราว์เซอร์ แล้วต่อ SFTP หรือใช้ตัวจัดการไฟล์ของโฮสต์เพื่อดูว่ามีไฟล์ robots.txt จริงวางอยู่ข้าง ๆ wp-config.php และ .htaccess หรือไม่ ถ้ามี ไฟล์นั้นแหละคือ robots.txt ของคุณ ให้แก้ที่นั่น หรือลบทิ้งแล้วปล่อยให้ WordPress จัดการแทน แต่ต้องเลือกอย่างใดอย่างหนึ่ง การใช้ทั้งสองทางพร้อมกันคือที่มาของเว็บที่มี URL ไซต์แมปเก่าค้างจนไม่มีใครหาเจอ

ทำไมถึงบล็อก /wp-admin/ แต่อนุญาต admin-ajax.php

/wp-admin/ คือที่อยู่ของหน้าแดชบอร์ด URL เหล่านั้นไม่มีประโยชน์ในผลการค้นหา และการไล่เก็บมันก็เผา crawl budget ไปกับหน้าที่เปลี่ยนเส้นทางไปหน้าล็อกอินอยู่ดี การบล็อกไดเรกทอรีนี้จึงไม่มีใครเถียง

admin-ajax.php อยู่ในไดเรกทอรีเดียวกันแต่ไม่ใช่หน้าแอดมิน มันคือปลายทางที่ปลั๊กอินและธีมใช้จัดการคำขอ AJAX จากฝั่งหน้าเว็บ ทั้งปุ่มโหลดเพิ่ม ตารางสินค้าแบบกรอง เครื่องคิดเลข และฟอร์มต่าง ๆ ถ้า crawler ดึงไฟล์นี้ไม่ได้ มันก็มองไม่เห็นเนื้อหาที่ฟีเจอร์เหล่านั้นโหลดเข้ามา และ Google จะเรนเดอร์หน้าของคุณแบบเดียวกับที่ผู้เข้าชมเห็นตอนฟีเจอร์พัง

ส่วนที่ว่า Google จำเป็นต้องดึง admin-ajax.php บนเว็บของคุณจริงหรือไม่ ขึ้นอยู่กับว่าหน้าเว็บของคุณใช้มันหรือเปล่า คำตอบตรง ๆ คือ บนเว็บสมัยใหม่จำนวนมากมันไม่มีผลอะไรเลย เพราะธีมหันไปใช้ REST API ที่ /wp-json/ แทน บรรทัด Allow จึงเป็นประกันราคาถูกกันความพังที่เกิดขึ้นได้จริง ไม่ใช่ปัจจัยจัดอันดับ เก็บมันไว้เพราะมันไม่มีต้นทุนอะไร

อย่าบล็อก /wp-content/ หรือ /wp-includes/

นี่คือคำแนะนำเรื่อง robots.txt ที่แย่ที่สุดซึ่งยังลอยอยู่ในอินเทอร์เน็ต และมันมาจากยุคที่ Google ยังไม่เรนเดอร์หน้าเว็บ

/wp-content/ เก็บธีม ปลั๊กอิน และไฟล์อัปโหลดของคุณ ซึ่งก็คือสไตล์ชีต สคริปต์ และรูปภาพที่ทำให้หน้าเว็บของคุณดูเป็นหน้าเว็บ ส่วน /wp-includes/ เก็บ JavaScript ของ core ที่ปลั๊กอินต้องพึ่งพา Google เรนเดอร์หน้าเว็บของคุณด้วยเบราว์เซอร์แบบไร้หน้าจอก่อนจะตัดสินมัน ถ้าบล็อกไดเรกทอรีเหล่านั้น ตัวเรนเดอร์จะได้หน้าเว็บที่ไม่มี CSS และไม่มีรูปภาพ สิ่งที่ Google ประเมินจึงกลายเป็นกำแพงข้อความไร้สไตล์ที่เลย์เอาต์พัง ซึ่งกระทบทั้งความเข้าใจเนื้อหาของคุณและคะแนนความเหมาะกับมือถือ

ถ้าคุณรับไฟล์ที่มีบรรทัดเหล่านี้ต่อมา ให้ลบทิ้ง

Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

คุณยืนยันความเสียหายนี้ด้วยตัวเองได้ในเครื่องมือ URL Inspection ของ Google Search Console ลองรัน live test กับหน้าใดก็ได้ ดูภาพหน้าจอที่เรนเดอร์ออกมา แล้วตรวจรายการทรัพยากรของหน้าว่ามีอะไรถูกบล็อกบ้าง ถ้า CSS ของคุณขึ้นว่าถูกบล็อก นั่นแหละคือสาเหตุ

คำสั่ง Sitemap

บรรทัดเดียว ใช้ URL แบบเต็ม และวางไว้ตรงไหนของไฟล์ก็ได้ เพราะมันไม่ได้ผูกกับกลุ่ม User-agent ใด

Sitemap: https://example.com/wp-sitemap.xml

ใช้ URL ที่เปิดได้จริง WordPress core ให้บริการที่ wp-sitemap.xml ส่วนปลั๊กอิน SEO ส่วนใหญ่จะปิดไซต์แมปของ core แล้วให้บริการดัชนีของตัวเองที่เส้นทางอื่น ซึ่งมักเป็น sitemap_index.xml ให้โหลด URL ของคุณในเบราว์เซอร์ก่อนจะยืนยันใช้ เพราะบรรทัด Sitemap ที่ชี้ไปหน้า 404 แย่กว่าการไม่มีบรรทัดนั้นเลย ด้วยเหตุผลว่ามันดูถูกต้องเวลาตรวจสอบเว็บ

การลิสต์ไซต์แมปหลายอันก็ทำได้ บรรทัดละหนึ่งอัน การส่งไซต์แมปใน Search Console แยกต่างหากก็ยังควรทำอยู่ ส่วนคำสั่งใน robots.txt คือช่องทางให้ crawler ที่ไม่เคยเห็นบัญชี Search Console ของคุณหามันเจอ

robots.txt ไม่ใช่ noindex และไม่ใช่ความปลอดภัย

ความเข้าใจผิดสองข้อนี้เป็นต้นเหตุของความเสียหายจาก robots.txt เกือบทั้งหมด

การบล็อก URL ไม่ได้ลบมันออกจาก Google robots.txt ควบคุมการเก็บข้อมูล ถ้าเว็บอื่นลิงก์มาที่ URL ที่ถูกบล็อก Google ก็ยังจัดทำดัชนี URL นั้นได้ คุณจะได้ผลการค้นหาที่มีแค่ที่อยู่เปล่า ๆ พร้อมข้อความว่าไม่มีข้อมูลให้แสดง และยังมีกับดักที่ร้ายกว่านั้น ถ้าหน้าหนึ่งมีแท็ก noindex อยู่แล้วคุณไปบล็อกมันใน robots.txt Google จะเก็บข้อมูลไม่ได้ จึงมองไม่เห็น noindex และหน้านั้นอาจค้างอยู่ในดัชนีไปเรื่อย ๆ ถ้าจะเอาหน้าออก ให้อนุญาตการเก็บข้อมูลแล้วใส่แท็ก meta robots แบบ noindex ในส่วนหัวของหน้า หรือส่ง HTTP header ชื่อ X-Robots-Tag ทั้งนี้ Google เลิกรองรับคำสั่ง noindex ภายใน robots.txt ไปตั้งแต่ปี 2019

การบล็อกเส้นทางไม่ได้ปกป้องมัน robots.txt ของคุณเปิดสาธารณะอยู่แล้วโดยธรรมชาติ การใส่ /private-client-files/ ลงไปเท่ากับบอกผู้เข้าชมทุกคนและสแกนเนอร์ทุกตัวว่าให้ไปดูตรงไหน และการปฏิบัติตามก็เป็นเรื่องสมัครใจ Google ทำตาม แต่บอตที่ไม่หวังดีไม่ทำ อะไรก็ตามที่ต้องการการปกป้องต้องใช้การยืนยันตัวตน การจำกัด IP หรือกฎระดับเซิร์ฟเวอร์ใน .htaccess ไม่ใช่บรรทัดในไฟล์ข้อความที่ประกาศเป้าหมายให้คนอื่นรู้

กฎที่ควรเพิ่ม และกฎที่ควรข้าม

มีสองอย่างที่เพิ่มแล้วมีประโยชน์จริงกับเว็บจำนวนมาก การบล็อกเส้นทางผลการค้นหาภายในจะหยุด crawler ไม่ให้สร้าง URL คุณภาพต่ำได้ไม่รู้จบจากช่องค้นหาในเว็บของคุณ และการบล็อกเส้นทางตะกร้าหรือหน้าชำระเงินบน WooCommerce จะกัน URL ที่มีพารามิเตอร์ session ออกจากการเก็บข้อมูล

Disallow: /?s=
Disallow: /search/

ส่วนพวกนี้ให้ข้ามไป

• Crawl-delay — Google เมินมันทั้งหมด ถ้าเซิร์ฟเวอร์มีปัญหาโหลดจริง ให้ใช้ตัวควบคุมอัตราการเก็บข้อมูลใน Search Console แทน
• การบล็อก /feed/ หรือ /trackback/ — เป็น URL ที่ไม่มีพิษภัย และฟีดก็มีประโยชน์
• รายชื่อบอตยาวเป็นหางว่าว — บอตส่วนใหญ่ที่คนพยายามบล็อกก็ไม่ได้แจ้งตัวตนตามจริงอยู่แล้ว
• การบล็อก /wp-json/ — มันอาจเป็นสิ่งที่ธีมของคุณใช้ในการเรนเดอร์เนื้อหา

สร้างไฟล์นี้ด้วย ตัวสร้าง robots.txt สำหรับ WordPress ซึ่งจะให้เวอร์ชันที่น้อยแต่ถูกต้อง และให้คุณเพิ่มกฎสำหรับการค้นหาและร้านค้าได้โดยไม่ต้องมานั่งแก้ไวยากรณ์เอง

หลังจากแก้เสร็จแล้ว

เปิด https://yoursite.com/robots.txt ตรง ๆ แล้วยืนยันว่าไบต์ที่ถูกเสิร์ฟออกมาคือสิ่งที่คุณคาดไว้ ไม่ใช่สิ่งที่หน้าแก้ไขของปลั๊กอินโชว์ให้ดู จากนั้นรัน live URL inspection ใน Search Console กับหน้าปกติหน้าหนึ่ง แล้วตรวจว่าไม่มีทรัพยากร CSS หรือ JavaScript ตัวไหนถูกรายงานว่าถูกบล็อก Google แคช robots.txt ไว้ราวหนึ่งวัน การแก้ไขจึงไม่มีผลทันที และความผิดพลาดก็เช่นกัน ความหน่วงตรงนี้แหละคือเหตุผลที่ควรตรวจสอบให้ดีตั้งแต่แรก แทนที่จะไปลองบนเว็บจริงแล้วนั่งรอ