Bản đồ schema.org cho trang web AI Search rõ ràng hơn

Cần ghi lại điều gì trước khi chọn loại schema?

Một bảng kiểm kê URL cho thấy trang nào cần mô tả có cấu trúc và chúng hỗ trợ thông tin nào. Bắt đầu với trang, không phải danh sách các loại schema. Ghi lại mục đích, entity chính, các tuyên bố hiển thị và chủ sở hữu của nó. Điều này tạo cơ sở có thể kiểm tra cho các quyết định về markup.

Đối với mỗi URL ưu tiên, hãy ghi lại:

• Mục đích trang: khách truy cập có thể học hoặc làm gì ở đó.
• Entity chính: tổ chức, cá nhân, sản phẩm hoặc bài viết được mô tả.
• Bằng chứng: mỗi giá trị được đề xuất xuất hiện ở đâu trên trang hoặc nguồn chính thức.
• Chủ sở hữu cập nhật: ai xem xét mô tả khi thông tin trang thay đổi.

Tổng quan công ty có thể mô tả một tổ chức. Trang sản phẩm nên xác định sản phẩm thực tế và các chi tiết được hỗ trợ. Trang biên tập nên xác định nội dung bài viết và tác giả của nó. Nếu trang không hiển thị một thông tin được đề xuất, đừng thêm nó vào mô tả có cấu trúc chỉ vì nó có vẻ hữu ích.

Hồ sơ này cũng giúp tách biệt việc sửa nội dung khỏi sửa markup. Thông tin bị thiếu hoặc không rõ ràng cần được biên tập trước. Thông tin đúng nhưng được thể hiện ở định dạng không nhất quán cần được xem xét triển khai. Để có thêm hướng dẫn cấp trang, hãy xem nội dung có thể trích dẫn cho AI assistant.

Loại schema.org nào phù hợp với trang mà khách truy cập thấy?

Mục đích hiển thị của trang đưa ra manh mối đầu tiên về loại schema.org của nó. Chọn một loại mô tả nội dung, sau đó chỉ bao gồm các thuộc tính được hỗ trợ bởi trang hoặc một nguồn chính thức đã xác định. Một bản đồ loại làm cho các quyết định đó có thể xem xét được trên toàn bộ trang web.

Đây là công cụ hỗ trợ lựa chọn, không phải gói bắt buộc. Một trang có thể liên quan đến một trang web và một tổ chức, nhưng mỗi mô tả cần có mục đích rõ ràng. Tránh gán loại biên tập cho một trang quảng cáo khi trang đó không chứa bài viết. Tránh thêm thuộc tính chỉ để làm cho markup dài hơn.

Xem xét định nghĩa schema.org cho các loại ứng viên trước khi xuất bản. Sau đó so sánh từng thuộc tính được đề xuất với bằng chứng trang được ghi lại trong bảng kiểm kê của bạn. Hướng dẫn AEO kỹ thuật đề cập đến schema cùng với các lĩnh vực xem xét kỹ thuật khác.

Điều gì thuộc về một ví dụ JSON-LD thực tế?

Một bản ghi JSON-LD hữu ích chứa một loại và các giá trị mà người xem xét có thể xác minh. Giữ ví dụ đủ nhỏ để so sánh với trang. Bản ghi tổ chức sau đây sử dụng các giá trị mẫu phải được thay thế trước khi xuất bản:

Ví dụ JSON-LD: {"@context":"https://schema.org","@type":"Organization","name":"Example Project","url":"https://example.org","sameAs":["https://social.example.org/project"]}

Context xác định từ vựng. Type đặt tên cho entity được mô tả. Các thuộc tính cung cấp tên, URL và tham chiếu hồ sơ của nó. Không xuất bản các URL mẫu. Chỉ thay thế chúng bằng các đích đến đã được xác minh đại diện cho cùng một tổ chức.

Sử dụng cùng cách xem xét cho các loại khác. Một bản ghi bài viết nên khớp với tiêu đề hiển thị và quyền tác giả được nêu tên. Một bản ghi sản phẩm nên mô tả sản phẩm được hiển thị trên trang đó. Nếu một thuộc tính không có bằng chứng rõ ràng, hãy bỏ qua nó cho đến khi trang hoặc một nguồn chính thức hỗ trợ nó.

Chọn một cách triển khai mà nhóm xuất bản của bạn có thể duy trì. JSON-LD có thể nằm trong template hoặc trường CMS có kiểm soát. Điều quan trọng không chỉ là vị trí. So sánh trang đã hiển thị và bản ghi có cấu trúc đã xuất bản sau khi triển khai.

Làm thế nào một nhóm có thể triển khai schema mà không làm phân tán thông tin của nó?

Một bản đồ từ trang sang thuộc tính giữ cho thông tin biên tập và các trường triển khai được kết nối. Sử dụng một chuỗi phát hành ngắn để mỗi bản ghi đã xuất bản có chủ sở hữu và một điểm xem xét. Điều này đặc biệt hữu ích khi các template tạo markup trên nhiều URL.

1. Kiểm kê các URL ưu tiên và ghi lại mục đích của mỗi trang.
2. Ánh xạ thông tin hiển thị sang một loại và thuộc tính phù hợp.
3. Thêm bản ghi thông qua trường CMS có kiểm soát hoặc template.
4. Xem xét đầu ra đã xuất bản so với trang đã hiển thị.
5. Kiểm tra lại các bản ghi bị ảnh hưởng khi tên, URL hoặc quyền sở hữu thay đổi.

Giữ một nguồn có thẩm quyền duy nhất cho các thông tin xuất hiện ở nhiều nơi. Ví dụ, sử dụng tên đã được phê duyệt và URL chính thức của tổ chức một cách nhất quán trên trang và mô tả có cấu trúc của nó. Nếu nhiều nhóm chỉnh sửa cùng một chi tiết, hãy chỉ định một chủ sở hữu nội dung và một người xem xét triển khai. Sự phân chia đó giúp xác định các giá trị lỗi thời trước khi chúng lan rộng.

Đừng coi việc cài đặt là kết thúc nhiệm vụ. Một bản phát hành trang web có thể thay đổi template, URL trang hoặc nội dung hiển thị. Thêm kiểm tra schema vào quy trình xem xét xuất bản có liên quan. Để có kế hoạch rộng hơn về markup và thiết lập AI crawler, hãy tham khảo AEO kỹ thuật.

Những bản ghi nào cho thấy liệu kiểm tra markup và khả năng hiển thị có hợp lý không?

Một bản ghi xác thực cho thấy liệu markup đã xuất bản có hiện diện, có thể đọc được và nhất quán với trang của nó hay không. Giữ kiểm tra kỹ thuật đó tách biệt với các quan sát về câu trả lời AI. Một bản ghi hợp lệ không cho thấy thông tin nào mà một answer engine cụ thể đã sử dụng.

Đối với mỗi URL được xem xét, hãy ghi lại địa chỉ trang, ngày xem xét, loại dự kiến, các thuộc tính đã kiểm tra và kết quả. Kiểm tra đầu ra đã hiển thị cũng như nguồn hoặc đầu ra CMS. Tìm kiếm các bản ghi trùng lặp từ plugin và template. So sánh tên, URL, quyền tác giả và các thông tin được đánh dấu khác với nội dung dành cho khách truy cập.

Để có một quan sát câu trả lời có thể lặp lại, hãy xác định một giao thức nhỏ trước khi kiểm tra. Một bảng khởi đầu thực tế là 10 prompt có liên quan trên 3 answer engine, với 2 lần chạy mỗi prompt. Ghi lại prompt, engine, ngày, câu trả lời, các nguồn được trích dẫn và liệu trang hoặc tổ chức có xuất hiện hay không. Đây là các trường quan sát, không phải bằng chứng về lý do câu trả lời xuất hiện.

Giữ cách diễn đạt prompt ổn định khi so sánh các vòng xem xét. Lưu văn bản câu trả lời hoặc một bản chụp đáng tin cậy cùng với bản ghi. Tách biệt các thay đổi đối với nội dung trang khỏi các thay đổi trong câu trả lời được quan sát. Điều này làm cho việc xem xét sau này hữu ích hơn một tìm kiếm không chính thức duy nhất. Xem tối ưu FAQ để căn chỉnh câu trả lời hiển thị với câu hỏi của người đọc.

LLMs.txt so với schema.org: tệp nào giải quyết vấn đề nào?

Schema.org mô tả các entity và nội dung trang thông qua các thuộc tính có cấu trúc. llms.txt là một quy ước tệp văn bản riêng biệt để tóm tắt tài nguyên trang web. Chúng là các artifact khác nhau, vì vậy cái này không thay thế cái kia hoặc chính nội dung trang.

Sử dụng bảng kiểm kê trang để xác định vấn đề trước. Nếu entity hoặc mối quan hệ của trang không rõ ràng, hãy xem xét nội dung hiển thị của nó và xem xét structured data chính xác. Nếu bạn đang đánh giá một tệp llms.txt, hãy xem xét các bản tóm tắt và liên kết của nó như một nhiệm vụ xuất bản riêng biệt. Giữ một chủ sở hữu cho mỗi artifact và kiểm tra nội dung của nó khi các trang liên quan thay đổi.

Tránh duy trì các phiên bản khác nhau của cùng một thông tin mà không có chủ sở hữu. Một URL hồ sơ lỗi thời trong một tệp hoặc bản ghi markup có thể xung đột với trang hiển thị. Để có thông tin nền về quy ước tệp văn bản, hãy đọc llms.txt: nó là gì và bạn có cần nó không. Để biết các cân nhắc triển khai, hãy xem llms.txt và thiết lập AI crawler.

Bản ghi schema có thể cho bạn biết điều gì về ChatGPT và Perplexity?

Một bản ghi schema cho phép bạn kiểm tra những gì một trang tuyên bố ở dạng có cấu trúc. Nó không thể tiết lộ cách ChatGPT hoặc Perplexity truy xuất, đánh giá hoặc chọn nguồn cho một câu trả lời. Quyền truy cập, xử lý và lựa chọn trích dẫn của chúng vẫn nằm ngoài tầm kiểm soát của chủ sở hữu trang web.

Sự khác biệt đó rất quan trọng khi so sánh các trích dẫn của ChatGPT và Perplexity. Một trang có thể có markup hợp lệ trong khi các quan sát câu trả lời khác nhau tùy theo engine, prompt hoặc ngày xem xét. Coi nhật ký trích dẫn là bằng chứng về những gì bạn đã quan sát, không phải bằng chứng rằng schema đã gây ra sự xuất hiện. Giữ xác thực kỹ thuật và theo dõi câu trả lời trong các bản ghi riêng biệt.

Một gói xem xét hữu ích chứa bảng kiểm kê URL, bản đồ trang sang loại, ví dụ JSON-LD, ghi chú xác thực và nhật ký quan sát câu trả lời. Sử dụng nó để xác định các hành động tiếp theo cụ thể: sửa một thuộc tính lỗi thời, làm rõ nội dung hiển thị hoặc lặp lại một kiểm tra prompt ổn định. Đừng thêm một loại chỉ vì một câu trả lời không trích dẫn một trang.

Để bắt đầu, hãy thu thập 3 đến 5 URL ưu tiên và các nguồn chính thức xác nhận thông tin chính của chúng. Chúng tôi có thể xem xét bản đồ trang, gắn cờ các thuộc tính không được hỗ trợ và trả lại một danh sách kiểm tra triển khai tập trung cho nhóm xuất bản của bạn.

Cách hoạt động

1. Liệt kê các URL ưu tiênGhi lại mục đích, entity chính và chủ sở hữu nội dung của mỗi trang. Bắt đầu với các trang giải thích về tổ chức, sản phẩm hoặc công việc biên tập.
2. Ánh xạ thông tin sang loạiChọn các loại schema.org phù hợp. Liên kết mỗi thuộc tính được đề xuất với nội dung trang hiển thị hoặc một nguồn chính thức.
3. Chuẩn bị markupThêm các thuộc tính được hỗ trợ thông qua trường CMS có kiểm soát hoặc template. Giữ một người xem xét chịu trách nhiệm kiểm tra các thay đổi.
4. Kiểm tra đầu ra đã xuất bảnSo sánh markup với trang đã hiển thị. Ghi lại URL, loại, các thuộc tính đã xem xét và kết quả xác thực.
5. Ghi nhật ký quan sát câu trả lờiSử dụng các prompt ổn định và ghi lại engine, ngày, câu trả lời và các nguồn được trích dẫn. Giữ nhật ký này riêng biệt với kiểm tra cú pháp.