Kiểm tra backlink trang khi xuất bản, từng bước một
Một webhook, một lệnh gọi HTTP, một quyết định. Sổ tay thực thi này hướng dẫn đội ngũ CMS headless qua quy trình hook, các lệnh gọi và các trường hợp lỗi.
Nhóm nghiên cứu Contentin ·
Quyết định những hành động mà cổng kiểm soát có thể thực hiện
Việc kiểm tra backlink trang trong quy trình phát hành là một nhiệm vụ nhỏ. Hãy giữ nó nhỏ gọn. Phần khó nhất là xác định những thay đổi nào trong kết quả là chấp nhận được, vì một đồ thị liên kết được làm mới hàng tháng không thể phủ quyết một trang một cách đơn độc.
Chúng tôi đề xuất cổng kiểm soát chỉ nên cảnh báo, ghi log và cho phép quy trình xây dựng tiếp tục. Các cài đặt mặc định có thể thay đổi. Các chặn cứng (hard blocks) nên dành cho những thứ bạn kiểm soát được, như markup bị lỗi hoặc thẻ canonical bị thiếu. Dữ liệu liên kết là một tín hiệu, và các tín hiệu có thể biến động.
Hãy ghi lại chính sách của bạn. Hãy làm điều đó trước khi viết mã. Một chính sách ngắn gọn như "cảnh báo editor, gắn thẻ entry, không bao giờ dừng quá trình deploy" sẽ tiết kiệm cho bạn những cuộc tranh luận dài dòng vào lúc 6 giờ chiều trong ngày phát hành. Nó cũng giúp kỹ sư tiếp theo phân biệt được lỗi nào là do thiết kế và lỗi nào là do bug, điều này quan trọng hơn bạn nghĩ. Hãy xem xét chính sách này mỗi quý một lần.
Sáu bước từ khi nhấn xuất bản đến khi lưu ghi chú
1
Chọn điểm kích hoạt
Đăng ký theo dõi sự kiện xuất bản của CMS của bạn. Contentful, Sanity và Strapi có thể gọi đến một URL do bạn sở hữu khi một entry được xuất bản, trong khi Storyblok và Payload cũng cung cấp webhook hoặc hooks. Hãy lọc theo các loại nội dung chứa các URL ra ngoài hoặc URL canonical.
2
Chuẩn hóa URL thành tên miền
API yêu cầu tên miền trong tham số q, vì vậy https://www.example.com/blog/post?x=1 phải được chuyển đổi thành example.com trước tiên. Hãy quyết định một lần cách bạn xử lý www và kiểm thử một tên miền thực tế với hành động domain miễn phí trước khi bắt đầu xây dựng.
3
Gọi hành động miễn phí trước
overview không tốn phí. Nếu kết quả trả về ít dữ liệu, tên miền có thể mới hoặc chưa được chỉ mục của chúng tôi biết đến. Điều đó không có nghĩa là có vấn đề gì xấu.
4
Chỉ tiêu tốn credits khi có quy tắc kích hoạt
Khi quy tắc của bạn yêu cầu xem xét kỹ hơn, hãy gọi backlinks với tham số per=100. Hành động này tốn 2 credits bất kể số lượng hàng trả về, vì vậy hãy yêu cầu một trang dữ liệu có ý nghĩa thay vì nhiều trang nhỏ lẻ.
5
Ghi chú, không phải JSON thô
Lưu một kết luận ngắn gọn vào một trường riêng của bạn, cùng với ngày thực hiện kiểm tra. Các phản hồi thô làm tăng kích thước mục nhập và nhanh chóng lỗi thời, vì chỉ mục được cập nhật hàng tháng.
6
Xử lý gracefully khi gặp lỗi
HTTP 401 có nghĩa là khóa API bị thiếu hoặc sai, hãy thông báo cho người quản trị. HTTP 402 có nghĩa là hết hạn mức tín dụng. Với mọi lỗi khác: hãy ghi log, bỏ qua lần kiểm tra đó và cho phép bài viết được xuất bản.
Vị trí lưu khóa và cách xử lý khi gặp mã 402
Mọi yêu cầu trả phí đều kèm theo khóa của bạn, dưới dạng tham số truy vấn hoặc tiêu đề Bearer. Ưu tiên sử dụng tiêu đề. Tham số truy vấn có thể bị ghi vào nhật ký máy chủ và các bản ghi proxy, trong khi tiêu đề thường không xuất hiện trong đó.
Lưu khóa dưới dạng bí mật trong nền tảng lưu trữ của bạn, không lưu trực tiếp trong mục nhập. Người biên tập có thể đọc bất kỳ trường nào họ có quyền truy cập, nhưng môi trường của một hàm thường chỉ hiển thị với những người quản lý quá trình triển khai.
Nên lưu khóa ở đâu?
Một khóa bị rò rỉ có thể làm cạn kiệt hạn mức trên tài khoản của bạn, vì vậy hãy coi nó như một mật khẩu. Giữ khóa này khỏi kho lưu trữ mã nguồn và khỏi CMS, và thay đổi khóa nếu nó xuất hiện dưới dạng văn bản rõ ràng trong bất kỳ tệp nhật ký nào.
Gắn nhãn cho các nhật ký của bạn bằng tên của hook. Khi đó, việc theo dõi chi tiêu trở nên dễ dàng cho từng hàm, ngay cả khi nhiều hook chia sẻ cùng một tài khoản.
Một công cụ không cần code có thể thực hiện yêu cầu gọi API không?
Có, khi công cụ có một bước yêu cầu HTTP đơn giản. Nhiều công cụ xây dựng quy trình tự động có thể gửi yêu cầu GET với tham số truy vấn và đọc lại phản hồi JSON, vì vậy hành động xem tổng quan miễn phí không cần đến code.
Hãy bắt đầu chỉ với các hành động miễn phí. Một luồng tự động kích hoạt mỗi khi lưu bản nháp có thể tiêu tốn tín dụng nhanh hơn cả khi người biên tập nhận ra, vì vậy hãy thêm một bước trả phí sau khi các yêu cầu miễn phí đã chạy ổn định trong một thời gian.
Nên kích hoạt hành động gì khi gặp mã 402?
Mã 402 có nghĩa là hết hạn mức tín dụng. Nó không phản ánh trạng thái của trang. Hãy bỏ qua yêu cầu trả phí, ghi log sự kiện và gửi một cảnh báo đến người phụ trách nạp thêm tín dụng, sau đó cho phép bài viết được xuất bản.
Đặt cảnh báo về hạn mức tín dụng ở mức cao hơn mức không đáng kể, để cảnh báo được gửi đi khi vẫn còn thời gian để nạp thêm. Chu trình thử lại sẽ không giúp ích ở đây, vì mọi yêu cầu đều sẽ thất bại theo cùng một cách cho đến khi ai đó nạp thêm tín dụng. Bảng chi phí kiểm tra trên mỗi lần xuất bản có các con số chi tiết.
Kiểm tra hai yêu cầu API từ terminal
Hãy chạy các lệnh này một lần đối với một tên miền bạn đã biết trước khi hook thực hiện nó cho bạn. Hãy đọc trường _credits trong phản hồi thứ hai.
bash
# free, no key
curl -s "https://contentin.app/api.php?action=overview&q=example.com"
# 2 credits, key in a header
curl -s -H "Authorization: Bearer sk_live_..." \
"https://contentin.app/api.php?action=backlinks&q=example.com&per=100"
Tên miền nào được đưa vào tham số q
API yêu cầu tên miền thuần túy trong tham số q, vì vậy một URL đầy đủ cần được rút gọn trước. Hãy viết hàm rút gọn này một lần duy nhất trong một hàm. Sau đó, hãy kiểm tra nó trên các URL thực tế.
Các liên kết tương đối và các URL thiếu lược đồ (scheme) là những trường hợp thường gây lỗi cho hook. Một hàm rút gọn hoạt động tốt với các ví dụ sạch sẽ vẫn có thể thất bại với các URL lộn xộn mà người biên tập dán vào lúc 5 giờ chiều.
Việc có www có thay đổi kết quả không?
Có thể, và cách trung thực nhất để biết là hãy hỏi. Chạy hành trình kiểm tra miễn phí trên cả hai phiên bản của một trang web bạn đã biết, sau đó so sánh hai phản hồi cạnh nhau.
Bất kể quy tắc nào bạn chọn, hãy ghi chú trong mã nguồn để kỹ sư tiếp theo không phải đoán mò. Một ghi chú không tốn gì và tiết kiệm một cuộc tranh luận dài sau này.
Còn về chuyển hướng và tên miền con?
Hãy gửi máy chủ mà độc giả thực sự truy cập vào, không phải liên kết mà biên tập viên dán từ nhiều năm trước. Nếu liên kết đó chuyển hướng, hãy rút gọn địa chỉ cuối cùng và bỏ qua bước trung gian.
Một blog trên tên miền con riêng biệt là một quyết định mang tính chủ quan. Hãy quyết định trước xem nó được kiểm tra riêng lẻ hay cùng với tên miền cha, và ghi lại lựa chọn đó bên cạnh quy tắc.
Danh sách kiểm tra trước khi phát hành cho hook
Hook chỉ kích hoạt khi xuất bản, không phải mỗi lần lưu bản nháp
URL được rút gọn về tên miền cơ bản trước khi gọi API
Các hành trình miễn phí chạy trước và chỉ tiêu tốn credits khi có cờ báo
Mã 401 và 402 mỗi mã có cảnh báo riêng và thông báo riêng
Thời gian chờ được đặt, nên một API chậm không bao giờ làm停滞 biên tập viên
Ghi chú đã lưu có ngày tháng, nên không ai nhầm nó với dữ liệu thời gian thực
Cùng một mục được xuất bản hai lần không bị tính phí hai lần (xem danh sách lầm tưởng)
Ai đó đã đọc bảng chi phí cho khối lượng hàng tháng của bạn
Những gì cần ghi log, và những gì không xuất hiện trong mục nhập
Một dòng log cho mỗi lần bỏ qua kiểm tra là chuỗi kiểm toán rẻ nhất bạn có thể xây dựng. Hãy ghi lại ID mục nhập, tên miền bạn đã gửi, mã trạng thái và xem bước trả phí có chạy không. Thường thì như vậy là đủ.
Ghi chú đã lưu giữ ngắn gọn và có ngày tháng, như các bước trên đã nói. Phản hồi đầy đủ thuộc về log của bạn, nếu chúng thuộc đâu đó, vì chúng lớn và nhanh chóng lỗi thời.
Những trường nào thuộc về một dòng log?
Bắt đầu với ID mục nhập và phiên bản xuất bản. Một webhook lặp lại sau đó sẽ xuất hiện dưới dạng cùng một cặp hai lần, đúng như những gì bạn muốn thấy.
Thêm tên miền, tên hành động, mã trạng thái và thời gian bắt đầu gọi. Để khóa chính ra ngoài, vì một log chứa nó sẽ trở thành nơi thứ hai lưu trữ bí mật.
Ghi chú đã lưu nên tồn tại bao lâu?
Càng lâu越好 mục nhập tồn tại, trừ khi một kiểm tra mới hơn thay thế nó. Điều quan trọng là người đọc có thể biết ghi chú cũ như thế nào, vì một ghi chú từ vài tháng trước có thể bị nhầm là dữ liệu thời gian thực.
Hướng dẫn trường điểm số hiển thị bốn trường chúng tôi đề xuất cho ghi chú đó, bao gồm ngày tháng.
Kiểm tra hook trên môi trường staging trước khi phát hành
Chạy bốn kiểm tra này trước khi bất kỳ ai dựa vào hook.
1
Phát lại một lần xuất bản đã qua
Kích hoạt hook với một bản sao của một mục bạn đã xuất bản trước đó. So sánh ghi chú đã lưu với những gì bạn mong đợi, và xác nhận rằng cùng một mục không bị tính phí hai lần.
2
Thử một tên miền được đăng ký gần đây
Sử dụng một tên miền đối tác mới đối với bạn. Một câu trả lời trống hoặc mỏng nên được lưu dưới dạng không xác định, không phải là thất bại, và ghi chú nên nói rõ điều đó bằng lời văn đơn giản.
3
Buộc lỗi 402 có chủ đích
Chạy hook với một khóa trên tài khoản thử nghiệm mà bạn đã làm cạn số dư. Xác nhận rằng việc bỏ qua, dòng log và cảnh báo đều kích hoạt, và việc xuất bản vẫn đạt đến quá trình xây dựng.
4
Đọc thông báo mà biên tập viên thấy
Yêu cầu một người ngoài nhóm đọc to văn bản lỗi. Nếu họ không thể nói phải làm gì tiếp theo, hãy viết lại thông báo trước ngày phát hành. Báo cáo sau sự cố cho thấy một thông báo mơ hồ đã khiến một nhóm giả định tốn kém như thế nào.
Những gì hook không thể thấy
Chỉ mục của chúng tôi làm mới khoảng một lần một tháng. Một liên kết được thêm sau lần làm mới cuối cùng sẽ không hiển thị, và một liên kết bị xóa từ trước có thể vẫn xuất hiện. Để chứng minh cùng ngày, hãy sử dụng Báo cáo Liên kết trong Google Search Console.
