Cập nhật lần cuối:

Tối ưu hóa văn bản OGP - Cải thiện hiển thị chia sẻ mạng xã hội

13 phút đọc

Open Graph Protocol (OGP) kiểm soát cách các trang web của bạn hiển thị khi được chia sẻ trên mạng xã hội. Được Facebook giới thiệu năm 2010, OGP là một bộ từ vựng siêu dữ liệu dựa trên RDFa và tính đến tháng 8 năm 2026 vẫn được các mạng xã hội cùng ứng dụng nhắn tin lớn sử dụng rộng rãi. Nếu không cấu hình đúng cách, tiêu đề sẽ bị cắt ngắn và một đoạn mô tả không mong muốn xuất hiện, khiến liên kết mất đi sức hấp dẫn. Hướng dẫn này bao gồm cách viết văn bản OGP sao cho vẫn truyền đạt được ý dù bị cắt ngắn, và cách tự kiểm tra bản xem trước trước khi công bố.

Đặc tả và lịch sử OGP

OGP được Facebook tạo ra vào năm 2010 để chuẩn hóa cách các trang web được hiển thị trong bảng tin mạng xã hội. Đặc tả được công bố tại ogp.me định nghĩa bốn thuộc tính bắt buộc: og:title, og:type, og:image và og:url. Chúng được đặt dưới dạng thẻ <meta property="og:..."> trong phần tử <head> của HTML.

Một điểm cần nắm rõ ngay từ đầu: ogp.me chỉ quy định cách viết các thẻ này, chứ không định nghĩa bất kỳ giới hạn số ký tự nào. Đặc tả chỉ nói og:description nên là một đến hai câu mô tả trang. Vì vậy mọi con số làm mốc được nhắc đến ở phần sau đều không phải đặc tả, mà là giá trị thực dụng suy ra từ cách các nền tảng hiển thị.

Trước khi có OGP, các nền tảng mạng xã hội thu thập thẻ <title> và <meta name="description"> để tạo bản xem trước liên kết. Tuy nhiên, các phần tử này được tối ưu hóa cho công cụ tìm kiếm và thường tạo ra bản xem trước khó đọc hoặc quá dài trong bảng tin mạng xã hội. OGP đã giải quyết vấn đề này bằng cách cung cấp một lớp siêu dữ liệu riêng dành cho việc chia sẻ trên mạng xã hội.

Tại sao không có con số chính thức về số ký tự hiển thị

Câu hỏi thường gặp nhất là "bao nhiêu ký tự thì không bị cắt". Không nền tảng nào công bố một con số chính thức, và điều đó có lý do: phần bị cắt không được quyết định theo số ký tự mà theo số dòng vừa với khung thẻ. Cùng một og:title sẽ chiếm số dòng khác nhau tùy chiều rộng màn hình, phông chữ mà ứng dụng sử dụng, cỡ chữ người dùng tự đặt trong hệ điều hành, và loại thẻ đang hiển thị (thẻ nhỏ hay thẻ có ảnh lớn). Ngay trong cùng một dòng, chữ rộng như "M" và chữ hẹp như "i" cũng không chiếm cùng một khoảng ngang.

Vì vậy cách làm bền vững không phải là đếm sao cho vừa một con số, mà là viết với giả định rằng câu sẽ bị cắt. Hãy đặt thông tin quyết định việc nhấp chuột lên đầu, và bảo đảm câu vẫn còn nghĩa khi phần đuôi biến mất. Những con số làm mốc ở các phần sau chỉ dùng để tự kiểm tra nhanh; kết luận cuối cùng luôn đến từ việc xem bản xem trước thật.

Thiết kế thứ tự từ để câu vẫn đứng vững khi bị cắt

Trong tiếng Việt, phần bổ nghĩa thường đứng sau danh từ chính, nên chính những chi tiết giới hạn phạm vi lại nằm ở đuôi câu và dễ mất đi trước tiên. Một tiêu đề như "Cách xử lý lỗi hiển thị khi chia sẻ trang lên mạng xã hội dành cho người mới" khi bị cắt ở giữa sẽ chỉ còn lại một mệnh đề chung chung, không cho người đọc biết bài viết dành cho ai.

Cách viết an toàn hơn là dồn từ khóa và con số ra phía trước, rồi tách phần bổ nghĩa bằng dấu gạch dọc: "5 cách xử lý lỗi hiển thị OGP | dành cho người mới". Kiểu này vẫn đọc được ngay cả khi phần sau dấu gạch dọc biến mất, vì cụm mang thông tin đã nằm trọn ở đầu. Con số cụ thể có tác dụng không phải vì bản thân con số hấp dẫn, mà vì nó cho biết trước quy mô nội dung nên người đọc đoán được mình sẽ nhận gì. Tiêu đề dạng câu hỏi cũng vậy: nó chỉ hiệu quả khi câu hỏi trùng với điều người đọc đang thực sự vướng, chứ không phải vì có dấu hỏi.

Về mốc tham chiếu: giữ og:title trong khoảng 40 ký tự và og:description trong khoảng 70-100 ký tự thì ở phần lớn môi trường, phần mang thông tin chính vẫn đọc được. Hãy coi đây không phải là giới hạn được nền tảng bảo đảm, mà là giá trị thực dụng đã trừ sẵn phần dư với giả định câu sẽ bị cắt.

Tối ưu hóa og:title

Hành vi khi og:title và HTML Title không khớp

og:title và thẻ HTML <title> là các phần tử độc lập có thể có giá trị khác nhau. Trình thu thập dữ liệu của nền tảng ưu tiên og:title, nhưng sẽ sử dụng thẻ <title> khi og:title không được đặt.

Tuy nhiên, hãy cẩn thận khi hai giá trị này khác nhau đáng kể. Tài liệu của Google về liên kết tiêu đề nêu rõ og:title là một trong những nguồn mà Google có thể dùng để tạo tiêu đề trên trang kết quả tìm kiếm. Nghĩa là nội dung bạn viết riêng cho mạng xã hội vẫn có khả năng xuất hiện trong kết quả tìm kiếm. Cách tiếp cận hợp lý là tối ưu thẻ title cho từ khóa và og:title cho ngữ cảnh chia sẻ, đồng thời giữ cả hai cùng hướng về một chủ đề cốt lõi.

Cũng cần phân biệt hai hiện tượng thường bị gộp làm một. Google có thể viết lại tiêu đề khi tiêu đề gốc bỏ trống hoặc gần như trống, khi nó không khớp với nội dung trang, khi chứa năm cũ đã lạc hậu, khi nhiều trang dùng chung một khuôn mẫu giống nhau, khi không nêu rõ tiêu đề chính của trang, hoặc khi ngôn ngữ của tiêu đề khác ngôn ngữ nội dung. Trong danh sách lý do đó không có việc tiêu đề vượt quá một số ký tự nào. Còn việc một tiêu đề dài bị hiển thị ngắn lại chỉ là cắt ngắn khi trình bày, hoàn toàn khác với việc bị viết lại: bản thân tiêu đề vẫn giữ nguyên.

Viết og:description

Giữ og:description trong khoảng 70-100 ký tự. Đặt thông tin quan trọng nhất trong 40 ký tự đầu tiên để việc cắt ngắn không làm mất ý nghĩa. Bạn có thể sử dụng cùng nội dung với meta description, nhưng hãy cân nhắc sử dụng ngôn ngữ thân thiện hơn phù hợp với đối tượng mạng xã hội.

Hành vi dự phòng của og:description

Khi og:description không được đặt, mỗi nền tảng sử dụng logic dự phòng riêng. Facebook đọc <meta name="description">, và nếu cũng không có, nó tự động trích xuất văn bản từ nội dung trang. X (Twitter) ưu tiên các thẻ họ twitter: và chuyển sang các thẻ họ og: khi chúng không được đặt; nếu không có thuộc tính nào, nội dung xem trước cũng được lấy từ văn bản trong trang.

Văn bản được trích xuất tự động thường bao gồm menu điều hướng và nội dung thanh bên, dẫn đến bản xem trước không mong muốn. Luôn đặt og:description một cách rõ ràng. Sử dụng Bộ đếm ký tự để kiểm tra độ dài og:title và og:description có nằm trong các mốc thực dụng hay không.

Hướng dẫn hình ảnh OGP

Trong số các nền tảng, Facebook là nơi công bố con số rõ ràng nhất. Tài liệu dành cho webmaster của Facebook nêu kích thước tối thiểu 200×200 pixel, khuyến nghị từ 1200×630 pixel trở lên, riêng dạng thẻ ảnh lớn cần ít nhất 600×315 pixel, tỷ lệ khung hình 1,91:1 và dung lượng không quá 8 MB. Đây là bộ số đáng lấy làm chuẩn khi bạn chỉ muốn chuẩn bị một tấm ảnh duy nhất dùng cho mọi nơi.

Bảng dưới đây tổng hợp thêm các nền tảng khác để tiện tra cứu. Cần lưu ý rằng ngoài dòng Facebook, một số giá trị không được nền tảng công bố dưới dạng con số chính thức, mà là giá trị thực dụng được dùng phổ biến tại thời điểm tháng 8 năm 2026.

Nền tảngKích thước tối thiểuKích thước khuyến nghịTỷ lệ khung hình
Facebook200×200px1200×630px1,91:1
X (Twitter)144×144px (tóm tắt) / 300×157px (lớn)1200×628px1,91:1
LinkedIn200×200px1200×627px1,91:1
Slack250×250px1200×630px1,91:1

Hành vi crawler của nền tảng

Trình thu thập dữ liệu OGP của mỗi nền tảng hoạt động khác nhau. Trình thu thập của Facebook (facebookexternalhit) không thực thi JavaScript, điều này có nghĩa là các trang web được render phía client (CSR) tạo thẻ OGP động sẽ không cung cấp được siêu dữ liệu đúng cách.

Twitterbot của X và trình thu thập của LINE cũng chỉ phân tích HTML tĩnh. Slackbot của Slack có theo chuyển hướng, nhưng cũng không thực thi JavaScript. Vì các trình thu thập này chỉ đọc những gì máy chủ trả về ngay ở lần truy cập đầu tiên, hãy đảm bảo thẻ OGP đã có sẵn trong HTML được trả về tức thì, thay vì được bổ sung sau đó.

Nếu bạn đang sử dụng các framework SPA như React hoặc Vue.js, thẻ OGP phải được xuất thông qua render phía server (SSR) hoặc tạo trang tĩnh (SSG). generateMetadata của Next.js và useHead của Nuxt cung cấp các cách tích hợp sẵn trong framework để xuất thẻ OGP chính xác.

Cơ chế cache OGP và phương pháp cập nhật

Mỗi nền tảng lưu cache thông tin OGP, vì vậy việc cập nhật thẻ OGP sẽ không được phản ánh ngay lập tức. Tính đến tháng 8 năm 2026, không nền tảng nào trong số này công bố thời gian lưu cache dưới dạng con số chính thức, nên chờ cho cache hết hạn là một cách làm không thể dự đoán được. Cách phân loại hữu ích hơn là xét xem nền tảng có cung cấp phương tiện cập nhật tường minh hay không:

Kết luận thực dụng rút ra từ đây rất đơn giản: vì bạn không kiểm soát được thời điểm bản sửa được phản ánh, hãy tự chia sẻ URL cho chính mình và xem bản xem trước trước khi phát URL đó cho người khác. Sửa sau khi liên kết đã lan đi luôn đắt hơn nhiều so với kiểm tra một lần trước khi công bố.

Gỡ lỗi và xác thực

Luôn xác minh cài đặt OGP bằng công cụ gỡ lỗi của nền tảng trước khi xuất bản. Các lỗi cấu hình không được phát hiện sẽ lan truyền hiển thị không mong muốn mỗi khi trang được chia sẻ.

Gộp các bước kiểm tra trước khi công bố thành một quy trình sẽ giảm được sai sót. Cách làm cơ bản gồm hai lớp: dùng Bộ đếm ký tự để kiểm tra độ dài og:title và og:description, rồi xem cách thẻ hiện ra bằng công cụ gỡ lỗi hoặc bằng một bài đăng nháp.

Cấu hình OGP theo CMS

Các nền tảng CMS và framework chính đều có cách tiếp cận riêng để cấu hình OGP:

Cạm bẫy khi tạo OGP động

Khi tạo thẻ OGP động dựa trên đầu vào của người dùng hoặc giá trị cơ sở dữ liệu, có một số cạm bẫy cần chú ý.

Đầu tiên, việc escape HTML là thiết yếu. Nếu og:title hoặc og:description bao gồm đầu vào của người dùng, việc không escape <, >, & và " sẽ tạo ra lỗ hổng HTML injection.

Thứ hai, khi tạo og:image động (ví dụ: thông qua Vercel OG Image Generation hoặc biến đổi Cloudinary), việc tạo hình ảnh chậm có thể khiến trình thu thập bỏ dở việc lấy ảnh. Các trình thu thập không chờ lâu như một người dùng thật, nên hãy dựng sao cho lần truy cập đầu tiên đã trả về ảnh ngay: tạo và lưu cache ảnh trước, hoặc phục vụ qua CDN.

Thứ ba, khi URL chứa tham số truy vấn hoặc fragment, hãy đặt og:url thành URL canonical (không có tham số truy vấn). Điều này ngăn số lượt chia sẻ bị phân tán giữa các biến thể URL khác nhau của cùng một nội dung.

Thứ thay đổi không phải đặc tả mà là phía hiển thị

Nhiều người cho rằng OGP là một đặc tả liên tục được sửa đổi, nên phải theo dõi thường xuyên. Thực tế thì bốn thuộc tính bắt buộc do ogp.me định nghĩa vẫn giữ nguyên cấu trúc, và cách viết thẻ cũng không đổi. Thứ thay đổi theo thời gian là phía hiển thị: hình dạng thẻ trên bảng tin và kích thước ảnh mà từng nền tảng khuyến nghị. Phân biệt được hai lớp này giúp bạn xác định thứ tự ưu tiên khi bảo trì: phần đánh dấu trong <head> gần như viết một lần là xong, còn ảnh và bố cục ảnh mới là phần cần xem lại định kỳ.

X (trước đây là Twitter) duy trì các thẻ meta Twitter Card riêng (twitter:card, twitter:title, v.v.), nhưng sử dụng thẻ OGP dự phòng khi thẻ Twitter Card không được đặt. Điều này có nghĩa là thẻ OGP được cấu hình đúng cách cung cấp phạm vi hiển thị cơ bản ngay cả khi không có thẻ Twitter Card. Tuy nhiên, thẻ twitter:card không có tương đương OGP và phải được đặt rõ ràng.

Các lỗi thường gặp

Kỹ thuật OGP chuyên nghiệp

Kết luận

Có hai điểm cần nắm khi tối ưu hóa văn bản OGP. Thứ nhất, đặc tả tại ogp.me không định nghĩa giới hạn số ký tự nào, và các nền tảng cũng không công bố chính thức số ký tự hiển thị. Vì vậy không thể thiết kế theo lối "bao nhiêu ký tự thì không bị cắt". Hãy lấy các mốc thực dụng - khoảng 40 ký tự cho og:title và khoảng 70-100 ký tự cho og:description - rồi sắp thứ tự từ sao cho chủ đề vẫn còn nguyên dù bị cắt ở bất cứ đâu. Thứ hai, thẻ OGP độc lập với thẻ title HTML và meta description, nên bạn có thể viết khác nhau cho kết quả tìm kiếm và cho bảng tin mạng xã hội. Vì thời điểm bản sửa được phản ánh là điều bạn không kiểm soát được, hãy tự chia sẻ URL cho chính mình và xem bản xem trước trước khi phát URL đó ra. Dùng Bộ đếm ký tự để kiểm tra trước độ dài og:title và og:description, bạn sẽ tránh được việc công bố khi văn bản đã vượt quá mốc quá nhiều.

Chia sẻ bài viết này

Độ dài bài blog tối ưu cho SEO

Độ dài bài blog lý tưởng cho SEO và khả năng đọc. Hướng dẫn số từ theo thể loại, kỹ thuật mở rộng nội dung tự nhiên và cân bằng chất lượng.