1. Перейдите на страницу http://developers.facebook.com/tools/debug.
2. Введите URL-адрес, следующий за fbrefresh=CAN_BE_ANYTHING

Примеры:

1. http://www.example.com?fbrefresh=CAN_BE_ANYTHING
2. http://www.example.com?postid=1234&fbrefresh=CAN_BE_ANYTHING
3. ИЛИ посетите: http://developers.facebook.com/tools/debug/og/object?q=http://www.example.com/?p=3568&fbrefresh=89127348912

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

Facebook сохраняет миниатюру кеша. Он не будет обновляться, даже если вы удалите миниатюру / изображение со своего сервера. Но Facebook позволяет вам обновляться, используя fbrefresh

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

Вопрос, получивший наибольшее количество голосов, устарел:

Это единственные 2 варианта, которые следует использовать по состоянию на ноябрь 2014 г.:

Для не разработчиков

1. Используйте отладчик FB: https://developers.facebook.com/tools/debug/og/object
2. Вставьте URL-адрес, который вы хотите повторно кэшировать. (Убедитесь, что вы используете тот же URL, что и в теге og: url)
3. Еще раз нажмите кнопку "Получить информацию о цикле".

Разработчикам

1. Выполните программный вызов GET по этому URL-адресу: https://graph.facebook.com/?id=[YOUR_URL_HEREvisible&scrape=true (см .: https://developers.facebook.com/docs/games_payments/takingpayments#scraping)
2. Убедитесь, что тег og: url в заголовке на этой странице совпадает с тем, который вы передаете.
3. вы даже можете проанализировать ответ json, чтобы узнать количество долей этого URL-адреса.

Дополнительная информация об обновлении изображений

• Если URL-адрес og: image остается прежним, но изображение фактически изменилось, оно не будет обновляться и повторно использоваться парсерами Facebook, даже если они выполняются выше. (даже передача? last_update = [TIMESTAMP] в конце URL-адреса изображения у меня не сработала).
• Единственный эффективный обходной путь для меня - присвоить изображению новое имя.

Примечание относительно обновлений изображений или видео в ранее опубликованных сообщениях:

• Когда вы вызываете отладчик для отмены изменений в тегах og: вашей страницы, все предыдущие акции Facebook этого URL-адреса по-прежнему будут показывать старое изображение / видео. Невозможно обновить все предыдущие сообщения, и это сделано специально из соображений безопасности. В противном случае кто-то сможет притвориться, что пользователь поделился чем-то, чего он на самом деле не делал.

Если у вас много страниц и вы не хотите обновлять их вручную - вы можете сделать это автоматически.

Допустим, у вас есть страница профиля пользователя с фотографией:

$url = 'http://'.$_SERVER['HTTP_HOST'].'/'.$user_profile;
$user_photo = 'http://'.$_SERVER['HTTP_HOST'].'/'.$user_photo;

<meta property="og:url" content="<?php echo $url; ?>"/>
<meta property="og:image" content="<?php echo $user_photo; ?>"

Просто добавьте это на свою страницу:

// with jQuery
$.post(
    'https://graph.facebook.com',
    {
        id: '<?php echo $url; ?>',
        scrape: true
    },
    function(response){
        console.log(response);
    }
);

// with "vanilla" javascript
var fbxhr = new XMLHttpRequest();
fbxhr.open("POST", "https://graph.facebook.com", true);
fbxhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
fbxhr.send("id=<?php echo $url; ?>&scrape=true");

Это обновит кеш Facebook. Если вы используете решение jQuery, посмотрите «response» в console.log - вы найдете там поле «updated_time» и другую полезную информацию.

Миниатюра OG не обновляется даже при передаче переменной fbrefresh. Чтобы обновить это, не дожидаясь автоматической очистки, вам необходимо изменить имя файла значения метатега, связанного с эскизом, и обновить.

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

В новых правилах facebook указано, что размер изображения должен быть 1200 x 630 или иметь такое соотношение сторон, это кажется неправильным, единственное, что сработало для меня, - это использование изображения с квадратными размерами.

Редактировать * Через несколько часов я вернулся к использованию 1200 x 630, и это волшебным образом сработало, это было волшебно.

Я также переименовал файлы в f * ^ * kfacebook.jpg, не уверен, что это помогло, но мне понравилось.

В основном ответ - терпение;)

Сегодня утром я проверил ЛИНТЕР, и og: title и og: url отображаются правильно, без лишних значений. Я предполагаю, что FaceBook автоматически очищает свой кеш через определенный интервал. Мне просто нужно подождать.

Да, facebook автоматически очищает кеш каждые 24 часа: на самом деле facebook очищает страницы и обновляет кеш каждые 24 часа https://developers.facebook.com/docs/reference/plugins/like/#scraperinfo.

Оооок, наконец-то помогло (использую IP.Board). Что мне нужно было сделать:

1. Измените URL-адрес изображения og: на моем веб-сайте (общая конфигурация).
2. Попробуйте этот метод с? Fbrefresh = 1154464gd56

Спасибо автору за эту ветку!

РЕДАКТИРОВАТЬ: Что еще нужно помнить о требованиях к изображениям. На данный момент (январь 2013 г.) это: - не менее 200 пикселей в обоих направлениях - максимальное соотношение 3: 1

1. Посетите страницу FB https://developers.facebook.com/tools/debug/og/object/
2. Введите свой домен.
3. Нажмите кнопку "Получить новую информацию для очистки".
4. Сделанный

Извините, ребята, но правильный ответ:

Не существует надежного способа обновить URL-адрес открытого графика og: image с немедленным результатом. Он кешируется до обновления fb (как сообщается, каждые 24 часа).

Вот вещи, которые, по мнению других, работают, но я не добился НУЛЕВОГО успеха ни с одним из них.

• Выбор "Получить новую информацию для очистки"
• Изменение фактического имени файла изображения и / или удаление оригинала
• Добавление строки запроса к URL-адресу изображения путем добавления PHP TIMESTAMP или?
• Добавление строки запроса "... yoursite.com/?fbrefresh=anything" к URL-адресу выборки отладчика
• Выбор ссылки API графика внизу страницы og dev
• Выбор точного просмотра того, что видит парсер - похоже, он не запрашивает некэшированные данные очистки в реальном времени, он все равно показывает URL-адрес кэшированного изображения, даже если файл больше не существует

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

Мы просто столкнулись с этим, как выяснилось, мы не использовали правильный URL-адрес, так как у настоящего URL-адреса была строка запроса (да, другая страница для бота).

http://example.com/

!==

http://example.com/?utm_campaign=foo

Линтер повторно кэширует вашу страницу, вам не нужно ждать.

Следует добавить, что URL-адрес чувствителен к регистру. Обратите внимание, что:

apps.facebook.com/<▪HELLO

в глазах линтера другое тогда

apps.facebook.com/< sizeshello

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

Я обнаружил, что если ваше изображение 72dpi, это даст вам ошибку размера изображения. Вместо этого используйте 96 точек на дюйм. Надеюсь это поможет.

1. Перейдите на страницу http://developers.facebook.com/tools/debug.

2. Вставьте URL-адрес страницы и нажмите «Отладка». Если ваш сайт использует псевдонимы URL-адресов, убедитесь, что вы используете тот же URL-адрес, который использует Facebook для страницы, которой вы делитесь (пример: в Drupal используйте путь node / * вместо псевдонима, если к странице предоставлен общий доступ через этот URL-адрес).

3. В разделе «Предварительный просмотр» нажмите ссылку «Посмотреть в диалоговом окне публикации».

Документы разработчика Facebook говорят, что свойство title имеет исключение:

После того, как с объектом были связаны 50 действий (лайки, публикации и комментарии), вы не сможете обновить его заголовок.

https://developers.facebook.com/docs/sharing/opengraph/using-objects#update

Был подобный опыт. Ссылка на веб-сайт показывала 404 в превью, созданном facebook. Оказывается, метаданные og: url были неправильными. Мы уже исправили это несколько дней назад, но все еще видели 404 на превью. Мы использовали инструмент по адресу https://developers.facebook.com/tools/debug/ и это привело к принудительному обновлению (кстати, не нужно было добавлять какие-либо параметры). В нашем случае Facebook не обновлял кеш через 24 часа, но инструмент помог его принудительно.

Это кеш, который, конечно, обновляется, это то, что кеш нужно делать время от времени. Так что ожидание в конечном итоге сработает, но иногда вам нужно делать это быстрее. Смена имени файла работает.

У меня тоже была эта проблема. Скребок показывает правильную информацию, но URL-адрес общего ресурса по-прежнему заполнен старыми данными.

Я решил использовать метод подачи вместо совместного использования, а затем заполнить данные вручную (что не отображается в методе совместного использования).

Что-то вроде этого:

shareToFB = () => {
    window.FB.ui({
    method: 'feed',
    link: `signup.yourdomain.com/?referrer=${this.props.subscriber.sid}`,
    name: 'THIS WILL OVERRIDE OG:TITLE TAG',
    description: 'THIS WILL OVERRIDE OG:DESCRIPTION TAG',
    caption: 'THIS WILL OVERRIDE THE OG:URL TAG'
  });
};

Действительно простое решение. Проверено и работает. Вам просто нужно сгенерировать новый URL-адрес при обновлении метатегов. Это так же просто, как добавить «& cacheBuster = 1» к вашему URL-адресу. Если вы измените метатеги, просто увеличьте "& cacheBuster = 2"

Исходный URL

www.example.com

URL при обновлении метатегов og:

www.example.com?cacheBuster=1

URL при повторном обновлении метатегов og:

www.example.com?cacheBuster=2

Facebook будет рассматривать каждый как новый URL-адрес и получать свежие метаданные.

Спустя годы это все еще распространенная проблема, но это не всегда кеш facebook: очень часто это человеческая ошибка (позвольте мне уточнить)

OG: TYPE влияет на очистку изображения:

1. https://ogp.me/#type_article не то же самое, что https://ogp.me/#type_website

Имейте в виду, что og: type = website приведет к тому, что любые / подстраницы / этого URL станут «каноническими». Это означает, что у вас будут проблемы с обновлением изображений с помощью скребка, что бы вы ни делали.

Считайте это "предположением и распространенной ошибкой"

-<meta property="og:type" content="website" /> => https://www.example.org (родительский)
-<meta property="og:type" content="website" /> => https://www.example.org/sub-page/
-<meta property="og:type" content="website" /> = > https://www.example.org/sub-page/child-2/
- Ergo: /sub-page/ и /child-2/ унаследуют og:image родителя

Это не «все сайты», 1 - это сайт, остальные - статьи.

Если вы это сделаете, Facebook сочтет все это каноническим и поместит ПЕРВОЕ изображение во все из них. (попробуйте, вы увидите) - если вы установите og: url в качестве корневого или родительского домена, вы сказали facebook, что все они канонические. (для этого есть веская причина, но это не по теме)

Рассмотрите это решение (это то, чего "действительно хочет" большинство людей)

-<meta property="og:type" content="article" /> => https://www.example.org/sub-page/ < br> -<meta property="og:type" content="article" /> => https://www.example.org/sub-page/child-2/

Если вы сделаете это сейчас, Facebook даст вам гораздо меньше проблем с очисткой ваших НОВЫХ изображений.

В заключение, ДА, прерыватели кеша, случайные переменные, изменение URL-адресов и предложения здесь могут работать, но они будут выглядеть как «прерывистое вуду», если og:type не указан правильно.

PS: помните, что CDN или кеш на стороне сервера будут служить парсеру Facebook, даже если вы «думаете», что видите самую последнюю версию. (Я не буду тратить на это время, кроме как указать, что это будет тратить колоссальное количество вашего времени, если не будет дважды проверено.)

Недавно у меня была другая, но похожая проблема с Facebook, и я обнаружил, что упомянутая страница парсера / отладки просто не читает ни одну страницу целиком. Мои мета-свойства для Open Graph были ниже в разделе заголовка, и парсер постоянно сообщал мне, что спецификация изображения неверна, и в любом случае будет использовать кешированную версию. Я переместил теги Open Graph дальше в коде, в самый верх страницы, и каждый раз все работало идеально.

У меня была такая же проблема с fb и twitter, кешировавшими старые метаданные, это заставило меня задуматься, поскольку я продолжал редактировать код, но без изменений. Я наконец обнаружил, что они кэшировали мой первый запрос. Добавление строки запроса к URL-адресу сработало для твиттера, но не для fb (для меня).