Robots.txt คืออะไร? ตั้งค่าอย่างไรไม่ให้เว็บไซต์หายจาก Google

Robots.txt เป็นไฟล์ขนาดเล็กที่มีผลต่อการทำงานของ Search Engine อย่างมาก หากตั้งค่าถูกต้อง ไฟล์นี้ช่วยควบคุมไม่ให้ Crawler เสียเวลาเข้าถึงหน้าหรือทรัพยากรที่ไม่สำคัญ แต่หากตั้งค่าผิด อาจทำให้ Googlebot เข้าถึงบทความ หน้าสินค้า หน้าบริการ หรือไฟล์ที่จำเป็นต่อการแสดงผลของเว็บไซต์ไม่ได้

ปัญหาที่พบบ่อยคือเจ้าของเว็บไซต์ต้องการปิดกั้นเพียงหน้าทดสอบ แต่กลับใช้คำสั่งที่บล็อกทั้งเว็บไซต์ หรือเข้าใจว่า Robots.txt สามารถใช้ลบหน้าออกจาก Google ได้ ทั้งที่หน้าที่ถูกบล็อกยังอาจปรากฏเป็น URL ในผลการค้นหา หาก Google พบ URL จากลิงก์ภายนอกหรือแหล่งข้อมูลอื่น

ดังนั้น ก่อนแก้ไข Robots.txt ควรเข้าใจความแตกต่างระหว่างการ Crawl และการ Index ให้ชัดเจน รวมถึงตรวจสอบทุกกฎก่อนนำไปใช้กับเว็บไซต์จริง

Robots.txt คืออะไร?

Robots.txt คือไฟล์ข้อความที่ใช้บอก Web Crawler ว่า URL หรือไดเรกทอรีใดบนเว็บไซต์สามารถหรือไม่สามารถเข้าถึงได้

ไฟล์นี้ต้องอยู่ที่ Root Directory ของ Host เช่น

https://www.example.com/robots.txt

ไม่ควรวางไว้ในตำแหน่งอื่น เช่น

https://www.example.com/folder/robots.txt

เพราะกฎในไฟล์ดังกล่าวจะไม่ทำหน้าที่เป็น Robots.txt หลักของเว็บไซต์

Google อธิบายว่า Robots.txt ใช้ควบคุม Traffic จาก Crawler เป็นหลัก ไม่ใช่เครื่องมือสำหรับป้องกันหน้าเว็บออกจากผลการค้นหา หากต้องการไม่ให้หน้าแสดงบน Google ควรใช้ noindex หรือป้องกันหน้าด้วยรหัสผ่านตามวัตถุประสงค์ของเนื้อหา

Robots.txt ทำงานอย่างไร?

ก่อนที่ Googlebot จะเข้าไป Crawl หน้าในเว็บไซต์ ระบบจะพยายามเรียกไฟล์ Robots.txt ของ Host นั้นก่อน แล้วตรวจสอบว่ามีกฎอนุญาตหรือปิดกั้น URL ที่กำลังจะเข้าถึงหรือไม่

กระบวนการโดยสรุปคือ

1. Googlebot พบ URL จากลิงก์ Sitemap หรือแหล่งข้อมูลอื่น
2. Googlebot ตรวจไฟล์ Robots.txt
3. ระบบเปรียบเทียบ URL กับกฎที่ตรงกับ User-agent
4. หากอนุญาต Googlebot สามารถส่งคำขอ Crawl หน้าได้
5. หากถูกปิดกั้น Googlebot จะไม่เรียกเนื้อหาของ URL นั้น
6. การ Index จะถูกพิจารณาแยกจากการอนุญาตให้ Crawl

จุดสำคัญคือ การบล็อก Crawl ไม่ได้เท่ากับการสั่งให้ Google ลบ URL ออกจากดัชนี Google ระบุว่า URL ที่ถูกบล็อกด้วย Robots.txt ยังอาจปรากฏในผลการค้นหาได้ แม้ระบบจะไม่สามารถอ่านเนื้อหาภายในหน้าได้

Crawl กับ Index ต่างกันอย่างไร?

ความเข้าใจผิดเกี่ยวกับ Robots.txt ส่วนใหญ่เกิดจากการสับสนระหว่าง Crawl และ Index

Robots.txt ควบคุมที่ขั้นตอน Crawl เป็นหลัก ไม่ได้สั่งควบคุม Index โดยตรง

ตัวอย่างเช่น หากเว็บไซต์อื่นลิงก์มายังหน้าที่ถูก Disallow Google อาจรู้ว่า URL นั้นมีอยู่ แต่ไม่สามารถเข้าไปอ่าน Title, Meta Description หรือเนื้อหาได้ ผลลัพธ์อาจแสดง URL โดยไม่มีคำอธิบายที่สมบูรณ์

ข้อความลักษณะ “No page information is available” มักเกิดขึ้นเมื่อ Google ไม่สามารถ Crawl เนื้อหาของหน้าได้ รวมถึงกรณีที่หน้าถูกบล็อกด้วย Robots.txt

โครงสร้างพื้นฐานของ Robots.txt

ไฟล์ Robots.txt ประกอบด้วยกฎสำคัญ เช่น

• User-agent
• Disallow
• Allow
• Sitemap

ตัวอย่างพื้นฐาน:

User-agent: *
Disallow: /private/
Allow: /

Sitemap: https://www.example.com/sitemap.xml

ความหมายคือ

• ใช้กฎกับ Crawler ทุกตัว
• ไม่อนุญาตให้ Crawl URL ภายใต้ /private/
• อนุญาตให้ Crawl URL อื่น
• ระบุตำแหน่ง XML Sitemap

User-agent คืออะไร?

User-agent ใช้ระบุว่า กลุ่มกฎถัดไปต้องการใช้กับ Crawler ใด

ตัวอย่างใช้กับ Crawler ทุกตัว:

User-agent: *

ตัวอย่างใช้กับ Googlebot:

User-agent: Googlebot

ตัวอย่างใช้กับ Googlebot สำหรับรูปภาพ:

User-agent: Googlebot-Image

หากไม่มีเหตุผลเฉพาะ เว็บไซต์ทั่วไปมักใช้

User-agent: *

เพื่อกำหนดกฎพื้นฐานให้ Crawler ทุกตัว

Googlebot Smartphone และ Googlebot Desktop ใช้ Product Token เดียวกันใน Robots.txt จึงไม่สามารถใช้กฎ Robots.txt เพื่ออนุญาตเฉพาะ Googlebot Smartphone แต่บล็อก Googlebot Desktop หรือกลับกันได้

Disallow คืออะไร?

Disallow ใช้ระบุเส้นทางที่ไม่ต้องการให้ Crawler เข้าถึง

ตัวอย่างบล็อกโฟลเดอร์:

User-agent: *
Disallow: /private/

กฎนี้อาจครอบคลุม URL เช่น

/private/
/private/document/
/private/test-page/

ตัวอย่างบล็อก URL เฉพาะ:

User-agent: *
Disallow: /temporary-page.html

ตัวอย่างไม่บล็อก URL ใดเลย:

User-agent: *
Disallow:

การเว้นค่า Disallow ว่าง หมายถึงไม่มีเส้นทางที่ถูกปิดกั้นภายใต้กลุ่มกฎนั้น

Allow คืออะไร?

Allow ใช้เปิดทางให้ URL บางส่วนสามารถถูก Crawl ได้ แม้อยู่ภายใต้โฟลเดอร์ที่ถูก Disallow

ตัวอย่าง:

User-agent: *
Disallow: /folder/
Allow: /folder/public-page/

กฎนี้สื่อว่าต้องการบล็อกเนื้อหาส่วนใหญ่ภายใต้ /folder/ แต่เปิดให้ Crawler เข้าถึง /folder/public-page/

อย่างไรก็ตาม การใช้กฎซ้อนกันหลายชั้นอาจสร้างความผิดพลาดได้ง่าย เว็บไซต์ขนาดเล็กควรใช้โครงสร้างที่เรียบง่ายเท่าที่จำเป็น

Sitemap ใน Robots.txt คืออะไร?

สามารถระบุตำแหน่ง XML Sitemap ใน Robots.txt ได้ เช่น

Sitemap: https://www.example.com/sitemap_index.xml

หรือมีหลาย Sitemap:

Sitemap: https://www.example.com/post-sitemap.xml
Sitemap: https://www.example.com/page-sitemap.xml
Sitemap: https://www.example.com/product-sitemap.xml

การใส่ Sitemap ช่วยให้ Crawler พบตำแหน่งไฟล์ได้สะดวกขึ้น แต่ไม่ได้รับประกันว่า URL ทุกหน้าภายใน Sitemap จะถูก Crawl, Index หรือจัดอันดับ

Sitemap ควรมีเฉพาะ URL หลักที่เปิดใช้งานได้ ไม่ติด noindex ไม่ Redirect และต้องการให้ปรากฏบน Search Engine

ตัวอย่าง Robots.txt สำหรับเว็บไซต์ทั่วไป

เว็บไซต์บริษัทหรือเว็บไซต์บทความที่ไม่มีระบบซับซ้อน อาจใช้โครงสร้างพื้นฐานดังนี้

User-agent: *
Disallow:

Sitemap: https://www.example.com/sitemap.xml

หมายความว่าเว็บไซต์ไม่ได้ปิดกั้นเส้นทางใด และระบุตำแหน่ง Sitemap ไว้

Google ระบุว่าเว็บไซต์ขนาดเล็กอาจไม่จำเป็นต้องมี Robots.txt หากไม่ได้ต้องการบล็อก URL หรือจัดการ Traffic ของ Crawler เป็นพิเศษ

ตัวอย่าง Robots.txt สำหรับ WordPress

ตัวอย่างที่พบได้บ่อยสำหรับ WordPress:

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

Sitemap: https://www.example.com/sitemap_index.xml

คำอธิบาย:

• ปิดกั้นการ Crawl พื้นที่ผู้ดูแล /wp-admin/
• อนุญาตไฟล์ admin-ajax.php ซึ่งบางระบบอาจใช้ในการทำงานหน้าเว็บไซต์
• ระบุตำแหน่ง Sitemap Index

ไม่ควรคัดลอก Robots.txt จากเว็บไซต์อื่นมาใช้ทันที เพราะ Plugin, Theme, โครงสร้าง URL และฟังก์ชันของแต่ละเว็บไซต์ไม่เหมือนกัน

WordPress สร้าง Robots.txt อย่างไร?

WordPress อาจสร้าง Virtual Robots.txt ให้โดยอัตโนมัติ แม้ไม่มีไฟล์จริงอยู่บน Server

สามารถตรวจได้โดยเปิด:

https://www.example.com/robots.txt

หากเว็บไซต์ใช้ SEO Plugin เช่น Rank Math, Yoast SEO หรือระบบจัดการ Hosting บางประเภท อาจมีหน้าสำหรับแก้ไข Robots.txt โดยไม่ต้องเข้าถึง File Manager

ก่อนสร้างไฟล์จริง ควรตรวจสอบก่อนว่า

• WordPress มี Virtual Robots.txt อยู่หรือไม่
• SEO Plugin กำลังควบคุมไฟล์หรือไม่
• Server มีไฟล์ Robots.txt จริงอยู่แล้วหรือไม่
• CDN หรือระบบ Cache จัดเก็บเวอร์ชันเก่าไว้หรือไม่

หากมีหลายระบบแก้ไขไฟล์เดียวกัน อาจทำให้กฎที่แสดงจริงไม่ตรงกับที่เห็นในหลังบ้าน

Robots.txt สำหรับ WooCommerce ควรบล็อกอะไร?

เว็บไซต์ WooCommerce อาจมีหน้าระบบที่ไม่จำเป็นต้องติดอันดับ เช่น

• ตะกร้าสินค้า
• ชำระเงิน
• บัญชีผู้ใช้
• หน้าค้นหาภายใน
• URL ที่เกิดจากการจัดเรียงบางประเภท

อย่างไรก็ตาม ไม่ควรบล็อกแบบกว้างโดยไม่ตรวจ URL จริง เพราะหน้าสินค้า หมวดหมู่ และทรัพยากรที่จำเป็นอาจได้รับผลกระทบ

ตัวอย่างแนวคิดเบื้องต้น:

User-agent: *
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/
Disallow: /?s=
Disallow: /search/

Sitemap: https://www.example.com/sitemap_index.xml

ก่อนใช้ต้องตรวจ Permalink ของเว็บไซต์จริง เนื่องจาก Slug อาจเป็นภาษาไทยหรือถูกเปลี่ยนจากค่าเริ่มต้น

นอกจากนี้ หน้า Cart, Checkout และ Account มักเหมาะกับการตั้ง noindex ด้วย เพราะ Robots.txt เพียงอย่างเดียวไม่ได้รับประกันว่าจะไม่ปรากฏในผลการค้นหา

Robots.txt สำหรับเว็บไซต์หลายภาษา

เว็บไซต์หลายภาษาอาจมีโครงสร้าง เช่น

/th/
/en/
/jp/

โดยทั่วไปไม่ควรบล็อกโฟลเดอร์ภาษา หากต้องการให้เนื้อหาแต่ละภาษาติดอันดับ

ตัวอย่างที่เสี่ยง:

User-agent: *
Disallow: /en/

กฎนี้อาจทำให้ Googlebot เข้าไปอ่านหน้าเวอร์ชันภาษาอังกฤษไม่ได้

เว็บไซต์หลายภาษาควรใช้

• URL แยกแต่ละภาษา
• Canonical ที่เหมาะสม
• hreflang
• Internal Link ระหว่างภาษา
• Sitemap ที่ครอบคลุม URL ภาษา
• Robots.txt ที่ไม่บล็อกเนื้อหาหลัก

กฎที่อาจทำให้เว็บไซต์หายจาก Google

1. Disallow ทั้งเว็บไซต์

กฎที่อันตรายที่สุดคือ

User-agent: *
Disallow: /

เครื่องหมาย / หมายถึงเส้นทางทั้งหมดภายใต้ Host ทำให้ Crawler ที่ปฏิบัติตามกฎไม่สามารถเข้าถึงทุกหน้าในเว็บไซต์

กฎนี้มักถูกใช้บนเว็บไซต์ Staging หรือเว็บไซต์ระหว่างพัฒนา แต่บางครั้งทีมงานลืมนำออกเมื่อเปิดเว็บไซต์จริง

ผลที่อาจเกิดขึ้น ได้แก่

• Googlebot เข้าไป Crawl หน้าใหม่ไม่ได้
• Google ไม่เห็นการอัปเดตเนื้อหา
• Snippet ในผลค้นหาไม่สมบูรณ์
• หน้าใหม่ไม่ถูกประมวลผล
• หน้าเดิมอาจค่อย ๆ สูญเสียประสิทธิภาพ
• รายงาน Search Console แสดงว่าถูกบล็อกด้วย Robots.txt

หากพบกฎนี้บนเว็บไซต์จริง ควรตรวจสอบและแก้ไขทันที

2. บล็อกโฟลเดอร์เนื้อหาหลัก

ตัวอย่าง:

User-agent: *
Disallow: /blog/

หากบทความทั้งหมดอยู่ภายใต้ /blog/ Googlebot จะเข้าไป Crawl บทความเหล่านั้นไม่ได้

กฎอื่นที่ควรระวัง เช่น

Disallow: /products/
Disallow: /services/
Disallow: /category/
Disallow: /uploads/

การบล็อก /uploads/ อาจทำให้ Googlebot เข้าถึงรูปภาพหรือไฟล์ที่เกี่ยวข้องไม่ได้ โดยเฉพาะเว็บไซต์ที่ต้องการ Traffic จาก Google Images

3. บล็อก CSS และ JavaScript

หาก Googlebot ไม่สามารถโหลด CSS หรือ JavaScript ที่จำเป็น ระบบอาจประมวลผลหน้าไม่เหมือนผู้ใช้จริง

ตัวอย่างที่ควรระวัง:

Disallow: /wp-content/
Disallow: /wp-includes/

กฎแบบกว้างอาจปิดกั้นไฟล์ Theme, Plugin, CSS, JavaScript หรือรูปภาพที่จำเป็น

Google แนะนำให้ทรัพยากรสำคัญที่ใช้แสดงหน้า เช่น CSS และรูปภาพ สามารถเข้าถึงได้ และไม่ถูกบล็อกโดยกฎ Robots.txt

4. คัดลอกกฎจากเว็บไซต์อื่น

Robots.txt ไม่ใช่ Template ที่ใช้ได้เหมือนกันทุกเว็บไซต์

ตัวอย่างเช่น เว็บไซต์หนึ่งอาจมี /search/ เป็นหน้าค้นหาภายใน แต่อีกเว็บไซต์อาจใช้ /search/ เป็นหน้าบริการสำคัญ การคัดลอกกฎโดยไม่ตรวจโครงสร้างจริงอาจปิดกั้นหน้าเงินโดยไม่รู้ตัว

5. ใช้ Wildcard ผิด

Robots.txt รองรับรูปแบบการจับคู่บางประเภท เช่น * และ $

ตัวอย่าง:

Disallow: /*?

อาจใช้ปิดกั้น URL ที่มี Query Parameter แต่มีความเสี่ยงปิดกั้น URL ที่จำเป็นด้วย

ตัวอย่าง:

Disallow: /*.pdf$

ใช้ปิดกั้น URL ที่ลงท้ายด้วย .pdf

ก่อนใช้ Wildcard ควรทดสอบ URL หลายรูปแบบ ทั้งหน้าที่ต้องการบล็อกและหน้าที่ต้องการอนุญาต

Robots.txt ใช้ลบหน้าออกจาก Google ได้ไหม?

ไม่ควรใช้ Robots.txt เป็นวิธีลบหน้าเว็บออกจาก Google

เหตุผลคือ หาก Googlebot ถูกบล็อกไม่ให้ Crawl หน้า ระบบจะไม่เห็นคำสั่ง noindex ที่อยู่ภายในหน้า และ URL อาจยังปรากฏในผลการค้นหาได้จากข้อมูลลิงก์หรือสัญญาณอื่น

Google ระบุชัดเจนว่า Robots.txt ใช้ป้องกันการ Crawl ไม่ใช่ป้องกันหน้าออกจากผลการค้นหา

หากต้องการเอาหน้าออกจาก Google ควรเลือกวิธีให้เหมาะกับกรณี

Noindex คืออะไร?

noindex เป็นคำสั่งที่บอก Search Engine ไม่ให้เก็บหน้าไว้ในดัชนีหรือแสดงหน้าในผลการค้นหา

ตัวอย่างใน <head>:

<meta name="robots" content="noindex">

หรือสำหรับ Googlebot:

<meta name="googlebot" content="noindex">

Google ไม่รองรับการใส่คำสั่ง noindex ภายใน Robots.txt

ตัวอย่างที่ไม่ควรใช้:

User-agent: *
Noindex: /private-page/

กฎนี้ไม่ใช่วิธีที่ Google รองรับสำหรับนำหน้าออกจากดัชนี

ทำไมไม่ควรบล็อกหน้าที่ติด Noindex ด้วย Robots.txt?

เพื่อให้ noindex ทำงาน Googlebot ต้องเข้าไป Crawl หน้าและเห็นคำสั่งดังกล่าว

หากตั้งค่าแบบนี้:

User-agent: *
Disallow: /private-page/

และภายในหน้ามี:

<meta name="robots" content="noindex">

Googlebot อาจไม่สามารถเข้าไปอ่าน noindex เพราะถูก Robots.txt ปิดกั้นก่อน

Google ระบุว่า หากหน้าถูกบล็อกด้วย Robots.txt Crawler จะไม่เห็นคำสั่ง noindex และ URL อาจยังปรากฏในผลการค้นหาได้

แนวทางที่เหมาะสมคือ

1. อนุญาตให้ Googlebot Crawl หน้า
2. ใส่ noindex
3. รอให้ Google Crawl และนำหน้าออกจากดัชนี
4. หลังจากนั้นจึงพิจารณาการควบคุม Crawl หากจำเป็นและเข้าใจผลกระทบ

Robots.txt ต่างจาก Meta Robots อย่างไร?

Robots.txt ต่างจาก Canonical อย่างไร?

Canonical ใช้บอกว่า URL ใดควรเป็นตัวแทนหลักเมื่อมีหน้าซ้ำหรือใกล้เคียงกัน ส่วน Robots.txt ใช้ควบคุมการ Crawl

ตัวอย่าง Canonical:

<link rel="canonical" href="https://www.example.com/main-page/">

ไม่ควรบล็อกหน้าซ้ำด้วย Robots.txt หากต้องการให้ Google เห็น Canonical ภายในหน้า เพราะ Googlebot ต้อง Crawl หน้าเพื่ออ่านสัญญาณนั้น

กรณีหน้า Parameter หรือหน้าสินค้าซ้ำ ควรพิจารณา

• Canonical
• Internal Link
• Sitemap
• Redirect
• Noindex
• Robots.txt

ร่วมกันตามวัตถุประสงค์ ไม่ควรพึ่งเครื่องมือใดเครื่องมือหนึ่งโดยไม่วิเคราะห์

Robots.txt ป้องกันข้อมูลส่วนตัวได้ไหม?

ไม่ได้

Robots.txt เป็นไฟล์สาธารณะ ทุกคนสามารถเปิดดูได้ที่ /robots.txt หากใส่เส้นทางข้อมูลลับลงไป ผู้ไม่หวังดีอาจใช้ไฟล์นี้เป็นรายการบอกว่ามีหน้าใดน่าสนใจอยู่

ไม่ควรใช้ Robots.txt เพื่อปกป้อง

• ข้อมูลลูกค้า
• เอกสารภายใน
• หน้าผู้ดูแลระบบที่ไม่มีระบบยืนยันตัวตน
• ไฟล์สำรองข้อมูล
• รายงานทางการเงิน
• ข้อมูลส่วนบุคคล
• API ที่มีข้อมูลสำคัญ

เนื้อหาลับควรป้องกันด้วย

• Login
• Password
• Authentication
• Authorization
• Firewall
• การตั้งค่า Server
• การจำกัด IP
• การนำไฟล์ออกจาก Public Directory

หากไม่มี Robots.txt จะเกิดอะไรขึ้น?

หากเว็บไซต์ไม่มี Robots.txt และ Server ตอบกลับอย่างเหมาะสม โดยทั่วไป Crawler สามารถ Crawl URL ที่ค้นพบได้ตามปกติ

เว็บไซต์ขนาดเล็กที่ไม่มีหน้าซับซ้อนหรือ URL ที่ต้องควบคุม อาจไม่จำเป็นต้องสร้าง Robots.txt เอง

อย่างไรก็ตาม การมีไฟล์พื้นฐานช่วยให้

• ระบุตำแหน่ง Sitemap
• ควบคุมส่วนที่ไม่สำคัญ
• ตรวจสอบการตั้งค่าได้ง่าย
• ลดความเสี่ยงจาก Virtual Robots.txt ที่ไม่ทราบเนื้อหา

Robots.txt ตอบ Status Code แบบใดจึงถูกต้อง?

ไฟล์ที่เปิดใช้งานปกติควรตอบ HTTP Status 200 OK

สถานะอื่นอาจส่งผลต่างกัน เช่น

กรณี Server Error กับ Robots.txt ควรแก้ไขโดยเร็ว เพราะระบบอาจระมัดระวังและลดหรือหยุดการ Crawl ชั่วคราวเพื่อหลีกเลี่ยงการเข้าถึง URL ที่เจ้าของเว็บไซต์อาจตั้งใจปิดกั้น

หลังอัปโหลดไฟล์ Google แนะนำให้ตรวจว่าไฟล์เข้าถึงได้แบบสาธารณะ และระบบสามารถประมวลผลกฎได้

วิธีตรวจสอบ Robots.txt

1. เปิด URL โดยตรง

เปิด:

https://www.example.com/robots.txt

ตรวจว่า

• เปิดได้
• ไม่มีหน้า Login
• ไม่ Redirect ผิด Host
• ไม่มี HTML แทรก
• เนื้อหาเป็นข้อความธรรมดา
• กฎตรงกับที่ต้องการ
• Sitemap ใช้ URL ถูกต้อง

2. ใช้ Robots.txt Report ใน Search Console

รายงาน Robots.txt ใน Google Search Console ช่วยตรวจสอบ

• Google พบไฟล์ใด
• Crawl ไฟล์ครั้งล่าสุดเมื่อใด
• มี Error หรือ Warning หรือไม่
• Google สามารถประมวลผลไฟล์ได้หรือไม่
• URL ตัวอย่างถูกปิดกั้นหรืออนุญาตหรือไม่

รายงานนี้ยังรองรับการร้องขอให้ Google Crawl ไฟล์ Robots.txt ใหม่ในกรณีเร่งด่วน และใช้ตรวจ URL ว่าถูกกฎใดบล็อกอยู่

3. ใช้ URL Inspection

นำ URL สำคัญไปตรวจใน Search Console เช่น

• หน้าแรก
• หน้าบริการ
• หน้าสินค้า
• บทความหลัก
• หน้าหมวดหมู่
• หน้า Landing Page

ตรวจดูว่า Googlebot สามารถ Crawl หน้าได้หรือไม่ และมีข้อความเกี่ยวกับ Robots.txt หรือเปล่า

URL Inspection ใช้ดูสถานะของ URL และทดสอบ URL จริงได้ หากหน้าถูกบล็อก ควรตรวจหากฎใน Robots.txt ที่เป็นสาเหตุ

4. ทดสอบทั้ง URL ที่ต้องการบล็อกและอนุญาต

อย่าทดสอบเพียง URL ที่ตั้งใจปิดกั้น ควรทดสอบหน้าที่ต้องการให้ติด Google ด้วย เช่น

• หน้าแรก
• หน้าบริการหลัก
• หน้าบทความ
• หน้าสินค้า
• CSS
• JavaScript
• รูปภาพสำคัญ
• Sitemap

โดยเฉพาะเมื่อใช้ Wildcard หรือกฎระดับโฟลเดอร์

วิธีแก้เว็บไซต์ถูกบล็อกด้วย Robots.txt

ขั้นตอนที่ 1: ตรวจไฟล์ปัจจุบัน

เปิด /robots.txt และค้นหากฎ เช่น

User-agent: *
Disallow: /

หรือกฎที่ตรงกับโฟลเดอร์ของหน้าที่มีปัญหา

ขั้นตอนที่ 2: ตรวจระบบที่สร้างไฟล์

ดูว่า Robots.txt ถูกควบคุมจาก

• ไฟล์จริงบน Server
• WordPress
• SEO Plugin
• Hosting
• CDN
• Security Plugin
• Deployment Script

เพื่อป้องกันการแก้ไขผิดตำแหน่งหรือถูกระบบอื่นเขียนทับ

ขั้นตอนที่ 3: ลบหรือแก้กฎที่ปิดกั้น

ตัวอย่างจาก

User-agent: *
Disallow: /

เปลี่ยนเป็น

User-agent: *
Disallow:

Sitemap: https://www.example.com/sitemap.xml

ควรปรับตามโครงสร้างเว็บไซต์จริง ไม่ควรใช้ตัวอย่างโดยไม่ตรวจสอบ

ขั้นตอนที่ 4: ล้าง Cache

หากใช้ Cache, CDN หรือระบบ Proxy ควรล้าง Cache เพื่อให้ Googlebot และผู้ใช้เห็นไฟล์เวอร์ชันใหม่

ขั้นตอนที่ 5: ทดสอบไฟล์

ใช้ Robots.txt Report หรือ URL Inspection ตรวจว่า URL สำคัญได้รับอนุญาตแล้ว

ขั้นตอนที่ 6: ขอ Crawl ใหม่

หลังแก้ไข สามารถขอให้ Google Crawl Robots.txt ใหม่ผ่านรายงานที่เกี่ยวข้อง และใช้ URL Inspection ขอ Indexing สำหรับหน้าสำคัญบางหน้า

ขั้นตอนที่ 7: ติดตามรายงาน Indexing

ตรวจสอบว่า

• สถานะ Blocked by Robots.txt ลดลง
• หน้าเงินกลับมา Crawl ได้
• Google-selected Canonical ถูกต้อง
• Sitemap ไม่มี Error
• Click และ Impression เริ่มฟื้นตัว

การกลับมาของอันดับอาจไม่เกิดขึ้นทันที เพราะ Google ต้อง Crawl ประมวลผล และประเมินหน้าใหม่

Robots.txt สำหรับเว็บไซต์ Staging ควรตั้งอย่างไร?

เว็บไซต์ Staging ไม่ควรพึ่ง Robots.txt เพียงอย่างเดียว เพราะ URL อาจยังถูกค้นพบและปรากฏในผลการค้นหาได้

แนวทางที่ปลอดภัยกว่า ได้แก่

1. ป้องกันด้วย Username และ Password
2. จำกัดการเข้าถึงตาม IP
3. ใช้ Environment ที่ไม่เปิดสาธารณะ
4. ใส่ noindex เป็นชั้นเพิ่มเติมเมื่อ Googlebot ยังเข้าถึงได้
5. ไม่ใส่ Internal Link จากเว็บไซต์จริง
6. ไม่ส่ง Sitemap ของ Staging
7. ตรวจสอบก่อนเปิดเว็บไซต์จริง

เมื่อย้ายจาก Staging ไป Production ต้องตรวจว่า

• ไม่มี Password ค้างอยู่
• ไม่มี noindex
• ไม่มี Disallow: /
• Canonical ชี้โดเมนจริง
• Sitemap ใช้โดเมนจริง
• Analytics และ Search Console ใช้ Property ถูกต้อง

Checklist ก่อนแก้ Robots.txt

ข้อผิดพลาดที่พบบ่อย

ใช้ Robots.txt เพื่อซ่อนหน้าจาก Google

การ Disallow ไม่รับประกันว่า URL จะไม่ปรากฏในผลการค้นหา ควรใช้ noindex หรือการป้องกันด้วยรหัสผ่านตามกรณี

ใส่ Noindex ใน Robots.txt

Google ไม่รองรับคำสั่ง noindex ภายใน Robots.txt ต้องใช้ Meta Robots หรือ HTTP Header แทน

บล็อกหน้าที่มี Noindex

หาก Googlebot เข้าไม่ได้ ระบบจะไม่เห็นคำสั่ง noindex

บล็อกหน้า Canonical

หากหน้าถูกบล็อก Google อาจไม่สามารถอ่าน Canonical และสัญญาณภายในหน้าได้

บล็อก CSS และ JavaScript

อาจทำให้ Google ประมวลผลหน้าไม่เหมือนผู้ใช้จริง

ลืมเอา Disallow ทั้งเว็บออกจาก Staging

เป็นหนึ่งในปัญหาที่อันตรายที่สุดหลังเปิดเว็บไซต์ใหม่

ไม่ตรวจไฟล์หลังเปลี่ยน Plugin

Plugin หรือระบบ Hosting อาจแก้ Robots.txt โดยอัตโนมัติ

เชื่อว่า Robots.txt เป็นระบบรักษาความปลอดภัย

ไฟล์นี้เป็นข้อมูลสาธารณะและไม่สามารถป้องกันการเข้าถึงของผู้ใช้หรือ Bot ที่ไม่ปฏิบัติตามกฎได้

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

ทุกเว็บไซต์ต้องมี Robots.txt หรือไม่?

ไม่จำเป็น เว็บไซต์ขนาดเล็กที่ไม่มี URL ต้องควบคุมสามารถทำงานได้แม้ไม่มีไฟล์ แต่การมีไฟล์พื้นฐานและระบุ Sitemap อาจช่วยให้จัดการได้เป็นระบบขึ้น

Robots.txt ช่วยให้ติดอันดับดีขึ้นหรือไม่?

ไม่ได้เพิ่มอันดับโดยตรง แต่การตั้งค่าที่เหมาะสมอาจช่วยให้ Crawler ไม่เสียเวลากับ URL ที่ไม่สำคัญ โดยเฉพาะเว็บไซต์ขนาดใหญ่ สิ่งสำคัญกว่าคืออย่าบล็อกหน้าที่ต้องการให้ติดอันดับ

บล็อกหน้าใน Robots.txt แล้วหน้าจะหายจาก Google เมื่อใด?

ไม่มีการรับประกันว่าจะหาย เพราะ Robots.txt ไม่ใช่คำสั่งลบหน้าออกจากดัชนี ควรใช้ noindex, Redirect, 404, 410 หรือระบบป้องกันการเข้าถึงตามกรณี

ควรใส่ Sitemap ใน Robots.txt หรือไม่?

ควรใส่ได้ เพราะช่วยบอกตำแหน่ง Sitemap แก่ Crawler แต่ควรส่ง Sitemap ผ่าน Google Search Console ด้วย

ใช้ Disallow กับหน้า Login ได้ไหม?

ใช้ได้เพื่อควบคุม Crawl แต่หน้า Login ควรมีระบบรักษาความปลอดภัยจริงด้วย Robots.txt ไม่สามารถป้องกันผู้ใช้เข้าถึง URL ได้

Robots.txt บล็อก Googlebot อย่างเดียวได้ไหม?

ได้โดยใช้ User-agent: Googlebot แต่ควรมีเหตุผลชัดเจน เพราะอาจส่งผลต่อการค้นหาของ Google ขณะที่ Crawler อื่นยังเข้าถึงได้

Robots.txt มีผลกับ Subdomain หรือไม่?

ไฟล์มีผลเฉพาะ Host ที่วางอยู่ เช่น Robots.txt ของ www.example.com ไม่ได้ควบคุม shop.example.com โดยอัตโนมัติ แต่ละ Subdomain ควรมีไฟล์ของตนเองหากต้องการกำหนดกฎ

Robots.txt มีผลกับ HTTP และ HTTPS เหมือนกันหรือไม่?

แต่ละ Protocol และ Host ถือเป็นคนละขอบเขต ควรตั้ง Redirect ให้เว็บไซต์ใช้เวอร์ชันหลัก และตรวจว่า Robots.txt ของเวอร์ชันที่ใช้งานจริงเปิดได้ถูกต้อง

แก้ Robots.txt แล้ว Google จะเห็นทันทีหรือไม่?

ไม่จำเป็น Google ต้อง Crawl ไฟล์ใหม่ก่อน สามารถตรวจเวลาที่ Google Crawl ล่าสุดและร้องขอ Crawl ใหม่ผ่านรายงาน Robots.txt ใน Search Console ได้

สรุป

Robots.txt คือไฟล์สำหรับควบคุมว่า Search Engine Crawler สามารถเข้าถึง URL หรือส่วนใดของเว็บไซต์ได้บ้าง จุดประสงค์หลักคือการจัดการ Traffic จาก Crawler และลดการ Crawl หน้าหรือทรัพยากรที่ไม่สำคัญ ไม่ใช่เครื่องมือสำหรับลบหน้าออกจาก Google

หลักสำคัญที่ควรจำ ได้แก่

• Robots.txt ควบคุมการ Crawl ไม่ได้ควบคุมการ Index โดยตรง
• URL ที่ถูก Disallow ยังอาจปรากฏในผลการค้นหา
• หากต้องการเอาหน้าออกจาก Google ควรใช้ noindex หรือวิธีอื่นที่เหมาะสม
• Googlebot ต้อง Crawl หน้าได้จึงจะเห็น noindex และ Canonical
• ไม่ควรบล็อก CSS, JavaScript และรูปภาพที่จำเป็น
• ห้ามปล่อย Disallow: / ไว้บนเว็บไซต์จริง
• Robots.txt ไม่ใช่ระบบรักษาความปลอดภัย
• ต้องทดสอบ URL สำคัญทุกครั้งหลังแก้ไข
• ควรตรวจรายงาน Robots.txt และ URL Inspection ใน Search Console

ก่อนแก้ Robots.txt ควรสำรองไฟล์เดิม ตรวจโครงสร้าง URL และประเมินผลกระทบต่อหน้าเงินทั้งหมด หากเว็บไซต์มีหลายภาษา ร้านค้าออนไลน์ ระบบตัวกรอง หรือ URL จำนวนมาก ควรตรวจร่วมกับ Technical SEO, Canonical, Noindex, Sitemap และ Internal Link เพื่อไม่ให้กฎหนึ่งแก้ปัญหาแต่สร้างปัญหาใหม่ในส่วนอื่น

สำหรับเว็บไซต์ที่ต้องการตรวจสอบ Robots.txt, Sitemap, Indexing, Canonical และปัญหา Technical SEO ควรเชื่อมบทความนี้ไปยังหน้า “Technical SEO คืออะไร”, “SEO Audit คืออะไร”, “Google Index คืออะไร”, “Sitemap คืออะไร” และหน้าบริการรับทำ SEO ของ Moon Knight Creator