Base64 кодував зображення та наявність своїх метаданих для Googlebot


9

Якщо я вставляти зображення в сторінку як img- srcз base64 даними URI, є метадані зображення ( в EXIF, IPTC, XMP) по- , як і раніше доступні для ImageBot Google?


1
Напевно, ні. Googlebot, ймовірно, потребує URL-адресу, до якої він може оцінювати та посилати користувачів.
Джон Конде

1
Забудьте дані EXIF, я навіть не впевнений, що зображення Google навіть індексують зображення, яке не має власної URL-адреси.
Стівен Остерміллер

@StephenOstermiller: ось питання: якщо він індексує такі зображення, то він також читає EXIF
Євген

@Evgeniy Як зазначає Стівен, URI-адреси даних не відокремлюються від документа, що містить його (див. Це докладніше). URL-адреси пошукових систем індексують, тож індексуватиметься лише документ, що містить документ, і чи індексуватимуть вони метадані, що містяться в URI даних (якщо він теж містив це, роблячи його ще більшим), є недійсним моментом. Для підтвердження ви можете використовувати пошукову систему вихідного коду, щоб шукати URI даних, а потім перевірити, чи було це зображення індексовано та чи містить інформацію EXIF ​​в Google. Це здається дуже малоймовірним.
дан

@Evgeniy Зауважимо, що перехресне опублікування того ж питання на більш ніж одному сайті Stack Exchange не потурає.
дан

Відповіді:


6

Google не індексує зображення URI даних для пошуку зображень Google. Джон Мюллер від Google говорить про це тут і в коментарях нижче. Оскільки зображення URI даних не індексуються в пошуку зображень Google, дані EXIF ​​у них не мають значення.

Ви можете переконатися, що ці зображення не індексуються. Я шукав зображення в Google на "дані uri" і на місці перевіряв результати. Усі переглянуті нами зображення були файлами зображень, а не URI зображення закодованого зображення base64. Ви можете подумати, що якби Google вдалося проіндексувати зображення URI даних, деякі з них відображатимуться в результатах пошуку цього терміна.

Якщо Google коли-небудь вирішить індексувати зображення URI даних, вони повинні мати можливість отримати дані EXIF ​​з них. Data uri - це весь файл64, закодований (без пробілів та нових рядків) з data:image/png;base64,префіксом. Будь-які метадані у файлі все ще будуть міститись у версії URI з кодованими базовими даними.

Я використовую зображення URI даних на одному зі своїх веб-сайтів. Я роблю це тому, що користувачі зазвичай просто переглядають одну сторінку на сайті, щоб отримати всю необхідну їм інформацію. Включення всіх вбудованих даних CSS, JS та зображень на сторінку значно покращує продуктивність. Зображення всі невеликі, тому техніка працює особливо добре.

Мій сайт отримує значну кількість трафіку від Internet Explorer 7 і новіших версій, які не підтримують зображення URI даних. Тому я маю їх обслуговувати умовно. У мене також є зображення на сервері, і я вибираю регулярні URL-адреси зображень або URI даних на основі User-Agentзаголовка. Я ставлюся до ботів (включаючи Googlebot) так само, як до IE 7, тобто я подаю зображення як URL-адреси HTTP. Я роблю це, тому що включення даних uri-зображення різко збільшує розмір сторінки. Більшості ботів не потрібно завантажувати зображення, тому для них це більш ефективно. Я також помітив, що Google Webmaster Tools повідомляв, що Googlebot набагато повільніше сканує мій сайт із включеними зображеннями URI даних. Це технічно можна вважати маскуванням, але це був би спосіб індексувати ваші зображення URI даних.


2
Ваш перший приклад індексується за цією URL-адресою: photos.topicshow.com/…, а ваш другий за цим: images5.fanpop.com/image/photos/30600000/… У всіх випадках, які я міг знайти, є http URL для зображення так само.
Стівен Остерміллер

1
Кодована рядок @StephenOstermiller може містити пробіли: goo.gl/RF8r07 . я заповнюю зображення EXIF, кодую його, публікую і дивлюсь, чи входить він в індекс.
Євгеній

3
Джон Мюллер (від Google) вказує тут, що Google, як правило, не індексує зображення з URI даних. Багато інструментів в Інтернеті, які використовуються для кодування цих даних, також знімуть метадані, тому це дійсно залежить від того, яким чином вона кодується, чи зберігається інформація EXIF ​​... але враховуючи, що вони все одно не індексуються, це суперечка. Повідомте нас про ваші результати (не забудьте не дати URL-адресі зображення індексуватися - Google також використовує розпізнавання зображень, щоб EXIF-інформація могла використовуватися для відповідних зображень).
дан

1
@dan дякую! ваше посилання на відповідь Джона Мюллера очищує багато речей зараз! Якщо G не індексує зображення, де він не може отримати URI, тому не потрібно думати про те, залишається EXIF ​​всередині чи ні.
Євгеній

3
Як зазначено вище, ми наразі не індексуємо їх як зображення окремо. Це може змінитися в майбутньому, але хоча б на даний момент ви хочете використовувати окремі URL-адреси зображень, якщо ви хочете, щоб ці зображення були індексовані в пошуку зображень.
Джон Мюллер

2

Хоча Google використовує зображення як кодовані URI даних base64 на власній SERP, він не індексує подібні зображення на інших веб-сайтах. Дякую @dan, який вказав мені на дискусію в групах Google, де Джон Мюллер пояснює це питання . Це також означає, що питання про існування EXIF-даних на таких зображеннях не є актуальним.

Це пояснення дає зрозуміти, до яких зображень краще застосовувати цю техніку оптимізації продуктивності: невеликі зображення, як іконки, фавікони та кнопки, і ті зображення, які не надають додаткової цінності вмісту сайту.

З іншого боку, якщо один категорично повинен вбудовувати зображення з додатковим значенням вмісту як URI з кодованими даними base64, єдиною найкращою практикою надання метаданих зображення є використання розмітки Schema.org, де можна узгодити дані EXIF, наприклад, з цим вид розмітки.

Ще один багатообіцяючий вид розмітки для узгодження даних, схожих на "властивість: значення", як EXIF, на даний момент має статус пропозиції. Але ця стаття з блогу Google показує структуровані фрагменти, які можуть бути згенеровані пропозицією щодо розмітки i, пов'язаною вище.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.