Во-первых - я не полагаю, что это дублирующаяся проблема. Я искал те же или подобные проблемы на SO, и из-за характера устранения неполадок перед тем, как спросить, я считаю, что эта проблема уникальна.
Facebook не может понять мои файлы og:image, и я пробовал все обычные решения. Я начинаю думать, что это может иметь какое-то отношение к https://...
og:image", но они отображаются пустым. Однако, когда мы щелкаем по изображению (-ам), они существуют, и они берутся прямо на них.og:image в мета, FB linter находит и читает это. Он показывает предварительный просмотр. Предварительный просмотр пуст. Исключение только, которое мы получаем, предназначено для изображений, которые не находятся на этом веб-сайте.cpanel или .htaccess было предотвращено выщелачивание, что препятствовало отображению изображений, поэтому мы проверили. Не было. Мы даже сделали быстрый < img src="[remote file]" > на совершенно другом сервере, и изображение получилось отлично.og:type или другая странность с другим метатегом. Мы удалили все из них по одному и проверили. Без изменений. Просто предупреждения.og:image или image_src off, 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="#" onclick="location.href='https://www.[ourwebsite].com/images/shirts/overdriven-blues-music-tshirt-details-black.png'; return false;" />
<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 и запустить ссылку EVERY для обновления данных OG. Это сработало, но решение является обходной способ обхода, и если проблема с https исправлена, и мы вернемся к использованию естественного домена https, FB будет кэшировать изображения с другого веб-сайта, что усложняет вопросы. Надеемся, эта информация поможет спасти кого-то другого от потери 32 часов кодирования их жизни.
Я столкнулся с той же проблемой и сообщил об этом как об ошибке на сайте разработчиков Facebook. Кажется довольно очевидным, что OG: URI изображений, использующие HTTP, работают нормально, а URI с использованием HTTPS этого не делают. Они теперь признали, что они "изучают это".
Здесь можно найти ошибку: https://developers.facebook.com/bugs/260628274003812
В некоторых свойствах могут быть добавлены дополнительные метаданные. Они указаны так же, как и другие метаданные с property и content, но property будет иметь дополнительные значения:
Свойство og:image имеет некоторые необязательные структурированные свойства:
og:image:url - Идентично для og: image.og:image:secure_url -
альтернативный URL-адрес для использования, если веб-страница требует HTTPS.og:image:type - A
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 FOR IMAGE:
<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 debugger показывает правильное изображение.
Но изменение менялось og:image до og:image:url. Надеюсь, это поможет кому-то еще столкнуться с подобной проблемой.
Получил от Google, но это не помогло мне. Оказалось, что для логотипа минимальное соотношение сторон 3: 1. Мой был почти 4: 1. Я использовал Gimp, чтобы обрезать его ровно 3: 1 и voila - мой логотип теперь отображается на 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:. Иногда, меньше
Как я случайно обнаружил, прозрачное пустое изображение содержит заголовок ответа, указывающий на возможную причину проблемы.
https://external-ams3-1.xx.fbcdn.net/safe_image.php?d=...&url=...)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:image в диапазоне от нескольких тысяч пикселей и несколько мегабайт.
Это произошло из-за недавней миграции из WP в Jekyll, я оптимизировал свои изображения с помощью gulp, но по ошибке использовал исходные изображения в og: image.
Facebook дает нам следующие рекомендации на сегодняшний день:
Используйте изображения размером не менее 1200 x 630 пикселей для лучшего отображения на устройства с высоким разрешением. Как минимум, вы должны использовать изображения, которые 600 x 315 пикселей, чтобы отображать сообщения с более крупными изображениями. Изображения могут быть размером до 8 МБ.
Таким образом, верхний предел составляет 8 МБ.
Я столкнулся с той же проблемой, и тогда я заметил, что у меня был другой домен для 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
Кроме того, эта проблема возникает также при добавлении созданной пользователем истории (где вы не используете 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, вы получите сообщение об ошибке: Прикрепленное изображение() не удалось загрузить
Сегодня у меня была похожая проблема, которую мне помог решить Sharing Debugger. Кажется, что Facebook не может (в настоящее время) понимать изображения со встроенными метаданными XMP. Когда я заменил изображения в наших статьях на версии без метаданных XMP и заново очистил страницу (используя Sharing Debugger), проблема исчезла. Шестнадцатеричный редактор поможет вам увидеть, содержит ли ваше изображение метаданные XMP.
Я взял http:// из моего og:image и заменил его просто старым www. потом все заработало нормально.
Вы можете использовать этот инструмент на Facebook, чтобы сбросить кэш очистки изображения и проверить, какой URL он использует для демонстрационного изображения.
В моем случае кажется, что у сканера просто ошибка. Я пробовал:
Ни одна из этих работ. Это стоило мне недели. И вдруг из ниоткуда кажется, что снова работает.
Вот мое исследование, если кто-то снова столкнется с этой проблемой:
Кроме того, есть и другие проверки, кроме Отладчика объектов Facebook, которые вы можете проверить: OpenGraphCheck.com, Тестер открытых графов Abhinay Rathore, Iframely Embed Коды, Card Validator | Разработчики Twitter.
Я вижу, что Отладчик извлекает 4 og:image теги из вашего URL.
Первое изображение является самым большим и поэтому занимает наибольшее время загрузки. Попробуйте сжать это первое изображение вниз или изменить порядок, чтобы сначала показать меньшее изображение.
Из того, что я наблюдал, я вижу, что, когда ваш сайт является общедоступным, и хотя 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"/>
После того, как вы обновите метатег, убедитесь, что ссылка на контент (изображение) является абсолютным путем, и перейдите по ссылке https://developers.facebook.com/tools/debug/sharing введите ссылку на свой сайт и scrape again нажмите на ссылку на следующей странице.
После нескольких часов тестирования и тестирования вещей...
Я решил эту проблему как можно проще. Я замечаю, что они используют "тестовые страницы" на странице разработчиков Facebook, которая содержит только теги "og" и некоторый текст в теге body, который ссылается на эти теги og.
Итак, что я сделал?
Я создал второе представление в своем приложении, содержащее те же самые вещи, которые они используют.
И как я знаю, это Facebook, который обращается к моей странице, поэтому я могу изменить представление? У них есть уникальный User Agent: "facebookexternalhit/1.1"