Вбудоване зображення чи медіафайл потребує уваги

embedded_asset_broken · Проблема

Коротка відповідь

Перевірте адресу файлу разом з усіма сторінками, які його вбудовують. Один спільний файл може стосуватися багатьох сторінок, тому звіт групує їх під адресою в тому вигляді, у якому її було оголошено спочатку.

Серйозність: Низька. Відновіть файл або виправте посилання, коли наступного разу працюватимете з відповідними сторінками. Перш ніж щось змінювати, перегляньте обмеження доступу.

Чому це важливо

Браузер запитує вбудовані зображення й медіа за оголошеною адресою. Коли ця адреса не віддає файл, на сторінці може з’явитися порожнє місце або програвач, який не запускається.

Що зробити

  1. Прочитайте зафіксовану адресу файлу, відповідь і сторінки, які на нього посилаються. Запит може мати одну спробу або справжню повторну спробу; звіт зберігає те, що було прочитано.
  2. Якщо файл відсутній або видалений, відновіть його за цією адресою або змініть на кожній сторінці, що його оголошує, адресу на робочу. Перевірте кожну альтернативу в srcset і picture: кожна оголошена адреса перевіряється окремо.
  3. Для HTTP 401, 403 чи 451 спершу перегляньте правила автентифікації, CDN, брандмауера та регіональні правила. Якщо помилка сервера повторюється, перевірте сервер або сховище, яке віддає файл.

Коли залишити як є: Файл, доступ до якого навмисно обмежено лише для відвідувачів, що увійшли в обліковий запис, або для певного регіону, може відповідати сканеру аудиту кодом 401, 403 чи 451. Залиште обмеження, якщо воно задумане.

Що ми читаємо

Ми читаємо оригінальний HTML сторінки: img src і srcset, source src і srcset всередині picture, video чи audio, video src і poster, а також audio src. Вміст усередині head, script, style, template і noscript не враховується. Зображення з CSS, файли, додані JavaScript, і звичайні посилання не входять до цієї перевірки.

Спільний збір ресурсів запитує кожну вибрану адресу в межах наявних обмежень на кількість запитів і байтів. Для висновку потрібна справжня відповідь на GET і повна перевірка кожної спроби на відомі ознаки сторінки перевірки на бота.

Сторінки, що оголошують ту саму нормалізовану адресу, утворюють одну групу. Ідентичністю пункту є адреса в тому вигляді, у якому її оголошено спочатку; переспрямування файлу чи зміна списку сторінок не створює нового пункту.

Приклад і докази

Ілюстративний приклад — одне вбудоване зображення та його зафіксована відповідь, а не реальний аудит.

<picture>
  <source srcset="https://bakery.example/images/cake-wide.webp" type="image/webp">
  <img src="https://bakery.example/images/cake.png" alt="Layered cake">
</picture>

Якщо зафіксований запит GET до https://bakery.example/images/cake.png отримує відповідь HTTP 404 і ознак перевірки на бота немає, звіт групує під цією адресою всі відомі сторінки, що її оголошують. Альтернатива у форматі WebP — окрема адреса з власним результатом.

Можливе виправлення: відновіть цю адресу або змініть кожну сторінку, яка на неї посилається. Повна відповідь HTTP 200 разом із повною перевіркою, що не виявила ознак перевірки на бота, може пройти перевірку доступності; вона не доводить, що зображення відображається правильно.

Підтвердити й перевірити знову

Перевірте самі: Відкрийте вказану адресу безпосередньо. Перегляньте код сторінок зі списку й знайдіть кожне посилання на неї, зокрема альтернативи в srcset і атрибути poster. Якщо відповідь обмежена, порівняйте результат без входу в обліковий запис.

Повторна перевірка: Повний аудит — Запустіть новий повний аудит, коли зміна вже діятиме на сайті. Щоб закрити проблему, потрібне повне чисте порівняння для оригінального ресурсу й кожної сторінки, яка раніше була зафіксована як така, що на нього посилається. Її може закрити відповідь HTTP 200, що відповідає умовам, або повністю прочитані сторінки, які більше не посилаються на цей ресурс. Відсутні сторінки, часткові джерела, нерозв’язані перевірки на бота чи неповний початковий список сторінок не можуть довести виправлення.

Обмеження та джерела

Ми перевіряємо доступність за зафіксованою відповіддю та повними даними перевірки на ознаки сторінки перевірки на бота. Ми не перевіряємо формат медіа, не рендеримо сторінку й не відтворюємо файл; успішна відповідь не доводить правильного відображення.

HTTP 408, 425, 429 та інші статуси 4xx, одиночна чи непослідовна помилка сервера, тайм-аут, сторінка перевірки на бота, відповідь лише на HEAD, частково збережена відповідь і адреса, яку сканеру аудиту не дозволено запитувати, залишаються непідтвердженими. Їх не позначають як зламані, і вони не доводять виправлення.

Атрибути відкладеного завантаження на кшталт data-src, посилання, створені JavaScript, зображення з CSS і вміст усередині svg чи math не оцінюються. Сторінка, чий перелік HTML неповний або перевищує обмеження аудиту на читання, залишається непідтвердженою.

Відповідь — це та, яку отримав сканер аудиту; CDN, брандмауер чи регіональне правило можуть відповісти відвідувачу інакше. Якщо попередній аудит не зміг зафіксувати всі сторінки, що оголошують адресу, пізніший частковий список не може закрити пункт.

Упевненість: Висока Висновки щодо проблем спираються на точні зафіксовані відповіді на GET із повною перевіркою на ознаки перевірки на бота. Обмеження доступу має низьку впевненість, бо описує лише доступ сканера аудиту.

Джерела

  • Google Crawling Infrastructure, Як коди статусу HTTP впливають на сканери Google — Пояснює, як Google обробляє клієнтські й серверні помилки HTTP. Аудит застосовує вужчі умови для зафіксованих відповідей, описані тут; це джерело не доводить, що отримав браузер чи Google. Перевірено 11 жовтня 2026.

Редакційна перевірка: 2 листопада 2026