DeepSeek Harness (dsh) chạy các agent thực sự làm được việc, và rất ít công việc SEO phù hợp với nó hơn pipeline URL chưa được lập chỉ mục: đọc danh sách, kiểm tra từng URL, phân loại, chờ phê duyệt, gửi, xác minh. Mỗi giai đoạn là một lệnh hoặc một file — chính xác là vùng mà agent harness làm chủ.
Hai câu hỏi quyết định cách bạn thiết lập. Muốn một đợt chạy một lần có thể script hóa và đưa vào cron? Chạy headless. Muốn nhìn nó làm việc, trả lời câu hỏi của nó, và phê duyệt từng đợt trong cửa sổ trò chuyện? Dùng web UI. Hướng dẫn này trình bày cả hai đường, và pipeline bên dưới giống nhau cho cả hai. Nếu bạn muốn giải thích sâu về ý nghĩa của «Discovered – currently not indexed» và «Crawled – currently not indexed» cùng cách đọc chúng, chúng tôi đề cập trong phiên bản Hermes Agent của quy trình này; ở đây chúng tôi tập trung vào việc thực thi bằng dsh.
Chọn đường của bạn
Headless một lần | Web UI + lịch trình | |
|---|---|---|
Phù hợp nhất với | Đợt chạy có script, cron, chạy kiểu CI, thử nghiệm | Sàng lọc tương tác, thiết lập đầu tiên, học cách agent ra quyết định |
Bắt đầu |
|
|
Phê duyệt | Danh sách đã duyệt trước trong file; agent hỏi qua công cụ hỏi khi quy tắc cần con người | Hỏi trực tiếp trong trò chuyện, phê duyệt từng đợt |
Lên lịch | cron (hoặc công cụ lên lịch của dsh nếu profile tải plugin Schedule) | Giống nhau, nhưng bạn thấy từng lần chạy |
Đầu ra | File báo cáo trong thư mục dự án | File báo cáo cộng bản ghi trò chuyện |
Headless cho các đợt, web UI cho lần chạy đầu — pipeline bên dưới giống nhau.
Cả hai đường chia sẻ một quy tắc: bước ghi (gửi đến Google) luôn đứng sau cổng phê duyệt của con người. Trong chế độ headless, điều đó nghĩa là bạn rà soát file agent tạo ra trước khi để nó chạy lệnh gửi; trong chế độ web, bạn phê duyệt trong trò chuyện.
Bạn sẽ nhận được
Thư mục dự án indexing/ chứa: kho URL, danh sách đã phân loại (to-submit.txt, skip.txt, needs-fix.txt), hàng đợi gửi đã phê duyệt, và nhật ký chạy. Mỗi lần chạy dsh tạo một báo cáo ngắn: đã gửi bao nhiêu, đã bỏ qua bao nhiêu và vì sao, và điều gì thay đổi từ lần trước. Thiết lập đầu mất 60–90 phút (chủ yếu là thông tin xác thực phía Google); chạy hàng tuần mất 15 phút.
Trước khi bắt đầu
- dsh đã cài và cấu hình. Cập nhật lên bản hiện tại bằng
npx @deepseek-ai/dsh@latest webnếu cần. Khóa API và cài đặt của bạn nằm trong~/.dsh/(profiles, sessions,settings.yaml), vàdsh webchạy được hoặc một tác vụ headless thành công xác nhận cài đặt. - Property GSC bạn sở hữu, dạng
sc-domain:example.com. - Thông tin xác thực đọc: OAuth client cho Search Console API (client ID + secret) cho script đọc.
- Thông tin xác thực ghi: dự án Google Cloud với Indexing API đã bật, file JSON service account, và email service account được thêm làm Owner trong GSC → Cài đặt → Người dùng và quyền. 403 khi gửi nghĩa là bước này thất bại.
- Hai thư mục script GSC trong workspace: skill đọc (sitemaps, search analytics, kiểm tra URL) và skill lập chỉ mục (
index_submit.py). Python 3 vớipip install google-auth google-api-python-client. - Thư mục dự án, ví dụ
~/gsc-indexing-projectvớidata/,scripts/,logs/.
Thiết lập phía Google giống hệt cho mọi agent, và tài liệu của skill gsc-indexing hướng dẫn bạn qua các bước Cloud Console: bật Indexing API, tạo service account, tải file khóa, thêm làm Owner.
Đường A: chạy headless một lần
Chế độ headless là dsh --profile headless "tác vụ": một tác vụ, một câu trả lời, thoát. Đặt toàn bộ pipeline trong một lệnh, hoặc chia qua vài lần chạy trong lúc gỡ lỗi.
Lần chạy đầu, từ thư mục dự án:
dsh --profile headless "Chạy giai đoạn 1 của pipeline lập chỉ mục GSC. Liệt kê sitemap cho sc-domain:example.com bằng script gsc_query.py, lấy từng URL kèm lastmod, bỏ trùng, và ghi data/url-inventory.csv. Báo cáo tổng số."Đầu ra tốt trông như thế nào: CSV thật với tổng khớp báo cáo sitemap trong GSC, và không có cột bịa ra. Kiểm tra chất lượng: mở file và xem ngẫu nhiên năm URL. Nếu agent báo lỗi xác thực, chạy lại luồng OAuth của GSC và thử lại; script đọc cần token mới.
Giai đoạn 2:
dsh --profile headless "Kiểm tra URL trong data/url-inventory.csv qua URL Inspection API và chia thành data/to-submit.txt, data/skip.txt (kèm lý do một dòng), và data/needs-fix.txt. Chỉ bao gồm URL có lastmod trong 90 ngày qua."Agent chạy script kiểm tra theo nhóm (API giới hạn tốc độ theo property; kiểm tra hạn mức hiện tại trong Google Cloud Console). Kiểm tra sự hợp lý của việc chia: danh sách bỏ qua phải bị chi phối bởi trang noindex, canonical-away, và bản trùng. Nếu trang có hàng nghìn URL cho danh sách needs-fix rỗng, hãy mở rộng cửa sổ đầu vào.
Giai đoạn 3 là cổng phê duyệt, và nó không bao giờ chạy không giám sát:
dsh --profile headless "Đọc data/needs-fix.txt và data/skip.txt. Lập hàng đợi sửa-và-gửi thành bảng: URL, nguyên nhân nghi ngờ (không liên kết nội bộ, trùng, canonical, noindex, mỏng, soft 404), bằng chứng, hành động đề xuất, mức rủi ro. Đừng gửi gì cả."Bạn rà soát bảng trong báo cáo nó in ra, chỉnh data/to-submit.txt chỉ còn các URL bạn phê duyệt, rồi chạy giai đoạn 4:
dsh --profile headless "Gửi URL trong data/approved-urls.txt qua script lập chỉ mục (index_submit.py submit --urls-file data/approved-urls.txt). Chạy check-auth trước. Ghi từng kết quả vào logs/submissions.log."Đầu ra mong đợi: một dòng kết quả thông báo mỗi URL, không có 403. Đường khôi phục: 403 nghĩa là service account không phải Owner property; 429 nghĩa là bạn chạm hạn mức 200-mỗi-ngày hoặc 600-mỗi-phút; chia danh sách qua nhiều ngày. Nếu lần chạy chết giữa chừng, dsh --profile headless --resume <session> tiếp tục nó.
Đường B: web UI cộng lịch trình hàng tuần
dsh web mở UI trình duyệt tại 127.0.0.1:3080. Trò chuyện qua các giai đoạn giống nhau, nhưng tương tác: agent yêu cầu bạn xác nhận danh sách đã phân loại trước khi lập hàng đợi, và một lần nữa trước khi chạy lệnh gửi. Luồng phê duyệt trực tiếp đó là lý do chính chọn đường này khi thiết lập đầu: bạn thấy agent sắp làm gì với property Google của bạn trước khi nó làm.
Khi pipeline chạy được, thêm nhịp điệu. Plugin Schedule của dsh đăng ký schedule_create, nó chạy lại tác vụ theo bộ đếm thời gian trong phiên đang mở:
schedule_create: every 7 days, run "Inspect data/url-inventory.csv, classify new and changed URLs, and draft the submission queue. Do not submit."
Nếu profile của bạn không tải plugin Schedule, kết quả tương đương là một dòng cron bọc lệnh headless:
0 9 * * 1 cd ~/gsc-indexing-project && dsh --profile headless "Chạy kiểm tra lập chỉ mục GSC hàng tuần và lập hàng đợi gửi." >> logs/weekly.log 2>&1
Lịch trình chạy ba trạm đầu; việc gửi vẫn đứng sau cổng con người.
Giữ bước gửi ngoài lịch trình. Kiểm tra hàng tuần, phân loại, và lập hàng đợi có thể chạy không giám sát; việc gửi chờ con người.
Quy tắc sàng lọc agent áp dụng
Việc phân loại và hàng đợi dựa vào một bảng nhỏ, và bạn nên đặt nó trong thư mục dự án để mọi lần chạy dùng cùng quy tắc:
Nguyên nhân | Cách sửa | Gửi sau khi sửa? |
|---|---|---|
Không có liên kết nội bộ đến trang | Thêm liên kết ngữ cảnh từ trang đã lập chỉ mục | Có |
Trang hoàn toàn mới | Không có gì để sửa; gửi một lần, chờ 1–2 tuần | Có, một lần |
Bị chặn robots.txt | Mở chặn đường dẫn | Có |
Nội dung trùng hoặc mỏng | Viết lại, gộp, hoặc xóa | Chỉ sau thay đổi thực sự |
Canonical trỏ nơi khác | Sửa nếu sai; nếu cố ý, loại bỏ URL | Chỉ khi đã sửa |
noindex lúc thu thập | Gỡ noindex | Có, sau khi gỡ |
soft 404, archive, facet không giá trị | Sửa hoặc xóa; bỏ qua vĩnh viễn | Không |
Phân tích sâu hơn về hai trạng thái, gồm vì sao Google thu thập một số trang mà không thu thập số khác, nằm trong hướng dẫn Hermes Agent. Nguyên nhân giống nhau dù harness nào chạy pipeline.
Xác minh, rồi chờ
Sau mỗi đợt, xác nhận thông báo bằng status: nó chỉ chứng minh Google có metadata cho nó, không phải trang đã được lập chỉ mục. Ba đến bảy ngày sau, kiểm tra lại các URL đã gửi và so sánh trạng thái. Mô hình lành mạnh là discovered → crawled → indexed trong một đến hai tuần. Dữ liệu GSC trễ vài ngày, và Google thu thập lại theo lịch riêng của nó, nên URL vẫn kẹt ở «Crawled – currently not indexed» sau 10–14 ngày với sửa lỗi thực sự phía sau là phán quyết về chất lượng nội dung, không phải vấn đề gửi. File nhật ký là nơi thấy rõ điều này: ngày, URL, loại thông báo, và trạng thái kiểm tra ở lần chạy sau. Đó cũng là thước đo: danh sách chưa lập chỉ mục phải thu hẹp theo thời gian, không phải số thông báo tăng lên.
Giới hạn thẳng thắn
- Indexing API được tài liệu hóa chính thức cho trang
JobPostingvàBroadcastEvent. Gửi trang thường qua nó là thực hành phổ biến, nhưng Google không đưa ra đảm bảo và không hứa hỗ trợ cho mọi loại trang. - Không có API công khai cho nút «Request indexing» trong Search Console. Indexing API là kênh script hóa gần nhất, không phải bản sao của nút.
- Tự động hóa không tạo ra mức ưu tiên. Nếu trang vẫn chưa lập chỉ mục sau khi bạn sửa và gửi, bước tiếp theo là công việc nội dung, không phải thêm một lần chạy theo lịch.
FAQ
Tôi có thể chạy chỉ chế độ headless, không dùng web UI chút nào? Có. dsh --profile headless "tác vụ" chạy một tác vụ và thoát; thông tin xác thực vẫn ở ~/.dsh/, và script đọc hoạt động như nhau. Dùng web UI một lần để xác minh pipeline từ đầu đến cuối, rồi script hóa.
Lần chạy chết giữa đợt. Tôi có mất việc không? Không. Tiếp tục bằng dsh --profile headless --resume <session>, và chạy lại script gửi; nó loại bỏ URL trùng, nên gửi lại URL đã thông báo trong cùng đợt không gây hại.
Tôi quản lý nhiều property GSC. Tôi có phải lặp lại mọi thứ cho từng trang web? Script nhận đối số --site sc-domain:..., nên một workspace có thể chứa kho và nhật ký của nhiều property. Giữ một file hàng đợi đã duyệt và một lệnh gửi cho mỗi property, để lỗi hạn mức trên một trang web không bao giờ chặn trang khác.
Tác giả: Camille Rhodes, Kiến trúc sư hơn 300 quy trình nội dung AI tại Auspia. Camille viết về tự động hóa nội dung, hệ thống xuất bản, và các quy trình biến agent AI thành hoạt động tăng trưởng đáng tin cậy.
