Вопрос

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

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

  • я проверил http://developers.facebook.com/tools/debug и иметь нулевые предупреждения или ошибки.
  • Он находит изображения, с которыми мы связали вog:image«Но они появляются пустыми. Когда мы нажимаем на изображения (и), однако, они существуют, и это нужно прямо к ним.
  • Он показывает одно изображение-изображение, размещенное на не HTTPS-сервере.
  • Мы пробовали квадратные изображения, JPEG, PNG, большие размеры и меньшие размеры. Мы поместили изображения прямо в public_html. Ноль появляется.
  • Это не ошибка кэширования, потому что, когда мы добавляем другой og:image Для мета, FB Linter действительно находит и читает это. Это показывает предварительный просмотр. Предварительный просмотр пустой. А Только Исключение, которое мы получаем, предназначено для изображений, которых нет на этом сайте.
  • Мы подумали, может cpanel или .htaccess Это мешало отображать изображения, поэтому мы проверили. Там не было. Мы даже сделали быстро < img src="[remote file]" > На совершенно другом сервере, и изображение отображается нормально.
  • Мы подумали, что это было og:type Или другая странность с другой метагом. Мы удалили их всех, по одному и проверяли это. Без изменений. Просто предупреждения.
  • Один и тот же код на другом веб -сайте отображается без каких -либо проблем.
  • Мы думали может быть Это не вытаскивали изображения, потому что мы используем одну и ту же страницу продукта (ы) для нескольких продуктов (изменяя его на основе значения GET, т.е. другой URL).
  • Оставив все 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="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 ------

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

Опубликовал обходной путь ----

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

Это было полезно?

Решение

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

Ошибка можно увидеть здесь:https://developers.facebook.com/bugs/260628274003812

Другие советы

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

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

  • og:image:url - идентично OG: изображение.
  • 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 собственность для ваших HTTPS URL 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 <- Вы можете посетить этот сайт для получения дополнительной информации.

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

РЕДАКТИРОВАТЬ: Не забудьте Ping Facebook Servers после обновления ваших кодов - 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 предлагает два способа обойти такое поведение: а) запустить отладчик OG по всем своим ссылкам: изображение будет кэширован и готово к обмену через ~ 10 минут или B ) Указание OG: изображение: ширина и OG: изображение: высота. (Подробнее читайте по ссылке выше)

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

У меня была такая же ошибка, и ничего предыдущего не помогло, поэтому я попытался следовать оригинальной документации Протокол открытого графика И я добавил атрибут префикса в мой тег HTML, и все стало потрясающим.

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

У меня были подобные проблемы. Я удалил свойство = "OG: Image: Secure_Url", и теперь оно будет вычищено только OG: Image. Иногда меньше - это больше

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

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

Это произошло из -за недавней миграции из WP в Джекилл, я оптимизировал свои изображения с Gulp, но использовал оригинальные изображения в OG: изображение по ошибке.

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

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

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

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

  1. Перейти к отладчику в https://developers.facebook.com/tools/debug/og/object/
  2. Поместите свой URL
  3. Внизу, Facebook показывает ваше «изображение» (прозрачный GIF 1x1)
    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>

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

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

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

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

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

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

Отладчик Facebook

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

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

Подобные симптомы (Facebook et al. Не правильно извлекают OG: изображение и другие активы по HTTPS) могут возникнуть, когда сертификат HTTPS сайта не совсем соответствует полностью.

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

Возможно, не была вашей проблемой, но, возможно, были другие с похожими симптомами (как у меня). Есть много способов проверить ваш сертификат - тот, который я случайно использовал: 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, вы получите ошибку с надписью: Прикреплено Image () не удалось загрузить

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

я взял http:// из моего og:image и заменил его просто старым www. Тогда это начало работать нормально.

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

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

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

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

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

Кроме того, есть больше шашек, кроме как Отладчик объекта Facebook Чтобы проверить: OpenGraphCheck.com, Тестер открытого графика Абхинай Ратхар, Iframely's встроенные коды, Валидатор карты | Разработчики 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» и немного текста в теге тела, который ссылается на эти теги OG.

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top