FB OpenGraph og: изображение не тянет изображения (возможно, https?)

Во-первых, я не верю, что это дублирующий вопрос. Я искал те же или похожие проблемы в SO, и из-за характера устранения неполадок, прежде чем спрашивать, я считаю, что эта проблема уникальна.

Facebook не может захватить мои og:imageфайлы, и я попробовал каждое обычное решение. Я начинаю думать, что это может иметь какое-то отношение кhttps://...

• Я проверил http://developers.facebook.com/tools/debug и у меня ноль предупреждений или ошибок.
• Это поиск изображений, на которые мы ссылаемся, в " og:image", но они отображаются пустыми. Когда мы нажимаем на изображение (я), однако, они действительно существуют, и это прямо для них.
• Он показывает одно изображение - изображение, размещенное на не-https сервере.
• Мы пробовали квадратные изображения, JPEG, PNG, большие размеры и меньшие размеры. Мы поместили изображения прямо в public_html. Ноль обнаруживаются.
• Это не ошибка кеширования, потому что, когда мы добавляем другую og:imageв мету, линтер FB находит и читает это. Это показывает предварительный просмотр. Предварительный просмотр пуст. Только исключение , мы получаем для изображений, которые не на этом сайте.
• Мы подумали, что, возможно, был какой-то анти-выщелачивающий агент cpanelили .htaccessчто мешало отображению изображений, поэтому мы проверили. Не было. Мы даже сделали быстрый тест < img src="[remote file]" >на совершенно другом сервере, и изображение выглядит хорошо.
• Мы подумали, что это может быть та og:typeили иная странность с другим метатегом. Мы удалили их все по одному и проверили. Без изменений. Просто предупреждения.
• Тот же код на другом сайте появляется без каких-либо проблем.
• Мы подумали, что, может быть, это не вытягивание изображений, потому что мы используем одни и те же страницы продукта для нескольких продуктов (меняя его в зависимости от значения get, то есть «details.php? Id = xxx»), но он все еще вытягивает одну изображение (из другого URL).
• Оставив любой og:imageили image_src выключен, FB не находит никаких изображений.

Я в конце моей веревки. Если бы я сказал, сколько времени я и другие потратили на это, вы были бы шокированы. Проблема в том, что это интернет-магазин. Мы абсолютно, безусловно, не можем иметь изображения. Мы должны. У нас есть десять или около того других сайтов ... Это единственный с og:imageпроблемами. Он также единственный https, так что мы подумали, что, может быть, в этом проблема. Но мы не можем найти никакого прецедента нигде в Интернете для этого.

Это метатеги:

<meta property="og:title" content="[The product name]" /> 
<meta property="og:description" content="[the product description]" /> 
<meta property="og:image" content="https://www.[ourwebsite].com/images/shirts/overdriven-blues-music-tshirt-details-black.png" />
<meta property="og:image" content="https://www.[ourwebsite].com/images/shirts/overdriven-blues-music-tshirt-art-black.png" />
<meta property="og:image" content="http://www.[ADIFFERENTwebsite].com/wp-content/uploads/2011/06/ARS-Header-Shine2.png" />
<meta property="og:image" content="https://www.[ourwebsite].com/images/ARShopHeader.png" />
<meta property="og:image" content="http://www.[ourwebsite].com/overdriven-blues-music-tshirt-art-black.JPG" />
<meta property="og:type" content="product"/>
<meta property="og:url" content="https://www.[ourwebsite].com/apparel-details.php?i=10047" />
<meta property="og:site_name" content="[our site name]" />      
<meta property="fb:admins" content="[FB-USER-ID-NUMBER]"/>
<meta name="title" content="[The product name]" />
<meta name="description" content="[The product description]" />
<link rel="image_src" href="https://www.[ourwebsite].com/images/shirts/overdriven-blues-music-tshirt-details-black.png" />
<meta name="keywords" content="[four typical keywords]">
<meta name="robots" content="noarchive">

Если вы хотите, вот ссылка на одну из наших страниц продукта, над которой мы работали. [Ссылка сокращена, чтобы попытаться обуздать это попадание в результаты поиска для нашего сайта]: http://rockn.ro/114

РЕДАКТИРОВАТЬ ----

Используя скребок «Посмотри, что видит Facebook», мы смогли увидеть следующее:

"image": [          
      {
         "url": "https://www.[httpSwebsite].com/images/shirts/soul-man-soul-music-tshirt-details-safari.png"
      },
      {
         "url": "https://www.[httpSwebsite].com/images/shirts/soul-man-soul-music-tshirt-art-safari.png"
      },
      {
         "url": "http://www.[theotherNONSECUREwebsite].com/wp-content/uploads/2011/06/ARS-Header-Shine2.png"
      }
   ],

Мы проверили все найденные ссылки на одной странице. Все были совершенно правильными изображениями.

РЕДАКТИРОВАТЬ 2 ----

Мы попробовали выполнить тест и добавили поддомен на веб-сайт NONSECURE (с которого изображения фактически видны через Facebook). Субдомен был http: // img. [Nonsecuresite] .com. Затем мы помещаем все изображения в основную папку поддоменов и ссылаемся на них. Это не будет тянуть эти изображения в FB. Тем не менее, он по-прежнему будет тянуть любые изображения, на которые есть ссылки в незащищенном главном домене.

РАЗМЕЩЕНО ВРЕМЕННОЕ РЕШЕНИЕ ----

Благодаря Кигану мы теперь знаем, что это ошибка в Facebook. Чтобы обойти это, мы разместили поддомен на другом веб-сайте NON-HTTPS и поместили на него все изображения. Мы ссылались на координирующее http://img.otherdomain.com/[like-image.jpg]изображение og:imageна каждой странице продукта. Затем нам пришлось пройти через FB Linter и запустить КАЖДУЮ ссылку, чтобы обновить данные OG. Это сработало, но решение - это обходной путь, и если httpsпроблема будет решена, и мы вернемся к использованию естественного домена https, FB кэширует изображения с другого веб-сайта, что усложнит ситуацию. Надеемся, что эта информация поможет спасти кого-то еще от потери 32 часов кодирования своей жизни.

Я столкнулся с той же проблемой и сообщил о ней как об ошибке на сайте разработчика Facebook. Кажется довольно ясным, что og:imageURI, использующие HTTP, работают нормально, а URI, использующие HTTPS - нет. Теперь они признали, что «изучают это».

Обновление: с 2020 года ошибка больше не видна в системе тикетов Facebook. Они никогда не отвечали, и я не верю, что это поведение изменилось. Тем не менее, указание HTTPS URI в og:image:secure, кажется, работает нормально.

К некоторым свойствам могут быть прикреплены дополнительные метаданные. Они указываются так же, как и другие метаданные с propertyи content, но propertyбудут иметь дополнительные:

og:imageСвойство имеет некоторые дополнительные структурированные свойства:

• og:image:url - идентично og: image.
• og:image:secure_url - Альтернативный URL для использования, если веб-страница требует HTTPS.
• og:image:type - MIME-тип для этого изображения.
• og:image:width - Количество пикселей в ширину.
• og:image:height - Количество пикселей высокое.

Пример полного изображения:

<meta property="og:image" content="http://example.com/ogp.jpg" />
<meta property="og:image:secure_url" content="https://secure.example.com/ogp.jpg" /> 
<meta property="og:image:type" content="image/jpeg" /> 
<meta property="og:image:width" content="400" /> 
<meta property="og:image:height" content="300" />

Таким образом, вам нужно изменить og:imageсвойство для ваших URL-адресов HTTPS наog:image:secure_url

Пример:

HTTPS META TAG ДЛЯ ИЗОБРАЖЕНИЯ:

<meta property="og:image:secure_url" content="https://www.[YOUR SITE].com/images/shirts/overdriven-blues-music-tshirt-details-black.png" />

HTTP META TAG ДЛЯ ИЗОБРАЖЕНИЯ:

<meta property="og:image" content="http://www.[YOUR SITE].com/images/shirts/overdriven-blues-music-tshirt-details-black.png" />

Источник: http://ogp.me/#structured <- Вы можете посетить этот сайт для получения дополнительной информации.

Надеюсь, это поможет вам.

РЕДАКТИРОВАТЬ: не забудьте проверить связь с серверами facebook после обновления ваших кодов - URL Linter

Я не знаю, если это только со мной, но для меня og:imageне работает, и он выбирает логотип моего сайта, хотя отладчик facebook показывает правильное изображение.

Но изменения og:imageв og:image:urlработал для меня. Надеюсь, что это помогает кому-либо еще сталкиваются с подобной проблемой.

Получил от Google, но это не сильно помогло мне. Оказалось, что для логотипа требуется минимальное соотношение сторон 3: 1. У меня было почти 4: 1. Я использовал Gimp, чтобы обрезать его точно до 3: 1 и вуаля - мой логотип теперь отображается на FB.

tl; dr - наберись терпения

Я попал сюда, потому что я видел пустые изображения с сайта https. Проблема была совсем другой, хотя:

Когда контент публикуется впервые, сканер Facebook будет очищать и кэшировать метаданные из общего URL-адреса. Сканер должен увидеть изображение хотя бы один раз, прежде чем оно будет отображено. Это означает, что первый человек, который поделится частью контента, не увидит визуализированное изображение.

[ https://developers.facebook.com/docs/sharing/best-practices/#precaching]

Во время тестирования Facebook понадобилось около 10 минут, чтобы наконец показать изображение. Поэтому, пока я чесал голову и бросал случайные теги og в Facebook (и подозревал проблему https, упомянутую здесь), все, что мне нужно было сделать, это ждать.

Поскольку это может действительно помешать людям делиться вашими ссылками в первый раз, FB предлагает два способа обойти это поведение: a) запускать отладчик OG для всех ваших ссылок: изображение будет кэшировано и готово для обмена через ~ 10 минут или b ) указав og: image: ширину и og: image: высоту. (Подробнее в ссылке выше)

Все еще задаюсь вопросом, хотя, что занимает их так долго ...

У меня была та же ошибка, и ничто из предыдущего не помогло, поэтому я попытался следовать оригинальной документации Open Graph Protocol и добавил атрибут префикса в свой тег html, и все стало замечательно.

<html prefix="og: http://ogp.me/ns#">

У меня были похожие проблемы. Я удалил свойство = "og: image: secure_url" и теперь оно будет очищаться только с помощью og: image. Иногда меньше значит больше

Я обнаружил еще один сценарий, который может вызвать эту проблему. Я прошел все шаги, описанные в вопросе и ответах, но проблема осталась.

Я проверил свои изображения и обнаружил, что в некоторых моих сообщениях были слишком большие миниатюрные изображения og:imageразмером в несколько тысяч пикселей и несколько мегабайт.

Это произошло из-за недавнего перехода с WP на Jekyll, я оптимизировал свои изображения с помощью gulp, но по ошибке использовал исходные изображения в og: image.

На сегодняшний день Facebook дает нам следующие рекомендации :

Используйте изображения размером не менее 1200 x 630 пикселей для лучшего отображения на устройствах с высоким разрешением. Как минимум, вы должны использовать изображения размером 600 x 315 пикселей для отображения постов на странице ссылок с большими изображениями. Размер изображения может достигать 8 МБ.

Таким образом, существует верхний предел 8 МБ.

Как я случайно обнаружил, прозрачное пустое изображение поставляется с заголовком ответа, указывающим на возможную причину проблемы.

1. Перейдите в отладчик по адресу https://developers.facebook.com/tools/debug/og/object/.
2. Введите свой URL
3. Внизу Facebook показывает ваше «изображение» (прозрачный 1x1 GIF)
   1. Изображение связано с вашим исходным изображением - нет смысла нажимать на него
   2. Нажмите вправо и просмотрите изображение (вы получите что-то похожее https://external-ams3-1.xx.fbcdn.net/safe_image.php?d=...&url=...)
4. Включите вкладку Net в инструментах Firebug / Developer, при необходимости обновите страницу
5. Вы получите x-error-detailответный заголовок с объяснением

Например, в моем случае это было Invalid image extension for URL: https://[mydomain]/[myfilename].jpg

Реальная проблема в моем случае была связана с prerender.io .

Оказывается, если изображение запрашивается через prerender, оно конвертируется в HTML. Что-то вроде этого:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head>
<body style="margin: 0px;"><img style="-webkit-user-select: none; cursor: -webkit-zoom-in; " src="https://[yourdomain].com/[yourfilename].jpg" width="1078" height="718"></body>
</html>

Это либо ошибка в самом prerender, либо предполагается, что он настроен в вашем прокси-сервере, чтобы не использовать prerender для *.jpgзапросов (даже если их запрашивает бот Facebook).

Это действительно трудно заметить, так как prerender используется только для определенных заголовков пользовательских агентов.

Я столкнулся с той же проблемой, а затем заметил, что у меня был другой домен для og:url

Однажды я позаботился о том, чтобы домен был таким же, og:urlи og:imageон работал.

Надеюсь это поможет.

В моем случае проблема заключалась в том, что вы не предоставили CA Root Certificate . Я понял это после использования: https://www.ssllabs.com/ssltest/analyze.html для анализа конфигурации SSL.

Подобные симптомы (Facebook и др. Неправильно выбирают og: image и другие ресурсы через https) могут возникать, когда сертификат https сайта не полностью соответствует требованиям.

Сертификат https вашего сайта может показаться действительным (зеленый ключ в браузере и все), но он не будет корректно очищаться, если в нем отсутствует промежуточный или цепной сертификат. Это может привести к тому, что многие потраченные часы будут проверять и перепроверять все различные кэши и метатеги.

Возможно, это не ваша проблема, но могут быть и другие с похожими симптомами (как у меня). Есть много способов проверить ваш сертификат - тот, который мне довелось использовать: https://www.sslshopper.com/ssl-checker.html

Я http://вынул свой og:imageи заменил его просто старым, www.после чего он начал работать нормально.

Вы можете использовать этот инструмент на Facebook, чтобы сбросить кэш очистки изображения и проверить, какой URL он использует для демонстрационного изображения.

Я вижу, что отладчик получает 4 og:imageтега из вашего URL.

Первое изображение самое большое, поэтому для его загрузки требуется больше всего времени. Попробуйте уменьшить это первое изображение вниз или измените порядок, чтобы сначала показывать уменьшенное изображение.

Кроме того, эта проблема также возникает, когда вы добавляете сгенерированную пользователем историю (где вы не используете og: image). Например:

POST /me/cookbook:eat?
  recipe=http://www.example.com/recipes/pizza/&
  image[0][url]=http://www.example.com/recipes/pizza/pizza.jpg&
  image[0][user_generated]=true&
  access_token=VALID_ACCESS_TOKEN

Выше будет работать только с http, а не с https. Если вы используете https, вы получите сообщение об ошибке: Прикрепленное изображение () не удалось загрузить

Не забудьте обновить серверы через:

Отладчик Facebook

И нажмите «Собрать новую информацию»

Сегодня у меня была похожая проблема, которую мне помог решить Sharing Debugger . Кажется, что Facebook (в настоящее время) не может понять изображения со встроенными метаданными XMP. Когда я заменил изображения в наших статьях на версии без метаданных XMP и повторно очистил страницу (используя Sharing Debugger), проблема исчезла. Шестнадцатеричный редактор поможет вам увидеть, содержит ли ваше изображение метаданные XMP.

В моем случае кажется, что у сканера просто ошибка. Я пробовал:

• Изменение ссылок только на http
• Удаление конца пробела
• Переключение обратно на http полностью
• Переустановка сайта
• Установка связки плагинов OG (я использую WordPress)
• Подозрение на сервер имеет странную неверную конфигурацию, которая блокирует ботов (потому что все контроллеры OG не могут получить теги, а другие запросы к моим сайтам нестабильны)

Ни одна из этих работ. Это стоило мне недели. И вдруг из ниоткуда кажется, что снова работает.

Вот мое исследование, если кто-то снова столкнется с этой проблемой:

• Что делает средства проверки Open Graph неспособными обнаруживать данные Open Graph?
• Как узнать, какие боты сайта, если у меня нет root-доступа к хостингу, они будут читать? T
• Makes Что делает средства проверки Open Graph неспособными обнаруживать данные Open Graph? - Давайте зашифруем поддержку сообщества
• 👍 Crawler не может получить изображения, но добавление новой уникальной строки запроса может заставить его работать впервые - Facebook для разработчиков

Кроме того , есть еще другие , чем шашки Object Debugger Facebook, для вас , чтобы проверить: OpenGraphCheck.com , Абхинайте Rathore в Open Graph Tester , встраивать коды Iframely в , Card Validator | Разработчики Твиттера .

Хорошо ... Я понимаю, что эта ветка старая и переполненная, но в случае, если кто-то входит, как я, изо всех сил пытается заставить их тег og: image работать прямо в Facebook, вот уловка, которая работала для меня:

НЕ используйте эту ссылку:

https://developers.facebook.com/tools/debug/sharing/?q=https%3A%2F%2Fwww.google.com

работать через вашу проблему. Или, если вы это сделаете, немедленно прокрутите вниз и нажмите Scrape VIA API.

https://developers.facebook.com/tools/explorer/?method=POST&path=%3Fscrape%3Dtrue%26id%3Dhttps%3A%2F%2Fwww.google.com&version=v5.0

В инструменте проводника отображаются ошибки, которые НЕ отображаются в инструменте «отладка». Maddening !!! (в моем случае пробел в имени файла изображения молча выбил мое изображение в инструменте отладки, но он показал ошибку в инструменте проводника).

Я столкнулся с еще одной причиной, по которой изображения og не отображаются на картах FB. Кроме того, используя инструмент FB scraper для отладки метатегов og , я смог подтвердить все необходимые теги, присутствующие на моей странице WordPress, и все же я получил бы следующую ошибку загрузки файла:

Предоставленный файл og: image, <https-link-to-jpg-image> не может быть загружен. Это может произойти по нескольким причинам, таким как использование сервером неподдерживаемого кодирования содержимого. Искатель принимает кодировки содержимого deflate и gzip.

У меня было смутное ощущение, что с форматом изображения возникла проблема, работала ссылка на изображение, но в сообщении, похоже, что-то не так с кодировкой контента.

После долгих поисков я в итоге посмотрел на расширения php , необходимые для сервера WordPress , и понял, что модуль pho-exif не установлен. Модуль exif записывает метаданные exif во все загруженные изображения. В результате изображения, используемые в теге изображения FB og, не имели связанных метаданных exif.

Как только модуль exif включен, WordPress позволяет сбросить метаданные exif для изображения (Медиатека-> Выбрать и изображение-> Редактировать больше деталей-> Метаданные карты exif), и изображение теперь появилось на карте FB, как и ожидалось.

Из того, что я заметил, я вижу, что когда ваш сайт общедоступен и хотя URL-адрес изображения - https, он просто отлично работает.

Для меня это сработало:

<meta property="og:url" content="http://yoursiteurl" />
    <meta property="og:image" content="link_to_first_image_if_you_want" />
    <meta property="og:image" content="link_to_second_image_if_you_want" />
    <meta property="og:image:type" content="image/jpeg" /> 
    <meta property="og:image:width" content="400" /> 
    <meta property="og:image:height" content="300" />
    <meta property="og:title" content="your title" />
    <meta property="og:description"  content="your text about homepage"/> 

После нескольких часов испытаний и попыток ...

Я решил эту проблему максимально просто. Я заметил, что они используют «тестовые страницы» на странице разработчиков Facebook, которая содержит только теги «og» и некоторый текст в теге body, который ссылается на теги og.

Так что я сделал?

Я создал второе представление в своем приложении, содержащее те же самые вещи, которые они используют.

И откуда я знаю, что Facebook открывает мою страницу, чтобы я мог изменить вид? У них есть уникальный пользовательский агент: "facebookexternalhit / 1.1"

Как только вы обновите метатег, убедитесь, что ссылка на контент (изображение) является абсолютным путем, и перейдите сюда, https://developers.facebook.com/tools/debug/sharing введите ссылку на ваш сайт и нажмите на scrape againследующей странице.