DeepSeek Harness (dsh) รัน agent ที่ทำงานจริงได้ และงาน SEO ไม่กี่อย่างเหมาะกับมันเท่าไปป์ไลน์ URL ที่ไม่ได้ทำดัชนี: อ่านรายการ ตรวจสอบแต่ละ URL จำแนก รอการอนุมัติ ส่ง ตรวจสอบ ทุกขั้นตอนคือคำสั่งหรือไฟล์ — นั่นคือพื้นที่ที่ harness agent ถนัดพอดี
สองคำถามกำหนดวิธีตั้งค่าของคุณ ต้องการชุดครั้งเดียวที่เขียนสคริปต์และใส่ cron ได้ไหม? รันแบบ headless ต้องการดูมันทำงาน ตอบคำถาม และอนุมัติแต่ละชุดในหน้าต่างแชตไหม? ใช้ Web UI คู่มือนี้แสดงทั้งสองเส้นทาง และไปป์ไลน์ใต้พื้นผิวเหมือนกันทั้งคู่ ถ้าต้องการคำอธิบายเจาะลึกว่า «Discovered – currently not indexed» และ «Crawled – currently not indexed» หมายความว่าอะไรและอ่านอย่างไร เราครอบคลุมในเวอร์ชัน Hermes Agent ของเวิร์กโฟลว์นี้; ที่นี่เราโฟกัสที่การใช้งานผ่าน dsh
เลือกเส้นทางของคุณ
Headless ครั้งเดียว | Web UI + ตารางเวลา | |
|---|---|---|
เหมาะกับ | ชุดสคริปต์, cron, การรันแบบ CI, การทดสอบ | จัดลำดับแบบโต้ตอบ, การตั้งค่าครั้งแรก, เรียนรู้สิ่งที่ agent ตัดสินใจ |
เริ่ม |
|
|
การอนุมัติ | รายการที่อนุมัติล่วงหน้าในไฟล์; agent ถามผ่านเครื่องมือคำถามเมื่อกฎต้องการมนุษย์ | ถามในแชต อนุมัติทีละชุด |
ตารางเวลา | cron (หรือเครื่องมือตั้งเวลาของ dsh ถ้าโปรไฟล์โหลด Schedule plugin) | เหมือนกัน แต่เห็นทุกการรัน |
ผลลัพธ์ | ไฟล์รายงานในโฟลเดอร์โปรเจกต์ | ไฟล์รายงานบวกถอดเสียงแชต |
Headless สำหรับชุด Web UI สำหรับการรันแรก — ไปป์ไลน์ใต้พื้นผิวเดียวกัน
ทั้งสองเส้นทางมีกฎข้อเดียวร่วมกัน: ขั้นตอนการเขียน (ส่งไปยัง Google) อยู่หลังประตูอนุมัติของมนุษย์ ในโหมด headless หมายความว่าคุณตรวจสอบไฟล์ที่ agent สร้างก่อนปล่อยให้มันรันคำสั่งส่ง; ในโหมด web คุณอนุมัติในแชต
คุณจะได้อะไร
โฟลเดอร์โปรเจกต์ indexing/ ที่มี: สินค้าคงคลัง URL, รายการที่จำแนกแล้ว (to-submit.txt, skip.txt, needs-fix.txt), คิวส่งที่อนุมัติ และล็อกการรัน ทุกการรัน dsh สร้างรายงานสั้น ๆ: ส่งไปกี่อัน ข้ามกี่อันและเพราะอะไร และอะไรเปลี่ยนจากครั้งก่อน การตั้งค่าครั้งแรกใช้เวลา 60–90 นาที (ส่วนใหญ่เป็นข้อมูลรับรองฝั่ง Google); การรันรายสัปดาห์ใช้ 15 นาที
ก่อนเริ่ม
- ติดตั้งและกำหนดค่า dsh อัปเดตเป็นเวอร์ชันปัจจุบันด้วย
npx @deepseek-ai/dsh@latest webถ้าจำเป็น คีย์ API และการตั้งค่าของคุณอยู่ใน~/.dsh/(profiles, sessions,settings.yaml) และdsh webที่ทำงานได้หรือภารกิจ headless ที่สำเร็จยืนยันการติดตั้ง - พร็อพเพอร์ตี้ GSC ที่คุณเป็นเจ้าของ ในรูปแบบ
sc-domain:example.com - ข้อมูลรับรองการอ่าน: OAuth client สำหรับ Search Console API (client ID + secret) สำหรับสคริปต์อ่าน
- ข้อมูลรับรองการเขียน: โปรเจกต์ Google Cloud ที่เปิด Indexing API, คีย์ JSON ของ service account และอีเมล service account ที่เพิ่มเป็น Owner ภายใต้ GSC → การตั้งค่า → ผู้ใช้และการอนุญาต 403 ตอนส่งหมายถึงขั้นตอนนี้ล้มเหลว
- โฟลเดอร์สคริปต์ GSC สองโฟลเดอร์ ใน workspace: skill การอ่าน (sitemaps, search analytics, การตรวจสอบ URL) และ skill การทำดัชนี (
index_submit.py) Python 3 พร้อมpip install google-auth google-api-python-client - โฟลเดอร์โปรเจกต์ เช่น
~/gsc-indexing-projectที่มีdata/,scripts/,logs/
การตั้งค่าฝั่ง Google เหมือนกันสำหรับทุก agent และเอกสารของ gsc-indexing skill พาคุณผ่านขั้นตอน Cloud Console: เปิด Indexing API, สร้าง service account, ดาวน์โหลดคีย์, เพิ่มเป็น Owner
เส้นทาง ก: รัน headless ครั้งเดียว
โหมด headless คือ dsh --profile headless "งาน": งานหนึ่งคำตอบหนึ่งออกจากระบบ ใส่ไปป์ไลน์ทั้งหมดในพรอมต์เดียว หรือแบ่งข้ามการรันสองสามครั้งระหว่างแก้บั๊ก
รันแรก จากโฟลเดอร์โปรเจกต์:
dsh --profile headless "รันสเตจ 1 ของไปป์ไลน์การทำดัชนี GSC. ลิสต์ sitemap สำหรับ sc-domain:example.com ด้วยสคริปต์ gsc_query.py ดึงทุก URL พร้อม lastmod ตัดรายการซ้ำ แล้วเขียน data/url-inventory.csv รายงานจำนวนรวม"เอาต์พุตที่ดีคือ: CSV จริงที่จำนวนตรงกับรายงาน sitemap ใน GSC และไม่มีคอลัมน์ที่แต่งขึ้น ตรวจสอบคุณภาพ: เปิดไฟล์แล้วสุ่มตรวจห้า URL ถ้า agent รายงานข้อผิดพลาดการยืนยันตัวตน รันโฟลว์ OAuth ของ GSC ใหม่แล้วลองอีกครั้ง; สคริปต์อ่านต้องใช้ token ใหม่
สเตจ 2:
dsh --profile headless "ตรวจสอบ URL ใน data/url-inventory.csv ผ่าน URL Inspection API แล้วแบ่งเป็น data/to-submit.txt, data/skip.txt (พร้อมเหตุผลหนึ่งบรรทัด), และ data/needs-fix.txt ใส่เฉพาะ URL ที่มี lastmod ใน 90 วันที่ผ่านมา"agent รันสคริปต์ตรวจสอบเป็นชุด (API จำกัดอัตราต่อพร็อพเพอร์ตี้; ตรวจโควตาปัจจุบันของคุณใน Google Cloud Console) ตรวจความสมเหตุสมผลของการแบ่ง: รายการข้ามควรถูกครอบงำด้วย noindex, canonical-away และหน้าซ้ำ ถ้าเว็บที่มี URL นับพันให้รายการ needs-fix ว่าง ให้ขยายหน้าต่างอินพุต
สเตจ 3 คือประตูอนุมัติ และมันไม่เคยรันโดยไม่มีคนดูแล:
dsh --profile headless "อ่าน data/needs-fix.txt และ data/skip.txt ร่างคิวแก้ไขและส่งเป็นตาราง: URL, สาเหตุที่สงสัย (ไม่มีลิงก์ภายใน, ซ้ำ, canonical, noindex, บางบาง, soft 404), หลักฐาน, การกระทำที่เสนอ, ระดับความเสี่ยง อย่าส่งอะไร"คุณตรวจตารางในรายงานที่มันพิมพ์ แก้ data/to-submit.txt ให้มีเฉพาะ URL ที่คุณอนุมัติ แล้วรันสเตจ 4:
dsh --profile headless "ส่ง URL ใน data/approved-urls.txt ผ่านสคริปต์การทำดัชนี (index_submit.py submit --urls-file data/approved-urls.txt) รัน check-auth ก่อน บันทึกทุกผลลัพธ์ลง logs/submissions.log"เอาต์พุตที่คาดหวัง: หนึ่งบรรทัดผลลัพธ์การแจ้งเตือนต่อ URL ไม่มี 403 เส้นทางการกู้คืน: 403 หมายถึง service account ไม่ใช่ Owner ของพร็อพเพอร์ตี้; 429 หมายถึงชนโควตา 200 ต่อวันหรือ 600 ต่อนาที — แบ่งรายการข้ามวัน ถ้าการรันตายกลางคัน dsh --profile headless --resume <session> กลับมาเดินต่อ
เส้นทาง ข: Web UI บวกตารางรายสัปดาห์
dsh web เปิด UI เบราว์เซอร์ที่ 127.0.0.1:3080 แชตผ่านขั้นตอนเดียวกันแต่แบบโต้ตอบ: agent ขอให้คุณยืนยันรายการที่จำแนกก่อนร่างคิว และอีกครั้งก่อนรันคำสั่งส่ง โฟลว์การอนุมัติสดนี้คือเหตุผลหลักที่เลือกเส้นทางนี้ในการตั้งค่าครั้งแรก: คุณเห็นสิ่งที่ agent กำลังจะทำกับพร็อพเพอร์ตี้ Google ของคุณก่อนที่มันจะทำ
เมื่อไปป์ไลน์ใช้งานได้ เพิ่มจังหวะ Schedule plugin ของ dsh ลงทะเบียน schedule_create ซึ่งรันงานซ้ำด้วยตัวจับเวลาภายในเซสชันสด:
schedule_create: every 7 days, run "Inspect data/url-inventory.csv, classify new and changed URLs, and draft the submission queue. Do not submit."
ถ้าโปรไฟล์ของคุณไม่โหลด Schedule plugin ผลลัพธ์เดียวกันคือบรรทัด cron ที่ครอบคำสั่ง headless:
0 9 * * 1 cd ~/gsc-indexing-project && dsh --profile headless "รันการตรวจสอบการทำดัชนี GSC รายสัปดาห์และร่างคิวส่ง" >> logs/weekly.log 2>&1
ตารางเวลารันสามสถานีแรก; การส่งยังอยู่หลังประตูมนุษย์
อย่าใส่ขั้นตอนส่งลงในตารางเวลา การตรวจสอบรายสัปดาห์ การจำแนก และการร่างคิวรันได้โดยไม่มีคนดูแล; การส่งรอมนุษย์
กฎการจัดลำดับที่ agent ใช้
การจำแนกและคิวขึ้นอยู่กับตารางเล็ก ๆ และคุณควรวางไว้ในโฟลเดอร์โปรเจกต์เพื่อให้ทุกการรันใช้กฎเดียวกัน:
สาเหตุ | การแก้ไข | ส่งหลังแก้หรือไม่? |
|---|---|---|
ไม่มีลิงก์ภายในชี้มาที่หน้า | เพิ่มลิงก์เชิงบริบทจากหน้าที่ถูกทำดัชนี | ใช่ |
หน้าใหม่เอี่ยม | ไม่มีอะไรต้องแก้; ส่งครั้งเดียว รอ 1–2 สัปดาห์ | ใช่ ครั้งเดียว |
ถูกบล็อกด้วย robots.txt | ปลดบล็อกพาธ | ใช่ |
เนื้อหาซ้ำหรือบางบาง | เขียนใหม่ รวม หรือลบ | เฉพาะหลังเปลี่ยนจริง |
canonical ชี้ที่อื่น | แก้ถ้าผิด; ถ้าตั้งใจ ปล่อย URL ทิ้ง | เฉพาะเมื่อแก้แล้ว |
noindex ตอนครอว์ล | เอา noindex ออก | ใช่ หลังเอาออก |
soft 404, archive, facet ไม่มีคุณค่า | แก้หรือลบ; ข้ามถาวร | ไม่ |
การอ่านเจาะลึกสองสถานะ รวมถึงทำไม Google ครอว์ลบางหน้าแต่ไม่ครอว์ลบางหน้า อยู่ในคู่มือ Hermes Agent สาเหตุเหมือนกันไม่ว่า harness ตัวไหนรันไปป์ไลน์
ตรวจสอบ แล้วรอ
หลังทุกชุด ยืนยันการแจ้งเตือนด้วย status: นั่นพิสูจน์แค่ว่า Google มี metadata สำหรับมัน ไม่ใช่ว่าหน้าถูกทำดัชนี สามถึงเจ็ดวันต่อมา ตรวจสอบ URL ที่ส่งใหม่และเปรียบเทียบสถานะ รูปแบบที่ดีคือ discovered → crawled → indexed ภายในหนึ่งถึงสองสัปดาห์ ข้อมูล GSC ล่าช้าสองสามวัน และ Google ครอว์ลใหม่ตามตารางของมัน ดังนั้น URL ที่ยังติดที่ «Crawled – currently not indexed» หลัง 10–14 วันโดยมีการแก้จริงอยู่ข้างหลังคือคำตัดสินคุณภาพเนื้อหา ไม่ใช่ปัญหาการส่ง ไฟล์ล็อกคือที่ที่สิ่งนี้เห็นชัด: วันที่, URL, ประเภทการแจ้งเตือน, และสถานะการตรวจสอบในการรันถัดไป นั่นคือการวัดด้วย: รายการที่ไม่ได้ทำดัชนีควรหดลงเมื่อเวลาผ่านไป ไม่ใช่จำนวนการแจ้งเตือนที่เพิ่มขึ้น
ข้อจำกัดที่ตรงไปตรงมา
- Indexing API มีเอกสารทางการสำหรับหน้า
JobPostingและBroadcastEventการส่งหน้าทั่วไปผ่านมันเป็นแนวทางปฏิบัติทั่วไป แต่ Google ไม่ให้การรับประกันและไม่มีคำมั่นสัญญาการสนับสนุนสำหรับทุกประเภทหน้า - ไม่มี API สาธารณะสำหรับปุ่ม «Request indexing» ของ Search Console Indexing API คือช่องทางเขียนสคริปต์ที่ใกล้ที่สุด ไม่ใช่สำเนาของปุ่ม
- ออโตเมชันไม่สร้างลำดับความสำคัญ ถ้าหน้าไม่ถูกทำดัชนีหลังคุณแก้และส่งแล้ว ขั้นตอนถัดไปคืองานเนื้อหา ไม่ใช่การรันตามตารางอีกครั้ง
คำถามที่พบบ่อย
รันเฉพาะโหมด headless โดยไม่ใช้ Web UI เลยได้ไหม? ได้ dsh --profile headless "งาน" รันหนึ่งงานแล้วจบ; ข้อมูลรับรองยังอยู่ใน ~/.dsh/ และสคริปต์อ่านทำงานเหมือนเดิม ใช้ Web UI ครั้งเดียวเพื่อตรวจสอบไปป์ไลน์แบบครบวงจร แล้วเขียนสคริปต์
การรันตายกลางชุด ฉันเสียงานไหม? ไม่ ดำเนินต่อด้วย dsh --profile headless --resume <session> แล้วรันสคริปต์ส่งใหม่; มันตัดรายการซ้ำ ดังนั้นการส่ง URL ที่แจ้งไปแล้วในชุดเดียวกันซ้ำไม่เป็นอันตราย
ฉันจัดการพร็อพเพอร์ตี้ GSC หลายตัว ต้องทำซ้ำทุกอย่างต่อเว็บไหม? สคริปต์รับอาร์กิวเมนต์ --site sc-domain:... ดังนั้น workspace เดียวถือสินค้าคงคลังและล็อกของหลายพร็อพเพอร์ตี้ได้ เก็บไฟล์คิวที่อนุมัติหนึ่งไฟล์และคำสั่งส่งหนึ่งคำสั่งต่อพร็อพเพอร์ตี้ เพื่อให้ข้อผิดพลาดโควตาบนเว็บหนึ่งไม่บล็อกเว็บอื่น
ผู้เขียน: Camille Rhodes สถาปนิกเวิร์กโฟลว์เนื้อหา AI มากกว่า 300 รายการที่ Auspia เขียนเกี่ยวกับระบบอัตโนมัติเนื้อหา ระบบเผยแพร่ และเวิร์กโฟลว์ที่เปลี่ยน agent AI ให้เป็นการดำเนินการเติบโตที่น่าเชื่อถือ
