«Discovered – currently not indexed» และ «Crawled – currently not indexed» คือสองแถวที่พบบ่อยที่สุดในรายงานการสร้างดัชนีหน้าของ Search Console และเป็นสองแถวที่ถูกเข้าใจผิดมากที่สุดด้วย มันดูเหมือนความล้มเหลวทางเทคนิค แต่จริง ๆ แล้วมันคือการตัดสินใจเรื่องลำดับความสำคัญและคุณภาพที่ Google ทำกับหน้าของคุณ การส่งซ้ำแล้วซ้ำเล่าไม่เปลี่ยนผลลัพธ์ การแก้ที่ต้นเหตุต่างหากที่ได้ผล
คู่มือนี้คือลูปเต็มรูปแบบที่คุณยกให้ Hermes Agent ได้: ดึงรายการ URL ตรวจสอบแต่ละหน้า หาสาเหตุจริง อนุมัติคิวการแก้ไข และส่งเฉพาะหน้าที่สมควรถูกทำดัชนีผ่าน Google Indexing API เมื่อจบ คุณจะได้ไปป์ไลน์รายสัปดาห์ที่ทำซ้ำได้แทนที่จะเป็นการคลิกปุ่มครั้งเดียว
คุณจะได้อะไรเมื่อจบ
- สินค้าคงคลังที่จำแนกแล้ว: URL ไหนติดอยู่ที่ discovered ไหนที่ crawled-but-not-indexed และไหนที่ไม่ควรส่งตั้งแต่แรก
- รายการส่งที่อนุมัติแล้วไปยัง Indexing API พร้อมรายการข้ามที่มีเหตุผล
- รอบการตรวจสอบที่แสดงว่าการส่งของคุณขยับเข็มจริงหรือไม่
สิ่งที่ต้องมี: ติดตั้ง Hermes Agent และให้มันทำงานได้ (hermes chat เปิดเซสชัน; ดูขั้นตอนติดตั้งล่าสุดได้ที่เอกสารทางการ hermes-agent.nousresearch.com/docs) มีสิทธิ์ owner บนพร็อพเพอร์ตี้ Search Console และชุดข้อมูลรับรอง Google สองชุด (ชุดหนึ่งอ่าน GSC อีกชุดสำหรับ Indexing API) วางแผน 60–90 นาทีสำหรับการตั้งค่าครั้งแรก แล้วประมาณ 15 นาทีต่อการรันรายสัปดาห์ «เสร็จ» หมายความว่า URL ที่คุณส่งแสดงความเคลื่อนไหวสถานะจริงใน Inspection API ภายในสองสัปดาห์ หรือคุณมีหลักฐานชัดเจนว่าทำไมถึงไม่ขยับ
อ่านสองสถานะนี้ให้ถูก
Google ไม่ได้ติดอยู่บนเว็บไซต์ของคุณ มันตัดสินใจแล้ว และสถานะบอกคุณว่าเป็นการตัดสินใจแบบไหน
สถานะ | ความหมายจริง | สาเหตุทั่วไป | เมื่อไหร่ควรส่ง |
|---|---|---|---|
Discovered – currently not indexed | Google รู้ว่า URL มีอยู่ (จาก sitemap หรือจากลิงก์) แต่ยังไม่ได้ครอว์ล | ลำดับความสำคัญครอว์ลต่ำ ลิงก์ภายในอ่อนหรือไม่มี แรงกดงบประมาณครอว์ลบนเว็บใหญ่ เว็บใหม่ รองรับ JS ช้าหรือหนัก sitemap เปลี่ยนบ่อย | หลังจากปรับปรุงสัญญาณลำดับความสำคัญ (ส่วนใหญ่คือลิงก์ภายใน) แล้วส่งครั้งเดียว |
Crawled – currently not indexed | Google ดึง URL มาแล้วแต่เลือกไม่เพิ่มลงดัชนี | เนื้อหาซ้ำหรือเกือบซ้ำ เนื้อหาบางบาง canonical ชี้ไป URL อื่น มี noindex ตอนครอว์ล soft 404 คุณค่าที่รับรู้ต่ำ | เฉพาะเมื่อคุณเปลี่ยนอะไรจริง: เนื้อหา canonical หรือ noindex |
Indexed | อยู่ในดัชนีแล้ว | — | ไม่ต้องส่ง |
Excluded | ถูกครอว์ลและกีดกันโดยเจตนา (noindex canonical เลือกเวอร์ชันซ้ำ ถูกบล็อก) | — | ไม่ต้องส่ง; ตรวจว่าการกีดกันตั้งใจหรือไม่ |
กฎในหนึ่งประโยค: ส่งเฉพาะ URL ที่คุณเปลี่ยนจริงหรือสมควรได้รับการมองครั้งที่สอง Indexing API คือช่องทางการแจ้งเตือน ไม่ใช่ตัวเขียนทับอันดับการจัดอันดับ การส่งหน้าที่บางบางผ่านมัน 10 ครั้งให้ผลการตัดสินเดิม 10 ครั้ง
ทำไมต้องให้ agent ทำ
ปุ่ม «Request indexing» ของ GSC ไม่มี API สาธารณะ ไม่มีวิธีอย่างเป็นทางการที่จะกดปุ่มผ่านสคริปต์ ออโตเมชันที่ใกล้เคียงที่สุดคือ Google Indexing API ซึ่งรับการแจ้งเตือน URL โดยตรง agent คุ้มค่ากับตำแหน่งนี้ด้วยสามเหตุผล:
- ลูปเป็นกลไกและยาวนาน: inventory → inspect → classify → fix → submit → verify มันวนซ้ำทุกสัปดาห์
- ต้องมีร่องรอยการตรวจสอบ: คุณต้องการไฟล์ที่บอกว่า URL ไหนถูกส่ง เมื่อไหร่ และเพราะอะไร
- ต้องมีประตูอนุมัติ: ส่วนที่เขียนไปยัง Google ควรถูกตรวจสอบโดยมนุษย์ Hermes สร้างขึ้นรอบการแยกนี้โดยเฉพาะ ด้วย skills โฟลเดอร์โปรเจกต์ และกฎการอนุมัติ
ก่อนเริ่ม: สิ่งที่ต้องเตรียม
- ติดตั้ง Hermes Agent ยืนยันด้วย
hermes chatก่อนไปต่อ - พร็อพเพอร์ตี้ GSC ที่คุณเป็นเจ้าของ ในรูปแบบ
sc-domain:example.com(ไม่ใช่ URL เต็ม) - สิทธิ์อ่าน: OAuth client ของ Google Cloud สำหรับ Search Console API (client ID + secret) สคริปต์ของ GSC skill ใช้สิ่งนี้เพื่อลิสต์ sitemap รัน search analytics และตรวจสอบ URL
- สิทธิ์เขียน: โปรเจกต์ Google Cloud ที่เปิดใช้งาน Indexing API และคีย์ JSON ของ service account เพิ่มอีเมล service account เป็น Owner ภายใต้ GSC → การตั้งค่า → ผู้ใช้และการอนุญาต หากการส่งคืน 403 — นี่คือขั้นตอนที่พลาดไป
- Python 3 พร้อม
pip install google-auth google-api-python-client - โฟลเดอร์โปรเจกต์ เช่น
/hermes-seo-projectที่มีcontext/,data/,qa/และapproval-rules.mdที่ระบุว่าขั้นตอนการส่งต้องมีการเซ็นอนุมัติจากมนุษย์เสมอ
ขั้นตอนที่ 1: สร้างสินค้าคงคลัง URL
คัดลอก GSC skill สองตัวลงในไดเรกทอรี skills ของ Hermes (~/.hermes/skills): skill การอ่าน (sitemaps, search analytics, การตรวจสอบ URL) และ skill การทำดัชนี (สคริปต์ส่ง) Hermes ยังโหลดผ่าน skill_view ได้ถ้า harness จัดหมวดหมู่ไว้แล้ว
จากนั้นถาม Hermes ในเซสชันแชตจากโฟลเดอร์โปรเจกต์:
รายการ sitemap ทั้งหมดสำหรับ sc-domain:example.com ดึงทุก URL พร้อมวันที่ lastmod แล้วเขียนผลลัพธ์ไปที่ data/url-inventory.csv ระบุ sitemap ใดที่ดึงไม่สำเร็จ
Hermes รันคำสั่ง sitemap ผ่านเครื่องมือเทอร์มินัลและเขียน CSV เอาต์พุตที่ดีหน้าตาเป็นอย่างไร: CSV ที่ไม่มีรายการซ้ำพร้อม URL, lastmod และ sitemap ต้นทาง ตรวจสอบคุณภาพ: สุ่มตรวจห้าแถวแล้วเทียบจำนวนรวมกับรายงาน sitemap ใน GSC ถ้ารายการว่างหรือการยืนยันตัวตนล้มเหลว รันโฟลว์ยืนยันตัวตน GSC ใหม่; สคริปต์อ่านต้องใช้ OAuth token ใหม่
ขั้นตอนที่ 2: ตรวจสอบและจำแนก
ตอนนี้ agent ตรวจสอบสินค้าคงคลังเป็นชุดผ่าน URL Inspection API ซึ่งคืนสถานะการครอบคลุมปัจจุบันของแต่ละหน้า ขอขั้นตอนถัดไป:
ตรวจสอบทุก URL ใน data/url-inventory.csv แบ่งเป็นสามไฟล์: data/to-submit.txt (ไม่ได้ทำดัชนี สมควรขอ), data/skip.txt (พร้อมเหตุผลหนึ่งบรรทัดต่อ URL), และ data/needs-fix.txt (ไม่ได้ทำดัชนีและติดขัดด้วยสิ่งที่เราเปลี่ยนได้)
Inspection API จำกัดอัตราต่อพร็อพเพอร์ตี้ (ตรวจโควตาปัจจุบันของคุณใน Google Cloud Console; เป็นพันคำขอต่อวันแต่ไม่จำกัด) สำหรับเว็บขนาดใหญ่ ให้จำกัดรอบนี้เฉพาะ URL ที่มีวันที่ lastmod ใหม่ที่สุด — หน้าที่คุณเปลี่ยนจริงในไตรมาสนี้ ตรวจสอบคุณภาพ: สุ่มตัวอย่างรายการข้าม ส่วนใหญ่ควรเป็น noindex, canonical ชี้ที่อื่น และรายการซ้ำ ไม่ใช่หน้าที่คุณใส่ใจ หาก agent ให้รายการ needs-fix ว่างบนเว็บที่มี URL นับพัน แสดงว่าขั้นตอนสินค้าคงคลังน่าจะพลาดหน้าไป ขยายขอบเขตอินพุต
ขั้นตอนที่ 3: จัดลำดับก่อนส่ง
นี่คือขั้นตอนที่คนข้าม จับคู่ URL ที่ติดอยู่แต่ละอันกับสาเหตุและการแก้ไข ตามลำดับนี้:
สาเหตุ | การแก้ไข | ส่งหลังแก้ไขหรือไม่? |
|---|---|---|
ไม่มีลิงก์ภายในชี้มาที่หน้า | เพิ่มลิงก์เชิงบริบทจากหน้าที่เกี่ยวข้องและถูกทำดัชนี | ใช่ |
เว็บหรือหน้าใหม่เอี่ยม | ไม่มีอะไรต้องแก้; ส่งครั้งเดียวแล้วรอ 1–2 สัปดาห์ | ใช่ ครั้งเดียว |
ถูกบล็อกด้วย robots.txt | ปลดบล็อกพาธนั้น | ใช่ |
ถูกครอว์ลแต่ซ้ำหรือบางบาง | เขียนใหม่ รวม หรือลบหน้า | เฉพาะหลังเปลี่ยนเนื้อหาจริง |
canonical ชี้ไป URL อื่น | แก้ canonical ถ้าผิด; ถ้าตั้งใจ ให้หยุดส่ง URL นี้ | เฉพาะเมื่อแก้แล้ว |
มี noindex ตอนครอว์ล | เอา noindex ออกแล้วให้ Google ครอว์ลใหม่ | ใช่ หลังเอาออก |
soft 404 หรือ pagination/archive ไม่มีคุณค่า | แก้หน้าหรือลบทิ้ง | ไม่ — ข้ามถาวร |
ขอให้ Hermes ร่างคิวการแก้ไขเป็นตาราง: URL, สาเหตุที่สงสัย, หลักฐาน (ผลการตรวจสอบหรือการตรวจเนื้อหา), การกระทำที่เสนอ, ระดับความเสี่ยง อนุมัติแต่ละแถวในแชต approval-rules.md ของคุณควรทำให้ข้อนี้เป็นข้อบังคับ: agent เตรียม คุณอนุมัติ และไม่มีอะไรเกินความเสี่ยงต่ำถูกส่งโดยไม่มีการเซ็น
ประตูอนุมัติแยกการเตรียมงานของ agent ออกจากขั้นตอนการเขียน
การแก้ไขเองเป็นงาน SEO ปกติ: เขียนเนื้อหาใหม่ ทำความสะอาด canonical ลิงก์ภายใน ไปป์ไลน์นี้ครอบคลุมครึ่งการส่ง; บทความ audit และ refresh ในซีรีส์ Hermes ครอบคลุมครึ่งการแก้ไข
รายการส่งคือจุดตัดของ «แก้ไขได้» และ «สมควรทำดัชนี»
ขั้นตอนที่ 4: ส่งผ่าน Indexing API
เมื่อคิวได้รับการอนุมัติ ใส่ URL ใน data/approved-urls.txt แล้วให้ Hermes รัน indexing skill:
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py check-auth
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py submit --urls-file data/approved-urls.txtประเภทการแจ้งเตือนเริ่มต้นคือ URL_UPDATED ซึ่งเป็นสิ่งที่คุณต้องการสำหรับหน้าใหม่หรือหน้าที่เปลี่ยน ตัวเลขสามตัวที่ต้องจำ: โควตาเริ่มต้นคือ200 URL ต่อวันและ 600 คำขอต่อนาที; และ 403 หมายความว่า service account ไม่ใช่ Owner ของพร็อพเพอร์ตี้ ถ้ารายการที่อนุมัติเกิน 200 ให้แบ่งข้ามวัน; Hermes กำหนดเวลาชุดที่เหลือได้
ห้ามส่งหน้าที่ถูกทำดัชนีแล้วเด็ดขาด และห้ามส่งรายการข้าม การแจ้งเตือนที่สูญเปล่าแค่เผาโควตาและสร้างเสียงรบกวน
ขั้นตอนที่ 5: ตรวจสอบ แล้วรอ
ทันทีหลังส่ง status บอกคุณแค่ว่า Google มี metadata สำหรับการแจ้งเตือนของคุณหรือไม่ ไม่ใช่หน้าถูกทำดัชนีแล้ว การตรวจสอบจริงมาหลังจากนั้นหลายวัน
ถาม Hermes 3–7 วันหลังชุด:
ตรวจสอบ URL ใน data/approved-urls.txt อีกครั้งและรายงานการเปลี่ยนแปลงสถานะเทียบกับการรันครั้งล่าสุด
ความเคลื่อนไหวที่ดีคือ discovered → crawled → indexed หน้าตาแบบนี้ในสองสามสัปดาห์: รายการที่ไม่ได้ทำดัชนีหดลง และการแก้ไขที่คุณทำจริง (ลิงก์ภายในใหม่ เนื้อหาที่เขียนใหม่) ปรากฏในดัชนี จำไว้ว่าข้อมูล GSC ล่าช้าสองสามวัน และ Google ครอว์ลใหม่ตามตารางของมันเอง URL ที่ค้าง «Crawled – currently not indexed» 10–14 วันหลังการแก้ไขจริงคือสัญญาณคุณภาพ ไม่ใช่ปัญหาการส่ง โยนกลับไปทำงานเนื้อหา
ดูแลลูปให้เดินต่อ
เปลี่ยนไปป์ไลน์เป็นกิจวัตรรายสัปดาห์: URL ใหม่และที่เปลี่ยนตั้งแต่รันล่าสุด → ตรวจสอบ → จำแนก → จัดลำดับ → อนุมัติ → ส่ง → บันทึก Hermes รันส่วนที่อ่านอย่างเดียว (inventory, inspection, classification) โดยไม่มีคนดูแลตามตารางและนำเสนอคิวให้คุณทุกวันจันทร์ เก็บขั้นตอนส่งไว้หลังประตูอนุมัติของคุณ และเก็บล็อกต่อเนื่องใน qa/indexing-log.md: วันที่ส่ง, URL, ประเภทการแจ้งเตือน, ผลลัพธ์ ล็อกหกเดือนคือหนทางเดียวที่ซื่อสัตย์ในการวัดว่าไปป์ไลน์ทำงาน
ข้อจำกัดที่ตรงไปตรงมา
- Google จัดทำเอกสาร Indexing API สำหรับหน้าที่มี structured data
JobPostingหรือBroadcastEventการใช้กับหน้าทั่วไปเป็นแนวทางปฏิบัติ SEO ที่แพร่หลาย แต่ Google ไม่รับประกันการทำดัชนีหรือการสนับสนุนสำหรับทุกประเภทหน้า - ไม่มี API สาธารณะสำหรับปุ่ม «Request indexing» Indexing API คือออโตเมชันที่ใกล้เคียงที่สุด ไม่ใช่ปุ่มเดียวกัน
- การส่งไม่ได้สร้างลำดับความสำคัญ ถ้าหน้ายังไม่ถูกทำดัชนีหลังจากคุณแก้ ส่ง และรอแล้ว คำตอบถัดไปคือคุณภาพเนื้อหา ไม่ใช่การแจ้งเตือนอีกครั้ง
คำถามที่พบบ่อย
Indexing API ใช้กับหน้าทั่วไปได้ไหม? มันรับ URL ใดก็ตามที่คุณส่งไป เอกสารทางการของ Google จำกัดไว้ที่หน้า JobPosting และ BroadcastEvent ดังนั้นถือว่าการส่งหน้าทั่วไปเป็น best-effort: มีประโยชน์ พบได้ทั่วไป และไม่มีการรับประกัน
ทำไม URL ของฉันยังค้าง «Discovered – currently not indexed» หลังส่ง? สถานะนั้นปกติหมายถึงลำดับความสำคัญครอว์ล ไม่ใช่ความล้มเหลว ตรวจลิงก์ภายในที่ชี้มาที่หน้า ว่า robots.txt บล็อกพาธหรือไม่ และหน้าพึ่งพา JavaScript มากแค่ไหน แล้วรอ: บนเว็บใหม่ discovery ถึง crawl อาจใช้เวลาหนึ่งถึงสองสัปดาห์
200 URL ต่อวันพอไหม? สำหรับเว็บส่วนใหญ่พอ เพราะคุณควรส่งเฉพาะ URL ที่เปลี่ยนจริง ถ้าคุณมีมากกว่านั้นเป็นประจำ ให้จัดลำดับตามคุณค่าทางธุรกิจและขอเพิ่มโควตาใน Google Cloud Console
Indexing API ทำให้หน้าติดอันดับเร็วขึ้นไหม? ไม่ มันแจ้ง Google ว่า URL เปลี่ยนแล้ว การตัดสินใจจัดอันดับแยกต่างหาก และระบบของ Google เป็นผู้ตัดสิน ไม่ใช่ปริมาณการแจ้งเตือนของคุณ
ต่างจากการคลิก «Request indexing» ใน Search Console อย่างไร? เจตนาเดียวกัน กลไกต่างกัน ปุ่มเป็น UI ล้วนไม่มี API สาธารณะ; Indexing API คือช่องทางที่เขียนสคริปต์ได้ ไม่มีอันไหนเขียนทับการตัดสินของ Google ว่าหน้าควรอยู่ในดัชนีหรือไม่
ผู้เขียน: Julian Mercer ผู้ปฏิบัติงาน Technical SEO 14 ปีที่ Auspia เขียนเกี่ยวกับ crawlability, indexing, schema และพื้นฐานทางเทคนิคที่ทำให้ทั้ง Google และระบบ AI อ่านเว็บไซต์ได้อย่างถูกต้อง
