1. Báo cáo Enhancements trong Search Console trả lời câu hỏi gì
Báo cáo Enhancements trong Google Search Console trả lời đúng một câu hỏi: những đoạn schema bạn vừa khai đã được Google công nhận trên các URL thật hay chưa. Mở theo đường GSC, Enhancements, chọn loại schema muốn xem, màn hình tách số URL thành hai cột Valid items và Invalid items. Đây là chỗ nói bằng dữ liệu phía Google, không phải dữ liệu của công cụ kiểm.
Tài liệu Bài 8 Schema Pack của VLINK ASIA xếp Enhancements ở cuối chuỗi việc, không phải ở đầu. Trước nó là ba bước: implement schema đúng loại, validate cho tới khi không còn lỗi, rồi QA lại DOM. Enhancements là bước nghiệm thu, và câu nghiệm thu ghi thẳng trong bài về nhà là Valid items có tăng hay không.
Nhịp đọc trong tài liệu là hằng tuần. Invalid items xuất hiện thì sửa ngay lúc thấy, không gom lại cuối tháng, vì Invalid items tăng nghĩa là có URL mới vừa bị lỗi, mà URL mới thường là URL bạn vừa đụng vào.
2. Valid items và Invalid items: hai con số, hai việc phải làm
Valid items và Invalid items nằm cùng một báo cáo nhưng dẫn tới hai việc khác hẳn nhau: Valid items đếm số mục Google đã công nhận, còn Invalid items đếm số URL đang lỗi và phải sửa ngay. Đọc Valid items để biết tờ khai có được nhận hay không, đọc Invalid items để biết chỗ nào vừa hỏng. Gộp hai con số lại là mất phần việc cụ thể của từng con số.
Ba nguyên nhân hay gặp của Invalid items được tài liệu nêu tên: cập nhật nội dung làm schema text không còn khớp DOM, cập nhật plugin làm format schema đổi, và URL mới lên có schema lỗi. Cả ba đều không tự báo, chúng chỉ hiện ra ở cột Invalid items vài ngày sau khi bạn đã quên mình vừa đổi gì.
Hành động cho nhóm Invalid items chỉ có một: đưa từng URL invalid qua Rich Results Test để lấy thông báo lỗi cụ thể. Đích của cả đợt, theo checklist trong tài liệu, viết rất gọn: sau 7 ngày, Valid items có mặt và không kèm Invalid mới. Hai vế đó phải đúng cùng lúc.
3. Vì sao schema hợp lệ trong công cụ kiểm vẫn hỏng trên trang thật
Schema hợp lệ trong công cụ kiểm vẫn hỏng trên trang thật vì hai bên đo hai thứ khác nhau: công cụ kiểm đọc cú pháp của đoạn mã bạn dán vào, còn Google đọc trang thật sự trả về sau khi render. Tài liệu gọi schema là tờ khai, khai gì phải đúng cái người đọc thấy trên trang. Cú pháp đúng mà nội dung tương ứng không hiện trong DOM thì tờ khai không khớp trang, nên nó bị bỏ qua.
Khoảng cách này có tên nếu tách hai việc ra. Implement schema là dán được đoạn JSON-LD vào trang. Visible schema là nội dung tương ứng nằm sẵn trong Rendered HTML, tới mức bấm Ctrl+F là tìm thấy. Công cụ kiểm chấm việc thứ nhất, Google chấm việc thứ hai, và chỉ việc thứ hai mới chảy vào Valid items.
Luật trong tài liệu nói thẳng: không implement schema khi content tương ứng không tồn tại hoặc không visible, vì schema không sửa được content kém. Một trang không có quy trình tuần tự thật thì khai HowTo cũng chỉ tạo ra một dòng Invalid items. Một trang không có Q/A hiển thị thật thì khai FAQPage cũng vậy, và đó là lý do nhiều đợt triển khai schema markup pass hết validator mà Enhancements vẫn trống.
Cách kiểm nằm ngay trong Search Console: URL Inspection, Test live, View tested page, rồi Ctrl+F câu trả lời hoặc câu step. Không tìm thấy nghĩa là phải sửa DOM trước, sửa schema sau. Đảo thứ tự đó là sửa tờ khai cho khớp một trang mà bot chưa từng đọc được.
4. Debug ba tầng: Validate, DOM rồi mới tới GSC
Debug ba tầng nghĩa là chạy lần lượt Validate, DOM rồi mới tới GSC, và không bỏ tầng nào. Tầng một đo cú pháp, tầng hai đo điều kiện hiển thị, tầng ba đo thực tế trang trả về. Fail ở tầng nào thì sửa đúng tầng đó trước rồi mới đi tiếp, vì kết quả của tầng sau chỉ có nghĩa khi tầng trước đã sạch.
Tầng 1, cú pháp: validator.schema.org
Tầng cú pháp chạy trên validator.schema.org và chỉ hỏi ba thứ: JSON có hợp lệ không, @type khai đúng chưa, và các trường bắt buộc đã đủ chưa. Đây là tầng rẻ nhất, cũng là tầng dễ bỏ qua nhất khi bạn tin vào plugin.
Ba lỗi thường gặp ở tầng này đều là lỗi gõ: thiếu dấu phẩy, sai kiểu dữ liệu, thiếu dấu ngoặc đóng. Sửa xong cho pass tầng 1 rồi mới lên tầng 2.
Tầng 2, điều kiện hiển thị: Rich Results Test
Tầng hai chạy trên Rich Results Test tại địa chỉ search.google.com/test/rich-results, dán URL vào và đọc kết quả. Tầng này không đo cú pháp nữa, nó đo xem trang có đủ điều kiện để hiện kết quả giàu hay không.
Error và Warning không cùng một mức. Error chặn kết quả giàu nên bắt buộc phải sửa. Warning không chặn nhưng nên sửa. Mốc pass của tầng 2 là 0 Error, và tài liệu ghi rõ: không đưa lên production khi còn Error.
Tầng 3, thực tế: View tested page trong GSC
Tầng ba là tầng thật, và nó nằm trong Google Search Console: URL Inspection, Test live, View tested page, rồi Ctrl+F câu trả lời hoặc câu step trong Rendered HTML. Đây là lần đầu bạn nhìn thấy đúng cái bot nhìn thấy.
Tìm thấy là pass. Không tìm thấy nghĩa là DOM đang giấu nội dung, thường vì accordion đóng mặc định hoặc JavaScript chèn nội dung muộn. Hai ca đó sửa ở lớp giao diện, không phải lớp schema.
Chụp evidence rồi mới request indexing
Sau khi ba tầng đều sạch, việc còn lại là chụp màn hình từng tầng làm evidence rồi mới bấm request indexing, và chỉ bấm khi thật sự cần. Evidence không phải thủ tục giấy tờ, nó là thứ giúp bạn truy ngược khi Invalid items xuất hiện vài tuần sau.
Điều kiện để được bấm gồm ba vế cùng lúc: canonical đúng, schema validate pass, DOM QA pass. Thiếu một vế thì bấm cũng vô nghĩa vì Google đọc lại đúng cái trang đang hỏng. Tài liệu thêm một câu ngắn: không spam request.
5. Năm anti-pattern làm Invalid items xuất hiện
Năm anti-pattern dưới đây là năm cách quen thuộc nhất để đẩy một URL từ Valid items sang Invalid items, và cả năm đều không nằm trong đoạn JSON-LD. Chúng nằm ở accordion, ở JavaScript, ở chỗ tờ khai lệch nội dung, ở hai plugin cùng sinh schema, và ở canonical. Nhận sai nhóm thì bạn sửa mãi một đoạn mã vốn không hề sai.
| Anti-pattern | Bot nhìn thấy gì | Cách sửa |
|---|---|---|
| Accordion đóng, FAQ hoặc steps bị ẩn | Thấy Q, không thấy A, nên bỏ qua | Mở mặc định, hoặc đưa phần A core ra ngoài dạng static HTML |
| JavaScript chèn schema muộn | Không thấy gì ở lần render đầu | Đặt JSON-LD tĩnh trong <head> |
| Khai khống, schema lệch DOM | Phát hiện mismatch và đánh invalid | Đồng bộ schema text với DOM thật |
| Hai plugin cùng sinh schema | Conflict, invalid cả hai | Tắt auto schema của plugin, giữ một nguồn |
| Canonical hoặc noindex sai | Schema nằm trên URL sai | Sửa canonical và trạng thái index trước khi đụng tới schema |
Còn một nhóm nữa không nằm trong bảng nhưng nặng hơn cả năm nhóm trên: bịa dữ liệu. Tài liệu ghi thẳng rằng bịa bất kỳ trường nào, dù là địa chỉ, rating hay tên tác giả, đều có thể khiến Google phạt site.
6. Thứ tự sửa bắt buộc: canonical/index, DOM, schema, indexing
Khi một URL rơi vào Invalid items, thứ tự sửa bắt buộc là canonical/index trước, DOM thứ hai, schema thứ ba, indexing sau cùng. Tài liệu nhắc lại thứ tự này ở nhiều chỗ kèm một câu ngắn: không đảo thứ tự bao giờ. Mỗi bước sau chỉ có nghĩa khi bước trước đã đúng, nên đảo thứ tự không phải làm nhanh hơn, mà là làm lại vài lần.
Bước canonical/index đứng đầu vì nó quyết định schema đang nằm trên URL nào. Schema hoàn hảo đặt trên một URL canonical sai thì vô nghĩa, và một trang noindex thì không có cửa vào Enhancements.
Bước DOM đứng thứ hai vì nó quyết định tờ khai có khớp trang hay không. DOM fail thì schema không match, mà không match thì Google bỏ qua, nên mọi phút chỉnh JSON-LD lúc này đều rơi vào chỗ trống.
Bước schema đứng thứ ba, và đây mới là lúc mở đoạn JSON-LD ra sửa: đúng loại theo vai trò trang, đủ trường bắt buộc, text khớp nội dung hiển thị. Bước indexing đứng cuối.
7. Valid items đứng yên sau 7 tới 14 ngày thì kiểm lại ba chỗ
Valid items đứng yên sau 7 tới 14 ngày không phải là tín hiệu để khai thêm schema, mà là tín hiệu để kiểm lại ba chỗ đã làm: canonical, DOM và schema. Tài liệu đặt mốc này để người triển khai khỏi kết luận quá sớm, cũng để khỏi chờ vô hạn. Hết mốc mà con số không nhúc nhích thì mở lại đúng ba chỗ đó.
Bốn câu hỏi kiểm, hỏi lần lượt và trả lời bằng ảnh chụp chứ không bằng trí nhớ:
- Canonical đã đúng chưa: URL mang schema có phải là URL canonical mà bạn muốn Google giữ hay không.
- Trạng thái index có ổn không: trang có đang được lập chỉ mục, hay đang vướng noindex hoặc chưa được thu thập lại.
- DOM có pass không: View tested page rồi Ctrl+F câu schema text, tìm thấy trong Rendered HTML hay không.
- Schema text có match DOM không: câu trong
acceptedAnswer.texthoặc trongdescriptioncó khớp đúng câu hiển thị trên trang hay không.
Nếu cả bốn câu đều trả lời được là đạt thì việc còn lại là đợi thêm 7 ngày nữa. Đây là phần khó chịu nhưng thật: Enhancements chạy theo nhịp thu thập của Google, không chạy theo nhịp deploy của bạn. Đổi thêm một thứ trong lúc đang chờ là tự làm mất mốc so sánh, vì lần sau bạn sẽ không biết con số thay đổi nhờ cái nào.
8. Enhancements báo eligibility chứ không báo kết quả giàu
Enhancements báo eligibility, tức là báo trang đủ điều kiện, chứ không báo trang đã hiện kết quả giàu ngoài SERP. Valid trong báo cáo có nghĩa là eligible, không có nghĩa là đã xuất hiện. Kết quả giàu còn phụ thuộc hai thứ nằm ngoài tầm với của đoạn JSON-LD: intent của truy vấn lúc đó, và mức tin cậy Google dành cho site.
Hiểu sai chỗ này dẫn tới một kiểu lãng phí quen thuộc: thấy Valid items tăng mà SERP không đổi, thế là đi khai thêm loại schema khác. Tài liệu chặn lối đó bằng một câu: đừng đuổi theo kết quả giàu khi phần nền chưa pass. Thêm một chi tiết dễ làm người mới hụt hẫng, là trong bảng chọn schema của tài liệu, không phải loại nào cũng có cột kết quả giàu. DefinedTerm không tạo kết quả giàu, nó là tín hiệu thực thể. Service cũng không, nó là tín hiệu ngữ nghĩa. Khai hai loại đó rồi ngồi chờ một ô đẹp ngoài SERP là chờ thứ chưa từng được hứa.
Giá trị thật của hai loại đó nằm chỗ khác: tài liệu ghi rằng AI Overview thường trích dẫn các trang thực thể có DefinedTerm schema, còn Service thì đáng giá khi xếp chung trong @graph của một money page. Đọc rich snippets theo hướng này sẽ bớt kỳ vọng sai.
9. Bốn pack và điều kiện để chúng được công nhận
Bốn pack trong tài liệu là DefinedTerm, FAQPage, HowTo và Service, mỗi pack gắn với một vai trò trang và một bộ điều kiện bắt buộc phải đọc trước khi implement. Thiếu điều kiện thì không dùng loại đó, đây là luật chứ không phải khuyến nghị. Bảng dưới xếp bốn pack theo đúng cột mà tài liệu dùng, để bạn đối chiếu trang mình đang có trước khi viết dòng JSON-LD đầu tiên.
| Pack | Vai trò trang | Điều kiện bắt buộc | Có kết quả giàu không |
|---|---|---|---|
| DefinedTerm | Trang thực thể định nghĩa thuật ngữ | Trang riêng, khối trả lời hiện ngay, khớp DOM | Không, là tín hiệu thực thể |
| FAQPage | Trang có Q/A hiển thị thật | Q/A visible trong DOM, A core 40 tới 90 từ | Có |
| HowTo | Quy trình tuần tự có steps thật | Steps trong <ol> và <li> thật, hiển thị, có thứ tự | Có |
| Service | Money page BOFU | name, description và provider khớp content trang | Không, là tín hiệu ngữ nghĩa |
DefinedTerm cần một trang riêng và một câu description khớp từng chữ
DefinedTerm chỉ dùng cho một trang thực thể riêng với H1 dạng thuật ngữ là gì, không dùng cho một mục nằm trong bài dài. Trường description phải là chính câu answer first đang hiển thị trên trang, chép đúng từng chữ.
Cách kiểm là View tested page rồi Ctrl+F câu description, tìm thấy là pass. Nội dung trên trang đổi thì phải cập nhật schema theo, và không mượn description từ nơi khác. Trường inDefinedTermSet cần URL của một trang hub, nên chưa có hub thì dựng hub trước.
FAQPage cần Q/A thật, hiện thật, và phần trả lời tự đứng được
FAQPage yêu cầu cặp hỏi đáp hiện thật trong DOM, không nằm sau accordion đóng mặc định, và cần từ ba cặp trở lên mới đủ điều kiện kết quả giàu. Trường acceptedAnswer.text phải khớp đúng câu trả lời đang hiển thị.
Phần A core giữ trong khoảng 40 tới 90 từ, viết có điều kiện, đọc riêng vẫn hiểu mà không cần ngữ cảnh khác. Câu hỏi lấy từ sales call thật, bám intent thật như giá, thời gian, bảo hành, điều kiện áp dụng. Không giới thiệu công ty trong phần trả lời, không chép Q/A của bên khác. Cách viết cụm hỏi đáp theo intent có riêng bài FAQ schema cho AI.
HowTo chỉ dùng khi trang có steps thật, có thứ tự
HowTo đòi các bước nằm trong danh sách có thứ tự thật, hiển thị trên trang, mỗi bước là một hành động cụ thể. Mỗi HowToStep mang position, name, text và một url trỏ tới neo của chính bước đó.
Tài liệu liệt kê ba trường hợp không được dùng HowTo: guide tổng quan, checklist không có thứ tự, và trang có nói tới các bước nhưng không hiển thị thành danh sách thật. Khai HowTo ở đó là tạo sẵn một dòng Invalid items cho tuần sau.
Service dành cho money page, và nên đứng chung trong @graph
Service dùng cho money page ở cuối phễu, với name, description và provider khớp nội dung trang. Phần description viết 2 tới 3 câu về offer kèm điều kiện, không viết một câu quảng cáo rời khỏi thứ trang đang bán.
Vì Service không tạo kết quả giàu riêng, cách dùng hiệu quả là xếp chung Service, FAQPage và BreadcrumbList trong một @graph: một thẻ script, mỗi node một @id rõ ràng, các node tham chiếu nhau, không có hai node cùng loại, chuỗi tin cậy chạy từ WebPage sang WebSite rồi tới Organization.
10. WordPress: nguồn schema trùng, JS inject và bản nén
Trên WordPress, ba thứ hay biến một schema đúng thành Invalid items là hai plugin cùng sinh schema, JSON-LD chèn bằng JavaScript, và bản nén của plugin cache. Cả ba đều nằm ngoài nội dung bài viết, nên người viết thường không nghĩ tới, và cả ba đều chỉ lộ ra khi bạn xem mã nguồn trang thật sau khi cache đã chạy.
Một plugin SEO chính, không phải hai
Chọn một plugin SEO chính, RankMath hoặc Yoast, và không bật cả hai cùng lúc. Trộn hai plugin sinh ra schema trùng và xung đột, kết quả là cả hai node cùng bị đánh invalid chứ không phải node này thắng node kia.
Khi tự viết JSON-LD riêng, phải tắt phần auto schema tương ứng của plugin. Đây là chỗ hay sót nhất: đoạn mã tay thì đúng, nhưng plugin vẫn âm thầm in thêm một node cùng loại ở ngay bên dưới. Phần schema cơ bản cho WordPress nói kỹ hơn về việc chọn một chủ sở hữu cho đồ thị.
Dùng wp_head() thay cho JavaScript chèn muộn
JSON-LD nên đi qua hook wp_head() để nằm sẵn trong <head>, vì bot parse phần đó trước khi render. Chèn bằng JavaScript sau khi DOM sẵn sàng thì bot có thể không thấy gì, và không thấy thì không có gì để công nhận.
Checklist trong tài liệu cho phép JSON-LD nằm trong <head> hoặc ngay trước </body>, nhưng chặn hẳn kiểu lazy load bằng JavaScript.
Bản nén có thể ăn mất JSON-LD
Sau khi bật minify, phải kiểm lại một lần nữa: clear cache, mở View source, xem khối JSON-LD còn nguyên hay không. Bộ nén đôi khi cắt hỏng chuỗi JSON và trang vẫn hiển thị bình thường, nên lỗi này không lộ ra bằng mắt thường.
Khối bị hỏng thì loại JSON-LD ra khỏi phần minify trong cài đặt. Quy trình tài liệu đề nghị là test trên staging hoặc dán đoạn mã vào Rich Results Test, validate pass rồi mới deploy, sau đó mở View tested page trên bản production để kiểm lần cuối.
11. Checklist trước khi publish, và nhịp theo dõi hằng tuần
Checklist trước khi publish gom đủ mười điểm kiểm, và nhịp theo dõi sau publish là hằng tuần cho tới khi Valid items ổn định mà không kèm Invalid mới. Chạy checklist mất vài phút cho mỗi URL, ít hơn nhiều so với thời gian truy ngược một dòng Invalid items xuất hiện ba tuần sau đó. Mười điểm dưới đây chép theo đúng thứ tự trong tài liệu.
- Schema type đúng với vai trò trang, không chọn nhầm loại.
- validator.schema.org không còn lỗi cú pháp,
@typeđúng, trường bắt buộc đủ. - Rich Results Test còn 0 Error, Warning không chặn nhưng nên sửa.
- Schema text khớp với nội dung hiển thị trong DOM, không khai khống.
- View tested page, Ctrl+F câu schema text và tìm thấy trong Rendered HTML.
- Không có schema trùng, chỉ một plugin SEO chính chứ không hai.
- JSON-LD nằm trong
<head>hoặc trước</body>, không lazy load bằng JavaScript. - Canonical đúng và trang ở trạng thái indexable trước khi deploy schema.
- BreadcrumbList nếu có thì khớp breadcrumb đang hiển thị và khớp canonical.
- Sau 7 ngày, Enhancements cho thấy Valid items và không có Invalid mới.
Baseline là bốn pack pass trước, schema mở rộng tính sau
Tài liệu đặt một baseline rõ ràng: bốn pack phải pass định nghĩa hoàn thành trước đã, sau đó mới xem xét thêm schema mở rộng. Mở rộng quá sớm chỉ làm báo cáo Enhancements có thêm vài dòng loại schema mà bạn chưa kịp QA cái nào cho tới nơi.
Nhóm mở rộng gồm BreadcrumbList khi có breadcrumb thật khớp canonical, ItemList cho hub có danh sách URL thật, Article khi tác giả và datePublished là thật, LocalBusiness khi có địa chỉ, giờ và số điện thoại thật, Product khi trang có giá và tình trạng hàng thật. Điều kiện chung của cả nhóm vẫn là câu cũ: khai gì phải có thật, bịa một trường là mở đường cho Google phạt site.
Nhịp theo dõi hằng tuần, và thứ cần ghi lại
Nhịp theo dõi trong tài liệu là mở Enhancements mỗi thứ 2, chọn từng loại schema đang khai, đọc hai cột Valid và Invalid rồi ghi lại con số. Ghi con số quan trọng hơn người ta tưởng, vì xu hướng chỉ đọc được khi đã có hai mốc.
Một đợt triển khai đủ theo tài liệu gồm bốn URL implement schema đúng loại và validate pass, một @graph cho money page, năm URL chạy View tested page có ghi pass hay fail kèm hành động, và một tuần theo dõi Enhancements. Các báo cáo còn lại của Search Console nằm ở bài đọc báo cáo SEO bằng GA4 và GSC, phần nghiệm thu từng tiêu chí thì xem kiểm tra và xác nhận schema.
12. Câu hỏi thường gặp về báo cáo Enhancements và schema
Sáu câu dưới gom những chỗ hay mắc nhất khi đọc báo cáo Enhancements và khi schema pass công cụ kiểm mà trang thật vẫn hỏng. Khi phân vân, quay lại hai câu gốc trong tài liệu: schema là tờ khai, và thứ tự sửa là canonical/index, DOM, schema, indexing.
Rich Results Test báo 0 Error mà Enhancements vẫn không có Valid items thì làm gì?
Rich Results Test báo 0 Error mới chỉ là pass tầng hai, nên khi Enhancements chưa có Valid items thì kiểm lại theo thứ tự: canonical đúng chưa, trang có đang được lập chỉ mục không, DOM có pass khi mở View tested page không, schema text có khớp DOM không. Cả bốn câu đều đạt thì đợi thêm 7 ngày nữa rồi đọc lại.
Invalid items mới xuất hiện sau khi cập nhật nội dung, nguyên nhân thường là gì?
Ba nguyên nhân hay gặp là cập nhật nội dung làm schema text không còn match DOM, cập nhật plugin làm format schema đổi, và URL mới lên mang schema lỗi. Hành động giống nhau cho cả ba: đưa từng URL invalid qua Rich Results Test rồi sửa theo thứ tự canonical, DOM, schema.
Warning trong Rich Results Test có bắt buộc phải sửa không?
Không bắt buộc, nhưng nên sửa. Error mới là thứ chặn kết quả giàu và bắt buộc phải xử lý, còn Warning thì không chặn. Mốc pass của tầng hai là 0 Error. Tài liệu chốt thêm một câu đáng dán lên tường: không đưa lên production khi còn Error, vì lúc đó Enhancements chỉ đang chờ để ghi thêm một dòng Invalid.
Accordion đóng mặc định ảnh hưởng gì tới FAQPage?
Bot thấy phần câu hỏi nhưng không thấy phần trả lời, nên nó bỏ qua cả cặp và schema không được công nhận. Hai cách sửa: mở accordion mặc định, hoặc đưa phần A core ra ngoài dạng static HTML rồi giữ accordion cho phần mở rộng. Sửa xong thì mở View tested page và Ctrl+F câu trả lời để xác nhận nó đã nằm trong Rendered HTML.
Valid items tăng thì trang đã hiện kết quả giàu chưa?
Chưa chắc. Valid nghĩa là eligible, tức là đủ điều kiện, chứ không phải đã xuất hiện. Kết quả giàu còn phụ thuộc intent của truy vấn và mức tin cậy của site, hai thứ nằm ngoài đoạn JSON-LD. Riêng DefinedTerm và Service thì vốn không tạo kết quả giàu, nên với hai loại đó việc chờ một ô đẹp ngoài SERP là chờ nhầm thứ.
Nên mở báo cáo Enhancements bao lâu một lần?
Hằng tuần, và tài liệu đề nghị cố định vào thứ 2 để thành thói quen. Sau mỗi đợt publish thì theo dõi liên tục một tuần. Invalid items xuất hiện thì sửa ngay lúc thấy chứ không gom lại, vì càng để lâu càng khó truy ngược xem thay đổi nào đã làm hỏng URL đó.