Ảnh Open Graph: kích thước, định dạng và lý do ảnh của bạn không hiển thị

Bạn chia sẻ liên kết, nhưng thay vì ảnh đã chọn kỹ, nền tảng hiện thẻ trống, phần cắt bị kéo giãn hoặc ảnh từ ba lần triển khai trước. Hầu như mọi biến thể của vấn đề này đều bắt nguồn từ một vài nguyên nhân cụ thể có thể kiểm tra — sai kích thước, định dạng không hỗ trợ, URL tương đối hoặc bộ nhớ đệm chưa nhận ra tệp đã đổi.

Chuẩn 1200×630 và lý do

Chuẩn thực tế og:image kích thước là 1200×630 pixel, tỷ lệ khung hình khoảng 1,91:1. Con số này không phải một quy ước tùy ý: nó gần với tỷ lệ rộng nhất mà hầu hết thẻ xem trước liên kết hiển thị trên Facebook, LinkedIn, Slack và Discord, nên ảnh 1200×630 lấp đầy thẻ mà nền tảng không cần thêm dải trống hoặc cắt đáng kể.

Ảnh nhỏ vẫn dùng được nhưng bị nền tảng phóng đầy thẻ, làm mềm chi tiết và xấu rõ so với ảnh chuẩn bị riêng. Đa số nền tảng nêu tối thiểu khoảng 200×200 để chấp nhận xem trước, nhưng đó là sàn, không mục tiêu; thấp đáng kể dưới 1200×630 chỉ mất chất lượng mà không lợi ích.

Của Twitter/X summary_large_image thẻ dùng cùng ảnh 1200×630 và cùng tỷ lệ khung hình, nên một ảnh thường phục vụ cả hai og:image và twitter:image mà không cần bản xuất riêng.

Vùng an toàn: phần thực sự còn sau cắt

Ngay ở đúng tỷ lệ, nền tảng khác cắt thẻ hơi khác theo vị trí: bài bảng tin, xem trước liên kết tin nhắn và mục liên kết chia sẻ thanh bên không luôn cùng vùng cắt. Chữ hoặc logo sát cạnh có thể bị cắt ở một nơi dù trông tốt trong thẻ xem trước của bạn.

An toàn là để tiêu đề, logo, mặt trong khoảng 90% bên trong, chừa 5–10% mỗi mép. Nền, gradient, trang trí có thể tràn hết; chỉ phần mọi người cần thấy phải lùi. Nếu công cụ hỗ trợ, vẽ hướng dẫn lùi 60px mỗi cạnh canvas 1200×630 cho vùng an toàn hợp lý.

Thẻ 1200 × 630 có vùng an toàn bên trong nét đứt, được bao quanh bởi ba bản xem trước mô phỏng mang nhãn Slack, X/Twitter và Facebook, mỗi bản cắt thẻ khác nhau
Một ảnh, ba cách cắt. Không có gì ngoài vùng nét đứt được bảo đảm giữ lại, vì vậy tiêu đề nên nằm sâu bên trong chứ không sát cạnh.

Định dạng: JPG hoặc PNG, và vì sao không WebP

Với tệp ảnh thực, JPG và PNG an toàn. Hỗ trợ WebP cho og:image cụ thể không được hỗ trợ nhất quán giữa trình thu thập và bot tạo bản xem trước liên kết — một số hỗ trợ, một số âm thầm không hiển thị bản xem trước khi nhận WebP, và vì lỗi không báo ra, bạn dễ phát hành bản xem trước hỏng mà không nhận ra cho đến khi ai đó chỉ.

Yêu cầu tương thích hẹp hơn WebP cho trình duyệt, gần mọi trình hiện hỗ trợ tốt; xem So sánh WebP, PNG và JPG cho trường hợp chung. Trình thu thập bản xem trước liên kết là nhóm máy khách khác, thận trọng hơn trình duyệt của người dùng, và khả năng hỗ trợ WebP chậm hơn. Dùng JPG cho ảnh chụp xem trước (tệp nhỏ hơn ở chất lượng hình ảnh tương đương) và PNG khi ảnh có màu phẳng, chữ hoặc cần giữ trong suốt trong một số ngữ cảnh — dù độ trong suốt không có ý nghĩa với ảnh OG, vì nó luôn hiển thị trên nền mà thẻ của nền tảng sử dụng.

GIF được hầu hết nền tảng chấp nhận kỹ thuật như ảnh tĩnh nhưng không hợp lý cho xem trước ảnh chụp hoặc thiết kế nặng; không có lý do thực tế dùng thay JPG/PNG ở đây.

URL phải tuyệt đối

<meta property="og:image" content="/og-image.jpg" /> trông hợp lý và hoạt động tốt khi xem trang trực tiếp trong trình duyệt, vì trình duyệt phân giải đường dẫn tương đối theo URL của trang hiện tại. Trình thu thập bản xem trước liên kết thường không thực hiện cùng việc phân giải một cách đáng tin cậy, hoặc phân giải theo cơ sở sai — kết quả thực tế là ảnh hỏng hoặc không có ảnh trên một số nền tảng nhưng vẫn hoạt động trên nền tảng khác, khiến khó chẩn đoán lỗi chỉ từ báo cáo người dùng.

Luôn ghi URL tuyệt đối đầy đủ, gồm giao thức và tên miền:

<meta property="og:image" content="https://example.com/og-image.jpg" />

Trong Metadata API Next.js, nghĩa là đặt metadataBase trong bố cục gốc để đường dẫn ảnh tương đối khai báo trong siêu dữ liệu từng trang tự động được phân giải thành URL tuyệt đối khi dựng, hoặc viết URL đầy đủ trực tiếp trong openGraph.images mục như trang này làm.

Cache: vì sao ảnh đã sửa vẫn hiện bản xem trước cũ

Nguồn phổ biến nhất “sửa vẫn sai”. Nền tảng cache Open Graph cả ảnh theo URL, không hết hạn chỉ vì deploy mới. Tự tải lại kể cả cửa sổ riêng không cho biết cache nền tảng giữ gì.

Mỗi nền tảng lớn có công cụ riêng buộc quét lại:

  • Facebook / Meta: Sharing Debugger (developers.facebook.com/tools/debug/) — dán URL rồi nhấn “Scrape Again”. Việc này cũng xóa bộ nhớ đệm cho bản xem trước liên kết Instagram và WhatsApp, vốn dùng chung trình thu thập Meta.
  • X/Twitter: Card Validator trước đây phục vụ mục đích này; tính khả dụng đã thay đổi theo thời gian, nên nếu không truy cập được, thêm chuỗi truy vấn phiên bản vô hại vào URL (xem dưới) là phương án dự phòng đáng tin cậy hơn.
  • LinkedIn: Post Inspector (linkedin.com/post-inspector/) — dán URL để buộc lấy lại.
  • Slack, Discord, iMessage: không có trình gỡ lỗi công khai. Chúng thường tự hết hạn bộ nhớ đệm sau một thời gian theo lịch riêng, hoặc làm mới khi URL thay đổi dù chỉ một chút.

Khi không có trình gỡ lỗi riêng của nền tảng hoặc bản thân nó cũng không hoạt động như mong đợi, cách khắc phục chung là thay đổi URL mà nền tảng nhìn thấy — thêm chuỗi truy vấn phiên bản như ?v=2 vào liên kết chia sẻ hoặc chính URL ảnh sẽ buộc mọi nền tảng coi đó là tài nguyên chưa thấy và lấy lại thay vì cung cấp bản bộ nhớ đệm cũ.

Chẩn đoán thứ crawler thực nhận, không phải trình duyệt hiển thị. Dùng curl với user agent chung hoặc công cụ debug chính thức từng nền tảng phản ánh crawler thấy gì; trình duyệt áp dụng kết xuất phía khách và cache riêng có thể che phản hồi máy chủ thật.

Dung lượng và giới hạn khác

Phần lớn nền tảng ghi trần ảnh vài megabyte: Facebook từng khoảng 8 MB, nền tảng không ghi số vẫn thường hết thời gian hoặc không xem tệp quá lớn. JPG/PNG 1200×630 nén tốt kiểu nội dung này thường dưới 500 KB, nên chạm giới hạn gần luôn là xuất chưa tối ưu: ảnh nguồn lớn thu bằng markup nhưng chưa mã hóa ở kích thước nhỏ, hoặc ảnh chụp PNG thay JPG. Xem hướng dẫn giảm dung lượng tệp ảnh để xem cách chung giảm dung lượng bản xuất mà không giảm chất lượng nhìn thấy được.

Độ đọc được của chữ ở cỡ ảnh thu nhỏ

Ảnh OG thường hiển thị nhỏ hơn nhiều so với 1200×630 pixel gốc: bản xem trước Slack hoặc thẻ bảng tin di động có thể chỉ rộng vài trăm pixel. Chữ nằm trong ảnh phải đọc được sau khi giảm. Theo hướng dẫn thực tế, chữ thân bài dưới khoảng 40 px ở chiều rộng gốc 1200 px thường mờ khó đọc khi thu cho vị trí bảng tin thông thường; tiêu đề cần đọc ở kích thước thu nhỏ thường phải lớn hơn đáng kể, khoảng 60–80 px hoặc hơn, đậm và tương phản mạnh với nền.

Cũng là lý do giữ ảnh đơn giản. Nhiều chữ cạnh tranh đọc được lớn nhưng nhiễu ở thẻ. Một tiêu đề rõ trên nền tương phản đọc ổn mọi bề mặt.

twitter:card cần khai báo riêng

Thiết lập og:image không tự động đủ cho bản xem trước ảnh lớn trên X/Twitter. Hệ thống thẻ Twitter đọc twitter:card thẻ meta để quyết định kiểu thẻ, và nếu không có nó, một số ứng dụng Twitter dùng thẻ hình thu nhỏ nhỏ hơn dù một og:image hiện diện.

Khai báo rõ:

<meta name="twitter:card" content="summary_large_image" />

Twitter sẽ dùng thay og:image cho ảnh thực tế nếu twitter:image không được đặt riêng, nên thường bạn không cần lặp URL ảnh — nhưng khai báo loại thẻ không phải tùy chọn nếu muốn bố cục ảnh lớn.

Thứ tự chẩn đoán nhanh

  1. Xác nhận URL ảnh tuyệt đối, không tương đối, và tải trực tiếp trong trình duyệt.
  2. Xác nhận định dạng là JPG hoặc PNG, không phải WebP.
  3. Xác nhận kích thước đúng hoặc gần 1200×630.
  4. Xác nhận twitter:card được đặt nếu riêng bản xem trước Twitter/X bị sai.
  5. Chạy trình gỡ lỗi của nền tảng để buộc lấy lại dữ liệu trước khi cho rằng sửa chưa hiệu quả.
  6. Nếu không có debug, tăng chuỗi phiên bản URL để bỏ cache.

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

Tôi có thể dùng ảnh khác nhau cho Facebook và Twitter/X không?

Có — đặt twitter:image thành URL khác với og:image nếu muốn hình riêng theo nền tảng. Phần lớn trang không cần, vì cả hai nền tảng dùng cùng tỷ lệ 1200×630 và một ảnh phục vụ tốt cả hai.

Ảnh dùng Facebook nhưng không trong WhatsApp. Vì sao?

Bản xem trước liên kết WhatsApp và Instagram sử dụng hạ tầng trình thu thập dữ liệu của Meta, nên thu thập lại qua Sharing Debugger của Facebook thường sửa được cả hai. Lỗi kéo dài chỉ trên WhatsApp thường do robots.txt hoặc phản hồi máy chủ chặn user agent của trình thu thập cụ thể đó hơn là do ảnh.

Ảnh cần văn bản thay thế không?

Một số nền tảng hỗ trợ og:image:alt để hỗ trợ khả năng tiếp cận, và việc thêm mô tả ngắn, chính xác không tốn gì. Nó không ảnh hưởng bản xem trước có hiển thị hay không, chỉ ảnh hưởng nội dung trình đọc màn hình đọc lên.

Xuất tĩnh như trang này có hợp ảnh OG từng trang không?

Có. Vì URL ảnh và siêu dữ liệu chỉ là các thẻ tĩnh được xuất khi dựng trang, một trang web xuất tĩnh có thể đặt một og:image cho mỗi trang giống trang kết xuất trên máy chủ — không có gì về ảnh OG đòi hỏi backend đang chạy.

Ảnh thẻ của bạn là WebP. Hãy sửa điều đó trước.

Lý do preview trống phổ biến nhất. Chuyển ảnh biến WebP thành JPG/PNG crawler nhận, theo bộ nếu nhiều, tô nền alpha nếu sẽ đen trong JPG. Tất cả trong trình duyệt, không tải.

Mở Chuyển đổi ảnh