Jeden obraz o wymiarach 1200 na 630 pikseli, w PNG lub JPEG, poniżej około 1 MB, z ważną treścią wewnątrz środkowych 1080 na 600. Ten plik renderuje się poprawnie na Facebooku, LinkedIn, X, Slacku, Discordzie, WhatsAppie i iMessage, co jest całą odpowiedzią na pytanie o rozmiar obrazu Open Graph dla niemal każdej strony.
Wymiary to łatwa część. Zazwyczaj też nie one się psują. Psuje się tekst siedzący zbyt blisko krawędzi, którą jedna z platform przycina, obraz, który nigdy się nie aktualizuje, bo crawler zbuforował stary miesiące temu, albo karta renderowana bez żadnego obrazka, bo plik ważył 4 MB na wolnym serwerze źródłowym. Pytanie o rozmiar obrazu OG to tak naprawdę trzy pytania, a tylko jedno z nich dotyczy pikseli. Ten poradnik omawia specyfikację, strefę bezpieczną, zachowanie buforowania, które sprawia, że ludzie myślą, że ich tagi są błędne, oraz sposób, w jaki podglądy się rozwiązują, gdy udostępnianą rzeczą jest krótki link. Jeśli Twój podgląd całkowicie się nie pojawia, zamiast być źle przycięty, podgląd linku się nie wyświetla to poradnik diagnostyczny.
Rozmiar i dlaczego akurat taki
Proporcje 1.91:1 pochodzą z karty linku Facebooka i utrzymały się, bo wszyscy inni przyjęli zgodny układ zamiast wymyślać własny. Sam protokół Open Graph nie mówi nic o pikselach; definiuje og:image jako URL i pozostawia renderowanie konsumentowi, co jest dokładnie powodem, dla którego wokół jednego wygodnego rozmiaru uformował się faktyczny standard.
| Platforma | Renderuje 1200x630 jako | Warto wiedzieć |
|---|---|---|
| Karta na pełną szerokość | Źródło proporcji 1.91:1 | |
| Karta na pełną szerokość | 1200x627 też działa, różnica jest niewidoczna | |
| X | Duża karta podsumowania | Wymaga twitter:card = summary_large_image |
| Slack, Discord | Rozwinięcie inline | Przycina do krótszego paska w wąskich oknach |
| WhatsApp, iMessage | Mała miniatura | Często niemal kwadratowa, więc krawędzie znikają |
Własne wytyczne Facebooka dotyczące udostępniania obrazów ustalają minimum na 200 na 200 i zalecają większy plik dla wyświetlaczy o wysokiej rozdzielczości, a X dokumentuje znaczniki karty osobno, co jest jedynym miejscem, w którym potrzebujesz tagu specyficznego dla platformy, a nie pliku specyficznego dla platformy.
Strefa bezpieczna, o której nikt nie wspomina
Karta rzadko jest pokazywana w proporcjach, w jakich ją zaprojektowano. Aplikacje czatu przycinają w stronę kwadratu na potrzeby miniatury, niektóre kanały ucinają boki na wąskich ekranach, a zaokrąglony róg pożera ostatnie kilka pikseli logo w rogu.
Wszystko, co musi przetrwać, trzymaj wewnątrz środkowych 1080 na 600, wyśrodkowane, a zewnętrzny pas traktuj jako dekorację, którą możesz stracić. W praktyce oznacza to, że nagłówek siedzi na środku po lewej, a nie tuż przy krawędzi, logo mieszka wewnątrz marginesu, a nie w rogu, i nie ma cienkiej ramki, bo ramka to jeden element projektu, który wygląda na zepsuty w chwili, gdy zostanie przycięty.
Kontrast też ma większe znaczenie, niż się wydaje. Karty renderują się na białym tle w jednym kliencie i niemal czarnym w innym, więc obraz, który polega na otaczającym tle dla oddzielenia, traci swoje krawędzie w połowie z nich.
Tagi wokół obrazu
Cztery tagi wykonują całą pracę. Dwa z nich to te, które ludzie pomijają.
<meta property="og:image" content="https://example.com/og/spring-launch.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta
property="og:image:alt"
content="Spring launch: 30 percent off through May"
/>
<meta name="twitter:card" content="summary_large_image" />
URL musi być bezwzględny, wraz ze schematem i hostem, ponieważ crawler odczytuje tag bez kontekstu strony, względem którego mógłby rozwiązać ścieżkę względną. Szerokość i wysokość pozwalają platformie zarezerwować odpowiednie miejsce, zanim plik dotrze, co stanowi różnicę między kartą, która pojawia się natychmiast, a taką, która się przeukłada. A og:image:alt to tag dostępności, który nic nie kosztuje, a brakuje go niemal wszędzie.
Dlaczego Twój nowy obraz się nie pokaże
To ten problem, który generuje zgłoszenia do supportu. Naprawiłeś obraz, widzisz nowy plik pod jego URL, a karta wciąż pokazuje projekt z zeszłego kwartału.
Crawlery społecznościowe buforują agresywnie i nie robią tego subtelnie. Gdy URL zostanie już zeskanowany, to zapisana wersja jest renderowana przy kolejnych udostępnieniach, czasem przez tygodnie, a edycja Twojego HTML w żaden sposób nie mówi im, żeby spojrzały ponownie. Trzy sposoby wyjścia, w kolejności, w jakiej sam bym ich próbował:
- Wymuś ponowne zeskanowanie za pomocą własnego narzędzia platformy: zarówno Facebook Sharing Debugger, jak i LinkedIn Post Inspector pobierają stronę na żądanie.
- Opublikuj obraz pod nową nazwą pliku, co jest innym URL i dlatego nie ma w ogóle wpisu w buforze. To ten najbardziej niezawodny.
- Zmień sam udostępniany URL, co jest banalnie proste, gdy udostępniasz krótki link, który kontrolujesz, a nie stały adres strony.
Zanim cokolwiek opublikujesz, sprawdzarka Open Graph pokazuje Ci kartę dokładnie tak, jak zbudowałby ją crawler, co zajmuje dziesięć sekund i oszczędza kłopotliwego ponownego udostępnienia.
Podglądy, gdy udostępniasz krótki link
Krótki link nie ma własnych tagów Open Graph i żadnych nie potrzebuje. Crawler podąża za przekierowaniem, ląduje na stronie docelowej i buduje kartę z tagów tam obecnych, co oznacza, że skrócony URL dziedziczy podgląd, jaki ma strona docelowa. Jeśli karta jest błędna, to tagi na stronie docelowej są błędne.
Dwie rzeczy zależą jednak od warstwy linku. Przekierowanie musi dać się śledzić crawlerowi, co jest normalnym przypadkiem dla przeskoku po stronie serwera, ale nie dla przekierowania JavaScript - to kolejny powód, by utrzymywać łańcuch krótki i po stronie serwera. A ponieważ podgląd należy do strony docelowej, przekierowanie krótkiego linku na nowy adres zmienia też jego podgląd, co jest cicho przydatną właściwością, gdy strona kampanii zostaje zastąpiona po tym, jak link został już udostępniony.
Jeśli chcesz mieć link, kartę i dane o kliknięciach w jednym miejscu, załóż obszar roboczy na własnej domenie i sprawdź kartę za pomocą narzędzia przed wysyłką, a nie po.
Lista kontrolna, którą warto zachować
- 1200 na 630, PNG lub JPEG, poniżej 1 MB, bezwzględny URL HTTPS. To cała decyzja o rozmiarze obrazu OG.
- Nic ważnego poza środkowymi 1080 na 600, żadnych cienkich ramek.
- Obecne
og:image:width,og:image:heightiog:image:alt. twitter:cardustawiony nasummary_large_image, jeśli chcesz dużą kartę na X.- Nowy obraz, nowa nazwa pliku, a potem ponowne zeskanowanie, zanim cokolwiek ogłosisz.
Zrób te pięć rzeczy dobrze raz, umieść je jako szablon w sekcji head strony, a obrazy Open Graph przestaną być czymś, o czym myślisz. A to dokładnie tyle uwagi, ile powinny dostawać.
Przeczytaj serię filarową
Ten wpis znajduje się w klastrze tutoriali. Dla podglądów, które całkowicie zawodzą, zamiast być źle przycięte, podgląd linku się nie wyświetla to naprawa platforma po platformie, a jak zrobić klikalny link omawia warstwę poniżej.
Powiązane na blogu
- Podgląd linku nie wyświetla się? Przyczyny i jak to naprawić
- Skróć link dla X (Twitter): co robi z nim t.co
- Jak śledzić linki w mediach społecznościowych: kliknięcia według kanału
- Czym jest link brandowany i dlaczego lepiej konwertuje
- Jak przekierować URL: sześć sposobów i kiedy dany jest właściwy
- Krótkie linki na własnej domenie: DNS, TLS i edge
Najczęściej zadawane pytania
Jaki jest najlepszy rozmiar obrazu Open Graph?
1200 na 630 pikseli, proporcje 1.91:1, zapisany jako PNG lub JPEG i utrzymany poniżej około 1 MB. Ten jeden plik renderuje się poprawnie na Facebooku, LinkedIn, w dużej karcie podsumowania X, na Slacku, Discordzie, WhatsAppie i iMessage, dlatego stał się domyślnym rozmiarem zamiast osobnego rozmiaru dla każdej sieci. Starsze zalecenia sugerujące 1200x627 albo 600x315 wciąż działają, ale nie ma powodu, by ich używać.
Dlaczego mój og:image się nie aktualizuje?
Ponieważ platforma zbuforowała stary obraz. Crawlery społecznościowe zapisują to, co pobrały za pierwszym razem, i nie sprawdzają ponownie przy każdym udostępnieniu, więc nowy obraz może samodzielnie pojawić się dopiero po kilku dniach. Wymuś odświeżenie za pomocą własnego narzędzia platformy, takiego jak Facebook Sharing Debugger czy LinkedIn Post Inspector, albo opublikuj obraz pod nową nazwą pliku, co całkowicie omija bufor.
Jak duży może być plik og:image?
Utrzymuj go poniżej 1 MB. Facebook akceptuje pliki do 8 MB, ale crawlery pobierają z limitem czasu, a ciężki plik na wolnym serwerze źródłowym to najczęstsza przyczyna podglądu renderowanego całkowicie bez obrazu. Poniżej 1 MB jest wystarczająco szybko wszędzie, a PNG 1200x630 z prostym układem zwykle mieści się między 60 a 300 KB.
Czy potrzebuję osobnego obrazu dla X i LinkedIn?
Nie. Obie platformy odczytują og:image, gdy nie ma tagu specyficznego dla platformy, i obie renderują 1200x630 bez zastrzeżeń. Dodaj twitter:card ustawiony na summary_large_image, jeśli chcesz duży format na X, ale sam obraz może być tym samym plikiem. Jeden obraz, jeden URL, mniej rzeczy do zapamiętania, gdy strona się zmienia.
Skąd bierze się obraz podglądu, gdy udostępniam krótki link?
Ze strony docelowej, nie z linku. Crawler podąża za przekierowaniem i odczytuje tagi Open Graph na stronie, na której wyląduje, więc krótki link dziedziczy podgląd swojej destynacji. Dlatego brakująca karta po skróceniu prawie zawsze jest problemem tagów na stronie docelowej, a nie problemem samej skracarki.
Czy obraz musi mieć bezwzględny URL?
Tak. og:image musi być pełnym URL, wraz ze schematem i hostem, ponieważ crawler odczytuje tag bez kontekstu i nie może rozwiązać ścieżki względnej. Serwuj go przez HTTPS i ustaw og:image:width oraz og:image:height, aby platforma mogła rozplanować kartę, zanim plik skończy się pobierać.
Wypróbuj Elido
Wklej URL, otrzymaj krótki link
Bez rejestracji. Link działa 30 dni. Zarejestruj się, aby zachować go na zawsze.
Za darmo, bez rejestracji · 2 dziennie