Nhãn của một trang nên khớp với nội dung mà khách truy cập có thể thấy
Schema.org markup cung cấp cho phần mềm một mô tả có cấu trúc về một trang và chủ đề của nó. Nó nên giải thích những gì trang đã nói, chứ không thêm vào những tuyên bố mà khách truy cập không thể xác nhận.
Hãy bắt đầu bằng cách ghi lại mục đích của trang và entity chính của nó. Sau đó chọn kiểu đơn giản nhất phù hợp. Trang giới thiệu của một dự án và trang sản phẩm không thể thay thế cho nhau, ngay cả khi cả hai đều nằm trên cùng một website. Điều này mang lại cho bạn một bước kiểm tra đầu tiên hữu ích cho schema.org để tối ưu hóa khả năng hiển thị trên AI. Liệu một người có thể chỉ vào nội dung hiển thị đằng sau mỗi thông tin được đánh dấu không?
| Trang hoặc chủ đề | Kiểu dữ liệu khả thi | Một bước kiểm tra thực tế |
|---|---|---|
| Dự án hoặc công ty | Organization | Tên công khai và chi tiết của nó có chính xác không? |
| Toàn bộ website | WebSite | Bản ghi có mô tả chính trang web đó không? |
| Một URL | WebPage | Nó có xác định đúng trang đang được mô tả không? |
| Tài nguyên biên tập | Article | Thông tin tác giả và chi tiết xuất bản có hiển thị không? |
| Sản phẩm hoặc phần mềm | Product hoặc SoftwareApplication | Trang có thực sự mô tả sản phẩm/dịch vụ đó không? |
Chúng tôi muốn thấy một bộ nhỏ mà nhóm của bạn có thể duy trì hơn là một bản ghi cồng kềnh chứa đầy các thuộc tính không được hỗ trợ. Để có cái nhìn tổng quan hơn về công việc kỹ thuật, hãy xem hướng dẫn kỹ thuật AEO.
Bắt đầu từ những chi tiết dự án mà mọi người thường hỏi
Hãy tưởng tượng một founder có lần ra mắt đầu tiên rất yên ắng. Người duy nhất trả lời đi nghỉ mát, và những khách truy cập mới vẫn cần thông tin rõ ràng về dự án.
Chúng tôi sẽ bắt đầu với những trang mà những khách truy cập đó cần, chứ không phải với một mẫu markup lớn. Chúng tôi sẽ kiểm tra xem tên dự án, mô tả sản phẩm và thông tin liên hệ có xuất hiện rõ ràng trên trang web hay không. Sau đó, chúng tôi chỉ ánh xạ những thông tin hiển thị đó vào các thuộc tính schema.org phù hợp. Trang vẫn là nguồn sự thật; markup đi theo nó.
Hãy tưởng tượng dự án có một trang sản phẩm và một bài báo giải thích ngắn. Trang sản phẩm có thể hỗ trợ Product nếu nó thực sự mô tả sản phẩm. Bài báo giải thích có thể phù hợp với Article khi thông tin tác giả và chi tiết biên tập của nó được hiển thị. Nếu trang không hỗ trợ một trường nào đó, hãy bỏ qua nó và yêu cầu chủ dự án làm rõ nguồn trước.
Điều này cũng giúp việc bàn giao công việc dễ dàng hơn. Một đồng nghiệp có thể theo dõi mối liên hệ giữa mỗi trường và trang thay vì phải đoán tại sao nó được thêm vào. Để biết thêm về cách tạo các trang nguồn hữu ích, hãy truy cập nội dung có thể trích dẫn cho AI assistant.
Kiểu schema nào phù hợp với các phần khác nhau của trang dự án?
Kiểu schema phù hợp phụ thuộc vào những gì một trang cụ thể đại diện. Một website dự án có thể sử dụng nhiều kiểu trên các URL khác nhau, miễn là mỗi kiểu phản ánh đúng nội dung hiển thị.
Bắt đầu với trang web và các trang của nó
Organization có thể mô tả dự án hoặc công ty đứng sau trang web. WebSite mô tả toàn bộ website, trong khi WebPage mô tả một URL riêng lẻ. Các kiểu này có thể được kết nối với nhau nếu mối quan hệ là thực tế và rõ ràng. Giữ tên và chi tiết công khai nhất quán giữa trang và markup của nó.
Chỉ thêm các kiểu dành riêng cho nội dung khi chúng phù hợp
Article có thể phù hợp với một tài nguyên biên tập có thông tin tác giả hoặc chi tiết xuất bản hiển thị. Product có thể phù hợp với một trang thực sự giới thiệu một sản phẩm. SoftwareApplication có thể phù hợp với một trang mô tả phần mềm, nếu các chi tiết được thể hiện trong markup được hỗ trợ ở đó.
Ví dụ, một trang giải thích một tính năng phần mềm có thể được xem xét để sử dụng SoftwareApplication. Nếu nó chỉ thảo luận về dự án nói chung, việc thêm kiểu đó có thể mô tả sai. Một đánh giá nhanh theo từng trang ngăn chặn việc sao chép một mẫu lên các trang không tương đồng.
Một đối tượng JSON-LD có thể nhỏ và dễ đọc. Ở đây, tên và địa chỉ chỉ mang tính minh họa, không phải là thông tin thực tế về dự án của bạn:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Example Project",
"url": "https://example.org/"
}
Sử dụng các chi tiết công khai thực tế từ trang web của bạn, sau đó kiểm tra xem trang đã hiển thị có hỗ trợ chúng không. Đối với các trang câu hỏi, tối ưu FAQ có thể giúp bạn lên kế hoạch cho các câu trả lời hiển thị trước khi xem xét markup.
Một quy trình năm bước nhẹ nhàng từ danh sách trang đến JSON-LD đã được kiểm tra
Một danh sách trang và một bước kiểm tra bằng chứng ngắn giúp việc xem xét schema dễ dàng hơn. Chúng tôi sử dụng trình tự này để giữ mỗi bản ghi được kết nối với trang mà nó mô tả.
- Chọn các URL ưu tiên. Liệt kê những trang quan trọng nhất. Ghi lại mục đích, entity chính và địa chỉ chuẩn (canonical) của mỗi trang.
- Chọn một kiểu phù hợp. Quyết định xem trang mô tả tổ chức, website, bài báo, sản phẩm, phần mềm hay một chủ đề thích hợp khác.
- Truy xuất từng thuộc tính. Ghi lại nơi khách truy cập có thể thấy thông tin đó, hoặc nguồn dự án đáng tin cậy nào xác nhận nó. Loại bỏ các trường không có hỗ trợ rõ ràng.
- Thêm JSON-LD vào trang phù hợp. Kiểm tra xem các URL của nó có trỏ đến đúng trang không và cú pháp có được phân tích cú pháp (parse) không. So sánh bản ghi với nội dung đã hiển thị.
- Xem lại sau khi chỉnh sửa. Kiểm tra lại markup liên quan khi một trang, chi tiết sản phẩm, tác giả hoặc thông tin tổ chức thay đổi.
Chúng tôi sẽ yêu cầu một biên tập viên hoặc chủ sở hữu sản phẩm xác nhận danh tính và các tuyên bố về sản phẩm trước khi xuất bản. Việc đánh giá đó sẽ phát hiện ra các tên không khớp và mô tả lỗi thời khi chúng vẫn còn dễ sửa. Giữ danh sách kiểm tra cùng với ghi chú trang, để một biên tập viên tương lai có thể lặp lại các bước kiểm tra tương tự mà không cần xây dựng lại lý do từ đầu. Nếu bạn cũng đang xem xét cách triển khai llms.txt, hãy giữ nhiệm vụ đó riêng biệt: tệp tin và markup trang thực hiện các công việc khác nhau.
Sự chuyển giao giữa structured data và các nền tảng AI
Structured data có thể làm cho các chi tiết về một trang trở nên rõ ràng hơn. Nhưng nó không thể chỉ đạo cách ChatGPT, Perplexity, Google hoặc một nền tảng khác lựa chọn hoặc trình bày thông tin. Tài liệu của Google mô tả structured data như một cách để giúp nó hiểu nội dung và đánh giá tính đủ điều kiện cho các lần hiển thị tìm kiếm được hỗ trợ. Việc một lần hiển thị có được hiển thị hay không vẫn là quyết định của Google. Không có kiểu schema nào có thể hứa hẹn một trích dẫn hoặc một câu trả lời cụ thể.
Ranh giới đó mang lại cho nhóm bạn một bài kiểm tra chất lượng hữu ích. Hãy kiểm tra xem trang có trả lời một nhu cầu thực tế của người đọc không, các tuyên bố của nó có được hỗ trợ không và markup có phản ánh nội dung hiển thị không. Nếu dữ liệu được phân tích cú pháp nhưng trang còn mơ hồ, hãy cải thiện trang trước khi thêm nhiều thuộc tính hơn. Nếu một mô tả dự án thay đổi, hãy cập nhật trang và sau đó xem xét lại bản ghi liên quan.
Giữ ghi chú về những gì bạn đã thay đổi và tại sao. Bằng cách đó, người tiếp theo có thể biết liệu một trường đại diện cho một chi tiết trang thực tế hay một giả định cũ. Khi bạn so sánh những gì ChatGPT và Perplexity hiển thị, hãy ghi lại những gì mỗi nền tảng thực sự hiển thị. Đừng coi markup là nguyên nhân của một đề cập hoặc thiếu sót. Hướng dẫn của chúng tôi về khả năng hiển thị trên AI search bao gồm bức tranh xuất bản rộng hơn.
Giữ một bản ghi nhỏ để nhóm bạn có thể xem lại
Một bản ghi đánh giá nhỏ gọn giúp nhóm bạn tách biệt các thông tin trang, kiểm tra markup và quan sát khả năng hiển thị. Nó cũng làm cho lần cập nhật nội dung tiếp theo ít có khả năng để lại các chi tiết cũ hơn.
Đối với mỗi URL ưu tiên, hãy ghi lại kiểu dự định, địa chỉ chuẩn, lần đánh giá cuối cùng và trạng thái xác thực. Thêm một ghi chú ngắn khi trang thay đổi theo cách có thể ảnh hưởng đến structured data của nó. Sau đó, giữ các quan sát về nền tảng ở một nơi riêng biệt: ghi lại câu hỏi đã kiểm tra, nền tảng, ngày kiểm tra và những gì nó hiển thị. Những ghi chú này mô tả những gì nhóm bạn đã thấy; chúng không thiết lập lý do tại sao một nền tảng chọn một nguồn cụ thể.
Sử dụng một bộ nhỏ các câu hỏi mà khách truy cập thực tế có thể hỏi về dự án. Lặp lại chúng khi bạn xem xét trang và so sánh câu trả lời với những gì trang đã xuất bản nói. Nếu một câu trả lời thiếu một chi tiết quan trọng, hãy kiểm tra cách diễn đạt và thông tin nguồn trước khi thay đổi schema. Điều này giữ cho công việc dựa trên nội dung mà mọi người có thể xác minh.
Nếu bạn muốn một đánh giá kỹ thuật rộng hơn, llms.txt và thiết lập AI crawler giải thích một phần riêng biệt của công việc đó. Để bắt đầu đánh giá của riêng bạn, hãy thu thập một vài URL ưu tiên, các câu hỏi mà khán giả của bạn hỏi và bất kỳ bản xuất schema hiện có nào. Chúng tôi có thể giúp kiểm tra sự khớp giữa trang và markup và trả lại các chỉnh sửa rõ ràng cho nhóm bạn.
Cách hoạt động
- Liệt kê các trang ưu tiênGhi lại mục đích, entity chính và địa chỉ chuẩn của mỗi URL.
- Chọn kiểu trangChọn các kiểu mô tả đúng mục đích hiển thị của mỗi trang.
- Truy xuất thông tinKết nối mỗi thuộc tính với nội dung hiển thị hoặc một nguồn dự án đáng tin cậy.
- Thêm và kiểm tra JSON-LDĐặt nó trên trang mà nó mô tả, kiểm tra cú pháp và so sánh thông tin của nó với trang đã hiển thị.
- Xem lại sau khi chỉnh sửaKiểm tra lại markup khi nội dung trang liên quan hoặc chi tiết dự án thay đổi.
Câu hỏi thường gặp
Schema markup có thể giúp ChatGPT hoặc Perplexity đề cập đến một dự án không?
Schema có thể mô tả chi tiết trang một cách có cấu trúc, nhưng ChatGPT và Perplexity quyết định những gì chúng hiển thị và trích dẫn. Hãy kiểm tra xem trang có trả lời một câu hỏi rõ ràng của người đọc không và các thông tin được đánh dấu có khớp với văn bản hiển thị không. Khi bạn xem xét một kết quả, hãy lưu lại câu hỏi và nền tảng để nhóm bạn có thể lặp lại quan sát.
Một website dự án nên bắt đầu với những kiểu schema nào?
Hãy bắt đầu với những trang bạn có và những gì mỗi trang thực sự nói. Organization có thể mô tả dự án, trong khi WebSite và WebPage mô tả trang web và một URL riêng lẻ. Article, Product hoặc SoftwareApplication có thể phù hợp với các trang cụ thể khi các chi tiết hiển thị của chúng hỗ trợ các kiểu đó.
Tôi có cần cả llms.txt và schema.org markup không?
Không nhất thiết. Schema.org mô tả nội dung trang và entity trong structured data; llms.txt là một quy ước tệp văn bản được đề xuất để trỏ đến các tài nguyên trang web đã chọn. Hãy quyết định xem mỗi công cụ có giúp ích cho một nhu cầu riêng biệt không và chỉ giữ thông tin cập nhật nếu nhóm bạn có thể duy trì nó.
Làm thế nào để kiểm tra một ví dụ JSON-LD với trang của tôi?
Hãy kiểm tra xem cú pháp có được phân tích cú pháp không, kiểu có phù hợp với trang không và mỗi thuộc tính có hỗ trợ hiển thị hoặc đáng tin cậy không. So sánh tên, URL và mô tả với trang đã hiển thị trước khi xuất bản. Một người đánh giá thứ hai có thể xác nhận các chi tiết như quyền tác giả hoặc thông tin sản phẩm khi những thông tin đó không rõ ràng.
Có phải mọi trang có câu hỏi đều nên sử dụng markup FAQPage không?
Không. Chỉ sử dụng một kiểu khi nó mô tả chính xác trang và tuân theo các yêu cầu tài liệu của nền tảng liên quan. Một trang vẫn có thể trả lời các câu hỏi phổ biến một cách rõ ràng mà không cần markup FAQPage. Bước kiểm tra chính là liệu khách truy cập có thể tìm thấy câu trả lời được thể hiện trong dữ liệu hay không.
Nhóm của tôi nên xem xét lại schema markup bao lâu một lần?
Hãy xem xét nó khi trang hoặc các chi tiết mà nó mô tả thay đổi. Ví dụ, một mô tả sản phẩm đã sửa đổi hoặc tên tổ chức nên thúc đẩy việc kiểm tra bản ghi liên quan. Việc giữ URL, kiểu dự định và lần đánh giá cuối cùng trong một ghi chú ngắn sẽ giúp việc kiểm tra đó dễ lặp lại hơn.
Kể cho chúng tôi về dự án của bạn
Trả lời bốn câu hỏi nhanh và quản lý sẽ gửi kế hoạch, thời gian và mức giá trong vòng một giờ. Mọi thứ được bảo mật.
Đang tải biểu mẫu…