У мене проблеми з метатегами з Open Graph. Схоже, Facebook кешує старі значення моїх метатегів. Старі значення для атрибутів og:titleі og:urlдосі використовуються, хоча я вже їх змінив.

Я побіг Лінта на сторінці свого сайту , і це з’явилося:

Зауважте, що є два значення для og:titleі og:url, і останнє переважало. Однак останні два записи - це СТАРІ записи, які я використовував для цього сайту. Зараз я використовую ці метатеги (ви можете перевірити, чи переглядаєте джерело HTML):

<meta property="og:title" content="Smart og rummelig pusletaske fra Petit Amour med god plads til alt &#8211; værdi 1.099 kr &#8211; køb nu kun 599 kr   "/>
<meta property="og:description" content="Pinq.dk - Det gode liv for det halve"/>
<meta property="og:type" content="product"/>
<meta property="og:url" content="http://pinq.dk/tilbud/landsdaekkende/lissy/"/>
<meta property="og:image" content="http://pinq.dk/wp-content/themes/pinq/images/logo-top.png"/>
<meta property="og:site_name" content="Pinq" />
<meta property="fb:app_id" content="161840830532004" />

Чому кешування Facebook og:titleі og:url? Хтось стикається з тією ж проблемою?

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

Я сподіваюся, що це допомагає.

Найбільш проголосоване питання є досить застарілим:

Це єдині два варіанти, які слід використовувати з листопада 2014 року :

Для не розробників

1. Використовуйте FB Debugger: https://developers.facebook.com/tools/debug/og/object
2. Вставте URL, який потрібно повторно змінити. (Переконайтеся, що ви використовуєте той самий URL, який включений у ваш тег og: url)
3. Ще раз натисніть кнопку Інформація про видобуток

Для розробників

1. Здійснюйте виклик GET програмно за цією URL-адресою: https://graph.facebook.com/?id= evidenceYOUR_URL_HERESense&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, перегляньте "відповідь" у console.log - там ви знайдете поле "updated_time" та іншу корисну інформацію.

Здається, мініатюра OG не оновлюється, навіть якщо передає змінну fbrefresh. Щоб оновити це, не чекаючи автоматичного очищення, вам потрібно буде змінити ім'я файлу мініатюри, пов’язане із значенням метатегів та оновити.

У мене були ті самі проблеми, що використовуються og:image , кілька спроб перейменувати файл чи очистити кеш-пам'ять FB не спрацювали ні через налагоджувач у Facebook, ні на тестуванні через фактичний рахунок.

Нові вказівки у фейсбуці зазначають, що розмір зображення повинен бути 1200 x 630 або мати таке співвідношення сторін, це здається, що це неправильно, єдине, що працювало для мене, - це використання зображення з квадратними розмірами .

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

Я також перейменував файли на f * ^ * kfacebook.jpg, не впевнений, що це допомогло, але він почував себе добре.

В основному, відповідь - терпіння;)

Я перевірив Linter сьогодні вранці, і og: title та og: url відображається правильно, без зайвих значень. Я думаю, що FaceBook автоматично очищає кеш-пам'ять через певний інтервал. Мені просто чекати.

Ми просто зіткнулися з цим, як виявляється, ми не зв’язували потрібну URL-адресу, оскільки в реальному URL-адресі був рядок запиту (так, на сторінці бота інша сторінка).

http://example.com/

! ==

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

Лінтера буде помістити в кеш сторінки, ви не повинні чекати.

Так, facebook автоматично очищає кеш-пам'ять кожні 24 години: насправді фейсбук обчислює сторінки та оновлює кеш кожні 24 години https://developers.facebook.com/docs/reference/plugins/like/#scraperinfo .

Ooook, нарешті це допомогло (я використовую IP.Board). Що я повинен був зробити:

1. Змінити URL-адресу og: image на моєму веб-сайті (Загальна конфігурація).
2. Спробуйте цей метод за допомогою? Fbrefresh = 1154464gd56

Дякую автору за цю тему!

EDIT: Що ще потрібно пам’ятати про вимоги до зображення. Наразі (січень 2013 р.) Це: - принаймні 200 пікс в обох напрямках - максимальне співвідношення 3: 1

1. Відвідайте сторінку FB https://developers.facebook.com/tools/debug/og/object/
2. Введіть свій домен.
3. Натисніть кнопку "Отримати нову інформацію про скребок"
4. Зроблено

Варто додати, що URL-адреса відрізняється від регістру . Зауважте, що:

apps.facebook.com/ HELLO

тоді в очах лайнера різна

apps.facebook.com/ привіт

Не забудьте скористатися точним URL-адресом сайту, який було введено в налаштуваннях розробника для додатка. Лінійник поверне властивості інакше, але не оновить кеш.

Вибачте, але правильна відповідь:

Не існує дурного доказу способу оновити відкритий графік og: image URL з негайним результатом. Він зберігається в кешованому режимі до оновлення fb (повідомляється кожні 24 години)

Ось речі, про які, як повідомлялося, працюють інші, але я мав успіх у ZERO з будь-яким із них.

• Вибір "Отримати нову інформацію про скріплення"
• Зміна фактичного імені файлу зображення та / або видалення оригіналу
• Додавання рядка запиту до URL-адреси зображення, додавши PHP TIMESTAMP або?
• Додавання рядка запиту "... tvojeite.com/?fbrefresh=anything" до URL-адреси пошуку відладчика
• Вибір посилання API графіки внизу сторінки og dev
• Вибираючи, щоб точно побачити те, що бачить скрепер - не видається, щоб запитувати дані про скрепіння в кеш-пам'яті в режимі реального часу, він все ще показує URL-адрес кешованого зображення, навіть якщо файлу більше не існує

Перевірка вашого коду завжди є місцем для підтвердження, що це не проблема кешу браузера чи якоїсь послуги кешування. Якщо мета-інформація у вашому коді актуальна, і ви спробували все вищесказане (якщо інша пропозиція не вдається), правильна відповідь - ви не можете нічого не чекати, як чекати .

Я з’ясував, що якщо ваше зображення становить 72dpi, це призведе до помилки розміру зображення. Використовуйте замість цього 96dpi. Сподіваюся, це допомагає.

1. Перейдіть на сторінку http://developers.facebook.com/tools/debug

2. Вставте URL-адресу сторінки та натисніть налагодження. Якщо ваш сайт використовує псевдоніми url, переконайтеся, що ви використовуєте той самий URL, який використовує Facebook для сторінки, яку ви обмінюєтесь (наприклад: в Drupal використовуйте шлях до вузла / * замість псевдоніму, якщо сторінка надається через цей URL).

3. Натисніть на частину "Попередній перегляд" на посилання "Дивіться це у діалоговому вікні спільного доступу"

Facebook Developer Documents каже, що властивість заголовка має виняток:

Щойно 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-адреса при оновленні мета-тегів:

www.example.com?cacheBuster=1

URL, коли мета-теги og знову оновлюються:

www.example.com?cacheBuster=2

Facebook ставиться до кожного, як до нового URL-адреси, і отримає нові метадані.

Через роки, і це все ще є загальною проблемою, але кеш не завжди у фейсбуці: це дуже часто людська помилка (дозвольте мені детальніше)

OG: TYPE впливає на вичісування зображення:

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

Майте на увазі, що og: type = веб-сайт призведе до того, що будь-які / підсторінки / цього 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 /
- Ерго: /sub-page/і /child-2/успадкує og:imageбатьківське

Це не "всі веб-сайти", 1 - це веб-сайт, інші - статті.

Якщо ви зробите це, Facebook подумає, що все це є канонічним, і він поставить ПЕРШИЙ og: image у всі вони. (спробуйте, ви побачите) - якщо ви встановите, щоб og: url був вашим кореневим або батьківським доменом, ви сказали у Facebook, що вони все канонічні. (для цього є вагомі причини, але це поза темою)

Розглянемо це рішення (чого саме більшість людей "дійсно хочуть")

- <meta property="og:type" content="article" />=> https://www.example.org/sub-page/
- <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 далі в коді, біля самої верхньої частини сторінки, і тоді все працювало чудово, кожен раз.