SpeedyIndex: lập chỉ mục Google và Yandex, trả theo kết quả

SpeedyIndex đẩy URL vào hàng đợi lập chỉ mục của Google và Yandex, tính phí theo kết quả: token chỉ bị trừ khi URL thực sự vào chỉ mục, không phải mỗi lần bạn đưa link vào tác vụ. Bản tiếng Việt mở từ trang chủ SpeedyIndex tiếng Việt. Trên landing đó chưa có các trang công cụ riêng, nên drip-feed, checker và affiliate trong bài lấy từ sitemap bản tiếng Anh. Pay-per-Result đang chạy; chế độ trả theo lần gửi tạm ngưng. Bing chỉ có công cụ kiểm tra, không có trình lập chỉ mục.

Hóa đơn đếm gì, không đếm gì

Một URL đã vào chỉ mục tốn 100 token. Máy tìm kiếm quyết định có lưu tài liệu hay không. SpeedyIndex gửi địa chỉ, kiểm tra lại sau đó, rồi trừ token ở dòng thật sự nằm trong chỉ mục. URL đủ điều kiện mà vẫn đứng ngoài thì token được hoàn. 404, 403, robots chặn, noindex hay vòng chuyển hướng không phải lần trượt đủ điều kiện: trang đó không thể crawl để lưu. Đây không phải lời hứa đưa mọi địa chỉ lên kết quả. Google và Yandex giữ quyền lưu trữ.

Pay-per-Submit — trừ token theo lần gửi, bất kể đã vào chỉ mục hay chưa — hiện không mở. Người mới lập kế hoạch thì lập với Pay-per-Result. Crawler xuất hiện như Googlebot Smartphone. Bạn không cần xác minh Search Console hay Yandex Webmaster. URL trên domain người khác — bài guest post, comment, crowd link — vẫn đưa vào tác vụ được. Việc đó không thay Search Console, cũng không thay Webmaster. Nó lấp chỗ trống: trên site nhà xuất bản mà bạn không xác minh, bạn không bấm được nút yêu cầu lập chỉ mục.

Gói dùng thử là 200 token. Bài này không nêu tỉ giá token ra tiền; đơn vị tính trong sản phẩm là token, không phải một mức đô-la bị bịa cho từng URL. Khi báo giá nội bộ, hãy nói bằng token và giữ khách khỏi câu “mọi chỗ đặt link chắc chắn lên Google”.

Hóa đơn tách ba trạng thái mà nhóm hay gộp thành một chữ. Đã lập chỉ mục: trừ 100 token, máy tìm kiếm đã lưu. Chưa lập chỉ mục nhưng đủ điều kiện: hoàn token, quy trình đã chạy, việc lưu không xảy ra. Chưa lập chỉ mục vì không truy cập được: không hoàn tự động, nhà xuất bản hoặc kỹ thuật phải trả một trang sống. Không tách được ba dòng này thì bạn đang cãi nhầm chỗ.

Thu thập không phải lưu trữ

Trang tổng quan của Google về thu thập và lập chỉ mục tách ba bước: tìm thấy, crawl, lưu. Sitemap, liên kết nội bộ hay tín hiệu từ bên ngoài có thể làm URL được phát hiện. Crawl lấy tài liệu. Lưu trữ quyết định tài liệu có ở lại chỉ mục hay không. SpeedyIndex chủ yếu nằm ở khúc giữa: gửi lại URL rồi kiểm tra sau xem việc lưu đã xảy ra chưa. Nó không ép Google giữ một trang mỏng, trùng, hay đã canonical sang chỗ khác.

Vì thế không có bảo đảm lập chỉ mục 100 phần trăm. Ai viết điều đó lên hóa đơn agency là hứa thứ mà công cụ lẫn tài liệu máy tìm kiếm đều không bán. Điều có thể hứa: một quy trình lần được, một lần kiểm tra lại có ngày, và hoàn token khi lần trượt đủ điều kiện. Điều không thể hứa: URL lọc với vài từ sẽ được lưu như một bài biên tập.

Yandex có lịch riêng. Ngày kiểm tra lại là ngày 15, không phải ngày 7. Tác vụ Google và tác vụ Yandex là hai việc. Cần cả hai máy thì lập hai đồng hồ, đừng lấy một tuần trung bình. “Chưa thấy trên Yandex” vào ngày 8 của tác vụ Google không phải lỗi. Đó là đồng hồ kia.

URL được liên kết ở đâu đó thì có thể được phát hiện. URL Google lưu thì mới được lập chỉ mục. Ở giữa còn robots, canonical, soft-404 và trùng lặp. Trả theo kết quả mua cú đẩy và lần kiểm, không mua phán quyết.

Standard và Drip-Feed

Hai chế độ chia tải. Standard hợp danh sách ngắn: bạn đưa URL, quy trình chạy một mạch, lần kiểm Google tính bảy ngày từ lượt đó. Drip-Feed là chế độ Google của Pay-per-Result khi danh sách không nên đổ hết lên ngưỡng crawl của domain đích trong một buổi sáng. API dùng drip_feed và drip_feed_days; khoảng ngày từ 2 đến 30, và số URL phải lớn hơn hoặc bằng số ngày. Trang drip-feed indexing mô tả đúng lịch này.

Đồng hồ bảy ngày của Google bắt đầu sau lô hàng ngày cuối, không phải lúc tạo tác vụ. Ai mở drip 14 ngày vào thứ Hai rồi thứ Hai tuần sau đã đòi báo cáo hoàn token là đặt sai kim. Việc chia lô vẫn chạy. Báo cáo Google gộp chỉ bắt đầu khi lô cuối đã ra. Ghi vào bảng ngày “lô cuối cộng bảy” trước khi ai đó nhắn “hoàn token đâu”.

Standard với hàng chục nghìn URL comment không phải lịch, mà là một nhát. Drip-Feed với tám bài guest post là chờ không cần thiết. Chọn chế độ theo độ dài danh sách và ngân sách crawl của domain đích, không theo lời hứa nhỏ giọt sẽ kéo thứ hạng. Drip-Feed phân phối lần gửi. Thứ hạng vẫn thuộc máy tìm kiếm. Ai bán drip như đòn ranking là bán dịch vụ khác với thứ sản phẩm làm.

Tác vụ Yandex đứng cạnh lịch Google này. Drip-Feed trong dữ kiện sản phẩm là đường Google Pay-per-Result. Đừng trộn lần kiểm Yandex ngày 15 vào tranh luận drip Google. Hai máy, hai báo cáo, hai cửa sổ hoàn.

Kiểm trước, gửi sau

Trước khi token vào tác vụ, hiện trạng phải nằm trên bảng. Công cụ kiểm tra chỉ mục Google đánh dấu từng URL đã có trên Google hay chưa. Công cụ kiểm tra chỉ mục Yandex làm điều tương tự cho Yandex. Dòng đã nằm trong chỉ mục không cần đi qua Pay-per-Result nếu bạn không muốn đẩy lại. Dòng chết thuộc về nhà xuất bản, không thuộc tác vụ lập chỉ mục. Một lần kiểm tốn ít cãi hơn một hóa đơn cho URL đã có sẵn hoặc chưa bao giờ mở được.

Bing chỉ là kênh kiểm. Công cụ kiểm tra chỉ mục Bing trả lời có hoặc không. SpeedyIndex không có trình lập chỉ mục Bing; trang chủ tiếng Anh ghi Bing indexing tạm ngưng. “Có” trên Bing không phải “có” trên Google. Lấp lỗ Bing bằng drip Google là lấp nhầm lỗ. Ba cột trên bảng — Google, Yandex, Bing — tránh cái trung bình “đã lập chỉ mục 70 phần trăm” chẳng mô tả máy nào.

Công cụ kiểm không cần property trong webmaster tools. Đó là lý do chúng hợp guest post và URL đối thủ. Chúng không thay báo cáo kiểm URL trên domain bạn sở hữu. Chúng trả lời câu “chuỗi ký tự chính xác này đã nằm trong chỉ mục chưa?” trước khi bạn chấp nhận rủi ro 100 token mỗi dòng trúng. Scheme, host, path và dấu gạch cuối phải trùng với tác vụ sau này. Bản sao gắn UTM là URL khác.

Kiểm và gửi là hai việc. Gửi URL bị chặn biến hoàn token thành cuộc cãi. Kiểm trước thì chỉ gửi ứng viên còn cơ hội được lưu. Bộ lọc kiểm trước trong sản phẩm giúp việc này, nhưng không thay kỷ luật dọn bảng từ trước.

Hoàn token chỉ khi lần trượt đủ điều kiện

Quy tắc thật hẹp hơn vài câu quảng cáo. Token trở lại khi URL đã được xử lý, đủ điều kiện crawl, mà lần kiểm lại vẫn chưa thấy trong chỉ mục. URL không truy cập được — 404, 403, robots, noindex, vòng chuyển hướng — nằm ngoài hoàn tự động. Coi chỗ đặt link chết như “lỗi lập chỉ mục của dịch vụ” là cãi với nhà cung cấp thay vì với nhà xuất bản.

Google kiểm lại ngày 7. Yandex kiểm lại ngày 15. Với drip-feed phía Google: lô hàng ngày cuối cộng bảy ngày. Một lần kiểm độc lập vào ngày 6 là dòng có ngày, không phải hóa đơn. Kết quả site: cá nhân và báo cáo tác vụ có thể lệch một ngày; token lấy báo cáo làm chuẩn.

Đọc cột báo cáo trước khi mở ticket. Đã lập chỉ mục: trừ 100 token. Chưa lập chỉ mục và đủ điều kiện: hoàn 100 token. Chưa lập chỉ mục vì URL sống không truy cập được: không hoàn. Rồi kiểm một mẫu bằng cùng công cụ như trước tác vụ, cùng ngày với báo cáo. Hai mốc ngày, một cuộc nói.

“Chúng tôi hoàn token cho URL Google vào ngày 7 nếu địa chỉ đủ điều kiện để crawl mà vẫn chưa vào chỉ mục. 404, 403, robots, noindex hoặc vòng chuyển hướng thì không hoàn. Với drip-feed, cửa sổ bảy ngày theo lô cuối. Công cụ kiểm tra độc lập là một dòng có ngày, không phải hóa đơn thứ hai. Chúng tôi không bán lời hứa đưa vào chỉ mục một trăm phần trăm.”

— đội ngũ SpeedyIndex

Ranh giới này giữ cả hai phía. Dịch vụ không bán chỉ mục phép. Khách không mua bảo hiểm cho trang chết. Hoàn token là dòng đối soát cho trường hợp “quy trình đã chạy, việc lưu không xảy ra”, không phải bảo hiểm 404.

Bộ lọc kiểm trước, mặc định tắt

Tùy chọn lọc trước loại 404, 410, 451, robots/noindex, media và URL đã nằm trong chỉ mục. Mặc định tắt. Bật lên thì danh sách ngắn lại trước khi token và cuộc nói hoàn xuất hiện. Bỏ qua rồi gửi kèm 404 thì đừng đòi hoàn: trang không thể lưu.

Bộ lọc không thay nhật ký trạng thái của bạn. Một lần lấy header có đi theo chuyển hướng trên mẫu sẽ thấy status, location, đôi khi cả x-robots-tag. Canonical trỏ về kho tag có thể trả 200 mà vẫn không bao giờ được lưu như tài liệu riêng. Đó là ticket nội dung hoặc canonical, không phải lỗi tính tiền. URL media mà bộ lọc sẽ loại ít khi thuộc tác vụ lập chỉ mục trang chữ.

Bật lọc khi danh sách đến từ nhiều tay: chủ nhà, file xuất, kho linkbuilding cũ. Chỉ tắt khi bạn đã tự xác từng dòng — và dù vậy vẫn phải lấy mẫu. Bộ lọc là rây, không phải giấy phép đổ bảng chưa kiểm.

Chương trình liên kết trên trang affiliate là chuyện khác: 15 phần trăm suốt đời trên tiền nạp của người được giới thiệu, người đó gắn vĩnh viễn. Rút tiền mặt từ 20 đô-la qua PayPal hoặc USDT, theo trang tiếng Anh. Gói token có thể trả từ số dư giới thiệu, không cần vòng xuất ra ngoài. Ngưỡng 20 đô-la là ngưỡng rút tiền, không phải một câu bịa “đổi token không cần tối thiểu”. Trang công khai không nêu nhãn nút trong dashboard; bài này không bịa thêm.

Mười lăm phần trăm bám trên khoản nạp, không trên token người được giới thiệu tiêu. Trial 200 token là túi khác: để thử Pay-per-Result, không phải số dư đối tác.

Kịch bản minh họa — không phải khách hàng thật

Một freelancer ở Hà Nội gửi 80 bài guest post cho khách bán hàng sang thị trường Nga. Nhà xuất bản báo “đã lên”. Bốn URL trả 404, ba URL gắn noindex, mười URL đã có trên Google. Freelancer chạy công cụ kiểm Google trước, bỏ mười dòng đã có, gửi bảy dòng chết về cho tòa soạn, rồi đưa 63 URL còn lại vào tác vụ Standard — danh sách đủ ngắn. Ngày 7, báo cáo: một phần vào chỉ mục, trừ 100 token mỗi dòng; một phần đủ điều kiện nhưng chưa vào, token hoàn; không dòng 404 nào nằm trong tác vụ. Khách không nhận cam kết “cả 80 lên Google”, mà nhận bảng ba cột: đã có sẵn, mới được lưu, crawl được nhưng bị từ chối. Các trang 200 bị từ chối đi vào sửa nội dung, không vào một tác vụ y hệt trong cùng ngày.

Đồng hồ và quy tắc hoàn nằm trong brief trước tác vụ: không đòi hoàn cho noindex, không lấy ô site: trống ngày 6 làm hóa đơn.

Kịch bản minh họa thứ hai — không phải khách hàng thật

Một catalog 1500 URL danh mục và bộ lọc không muốn đổ cả danh sách lên Google trong một buổi. Biên tập chọn drip-feed 15 ngày, tức ít nhất 15 URL, thực tế 1500, khoảng 100 URL mỗi ngày. Tác vụ là Google Pay-per-Result drip. Đồng hồ bảy ngày của báo cáo bắt đầu sau ngày 15, không phải lúc bấm tạo. Yandex chạy tác vụ riêng, kiểm lại ngày 15, không lấy kỳ vọng drip từ lịch Google. Bing chỉ được kiểm: danh mục nào đã có, danh mục nào chưa. Không có tác vụ lập chỉ mục Bing. Sau lô Google cuối cộng bảy ngày, nhóm đọc báo cáo và chia phần còn lại: không truy cập được thì đưa kỹ thuật, crawl được nhưng không lưu thì đưa người viết mô tả danh mục. Không ai viết “lập chỉ mục 100 phần trăm trước cuối tháng” lên nhóm nội bộ.

Không mở ticket hoàn ngày thứ tám sau khi tạo, và không tuyên bố lỗ Bing đã vá bằng drip Google. Drip chỉ phân phối cú đẩy; việc lưu vẫn là quyết định của Google.

Một quy trình giữ đồng hồ ngay thẳng

Khóa đúng URL: scheme, host, path, dấu gạch. Tác vụ và bảng phải cùng một chuỗi. Đọc status và robots trên một mẫu; thứ không truy cập được thì để ngoài. Kiểm Google và, nếu chiến dịch cần, Yandex cùng Bing. Dòng đã có và dòng chết rời hàng đợi. Chọn Standard hoặc Drip-Feed theo độ dài danh sách. Ghi ngày báo cáo: drip thì lô cuối cộng bảy. Bật lọc trước nếu 404, noindex và dòng đã có chưa được tự dọn. Đợi đúng ngày. Đọc báo cáo và một mẫu kiểm trong cùng một buổi. Chia phần còn lại: nhà xuất bản hoặc kỹ thuật khi không truy cập được, nội dung và canonical khi 200 sạch nhưng không được lưu. Gửi lại cùng một 404 rồi đòi hoàn lần hai không phải quy trình, mà là vòng lặp.

Cùng quy trình đó cho URL người khác. Bạn không cần xác minh domain. Bạn vẫn phải gặp một tài liệu sống. Trả theo kết quả bỏ ngưỡng xác minh, không bỏ yêu cầu tài liệu tồn tại và được phép crawl.

Khi nào nên dùng, khi nào bỏ qua

SpeedyIndex hợp khi bạn có nhiều URL không xác minh được trên Search Console, hoặc khi bạn muốn đẩy danh sách của mình và gắn hóa đơn vào chỉ mục thay vì vào mỗi lần bấm gửi. Không hợp khi trang trả 404, gắn noindex, hay canonical sang chỗ khác. Nó không thay việc viết nội dung. Nó không lập chỉ mục Bing. Nó không hứa Google sẽ lưu mọi danh mục chỉ vì token đã trừ. Pay-per-Submit đang tạm đóng; ai bắt đầu hôm nay thì bắt đầu với Pay-per-Result.

Một URL lẻ trên domain bạn đã xác minh thường đi tiếp được bằng Search Console và sự kiên nhẫn. Vài trăm guest post không có property thì cần một đường không phụ thuộc tài khoản nhà xuất bản, cộng lần kiểm trước và quy tắc hoàn ngay thẳng sau. Trả theo kết quả được dựng đúng cho việc đó: quy trình, kiểm lại, token chỉ cho dòng đã lưu, hoàn chỉ cho lần trượt đủ điều kiện.

Bước tiếp: mở trang chủ tiếng Việt, kiểm một mẫu danh sách bằng công cụ Google trên bản tiếng Anh, rồi mới tạo tác vụ Pay-per-Result — Standard nếu danh sách ngắn, Drip-Feed nếu danh sách dài, đồng hồ tính từ lô cuối.

The previous note in this series covers the step before this one: SpeedyIndex: Google- und Yandex-Indexierung mit Zahlung pro Ergebnis. Read that first if you landed here on a related long tail.