Chuyển Schema khi redesign hoặc migration: Checklist kỹ thuật

Chuyển Schema khi redesign hoặc migration là việc kiểm kê dữ liệu có cấu trúc đang dùng, ánh xạ sang hệ thống mới và kiểm thử lại trước khi xuất bản. Mục tiêu là giữ dữ liệu chính xác, nhất quán với nội dung hiển thị và hạn chế lỗi làm ảnh hưởng đến khả năng đủ điều kiện xuất hiện trong các tính năng tìm kiếm được hỗ trợ.

Checklist này dành cho chủ website, PM, SEO và lập trình viên khi đổi giao diện, CMS, tên miền hoặc cấu trúc URL. Markup hợp lệ không bảo đảm rich results, thứ hạng hay lượt trích dẫn AI được giữ nguyên; cần tách nghiệm thu kỹ thuật khỏi đánh giá hiệu suất tìm kiếm.

1. Phân biệt Schema hợp lệ và điều kiện hiển thị trên Google

Schema.org cung cấp bộ từ vựng mô tả thực thể và nội dung. Google chỉ hỗ trợ một số tính năng tìm kiếm dựa trên dữ liệu có cấu trúc, với yêu cầu riêng cho từng loại. Một loại Schema hợp lệ không đồng nghĩa có một rich result tương ứng.

• Schema Markup Validator: kiểm tra cấu trúc và cách sử dụng từ vựng Schema.org.
• Rich Results Test: kiểm tra các loại dữ liệu và điều kiện kỹ thuật mà công cụ Google đang hỗ trợ; không phải bộ kiểm tra mọi loại Schema.
• Search Console: theo dõi các báo cáo liên quan khi có sẵn; không phải website nào cũng có báo cáo riêng cho mọi loại markup.

Cập nhật kiểm chứng ngày 01/11/2026: Google đã ngừng hiển thị FAQ rich results từ ngày 07/05/2026. Vì vậy, không dùng việc khôi phục FAQ rich results làm KPI nghiệm thu. FAQPage vẫn là một loại trong Schema.org; chỉ duy trì nếu mô tả đúng nội dung và có mục đích sử dụng rõ ràng.

2. Audit Schema trước khi thay đổi website

Trước khi sao chép markup sang hệ thống mới, hãy xác định dữ liệu đang được tạo ở đâu và ai chịu trách nhiệm cập nhật.

• Lấy mẫu trang chủ, sản phẩm, biến thể sản phẩm, bài viết, danh mục, trang doanh nghiệp và từng địa điểm thực tế nếu có.
• Lưu HTML gốc, DOM sau render, JSON-LD, microdata hoặc RDFa của từng mẫu; ghi thời điểm và phiên bản triển khai.
• Kiểm tra nguồn sinh markup: theme, plugin SEO, module thương mại điện tử, mã tùy chỉnh hoặc Google Tag Manager.
• Ghi nhận loại Schema, thực thể, @id, URL, các thuộc tính liên kết và lỗi/cảnh báo hiện có.
• Lưu baseline trong Search Console cho những nhóm trang và kiểu hiển thị thực sự có dữ liệu; không tự tạo số liệu còn thiếu.

Nếu website có nhiều plugin hoặc template chồng chéo, nên thực hiện SEO Audit trước khi redesign để phân biệt lỗi sẵn có với lỗi do migration.

Những vấn đề cần ghi rõ trong biên bản

• Giá, tiền tệ, tình trạng hàng hoặc thông tin doanh nghiệp không khớp nội dung người dùng nhìn thấy.
• Cùng một thực thể bị khai báo thành nhiều bản ghi mâu thuẫn từ theme và plugin.
• URL ảnh, logo, tác giả hoặc @id vẫn trỏ tới domain cũ hay staging.
• Markup chỉ xuất hiện sau tương tác, bị lỗi JavaScript hoặc không được nạp ổn định.
• Loại Schema không phù hợp trang: không gán Product cho mọi danh mục hoặc LocalBusiness cho một địa điểm không có thật.

3. Lập bảng mapping dữ liệu cũ sang mới

Bảng mapping cần thể hiện nguồn dữ liệu backend, thuộc tính đầu ra, quy tắc chuyển đổi và cách xử lý dữ liệu thiếu. Các đường dẫn backend dưới đây chỉ là ví dụ minh họa.

Các thuộc tính bắt buộc và khuyến nghị phụ thuộc vào tính năng cụ thể, chẳng hạn Product snippets hay Merchant listings. Không dùng một danh sách “bắt buộc cho mọi Product” để thay thế tài liệu của từng tính năng.

Quản lý @id khi đổi URL hoặc tên miền

@id dùng để nhận diện node trong đồ thị dữ liệu, không phải cam kết xếp hạng. Nếu thay đổi định danh dựa trên URL, phải cập nhật đồng bộ các tham chiếu publisher, author, brand hoặc các node liên quan. Tránh tạo nhiều định danh mới cho cùng doanh nghiệp chỉ vì thay template; ghi lại quyết định giữ hay thay từng ID để đội triển khai đối chiếu.

4. Chọn cách xuất JSON-LD và kiểm soát nguồn dữ liệu

JSON-LD inline và server-rendered không phải hai lựa chọn đối lập. Inline nghĩa là JSON-LD nằm trong thẻ script của trang; đoạn này có thể được tạo từ server hoặc được JavaScript thêm vào DOM.

• Xuất từ server: là lựa chọn triển khai dễ kiểm soát nếu backend đã có đủ dữ liệu; hỗ trợ kiểm tra markup ngay trong HTML trả về.
• Tạo bằng JavaScript: Google có thể xử lý structured data có trong DOM sau render. Cần kiểm thử bằng URL thực tế; không mặc định mọi crawler đều xử lý JavaScript giống nhau.
• Product thay đổi nhanh: chú ý độ tin cậy khi giá/tồn kho phụ thuộc xử lý JavaScript và tài nguyên hệ thống; đồng bộ nội dung hiển thị với markup.
• JSON-LD bên ngoài: không mặc định rằng đặt đường dẫn tới một file .jsonld là đủ để Google sử dụng. Kiểm tra dữ liệu thực sự được nhúng hoặc tạo trong trang được render.

Một trang có thể chứa nhiều node và nhiều khối JSON-LD hợp lệ, chẳng hạn Article, BreadcrumbList và Organization. Vấn đề cần sửa là dữ liệu dư thừa hoặc mâu thuẫn, không phải cứ thấy nhiều type là xóa còn một. Có thể dùng @graph và tham chiếu @id để quản lý các thực thể liên quan.

Ví dụ trước và sau khi chỉnh template sản phẩm

Trước: plugin và theme cùng tạo Product nhưng giá khác nhau; breadcrumb chứa URL cũ; tiền tệ thiếu hoặc sai.

Sau: một nguồn dữ liệu quản lý thông tin sản phẩm, giá và tiền tệ khớp trang, breadcrumb cập nhật, các node liên kết đúng. Chạy kiểm thử cho tính năng mục tiêu trước khi mở rộng; không kết luận chắc chắn sẽ có rich results chỉ vì test hợp lệ.

5. Kiểm thử trước go-live: đúng dữ liệu, đúng trang, đúng thực thể

• Kiểm thử nhiều trạng thái: có hàng/hết hàng, có/không khuyến mãi, thiếu ảnh, biến thể và ngôn ngữ khác nhau.
• Phân biệt lỗi khiến không đủ điều kiện với cảnh báo thuộc tính khuyến nghị; ghi rõ cách xử lý thay vì yêu cầu xóa mọi cảnh báo bằng dữ liệu bịa.
• Nếu dữ liệu thiếu, lấy từ nguồn đã xác thực, bỏ thuộc tính tùy chọn hoặc tạm không xuất node chưa đủ điều kiện. Không tạo giá, review, tác giả hay địa chỉ giả để vượt validator.
• Dùng thư viện serialize JSON phù hợp và cách nhúng an toàn của framework, tránh nối chuỗi trực tiếp từ nội dung chưa tin cậy vào thẻ script.

Không mở staging công khai chỉ để chạy công cụ Google. Với staging được bảo vệ, có thể kiểm tra mã và render nội bộ, sau đó kiểm tra URL production khi phát hành. Công cụ kiểm tra mã không thay thế hoàn toàn việc kiểm thử JavaScript trên URL thực tế.

6. Rollout theo template và giám sát sau phát hành

Chọn nhóm trang đại diện để phát hành thử, bao gồm cả dữ liệu ngoại lệ, rồi mở rộng khi kiểm tra đạt. Không mặc định 1–5% URL là phù hợp mọi website; quy mô mẫu phụ thuộc số template, số biến thể và khả năng giám sát.

1. Lưu phiên bản template, mapping, cấu hình plugin và kết quả trước triển khai.
2. Phát hành thử; kiểm tra HTML/DOM thực tế, dữ liệu và các URL tham chiếu.
3. Mở rộng có kiểm soát sau khi lỗi chặn đã được xử lý và người chịu trách nhiệm xác nhận.
4. Theo dõi báo cáo liên quan trong Search Console khi có sẵn, kiểm tra mẫu URL và đối chiếu dữ liệu kinh doanh.
5. Ghi nhận thay đổi theo nhóm trang; xem xét độ trễ dữ liệu, mùa vụ, thay đổi URL và các thay đổi khác diễn ra cùng lúc.

Có thể dùng 14–30 ngày như cửa sổ theo dõi nội bộ ban đầu, rồi kéo dài nếu cần. Đây không phải thời hạn bảo đảm Google xử lý hết thay đổi hoặc phục hồi hiển thị. Không dùng tổng clicks giảm để quy nguyên nhân ngay cho Schema.

7. Khi nào cần rollback Schema?

Ưu tiên sửa mapping hoặc cấu hình nếu phạm vi lỗi rõ ràng. Rollback khi phiên bản mới tạo dữ liệu sai trên diện rộng, gây lỗi template hoặc không thể sửa trong thời gian đã thống nhất; không rollback tự động chỉ vì rich results chưa xuất hiện.

• Khôi phục phiên bản code hoặc cấu hình đã kiểm chứng, không khôi phục mù quáng dữ liệu cũ.
• Kiểm tra markup cũ còn tương thích URL, giá, tồn kho và nội dung hiện tại hay không.
• Xóa cache liên quan rồi chạy lại kiểm thử trên các template bị ảnh hưởng.
• Lưu log, thời điểm, phạm vi và kết quả kiểm tra; giao người xử lý nguyên nhân gốc.

Đưa yêu cầu Schema vào tài liệu thiết kế lại website chuẩn SEO ngay từ đầu để tránh sửa riêng lẻ sau khi giao diện đã hoàn thành.

8. Schema hỗ trợ AEO/GEO như thế nào?

Dữ liệu có cấu trúc giúp mô tả nội dung và thực thể rõ ràng, nhưng không phải nguồn sự thật duy nhất mà mọi công cụ trả lời phải sử dụng. Với Google AI Overviews và AI Mode, không có Schema đặc biệt bắt buộc riêng để xuất hiện; vẫn cần nội dung truy cập được và đáp ứng yêu cầu tìm kiếm liên quan.

• sameAs: dùng cho trang nhận diện rõ cùng một thực thể, ví dụ hồ sơ chính thức. Không dùng như danh sách tài liệu tham khảo chung.
• Nguồn trích dẫn: đặt liên kết trong nội dung; nếu dùng thuộc tính citation cho CreativeWork phù hợp, cần mô tả đúng quan hệ, không thay bằng sameAs.
• Câu trả lời FAQ: nếu dùng FAQPage, nội dung nằm trong mainEntity → Question → acceptedAnswer → Answer; phần văn bản câu trả lời dùng text, không tự tạo trường answerText.
• Nhất quán thực thể: tên thương hiệu, URL, tác giả và thông tin liên hệ phải đúng thực tế; không thêm sameAs không liên quan để cố tạo tín hiệu uy tín.

Checklist nghiệm thu nhanh cho PM, SEO và dev

• Đã lưu mẫu trang và markup trước thay đổi.
• Đã biết nguồn sinh Schema và người phụ trách từng template.
• Mapping có quy tắc xử lý dữ liệu thiếu, URL và @id.
• Type và thuộc tính phù hợp trang, dữ liệu khớp nội dung hiển thị.
• Không còn thực thể trùng mâu thuẫn hoặc hostname staging.
• Đã kiểm tra cú pháp, ngữ nghĩa, render và tính năng Google phù hợp.
• Đã kiểm thử các trạng thái dữ liệu và cách nhúng JSON an toàn.
• Đã thống nhất điều kiện phát hành, sửa lỗi, rollback và giám sát.

Câu hỏi thường gặp

Đổi giao diện có bắt buộc chuyển toàn bộ Schema sang JSON-LD không?

Không. Google hỗ trợ JSON-LD, microdata và RDFa; JSON-LD thường dễ quản lý hơn khi triển khai ở quy mô lớn. Quyết định chuyển đổi nên dựa vào khả năng duy trì dữ liệu chính xác và kiểm thử.

Nhiều khối JSON-LD trên một trang có phải lỗi không?

Không tự động là lỗi. Một trang có thể mô tả nhiều thực thể. Cần loại bỏ các khai báo dư thừa hoặc mâu thuẫn và kiểm tra quan hệ giữa các node.

Pass Rich Results Test có bảo đảm hiển thị rich results không?

Không. Kết quả kiểm tra kỹ thuật không bảo đảm hiển thị; còn phụ thuộc chính sách, nội dung và cách hệ thống tìm kiếm xử lý trang.

Có cần giữ FAQPage sau migration không?

Chỉ giữ khi đúng nội dung và phục vụ nhu cầu sử dụng cụ thể. Không dùng FAQ rich results của Google làm mục tiêu vì tính năng này đã ngừng hiển thị.

Quản lý Schema theo dữ liệu, không chỉ theo validator

Một lần chuyển Schema thành công cần dữ liệu đúng, quan hệ thực thể nhất quán và bằng chứng kiểm thử trên website thực tế. Nếu cần phối hợp rà soát template, mapping hoặc kế hoạch triển khai, bạn có thể liên hệ Việt SEO để trao đổi phạm vi phù hợp.

Tài liệu tham khảo

• Google: Chính sách dữ liệu có cấu trúc
• Google: Tạo structured data bằng JavaScript
• Google: Cập nhật tài liệu, bao gồm việc ngừng FAQ rich results
• Google: AI features và website
• Schema.org: sameAs và Answer