контекст
Я управляю сайтом по https, где новый контент (каждая запись имеет свою собственную страницу) может быть создан и доступен пользователям.
Каждая страница имеет изображение, и этот URL-адрес изображения присутствует в og:image
метатег в верхней части страницы.
проблема
Фейсбук кажется медленным, чтобы поднять на og:image
, Когда страница создается впервые и пользователь пытается поделиться URL-адресом, для первых ~ 1-3 попыток og:image
не очищается / не отображается в Facebook (название и описание). После этого изображение хорошо видно в диалоговом окне «Поделиться».
Аналогичная проблема также возникает при использовании средства отладки URL OG Facebook. В первый раз, когда я захожу в URL, он не показывает изображение. Если я решу снова извлечь страницу из источника, она покажет изображение.
Дополнительные примечания
Сначала я подумал, что это может быть код сайта, изначально не показывающий изображение, но я отправил запрос скручивания и подделал одну из строк пользовательского агента Facebook (это важно для доступа к странице), а полученный HTML-код содержит og:image
тег с правильным URL-адресом изображения. Я также знаю, что это не имеет ничего общего с доступом к странице, или og:title
а также og:description
данные не будут отображаться (но это так).
Единственное, что я могу сделать, — это проблема SSL или HTTPS. Я недавно настроил сертификат SSL, но я не уверен, почему это вызвало бы задержку из-за того, что он вообще не работает.
Для ясности сайт работает на WordPress поверх стандартного стека LAMP.
Вопрос, по-видимому, довольно распространенный. Решение заключалось в том, чтобы при создании контента отправить запрос в инструмент для очистки Facebook с URL-адресом контента. Скребок подхватит и обработает изображение, позволяя первому ресурсу уже кэшировать это изображение в Facebook.
Да, я тоже это заметил. Facebook требует много времени для кэширования изображения og :. Tumblr делает это автоматически. Единственная причина, по которой я мог представить, что Facebook делает это, а не плохое программирование, заключается в том, что, возможно, у них есть команда по просмотру миниатюр, чтобы заблокировать обнаженные тела и другие грубые изображения. Как упомянуто выше, щелкнув URL-адрес ресурса Facebook вручную при создании, он попросит их кешировать его, надеюсь, до того, как другие нажмут.
Я анализировал эту проблему год назад. У меня такая же проблема. og:image
метатег был обновлен только после нескольких попыток рекрапа.
Эта повторная очистка может быть легко запущена на этой странице. https://developers.facebook.com/tools/debug/
Согласно моему старому анализу, основной причиной такого поведения является то, что скребок FB, похоже, имеет очень очень короткий тайм-аут. Если страница содержимого не отвечает на запрос скребка очень быстро, FB не принимает этот ответ во внимание. Даже если страница содержимого содержит правильные метаданные и правильный ответ HTTP / 200, FB игнорирует их, поскольку «слишком поздно — слишком поздно».
Я не нашел никакого решения для этого, кроме «предварительной очистки», как уже было описано Шоном.
В моем случае у меня было Azure WebApp с настройкой HTTPS без установленного сертификата SSL. Как это было в стадии производства, я проверил, вернувшись обратно к HTTP. Все теги «og» были обнаружены.
Таким образом, если ваш SSL не настроен должным образом и / или Facebook выдает ошибку CURL SSL, поиск SSL может помочь.