Полный SEO-аудит - myluminette.com

Анализ 11 измерений (техническое SEO, контент, структурированные данные, sitemap, производительность, визуал/мобильная версия, ИИ/GEO, поисковый опыт, e-commerce, семантический кластеринг, ссылочный профиль) на e-commerce сайте Shopify с множеством локальных рынков.

Дата аудита: 24 июля 2026 · Очки и лампы фотобиомодуляции (светотерапия), франко-бельгийский бренд (группа Lucimed), 24 варианта рынков ЕС/международных, активный блог из примерно 130 статей. Нет физических точек продаж - локальное SEO обоснованно вне периметра.

57 / 100 Скор здоровья SEO

Сигнал YMYL - прочитать перед остальной частью отчёта

Luminette - это устройство светотерапии медицинского/wellness назначения, с заявлениями о физиологическом и психическом здоровье (сон, сезонная депрессия, энергия, настроение). Google применяет повышенный уровень строгости (E-E-A-T) к такому типу контента. Пробелы, выявленные здесь - неподтверждённая источниками статистика эффективности, отсутствие видимых credentials автора, отсутствие упоминания медицинской проверки - отмечены с повышенной важностью на протяжении всего отчёта и должны рассматриваться как приоритет для бизнеса, а не как косметическая деталь.

Скоры по измерениям

Взвешенное среднее по 10 оцененным измерениям (Техническое SEO, Контент, Schema, Sitemap и Производительность взвешены сильнее как основа SEO; Визуал, GEO, SXO, E-commerce и Кластеринг - вспомогательные). Ссылочный профиль исключён из этого среднего - квота Ahrefs была исчерпана в ходе аудита, см. отдельный раздел.

Техническое SEO

74/100

Контент

58/100

Schema

52/100

Sitemap

66/100

Производительность

55/100

Визуал / Мобильная

64/100

ИИ / GEO

58/100

SXO

38/100

E-commerce

58/100

Семантический кластеринг

32/100

Ссылочный профиль

~30-40*

Ненадёжно - уверенность 0,25

≥70 - надёжно 50-69 - требует улучшения <50 - критично Не оценено / недостаточно данных

Рейтинг измерений по скору

Техническое SEO

Sitemap

Визуал / Мобильная

Контент

E-commerce

ИИ / GEO

Производительность

Schema

SXO

Кластеринг

Ссылочный профиль*

н/д

*Ссылочный профиль: плейсхолдер ~30-40/100 основан только на Common Crawl (уверенность 0,25) после исчерпания квоты Ahrefs в ходе аудита - не считать реальным скором, детали см. в отдельном разделе.

Executive-резюме

Центральное противоречие сайта

myluminette.com опирается на необычно прочный технический и инфраструктурный фундамент для международного e-commerce сайта с 24 локалями (чистый hreflang, корректные canonicals, действительно локализованный по рынкам перевод, серверный рендеринг, в целом согласованный robots.txt, валидная архитектура sitemap) - но этот фундамент не конвертируется в поисковую видимость, потому что опирается на хрупкий слой контента/авторитетности: фрагментированный и самоканнибализирующийся блог, отсутствующие структурированные данные Review/Rating несмотря на активные платформы отзывов, и - самое существенное для бренда с YMYL-коннотацией - реальная научная credibility (названные университетские исследователи, реальные клинические исследования), которая нигде на сайте не видна, не цитируема и не засчитана таким образом, чтобы её могли использовать Google или ИИ-движки.

Топ-5 критических выводов (по всем измерениям)

Ни одних структурированных данных Review/AggregateRating несмотря на три активные платформы отзывов (Okendo, Trustpilot, Loox) и более 1700 видимых отзывов. Это самый повторяющийся вывод всего аудита - независимо обнаружен в Schema, E-commerce, GEO и SXO. Звёзды отзывов - главный рычаг доверия/конверсии для взвешенной wellness-покупки, и сейчас они невидимы для Google и ИИ-движков.Schema - Критично
Карточки восстановленных (reconditionne) товаров декларируют itemCondition: NewCondition в своей schema, хотя продаются как восстановленные - реальный риск отклонения или приостановки карточки в Google Merchant Center из-за несоответствия состояния товара.E-commerce - Критично
Ноль присутствия бренда в SERP по информационным и сравнительным запросам с наивысшим интентом сайта ("светотерапия сезонная депрессия", "лучшая лампа светотерапии") - конкуренты и чисто редакционные домены полностью владеют этими запросами.SXO - Критично
Серьёзная каннибализация контента: блог из примерно 130 статей распределён по 4 параллельным и пересекающимся структурам URL, причём такие темы как "зимняя хандра" (8 статей) и "витамин D" (6 статей) фрагментированы вместо консолидации, плюс старый pillar-хаб, который отдаёт 404, оставаясь при этом проиндексированным.Семантический кластеринг - Высокая, уровень архитектуры
Заявления о здоровье/эффективности на YMYL-контенте не подкреплены источниками и не имеют видимых credentials: клинические исследования с точными процентами ("улучшение сна на 68%") не имеют исходящих ссылок на PubMed/NCBI, а флагманская медицинская статья блога цитирует автора без видимой био, credentials или упоминания медицинской проверки на странице.Контент - Высокая; независимо подтверждено в GEO - Средне-высокая

Топ-5 быстрых побед (по всем измерениям)

Исправить утечку кода рынка/страны в теги <title> и meta description (напр. "...Site officiel\n\n BE") - единый баг Liquid-шаблона, затрагивающий все страницы сайта; один фикс распространяется на весь сайт.Техническое SEO / E-commerce - Высокая серьёзность, низкие усилия
Заменить itemCondition с NewCondition на RefurbishedCondition в schema восстановленных товаров - единичное исправление значения на блок Offer.E-commerce - Критическая серьёзность, низкие усилия
Добавить schema FAQPage к уже существующему FAQ-контенту на карточке Luminette 3 и во флагманской статье "работает ли светотерапия" - Q/A-контент уже существует, не хватает только разметки.Контент / Schema / GEO - Средне-высокая серьёзность, низкие усилия
Исправить некорректный регистр @type: "Website" (должно быть "WebSite") через глобальный поиск/замену, и добавить URL профиля Trustpilot в массив sameAs Organization.Schema - Высокая серьёзность, низкие усилия
Добавить исключения Allow: в robots.txt для /policies/*, чтобы ИИ-роботы могли получить доступ к страницам, которые llms.txt им явно обещает - устраняет прямое противоречие в собственных инструкциях сайта для ИИ-роботов.GEO - Высокая серьёзность, низкие усилия

Сквозные выводы

Несколько выводов независимо появляются в разных измерениях аудита, что усиливает уверенность в общей коренной причине и оправдывает соответствующую приоритизацию.

1. Баг кода рынка в заголовке - это один и тот же баг, найденный дважды

Техническое SEO (вывод 1) и E-commerce (вывод 2) независимо выявили один и тот же дефект Liquid-шаблона: сырые двухбуквенные коды рынка, просачивающиеся в <title>/meta description с поломанными пробелами, на всех типах страниц и всех локалях. Это единый фикс с эффектом на весь сайт, а не две отдельные проблемы.

2. Противоречие индексации коллекций - это конфликт трёх сторон

Техническое SEO (вывод 2) и Sitemap (вывод 1) оба сообщают, что /collections/* одновременно заблокированы в robots.txt, помечены noindex и поданы в sitemap. GEO (вывод 1) добавляет ещё один поворот: llms.txt явно просит ИИ-агентов получать /collections/{handle} и /policies/* - пути, которые robots.txt блокирует для всех роботов, включая ИИ-роботов. Собственные сигналы контроля crawl сайта противоречат друг другу и собственным инструкциям для ИИ-агентов.

3. Schema отзывов/рейтинга - самый повторяющийся пробел всего аудита

Schema (вывод 1, Критично), E-commerce (вывод 3), GEO (вывод 5) и SXO (вывод 4 - "пространство отзывов уступлено Trustpilot") независимо сходятся к одной и той же коренной проблеме: более 1700 реальных отзывов на трёх активных платформах (Okendo, Trustpilot, Loox) существуют, но нигде не выражены в schema aggregateRating/Review. Это одновременно самое эффективное и самое дешёвое исправление всего аудита.

4. Сложность мульти-локали/hreflang повторяется в Техническом SEO, Sitemap и Кластеринге

Техническое SEO подтверждает, что сам hreflang корректен и взаимен. Sitemap сообщает о нерешённом вопросе дублирования /nl/ vs /nl-nl/. Кластеринг независимо выявляет дублирование варианта локали в своём анализе каннибализации (напр. дубли /en-ua англоязычного контента). По отдельности ни одно из этого не критично, но вместе они описывают структуру из 24 рынков, которой нужен единый владелец, чтобы подтвердить, какие пары локалей - намеренные рынки, а какие - legacy-артефакты.

5. Пробелы E-E-A-T/цитирования на YMYL-контенте повторяются в Контенте, GEO и SXO

Контент (вывод 1) сообщает о статистике эффективности без ссылок. GEO (вывод 3) независимо сообщает о поверхностных credentials автора той же флагманской статьи. GEO (вывод 6) сообщает об отсутствии сигналов сущности YouTube/Wikipedia. SXO (вывод 1) сообщает, что бренд имеет нулевое присутствие по запросу с точной медицинской формулировкой ("светотерапия сезонная депрессия"), где эта credibility значила бы больше всего. Бренд обладает базовыми активами (названные университетские исследователи, реальные данные клинических испытаний) - проблема системно в том, чтобы их выявить и процитировать, а не в их отсутствии.

6. Фрагментация архитектуры контента - одна коренная причина, проявляющаяся в трёх ипостасях

Вывод о каннибализации по 4 силосам из Кластеринга, наблюдение SXO, что французский контент сидит на английских URL-слагах, и вывод Контента, что блог показывает паттерны риска "контент-фермы на ИИ" (шаблонные сравнения, байлайны без credentials, почти-дублирующиеся сезонные статьи) - всё это следствие одного и того же недисциплинированного процесса производства контента на более чем 130 статьях и 24 локалях, без таксономии или владельца консолидации.

7. Баг размеров изображений/CLS проявляется на двух уровнях детализации

Производительность (вывод 3: 291 изображение без размеров на карточке товара) и Техническое SEO (вывод 3: 26 на главной странице) - это один и тот же системный баг шаблона, замеченный на разных типах страниц - подтверждает, что это общий сниппет Liquid для изображений, а не проблема, специфичная для одной страницы.

1. Технические основы

Техническое SEO, Sitemap и Schema формируют инфраструктурный слой сайта: crawlability, индексируемость и структурированные данные. Это самая сильная часть аудита (Техническое SEO 74/100), но и та, где больше всего исправлений с низкими усилиями и высоким эффектом.

Техническое SEO (74/100)Sitemap (66/100)Schema (52/100)

Техническое SEO

74/100

Редкий технический фундамент для сайта с 24 локалями: hreflang, canonicals и серверный рендеринг - всё в порядке; оставшиеся проблемы - локализованные баги шаблонов, а не архитектурные дефекты.

Источники проверены вживую (curl): главная + локали по умолчанию FR/BE, /fr-fr, /de-de, /nl, /en-gb, /en-us, карточка товара luminette-3 на 3 локалях, 2 страницы коллекций, 2 статьи блога, 1 внутренняя служебная страница, robots.txt, sitemap.xml + под-sitemap. Платформа Shopify (тема на основе Dawn) на Shopify Markets, за Cloudflare.

Что работает хорошо

robots.txt валиден и корректен, блокирует только checkout/корзину/админку/поиск/policies/collections/preview, без случайной блокировки всего сайта; корректно указывает Sitemap: https://myluminette.com/sitemap.xml.
Хорошо структурированная архитектура sitemap: индекс, разветвляющийся на под-sitemap по рынкам (товары/страницы/коллекции/блоги) для 24 отдельных префиксов рынок/локаль, с lastmod и расширениями для изображений.
Обширная и структурно корректная реализация hreflang: 242 тега hreflang на страницу, взаимность и self-reference проверены на всех выбранных локалях.
Корректные canonical-теги с учётом локали повсюду, включая нормализацию конечного слэша на карточках товара.
Контент локали действительно переведён, а не задублирован - проверено на статье блога (FR по умолчанию vs EN-GB), отдельный и полностью переведённый текст.
Нет зависимости от рендеринга JavaScript: главная, карточки товара и блог полностью рендерятся на стороне сервера Shopify.
Структурированные данные присутствуют и синтаксически чисты (WebSite/Organization на главной, ProductGroup/BreadcrumbList на карточках товара).
Чистая гигиена HTTPS/редиректов: редиректы в один переход, цепочек редиректов не найдено; валидный TLS-сертификат.
В основном надёжные security-заголовки (CSP, X-Frame-Options, X-Content-Type-Options, X-XSS-Protection, HSTS присутствуют).
Транспорт, благоприятный для производительности: HTTP/2, сжатие Brotli, 103 Early Hints с preconnect/preload для CSS и шрифтов.
Мобильный viewport корректно настроен по всему сайту; 404 отдают настоящие коды 404 (не soft-404).
Файл обнаружения для ИИ-роботов /agents.md (связан из sitemap_agentic_discovery.xml) - опережает большинство конкурентов на этом развивающемся направлении.

Выводы (8)

Код рынка/страны просачивается в сыром виде в теги <title> и meta description по всему сайту

Высокая

Каждая проверенная страница - главная, все локали, карточки товара, страницы коллекций, статьи блога, даже внутренняя тестовая страница - имеет двухбуквенный код рынка, добавленный к тегу <title> с поломанными пробелами/переносами строк, например:

<title>
      Luminette(r) : Lunettes et lampes de luminotherapie | Site officiel

      BE
    </title>

Подтверждено на нескольких рынках: /fr-fr -> "...| Site officiel\n\n FR", /de-de -> "...Offizielle Webseite\n\n DE", /en-gb -> "...Official website\n\n GB", /en-us -> "...Official website\n\n US". Та же картина в meta description главной. Заголовки страниц коллекций дополнительно повреждены буквальной сущностью – и лишним переносом строки. Это баг шаблона (вероятно, неэкранированная/неочищенная переменная Liquid), а не намеренный брендинг - влияет на SERP-сниппет, отображаемый Google, практически для каждого URL сайта, на тысячах комбинаций товар/блог/страница/локаль.

Рекомендация: исправить Liquid-шаблон title/meta-description темы, чтобы удалить или корректно отформатировать конкатенацию кода рынка, без лишних пробелов. Один фикс распространяется на весь сайт; после исправления перекраулить выборку страниц по локалям для подтверждения.

Страницы коллекций одновременно заблокированы в robots.txt, помечены noindex и поданы в XML sitemap

Средняя

robots.txt содержит Disallow: */collections, что блокирует доступ краулера ко всем URL /collections/*. Независимо от этого, проверенные страницы коллекций (/collections/accessories, /collections/refurbished-main-nav) также несут <meta name='robots' content='noindex'>. При этом все три URL коллекций перечислены в sitemap_collections_1.xml, продублированы на 24 под-sitemap локалей, и поданы на краулинг. Google не может увидеть тег noindex, потому что robots.txt мешает ему получить страницу - это обычно приводит к предупреждениям "Проиндексировано, хотя заблокировано robots.txt" в Search Console, если на эти URL ведут ссылки, и расходует бюджет краулинга.

Рекомендация: выбрать единый механизм. Если эти страницы никогда не должны появляться в результатах поиска - убрать их из XML sitemap и полагаться на блокировку robots.txt (или только на тег noindex, не оба варианта плюс подача в sitemap). Если некоторые коллекции должны быть индексируемыми (что часто имеет реальную SEO-ценность на e-commerce сайте) - убрать noindex и блокировку robots.txt для этой коллекции и оставить её в sitemap.

Изображения с пустыми width/height, помеченные loading='lazy', на главной странице (риск CLS/LCP)

Средняя

Первые три изображения селектора товара, отрендеренные в <body> главной страницы (миниатюры Luminette 3 / Luminette 2 / Drive, вероятно, близко к или выше линии сгиба), доставляются с буквально пустыми атрибутами размеров: width='' height='' и loading='lazy'. Без подсказки соотношения сторон место не может быть зарезервировано до загрузки изображения - прямой риск CLS, усугублённый lazy-загрузкой, если одно из этих изображений на самом деле является элементом LCP. По всей главной странице 26 из 354 тегов <img> вообще не имеют width/height. На всей странице есть только 3 подсказки fetchpriority, ни один <link rel="preload"> не нацелен на предполагаемое hero-изображение.

Рекомендация: задать явные width/height (или CSS aspect-ratio) для каждого изображения селектора/hero. Определить реальный элемент LCP по шаблону и пометить его loading="eager" fetchpriority="high", оставив loading="lazy" только для изображений, действительно находящихся ниже линии сгиба.

Внутренняя тестовая страница публично доступна и индексируема

Низкая

https://myluminette.com/pages/test-form отдаёт HTTP 200, не имеет тега noindex, не заблокирована robots.txt, и присутствует в sitemap_pages_1.xml на всех локалях. Её заголовок "Formulaire de test - Luminette BE" явно указывает на забытую внутреннюю QA-страницу, никогда не предназначенную для публичного доступа.

Рекомендация: снять страницу с публикации в админке Shopify, либо добавить noindex и убрать её из sitemap, если она должна оставаться онлайн для внутреннего использования. Проверить отсутствие других подобных тестовых/черновых страниц /pages/*.

Политика HSTS с коротким сроком действия, без includeSubDomains/preload

Низкая

Strict-Transport-Security: max-age=7889238 (~91 день) присутствует, но значительно ниже рекомендованного минимума в один год (31536000с) для допуска в список предзагрузки HSTS, и не включает ни includeSubDomains, ни preload.

Рекомендация: если поддомены также полностью поддерживают HTTPS, поднять max-age до 31536000+ и добавить includeSubDomains; preload, затем подать домен в список предзагрузки HSTS. Настройка на уровне платформы (Cloudflare/Shopify), не в теме.

Отсутствуют заголовки Referrer-Policy и Permissions-Policy

Низкая

CSP, X-Frame-Options, X-Content-Type-Options и HSTS присутствуют, но ни заголовок Referrer-Policy, ни Permissions-Policy не были возвращены на проверенных URL.

Рекомендация: добавить Referrer-Policy: strict-origin-when-cross-origin и базовый Permissions-Policy, ограничивающий неиспользуемые функции браузера, через настройки HTTP-заголовков Shopify или Transform Rule Cloudflare.

Протокол IndexNow не реализован

Инфо

Нет доказательств интеграции IndexNow - нет ссылки в исходном коде, /indexnow.txt отдаёт 404. Shopify не поддерживает IndexNow нативно без стороннего приложения.

Рекомендация: низкий приоритет, так как Google не использует IndexNow; стоит рассмотреть, если Bing/Yandex важны для конкретных рынков (ru-ru, pl-pl).

Примечание: рынок ru-ru онлайн и индексируем

Инфо

Локаль /ru-ru (русскоязычный рынок) полностью онлайн, отдаёт 200, и присутствует в sitemap и hreflang наряду с другими рынками ЕС. Бизнес/юридический вопрос, а не технический дефект.

Рекомендация: получить подтверждение от клиента, что это намеренный и в настоящее время обслуживаемый рынок, учитывая контекст санкций ЕС.

Sitemap

66/100

Зрелая архитектура sitemap, хорошо разбитая по типу контента и по рынку, но подорванная тем же противоречием с коллекциями, что и в измерении Техническое SEO, и нерешённым вопросом дублирования локали.

Что работает хорошо

robots.txt корректно указывает Sitemap: https://myluminette.com/sitemap.xml, валидный и доступный индекс.
Валидный индекс sitemap, логично разбитый на sitemap_products, sitemap_pages, sitemap_collections, sitemap_blogs.
Обширное покрытие по рынкам: 24 рынка/локали (nl, nl-nl, fr-fr, en-gb, en-us, en-au, en-ca, en-eu, en-nz, en-ua, de-de, de-ch, fr-ch, fr-ca, it-it, es-es, pl-pl, cs-cz, da-dk, fi-fi, no-no, sv-se, ru-ru, uk-ua) плюс корневой домен.
Далеко от лимита в 50 000 URL/файл, с доступной автоматической пагинацией.
Расширение sitemap для изображений используется на URL товаров; lastmod присутствует в большинстве записей; устаревших тегов priority не найдено.

Выводы (7)

Sitemap включает URL, заблокированные robots.txt (коллекции)

Высокая

sitemap_collections_1.xml (и варианты по локалям) перечисляет живые URL, такие как /collections/accessories, /collections/refurbished-main, /collections/refurbished-main-nav, тогда как robots.txt явно их disallow. Прямое противоречие, которое может вызвать предупреждения "Отправленный URL заблокирован robots.txt" в отчёте покрытия Search Console, снижая общий сигнал здоровья sitemap.

Рекомендация: убрать /collections из Disallow в robots.txt, если эти страницы должны индексироваться (вероятно, правильно для e-commerce сайта - страницы категорий обычно имеют реальную SEO-ценность), либо убрать sitemap_collections_*.xml из поданного индекса, если они намеренно исключены. Shopify генерирует этот sitemap нативно, вручную не редактируется - практическое решение - разрешить /collections в robots.txt.liquid темы.

Нет аннотаций hreflang в файлах sitemap

Средняя

Ни один из проверенных под-sitemap не содержит записей <xhtml:link rel="alternate" hreflang="...">. Каждый sitemap локали - независимый плоский список, без перекрёстной ссылки на свой эквивалент на других локалях.

Рекомендация: приемлемо, если hreflang в HTML <head> корректен (подтверждено измерением Техническое SEO) - Google принимает любой из методов, не обязательно оба одновременно. Кросс-проверка выполнена, действий не требуется, если HTML-hreflang остаётся надёжным.

Почти дублирующиеся пересекающиеся пути локалей: /nl/ vs /nl-nl/

Средняя

Индекс sitemap перечисляет два отдельных набора нидерландских sitemap с почти идентичной структурой URL: https://myluminette.com/nl/products/luminette-3 и https://myluminette.com/nl-nl/products/luminette-3 - потенциально два отдельных рынка (Бельгия-NL vs Нидерланды) или legacy-дубликат.

Рекомендация: подтвердить в настройках Shopify Markets, являются ли /nl/ и /nl-nl/ намеренно отдельными рынками с разной валютой/контентом, или /nl/ - это legacy-локаль, которую нужно консолидировать/перенаправить на /nl-nl/, чтобы избежать разбавления дублирующимся контентом.

Значения lastmod похожи на временную метку запроса, а не реальную дату изменения

Низкая

В sitemap_products_1.xml несвязанные товары (luminette-3, drive, garantie-4-ans, luminette-2, несколько аксессуаров) имеют одинаковое значение lastmod с точностью до секунды, что предполагает динамическую генерацию в момент запроса, а не отражение реальной истории изменений.

Рекомендация: стандартное нативное поведение Shopify, не исправляется через редактирование sitemap. Не полагаться на lastmod как сигнал свежести в отслеживании Search Console.

У записи главной страницы отсутствует lastmod

Низкая

Корневая запись в sitemap_products_1.xml не имеет тега <lastmod>, тогда как почти все остальные записи имеют.

Рекомендация: незначительно/косметически, вручную не исправить, так как sitemap нативен для Shopify - стоит отслеживать, повторяется ли паттерн на главных страницах локалей.

Нестандартная запись sitemap_agentic_discovery.xml

Инфо

Индекс включает https://myluminette.com/sitemap_agentic_discovery.xml, который содержит один URL: https://myluminette.com/agents.md. Недавняя функция Shopify, нацеленная на обнаружение ИИ-агентами/роботами.

Рекомендация: действий не требуется - безобидное и дальновидное дополнение. Подтвердить, что /agents.md действительно отдаёт 200, если обнаруживаемость ИИ-агентами важна для бренда.

changefreq присутствует, но функционально бездействует

Инфо

Все проверенные URL используют <changefreq>daily</changefreq> независимо от реальной частоты обновлений; Google официально игнорирует это поле.

Рекомендация: исправление не требуется, не стоит тратить инженерные усилия, так как это поле контролируется нативно Shopify.

Schema & структурированные данные

52/100

Чистая и коммерчески полная база JSON-LD (Product/Offer), подорванная одним, но массовым пробелом - полным отсутствием schema отзывов - и горсткой повторяющихся багов форматирования по всему сайту.

Проверенные страницы (сырой HTML через curl - Playwright недоступен для этого прохода, см. вывод #1 о возможном клиентском рендеринге Okendo/Loox): главная, ProductGroup (Luminette 3, с вариантами), простой Product (Drive, Luminette 2), BlogPosting (2 статьи). Формат по всему сайту: исключительно JSON-LD, устаревших Microdata/RDFa не обнаружено.

Что работает хорошо

Исключительно JSON-LD, нечего чистить со стороны устаревших Microdata/RDFa.
Organization на главной странице полная: имя, логотип, изображение, email, url, телефон, полный PostalAddress, sameAs (Facebook, Instagram, LinkedIn).
Product/Offer на каждой карточке товара включает требуемую тройку для rich results (price, priceCurrency, availability) плюс бонусные поля (gtin13/14, mpn, itemCondition, sku, seller, priceValidUntil).
BreadcrumbList реализован последовательно на карточках товара и статьях блога.
BlogPosting/Article имеет хорошую полноту свойств (headline, image, author, datePublished/dateModified, articleBody, mainEntityOfPage).
Все наблюдаемые URL - https://, @context последовательно https://schema.org, без использования устаревших типов.

Выводы (8)

Нет Review/AggregateRating на товарах несмотря на активные приложения отзывов - самая большая упущенная возможность

Критично

JSON-LD товара (Luminette 3, Drive, Luminette 2) не имеет свойства review или aggregateRating. При этом сырой HTML загружает три платформы отзывов: Okendo (17 упоминаний), Trustpilot (23 упоминания, включая профиль https://www.trustpilot.com/review/myluminette.com, связанный в <head>, но отсутствующий в массиве sameAs Organization), и Loox. Копирайтинг главной страницы даже заявляет "300 000 пользователей" как социальное доказательство, но ничего из этого сигнала доверия не читается машинами. Невозможно с уверенностью подтвердить, инжектируют ли Okendo/Loox JSON-LD Review/AggregateRating на стороне клиента после загрузки (Playwright недоступен в этом окружении) - нужно проверить через отрендеренный fetch.

Рекомендация: подтвердить, выдаёт ли Okendo schema; если нет - включить нативный вывод schema Okendo/Loox (обычно доступен переключатель), либо вручную добавить aggregateRating + несколько записей review, взятых из реального объёма/рейтинга (никогда не фабриковать цифры). Также добавить URL бизнес-профиля Trustpilot в массив sameAs Organization (быстрый выигрыш, без риска для разработки).

Невалидный @type: "Website" используется по всему сайту (нарушение регистра schema.org)

Высокая

Типы schema.org чувствительны к регистру. Корректное значение - WebSite (заглавная S), не Website. В том виде, как написано, это молча обрабатывается как неизвестный/пользовательский тип - в корневой schema главной страницы и в ListItem "Home" каждого BreadcrumbList (карточки товара, статьи блога). Право на sitelinks-searchbox для главной страницы и тип корневого узла каждой хлебной крошки невалидны.

Рекомендация: глобальный поиск/замена "@type": "Website" -> "@type": "WebSite" в шаблонах schema темы (вероятно, единый общий сниппет Liquid, учитывая идентичный баг на каждой проверенной странице).

Даты статей не в формате ISO 8601 - некорректны в каждой статье блога

Высокая

Пример из "do-light-therapy-glasses-work": "dateModified": "2025-12-16 10:13:43 +0100", "datePublished": "2022-11-16 00:00:00 +0100". ISO 8601 требует разделитель T между датой и временем, а не пробел - это формат datetime по умолчанию в Rails/Ruby, просачивающийся напрямую в JSON-LD. Парсер структурированных данных Google толерантен к некоторым некорректным датам, но на это не стоит полагаться - риск исключения свойств даты из права на rich results свежести.

Рекомендация: переформатировать весь вывод даты в строгий формат ISO 8601, напр. 2025-12-16T10:13:43+01:00.

ProductGroup.variesBy - пустой массив (Luminette 3)

Средняя

variesBy - обязательное свойство для ProductGroup, оно должно перечислять реальную ось варианта (цвет, в данном случае). Пустой массив означает, что Google не может определить, чем отличаются варианты, что может привести к отклонению ProductGroup или обработке вариантов как несвязанных дублированных товаров в Merchant Center / rich results товара.

Рекомендация: задать variesBy: ["https://schema.org/color"].

Сломанный/неабсолютный URL изображения во вложенном узле Article внутри BreadcrumbList

Средняя

В обеих проверенных статьях блога, внутри вложенного узла Article в BreadcrumbList: "url": "https:articles/img-1718977024200.png" - некорректный URL (отсутствуют сегменты пути/CDN-домена), ни валидный абсолютный URL, ни рабочий относительный путь. Блок Article верхнего уровня на той же странице имеет корректный полный CDN-URL - это конкретно баг в дублированных данных Article внутри хлебной крошки.

Рекомендация: исправить построение URL в image.url вложенного узла Article, или - лучше - прекратить дублировать полные свойства Article внутри BreadcrumbList. Согласно спецификации Google, каждому ListItem.item нужны только @id и name.

Недекодированные HTML-сущности просачиваются в текстовые поля JSON-LD

Низкая

Строки description/articleBody товаров и статей содержат буквальную сущность ' вместо настоящего апострофа, напр. "...Profitez d'une exposition lumineuse efficace...". Синтаксически валидно в JSON, но любая система, потребляющая это описание (сниппеты Google, голосовые ассистенты, AI Overviews), отобразит буквальные символы.

Рекомендация: декодировать HTML-сущности перед вставкой текста в JSON-LD - Liquid-шаблон, вероятно, применяет фильтр HTML-экранирования, предназначенный для HTML-рендеринга, а не для JSON-LD.

FAQPage не реализован - нет влияния на SERP, опциональное дополнение для ИИ/GEO

Инфо

Разметка FAQPage не найдена на главной странице, карточках товара или в блоге. Google убрал rich results FAQ для всех сайтов (7 мая 2026), поэтому нет функции SERP для получения. Учитывая, что это товар с медицинской коннотацией с частыми вопросами покупателей (медицинская безопасность, длительность ежедневного использования, совместимость с очками для зрения, побочные эффекты), добавление FAQPage остаётся релевантным для видимости в ИИ-движках/LLM.

Рекомендация: недорогое дополнение для GEO, если уже существует настоящий FAQ-контент (это так, см. Контент вывод #4). Если позже страница добавит Q/A от пользователей (не редакционный), использовать QAPage, а не FAQPage.

Нестандартный регистр productId на ProductGroup (вероятно, игнорируется парсерами)

Низкая

Пример: "productId": "0745844429340". Реальное свойство schema.org - productID (ID заглавными буквами). В том виде, как написано, это нераспознанное пользовательское свойство, молча игнорируемое парсерами - без функциональной потери, поскольку тот же GTIN уже корректно присутствует через gtin13, но это избыточные/мёртвые данные.

Рекомендация: переименовать в productID, либо удалить, поскольку gtin13/mpn уже корректно идентифицируют товар.

2. Контент и авторитетность

Контент, Семантический кластеринг, ИИ/GEO и SXO формируют самый слабый слой аудита и тот, где сконцентрировано больше всего ценности для раскрытия: бренд обладает реальной научной credibility и значительным объёмом контента, но ни то, ни другое не структурировано так, чтобы конвертироваться в поисковую видимость.

Контент (58/100)Кластеринг (32/100)ИИ / GEO (58/100)SXO (38/100)

Качество контента

58/100

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

Периметр: главная, 3 карточки товара (Luminette 3, Luminette 2, Drive), хаб-страницы clinical-study/new-research/light-therapy, FAQ, и 3 статьи блога из выборки ~140 опубликованных. Проход намеренно сокращён оркестратором во избежание таймаута - дублирование варианта локали выявлено структурно, но не сравнено построчно, требует последующей проверки.

Что работает хорошо

Настоящая научная история происхождения с названными и авторитетными экспертами: /pages/clinical-study и /pages/new-research цитируют Robert Poirrier (невролог, директор лаборатории сна CHU Liege), Yvon Renotte (физик PhD, экс-директор лаборатории оптики ULiege), Vincent Moreau (PhD, оптическая физика/аэрокосмическая отрасль) и Daniel Neu (медицина сна, CHU Brugmann) как соизобретателей/научных консультантов, с "4 годами исследований в Университете Льежа" (2006).
Точные, а не расплывчатые резюме исследований: год, размер выборки, методология, популяция (напр. "84 медсестры операционного блока", "21 человек, работающий в ночную смену", "114 женщин в послеродовом периоде за шесть недель") - гораздо убедительнее, чем общие заявления "клинически доказано".
Медицинские предупреждающие формулировки присутствуют в FAQ товара (катаракта/операции на глазах, соответствие безопасности глаз IEC 62471, заявление о безопасности "300 000 проданных единиц без единого зарегистрированного инцидента").
Сигналы свежести присутствуют в schema (datePublished/dateModified) на проверенных статьях.
Карточки товара преодолевают пороги глубины раскрытия темы (Luminette 3 ~1086 слов, Drive ~1042, Luminette 2 ~855) с инструкциями по использованию и блоком FAQ.

Выводы (4)

Заявления о здоровье/эффективности не связаны ни с одним проверяемым источником - пробел доверия и цитируемости ИИ

Высокая

Страница clinical-study и страница new-research цитируют названные исследования и даже ссылаются на "Publications fournies par le National Center for Biotechnology Information" и цепочки авторов вроде "Glickman G & al. Biol Psychiatry 2006", но ни одной исходящей ссылки на NCBI, PubMed или DOI не существует нигде на обеих страницах (проверено извлечением href против ncbi|pubmed|doi - 0 совпадений). Точные цифры эффективности ("68% пользователей улучшили качество сна", "58% ... увеличение уровня энергии") заявлены как голые факты без цитирования, которое читатель или LLM могли бы проследить для верификации.

Почему это важно: для устройства здоровья с YMYL-коннотацией несвязанная с источником статистика эффективности - классический негативный сигнал доверия согласно QRG. Это также ограничивает цитируемость ИИ - LLM отдают предпочтение заявлениям, которые можно проследить до первичного источника.

Рекомендация: связать каждую ссылку на исследование с её источником PubMed/журнала (или страницей публичных результатов/PDF). Добавить пронумерованный список цитирований внизу обеих страниц - единый фикс с наибольшим эффектом одновременно для E-E-A-T и цитируемости ИИ.

Главная страница функционально - товарный/ценовой прайс-лист почти без уникального брендового или образовательного текста

Средне-высокая

Текст основного содержимого, извлечённый с главной страницы, доминирован повторяющимся списком цен товаров (SKU, цена в евро x3 варианта, "штук") с всего примерно 2 короткими абзацами реального описательного текста ("Попробуйте Luminette", "60 дней возврат денег"). Используемый нарратив бренда (что такое Luminette, чем отличается, наука) вообще не на главной странице - он живёт на второстепенных страницах (/pages/clinical-study, /products/luminette-3).

Почему это важно: главная страница обычно имеет наибольшую авторитетность URL домена; главная страница-каталог недоиспользует эту авторитетность для сигнала E-E-A-T и не даёт ни пользователям, ни ИИ-роботам быстрого пути к истории доверия (университетские исследования, более 300 000 пользователей, стандарт безопасности).

Рекомендация: добавить секцию на главной странице (200-400 слов), заявляющую о происхождении университетских исследований, названных учёных и сертификации безопасности прямо над/рядом с линией сгиба - не заставляя пользователя кликать на /pages/clinical-study, чтобы найти это.

Тематическая pillar-страница тонкая и дублирует блог; корпус блога показывает паттерны риска "контент-фермы на ИИ"

Средняя

/pages/light-therapy - явно задуманная как хаб/pillar-страница тематического кластера "светотерапия" - составляет всего около 215 слов, почти полностью список ссылок на статьи блога с одним коротким вступительным абзацем. Отдельно, sitemap блога перечисляет более 140 статей, многие из которых следуют шаблонному и общему listicle-паттерну со слабой связью с товаром ("8 простых упражнений для глаз", "изучаем пользу ароматерапии", "лучшие книги о сне", "слушать музыку во сне") наряду с почти-дублирующимися сезонными вариантами (winter-fatigue, winter-fatigue-symptoms, how-to-beat-winter-blues, how-to-beat-the-winter-blues, light-therapy-summer-blues, seasonal-depression-in-summer, travel-light-therapy / jet-lag-and-its-impact-in-australia / effects-of-jet-lag). Проверенные статьи-сравнения (ayo-vs-luminette, retimer-vs-luminette, pegasi-2-vs-luminette) следуют идентичному шаблону оценённых функций - маркер повторяющейся структуры, отмеченный в QRG сентября 2025.

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

Рекомендация: (a) переписать /pages/light-therapy в настоящую pillar-страницу из 800+ слов с уникальным синтезом, а не просто списком ссылок; (b) добавить видимый байлайн автора с краткими credentials в статьи блога (даже "Контент-менеджер, проверено [научным консультантом]" усиливает Expertise); (c) консолидировать/перенаправить почти-дублирующиеся сезонные статьи.

Отсутствуют schema FAQPage и Review/AggregateRating несмотря на контент на странице, поддерживающий оба

Низко-средняя

Карточка Luminette 3 показывает видимый блок FAQ (7 вопросов/ответов о безопасности, катаракте, тайминге, совместимости с очками) и счётчик "1700+ отзывов", но сканирование JSON-LD находит Product присутствующим, тогда как FAQPage и AggregateRating/Review отсутствуют.

Рекомендация: добавить schema FAQPage к существующему блоку FAQ и schema AggregateRating, связанную с реальным объёмом/источником отзывов - контент уже присутствует, не хватает только разметки.

Семантический кластеринг (архитектура hub-and-spoke)

32/100

Самый низкий скор всего аудита: объём контента есть, но он распределён по 4 параллельным структурам URL, конкурирующим друг с другом - это и есть определение самоканнибализации.

Методология: аудит продакшн-сайта, а не построение кластера с чистого листа. Основан на краулинге индекса блога (11 страниц пагинации, ~130 опубликованных статей), выборке паттернов внутренних ссылок в теле статей, и запросах site:, использованных как прокси для реальной самоконкуренции в SERP.

Что работает хорошо

Высокий объём и тематическая широта: ~130 статей покрывают почти все смежные темы, которые может искать покупатель светотерапии (SAD/зимняя хандра, циркадный ритм, джетлаг, гигиена сна, витамин D, синий свет, сравнения устройств).
Отдельные статьи в основном ведут на релевантные карточки товара (light-therapy-glasses-guide, pegasi-2-vs-luminette, do-light-therapy-glasses-work - все ссылаются на /products/luminette-3 и/или /products/drive).
Контент сравнения с конкурентами существует и хорошо таргетирован (Pegasi 2, Re-Timer, Ayo).
Существует настоящий актив E-E-A-T: /pages/new-research агрегирует 15 опубликованных клинических исследований (Университет Льежа, рандомизированные испытания по сну/настроению/когнитивным функциям, особые популяции) - сильный сигнал авторитетности, сейчас недоиспользуемый блогом.

Выводы (6)

Серьёзная самоканнибализация: одни и те же центральные темы покрыты в 4 параллельных структурах контента

Высокая

Запросы site:myluminette.com выводят собственные URL сайта, конкурирующие друг с другом в одном и том же наборе результатов. Запрос "winter blues": 5 отдельных живых URL (/blogs/light-therapy-applications/winter-blues-light-therapy, /blogs/article/vitamin-d-for-seasonal-depression, /blogs/article/how-to-beat-winter-blues, /blogs/article/how-to-beat-the-winter-blues, /blogs/article/sun-lamps-for-seasonal-depression). Запрос "vitamin d light therapy": 5+ отдельных URL на трёх разных структурах путей, плюс вариант локали /en-ua/....

Как минимум 4 отдельных силоса URL/контента существуют параллельно, все живые (проверено через curl, 200 OK): (1) /blogs/article/* - основной плоский блог (~130 статей, тот, что связан в навигации), (2) /blogs/light-therapy/* - под-хаб "наука", (3) /blogs/light-therapy-applications/* - под-хаб "случаи использования", (4) /light-therapy/* - legacy-хаб, частично живой, частично 404. Только внутри силоса #1 пересечение ключевых слов по количеству статей: Витамин D 6 статей, Зимняя хандра / сезонное настроение 8 статей, Синяя светотерапия 4 статьи, Лампы полного спектра 3 статьи с почти идентичными заголовками, Джетлаг 5 статей.

Рекомендация: выбрать единую каноническую структуру URL (рекомендуется: оставить /blogs/article/*, ту, что присутствует в основной навигации) и консолидировать/301-перенаправить три остальных силоса на неё. Внутри каждого пересекающегося тематического кластера выше объединить в 1 pillar + максимум 2-3 дифференцированных spoke; канонизировать или перенаправить остальное. Единый фикс с наибольшим влиянием, доступный на этом сайте.

Осиротевший legacy pillar-хаб отдаёт 404, оставаясь при этом проиндексированным

Высокая

Проверка curl -I на URL, найденных в поиске: /light-therapy/light-therapy-all-about-light-therapy = 404, /light-therapy/how-does-light-therapy-work = 404, /light-therapy/3-contraindications = 404, тогда как /light-therapy/light-therapy (соседняя страница в той же папке) = 200. Эти 404-URL - именно тот тип фундаментальных pillar-страниц, которые нужны архитектуре hub-and-spoke ("что такое светотерапия", "как это работает", "противопоказания") - построенные, проиндексированные, а затем сломанные, вероятно во время неполной миграции URL/платформы.

Рекомендация: проверить все пути /light-therapy/* в отчёте покрытия Search Console, 301-перенаправить каждый 404 на ближайший живой эквивалент (вероятно, в /blogs/light-therapy/* или /pages/light-therapy), и определить единственный постоянный дом для этого контента.

Модуль "Похожие статьи" контекстуально нерелевантен

Средне-высокая

Три проверенные несвязанные между собой статьи (гайд по покупке, сравнение с конкурентом, FAQ по эффективности товара) показывают один и тот же блок "Похожие статьи" из трёх идентичных статей, что явно указывает на статичный/закреплённый вручную модуль, а не управляемый темой. Отдельно, статья does-vitamin-d-give-you-energy не содержит ссылок на 5 других смежных статей о витамине D, хотя это самая очевидная доступная возможность внутренней перелинковки.

Рекомендация: заменить на компонент связанного контента, управляемый тегом/категорией, чтобы spoke-статьи действительно перелинковывались внутри своего реального тематического кластера.

Тематическое разбавление нерелевантным wellness-контентом

Средняя

Значительная часть из ~130 статей не имеет прямого отношения к светотерапии или линейке товаров: "Лучшие книги о сне", "Тренировка за 7 минут", "Совет здоровья дня", "Польза сна без подушки", "Изучаем пользу ароматерапии для релаксации", "8 простых упражнений для глаз для улучшения зрения", "21 способ сделать рабочее пространство продуктивнее". Этот контент конкурирует за бюджет краулинга/тематический сигнал авторитетности центрального корпуса о светотерапии без правдоподобного пути к квалифицированному трафику по товару.

Рекомендация: снизить приоритет производства нового контента в этом ключе; для существующих статей - либо интегрировать их в более широкий spoke "гигиена сна" с настоящей связью со светотерапией, либо noindex/удалить те, которые невозможно привязать к центральной теме.

Пробелы контента относительно реального покупательского интента

Средняя

"Работает ли светотерапия при депрессии": нет выделенной страницы. Ближайшая статья, do-light-therapy-glasses-work, строится вокруг общей эффективности/безопасности и ссылается только на главную страницу и карточку товара - она не ссылается на данные клинического испытания MDD (clinicaltrials.gov NCT03685942, испытание LUMIDEP), которое, тем не менее, существует внешне и упоминается на /pages/new-research. "Очки светотерапии vs лампа SAD": страницы сравнения форматов не существует - на сайте есть три бренд-сравнения (Pegasi 2, Re-Timer, Ayo), но ничего по этому более распространённому вопросу верхней части воронки. "Сколько времени использовать очки светотерапии": фрагментировано минимум на 3 слабые и конкурирующие статьи вместо единого авторитетного гайда по использованию.

Рекомендация: построить/консолидировать авторитетную страницу по каждому выявленному выше пробелу, ведя напрямую на релевантную карточку товара и на /pages/new-research для клинической поддержки.

Нет таксономии категорий/тегов в блоге

Низко-средняя

/blogs/article - единый плоский список, хронологически с пагинацией (11 страниц), без видимого фильтра по категории или тегу. Пользователи и роботы не могут просмотреть тематический кластер как единое целое; обнаружение полностью зависит от внутренних ссылок, которые сейчас неконтекстуальны (см. вывод #3).

Рекомендация: ввести страницы архива категорий/тегов для блога, которые одновременно выступают лёгкими hub-страницами, каждая ведёт к своим spoke-статьям и к релевантной карточке товара.

Видимость в ИИ (GEO)

58/100

Нет блокировки ИИ-роботов и llms.txt, опережающий категорию - но противоречие robots.txt/llms.txt, отсутствие FAQPage и поверхностный сигнал E-E-A-T ограничивают оценку на YMYL-контенте.

Веса по под-измерениям: Цитируемость 25% (скор 65) · Структурная читаемость 20% (60) · Мультимодальный контент 15% (40) · Авторитетность и сигналы бренда 20% (45) · Техническая доступность 20% (75). Оценки по платформам (эвристические, без прямого отслеживания цитирований): Perplexity ~62, Google AI Overviews ~55, ChatGPT/OAI-SearchBot ~50, Bing Copilot ~55.

Что работает хорошо

Нет блокировки ИИ-роботов: GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot все неявно разрешены.
/llms.txt присутствует и необычно продвинут (эндпоинты UCP, инструкции agent-commerce), опережает конкурентов категории.
Контент полностью рендерится на сервере - все ИИ-роботы получают полный контент уже при первом fetch, без необходимости выполнения JS.
Существует по-настоящему отличная страница для цитируемости (do-light-therapy-glasses-work): заголовки в форме вопросов, завершающий FAQ, schema Article, названный байлайн, 2 цитирования PubMed.
Schema Organization включает ссылки sameAs на Facebook, Instagram, LinkedIn.

Выводы (6)

robots.txt блокирует /collections и /policies для всех роботов, включая ИИ - в противоречии с собственными инструкциями llms.txt

Высокая

robots.txt содержит Disallow: */collections и Disallow: */policies без исключений, применяется к User-agent: *. При этом /llms.txt явно просит агентов делать GET /collections/{handle} для обхода каталога, и напрямую ссылается на /policies/privacy-policy, /policies/terms-of-service, /policies/refund-policy как "Store Policies". Оба класса URL отдают HTTP 200 при прямом fetch - таким образом, соответствующий стандартам ИИ-робот, следующий robots.txt, откажется получать страницы, которые собственный файл инструкций сайта просит его получить.

Рекомендация: либо добавить явные исключения Allow: для /policies/* и /collections/* на уровне категории для ИИ-роботов (GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, Google-Extended), либо обновить llms.txt/agents.md, чтобы больше не ссылаться на заблокированные пути. Страницы политик несут особенно важные сигналы доверия/авторитетности, которые ИИ-движки используют для скоринга доверия к e-commerce.

Нет schema FAQPage несмотря на существующий FAQ-контент

Средне-высокая

Флагманская статья /blogs/article/do-light-therapy-glasses-work имеет видимую секцию H2 "FAQ" с тремя парами прямых вопрос/ответ ("Действительно ли работают очки светотерапии? Да, очки светотерапии разработаны, чтобы имитировать естественный солнечный свет..."). JSON-LD страницы декларирует только Article и BreadcrumbList - никакая schema FAQPage не оборачивает эти пары Q/A, поэтому текст прямого ответа не размечен для машин как извлекаемый Q/A для AI Overviews Google или ответов типа SGE.

Рекомендация: добавить schema FAQPage (пары Question/acceptedAnswer) на эту статью и повторить на других статьях блога, отвечающих на вопросы. Низкие усилия, высокое влияние на право попадания в AI Overview и голосового ассистента.

Поверхностный сигнал E-E-A-T автора на YMYL-контенте о здоровье

Средне-высокая

Заголовок статьи сам себя позиционирует как медицинскую рекомендацию ("Медицинское заключение и научная эффективность"), а поле JSON-LD author называет "Eric Delloye" - но никакой видимой на странице био автора, credentials или упоминания медицинской проверки нигде нет в отрендеренном HTML. Имя появляется только в объекте JSON-LD author и в push-событии analytics dataLayer, оба невидимы для обычного читателя. На примерно 2000 словах статьи, формулирующей многочисленные физиологические заявления (механизмы серотонина/мелатонина, "0,5-2 часа выигранного сна", сравнения люкс), существует только 2 исходящие цитаты на PubMed/PMC, обе привязаны к одному заявлению ("нет доказательств вреда для глаз").

Рекомендация: добавить видимый блок био автора/рецензента (credentials, напр. "проверено [офтальмологом/специалистом по сну]", со schema Person, включающей jobTitle/worksFor) и цитировать источники для конкретных количественных заявлений. Фикс с наибольшим эффектом для взвешивания доверия ИИ на контенте о здоровье с YMYL-коннотацией - LLM отдают предпочтение источникам с чёткой атрибуцией экспертизы для медицинских заявлений.

Оптимизация GEO непоследовательна в блоге - одна флагманская страница, слабые категорийные hub-страницы

Средняя

Сравнение между do-light-therapy-glasses-work (отличная) и /blogs/light-therapy/light-therapy-principles-and-health-benefits (центральная pillar-страница категории блога "light-therapy"). Вторая имеет общие H2, не сформулированные как вопрос ("Принципы и польза"), нет блока FAQ, нет цитирования PubMed, и только ~193 слова основного текста - значительно ниже любой полезной длины для извлечения фрагмента. Существует 4 категорийных хаба блога (light-therapy, chronobiology, light-therapy-lamps, light-therapy-applications) с десятками статей; только одна статья из выборки в этом аудите полностью оптимизирована под GEO.

Рекомендация: проверить все статьи категорий light-therapy и light-therapy-applications и переписать центральные pillar-страницы по тому же паттерну, что и флагманская статья: заголовки в форме вопроса, прямые ответные фрагменты примерно 150 слов, завершающий FAQ со schema FAQPage, цитируемые источники.

Нет schema aggregateRating/Review несмотря на активную интеграцию Trustpilot

Низко-средняя

HTML главной страницы включает dns-prefetch на widget.trustpilot.com, указывая на живой показ отзывов, а копирайтинг карточки товара заявляет "Более 300 000 пользователей доверяют нам с 2006 года". При этом JSON-LD ProductGroup не имеет ни aggregateRating, ни review, как и schema Organization на главной странице.

Рекомендация: добавить aggregateRating (из реального агрегированного рейтинга Trustpilot) в schema Product и Organization. Объём/рейтинг отзывов - распространённый сигнал доверия, который LLM учитывают при сравнении товарных рекомендаций по запросам с коммерческим интентом.

Нет собственного YouTube-канала и нет сущности Wikipedia - отсутствуют две сильнейшие корреляции цитирования ИИ

Средняя

sameAs Organization на главной странице перечисляет только Facebook, Instagram и LinkedIn - ни YouTube, ни Wikipedia. Живой поиск в Wikipedia по "Luminette light therapy glasses"/"Lucimed" не возвращает соответствующей статьи. Поиск на YouTube выдаёт сторонний контент ("Luminette 3 Review: Testing the Brightest Light Therapy Glasses!"), подтверждая органический интерес создателей контента, но ни один канал, принадлежащий бренду, на сайте не упомянут. Согласно данным корреляции бренда GEO, упоминания на YouTube (~0,737) и присутствие сущности Wikipedia - два самых сильных предиктора цитирования ИИ - оба здесь отсутствуют.

Рекомендация: (a) создать или формально связать собственный YouTube-канал (демо товара, объяснения "как работает светотерапия") и добавить его в sameAs; (b) стремиться к записи в Wikipedia для Lucimed/Luminette, если можно выполнить критерии заметности (освещение в прессе, одна статья блога уже упоминает "премию за инновации в психическом здоровье", что может поддержать заметность); (c) продолжать вовлекать существующих сторонних YouTube-создателей вместо того, чтобы начинать с нуля.

Поисковый опыт (SXO)

38/100

Самый критичный скор соответствия SERP во всём аудите: из 4 проанализированных французских ключевых слов бренд полностью отсутствует по двум запросам с наивысшим покупательским/информационным интентом.

Периметр: 4 французских ключевых слова проанализированы против ожиданий типа страницы SERP (lunettes de luminotherapie, luminotherapie depression saisonniere, meilleure lampe luminotherapie, luminette avis). Проход с намеренно ограниченным периметром - полный аудит SXO охватил бы 15-20+ ключевых слов по всей воронке.

Что работает хорошо

Брендовый запрос "luminette avis" хорошо покрыт выделенной страницей /pages/customer-reviews.
Главная страница имеет сильную ДНК landing-страницы для брендового/бренд-коммерческого интента: уникальное ценностное предложение, гарантия 60 дней, социальное доказательство "300 000 довольных пользователей с 2006 года", секция "Как это работает".
Существует настоящая длинная франкоязычная статья (/fr-fr/blogs/article/do-light-therapy-glasses-work, ~4000 слов, реальный перевод, а не заглушка).

Выводы (4)

Ноль присутствия бренда по информационным и сравнительным ключевым словам с высоким интентом

Критично

По запросу "luminotherapie depression saisonniere" первые 5 результатов на 100% - домены медицинского/санитарного авторитета (sante.fr, vidal.fr, allodocteurs.fr, mesoigner.fr, inicea.fr) - тип страницы чисто редакционная статья блога. Ни одна страница myluminette.com не появляется; проверка site:myluminette.com для этой точной фразы ничего не возвращает. По запросу "meilleure lampe luminotherapie" SERP на 100% типа Страница сравнения (conservation-nature.fr, edp-nutrition.fr, lampeluminotherapie.com "comparatif", maluminotherapie.com "guide d'achat"), рекомендующие конкурирующие лампы (Verilux HappyLight, Beurer TL 30) - собственная "Лампа светотерапии 2-в-1" Luminette нигде не появляется, несмотря на то что продаётся на главной странице.

Рекомендация: построить два типа выделенных страниц, которые сейчас не существуют на французском сайте: (a) медицински обрамлённую и подкреплённую E-E-A-T статью о "светотерапии и сезонной депрессии" с указанным профессиональным медицинским рецензентом (Luminette уже обладает Prof. Robert Poirrier, специалистом по сну, как активом для цитирования - сейчас неиспользуемым во французском контенте); (b) настоящую страницу сравнения/гайда по покупке ("Лучшая лампа светотерапии в 2026 году"), включающую собственную лампу 2-в-1 Luminette наряду с критериями категории (люкс, площадь, таймер), соответствующую таксономии Страница сравнения (таблица, плюсы/минусы, вердикт).

Нет выделенной коммерческой категорийной страницы для центрального товарного ключевого слова

Высокая

/collections/lunettes-de-luminotherapie отдаёт 404. Sitemap коллекций перечисляет только /collections/accessories, /collections/refurbished-main, /collections/refurbished-main-nav - не существует основной страницы коллекции "очки" или "лампа". По запросу "lunettes de luminotherapie" SERP смешивает страницы Товар/Категория (Medi-Lum, Lux-Therapie, Biron) с контентом Гайд/Сравнение (lampeluminotherapie.com x3, maluminotherapie.com) - гибридный коммерческо-информационный спрос. Myluminette сейчас отвечает только своей общей главной страницей (которая продаёт аксессуары, витамин D, носовые накладки - не сфокусированную landing-страницу "очки светотерапии").

Рекомендация: создать настоящую категорийную/landing-страницу /collections/lunettes-de-luminotherapie (или похожий слаг, соответствующий ключевому слову), сфокусированную исключительно на линейке очков, со встроенными блоками контента гайда по покупке (критерии, сравнительная таблица vs лампы), чтобы соответствовать гибридному паттерну, видимому в SERP.

Французский контент похоронен под английскими URL-слагами

Средняя

Статья /fr-fr/, лучше всего соответствующая "lunettes de luminotherapie", сидит на английском слаге /fr-fr/blogs/article/do-light-therapy-glasses-work. Заголовок и мета хорошо локализованы на французском, но сам URL не несёт никакого сигнала французского ключевого слова, а структура /blogs/article/ (без тематической категории в URL) общая. Все записи sitemap блога используют английские слаги, независимо от локали.

Рекомендация: локализовать URL-слаги по рынкам (Shopify Markets это поддерживает), напр. /fr-fr/blogs/luminotherapie/lunettes-luminotherapie-avis-medical, улучшая сигнал ключевое слово/URL без изменения контента.

Пространство отзывов уступлено Trustpilot

Средняя

По запросу "luminette avis" 3 из 6 видимых результатов SERP - страницы Trustpilot (fr и fr-be, несколько страниц в глубину) против всего одной собственной страницы (/pages/customer-reviews). Это предполагает, что странице отзывов на сайте не хватает либо schema агрегированного рейтинга, видимой для Google, либо более свежего/обновлённого контента, чем профиль Trustpilot.

Рекомендация: добавить schema AggregateRating/Review на страницу отзывов на сайте и убедиться, что она показывает свежие и датированные отзывы (не статичный блок), чтобы конкурировать за пространство сниппета отзывов, сейчас занимаемое Trustpilot.

Таблица соответствия типа страницы и SERP

Ключевое слово	Доминирующий тип в SERP	Актив myluminette	Серьёзность разрыва
lunettes de luminotherapie	Гибрид (Товар/Категория + Гайд)	Общая главная страница (гибрид Landing/Товар, не сфокусирована)	Высокая
luminotherapie depression saisonniere	Статья блога (медицинский авторитет)	Нет присутствия в SERP	Критично
meilleure lampe luminotherapie	Страница сравнения	Нет присутствия в SERP	Критично
luminette avis	Страница отзывов/UGC	/pages/customer-reviews (присутствует, делит SERP с Trustpilot)	Соответствует (слабо)

Ограничения: проанализировано только 4 ключевых слова (проход с ограниченным периметром); результаты SERP получены через WebSearch, а не через живой скриншот с отслеживанием позиций - точный порядок топ-10 и живые функции SERP (AI Overview, PAA, реклама) не зафиксированы. Не получено подтверждения реальной позиции myluminette по ключевому слову 1 (присутствует, но позиция не подтверждена) против полного отсутствия по ключевым словам 2-3 - требуется Ahrefs/GSC для точного подтверждения.

3. E-commerce SEO

Прочная база schema товаров и высокий уровень покрытия alt-текстом, подорванные критическим багом соответствия Merchant Center на восстановленных товарах и тем же багом заголовков, что и в измерении Техническое SEO.

E-commerce SEO

58/100

Коммерческая schema в целом хороша, но одно несоответствие состояния товара (новый vs восстановленный) подвергает бренд реальному риску приостановки карточки в Google Shopping.

Источник: статический on-page анализ (curl, без рендеринга JS). Проверенные страницы: главная, /products/luminette-3, /products/luminette-2, /products/refurbished-luminette-3, /products/drive, /fr-fr/products/luminette-3, /collections/all. Платформа Shopify, Shopify Markets с 20+ под-путями локалей.

Что работает хорошо

Schema ProductGroup + Offer реализована на всех проверенных карточках товара, включая gtin13, mpn, brand, sku по варианту, Offer.price, priceCurrency, availability, itemCondition, seller, priceValidUntil - хорошая база для Merchant Center / rich results.
BreadcrumbList присутствует на карточках товара (хотя неглубокий - см. выводы).
Хорошее покрытие alt-текстом: из 125 тегов <img>, связанных с товаром, из выборки на карточке Luminette 3, только 2 без атрибута alt; существующий текст описательный, а не общие имена файлов.
Сообщение о доверии/гарантии/доставке сильно представлено в on-page тексте: "60 дней" (гарантия) 13x, "деньги обратно" 7x, "бесплатная доставка" 12x на карточке Luminette 3.
Обнаружены интеграции платформ отзывов (Loox, Yotpo, Trustpilot, Okendo), указывающие на собираемые и, вероятно, отображаемые на стороне клиента отзывы.
Обширная реализация hreflang: 242 тега hreflang на страницу, корректная self-reference подтверждена на карточке восстановленного товара.

Выводы (6)

Schema восстановленных товаров ошибочно декларирует itemCondition: NewCondition

Критично

На https://myluminette.com/products/refurbished-luminette-3 все 3 блока Offer JSON-LD ProductGroup показывают "itemCondition": "https://schema.org/NewCondition". Товар явно продаётся и назван восстановленным/"reconditionne", но структурированные данные говорят Google (и любому фиду Merchant Center, черпающему из этой schema), что он новый.

Влияние: Google Shopping / Merchant Center может отклонить или приостановить карточки за несоответствие состояния между контентом страницы и schema/фидом. Это также провал сигнала доверия для rich results, поскольку покупатель, ищущий подержанный/восстановленный товар, видит бейдж "новый".

Рекомендация: изменить itemCondition на https://schema.org/RefurbishedCondition (значение, поддерживаемое Google) для всех восстановленных SKU. Проверить metafield Shopify или логику темы, генерирующую эту schema - вероятно, захардкожено, а не шаблонизировано по типу товара. Сделать то же для Refurbished Luminette 2 и Refurbished Drive (не проверены индивидуально в этом проходе, но с высокой вероятностью используют тот же шаблон ProductGroup).

Теги <title> содержат лишний код страны, добавленный после названия бренда

Высокая

Та же коренная причина, что и вывод #1 измерения Техническое SEO: каждая проверенная страница без пути локали отдаёт заголовок, заканчивающийся сырым двухбуквенным кодом со странным пробелом, напр. Lunettes Luminotherapie - Luminette 3 | Livraison gratuite | Luminette\n\n BE. Путь локали /fr-fr/ отдаёт тот же заголовок с FR вместо BE. Этот паттерн повторяется на главной странице, /collections/all, и 4 протестированных карточках товара - похоже на значение селектора страны Shopify Markets, просачивающееся в Liquid-шаблон заголовка, вместо того чтобы быть ограниченным элементом UI.

Влияние: Google обычно переписывает заголовки, которые считает некорректными, но это тратит пиксельный бюджет заголовка SERP, выглядит непрофессионально, если отображается как есть, и предполагает, что рынок/страна определяется по geo-IP в момент краулинга - то есть Googlebot может индексировать заголовок, отличающийся по geo от того, что видят французские или бельгийские пользователи.

Рекомендация: найти и убрать вывод {{ country_code }}/селектора рынка из шаблона <title>. Проверить, что канонические URL без префикса локали отдают стабильный, независимый от geo заголовок, а не заголовок, переключающийся между BE/FR/и т.д. в зависимости от происхождения запроса.

Нет schema aggregateRating/Review несмотря на активные приложения отзывов (Loox, Yotpo, Trustpilot, Okendo)

Средняя

Ноль вхождений aggregateRating или "review" в статическом JSON-LD ProductGroup на 4 карточках товара, при этом 4 отдельных скрипта платформ отзывов (Loox, Yotpo, Trustpilot, Okendo) загружены на каждой карточке - необычно высокое число пересечений, предполагающее, что отзывы существуют в объёме, но не раскрыты роботам в основной schema Product. Вывод только на основе статического HTML; если одно из этих приложений инжектирует schema на стороне клиента через JavaScript, проход рендеринга Googlebot всё же мог бы её захватить - нужно проверить через отрендеренный DOM-check, прежде чем считать полностью подтверждённым.

Рекомендация: консолидировать вывод schema в одну платформу отзывов (наличие 4 конкурирующих приложений - тоже пассив по скорости страницы/поддержке) и убедиться, что aggregateRating выдаётся на стороне сервера в том же блоке JSON-LD, что и данные Product/ProductGroup, а не только на стороне клиента.

Непоследовательное форматирование значений цены внутри одной и той же schema ProductGroup

Средняя

На карточке Luminette 3 значения "price" появляются в смешанных форматах в окружающих данных страницы: некоторые как "179", "183", "199", "229" (без десятичных) и другие как "229.00" / "183.00" (с десятичными) - некоторые могут принадлежать виджетам кросс-продаж/бандлов, а не основному предложению товара, но сама несогласованность указывает на нестандартизированную логику рендеринга цены.

Рекомендация: стандартизировать весь вывод цены в schema в формате строки с двумя десятичными ("229.00") и подтвердить, что живой фид Merchant Center берёт данные из нативных данных товара/варианта Shopify, а не из любого скрапленного/шаблонизированного значения.

Schema BreadcrumbList неглубокая (только Home > Товар, без уровня категории)

Низкая

BreadcrumbList на /products/luminette-3 имеет только 2 записи ListItem: "Home" и "Luminette 3". Промежуточного узла категории/коллекции не существует, хотя /collections/all и, вероятно, другие коллекции существуют.

Рекомендация: добавить релевантную коллекцию как промежуточный узел хлебной крошки, соответствующий реальной информационной архитектуре сайта (напр. Home > Очки > Luminette 3).

Карточка восстановленного товара почти дословно повторяет шаблон заголовка/мета нового товара

Низкая

<title> /products/refurbished-luminette-3 идентичен заголовку нового Luminette 3, отличается только лишним кодом страны в конце строки. Meta description отличается (упоминает "Оживите свои дни..."), но заголовок не даёт пользователям/поисковикам никакого сигнала, что это восстановленный/более дешёвый вариант.

Рекомендация: добавить "Восстановленный" в заголовок карточки восстановленного товара, отличный от заголовка нового товара, чтобы прояснить намерение покупателям и снизить внутреннюю каннибализацию запросов.

Не оценено в этом проходе

Размеры/формат файлов изображений (WebP vs PNG) только выборочно проверены, систематически не измерены против рекомендации Merchant Center ≥800px. Вызовов Merchant API DataForSEO не выполнялось (бенчмаркинг конкурентоспособности цен на маркетплейсах вне периметра). Проверка уникальности текста производителя против конкурирующих карточек не выполнена. Refurbished Luminette 2 и Refurbished Drive не проверены индивидуально - баг NewCondition подтверждён только на Refurbished Luminette 3, но с высокой вероятностью идентично шаблонизирован на всех восстановленных SKU.

4. Визуал и производительность

Прочная база выше линии сгиба и отличный TTFB, но чрезмерно раздутый DOM и не преloaded hero-изображение ограничивают скор Производительности, в то время как риск рендеринга анимаций потенциально угрожает видимости ключевого конверсионного контента.

Визуал / Мобильная (64/100)Производительность (55/100)

Визуальный рендеринг / мобильная версия

64/100

Кластер доверия выше линии сгиба прочен на десктопе и мобильной версии - но 30-40% от общей высоты страницы захватывается пустым при полном скролле, сигнал, требующий срочной ручной проверки.

Проверенные страницы: главная, карточка товара Luminette 3. Viewport: Desktop 1920x1080, Mobile 375x812 (iPhone).

Главная страница myluminette.com на десктопе — Главная страница, десктоп: H1, социальное доказательство "+300 000 клиентов", двойной CTA и бейдж Trustpilot видны без скролла.

Главная страница myluminette.com на мобильной версии — Главная страница, мобильная версия: тот же кластер доверия, сжатый в первом экране, липкая панель гарантии над хедером.

Карточка товара Luminette 3 на десктопе — Карточка товара, десктоп: галерея, список преимуществ, цена по объёму и бейдж доставки видны у верха страницы.

Карточка товара Luminette 3 на мобильной версии — Карточка товара, мобильная версия: цена (229€) и кнопка "Заказать" видны уже в первом экране, без необходимости искать.

Что работает хорошо

Сильный кластер доверия выше линии сгиба на обеих страницах: H1 "Верните энергию менее чем за 10 дней", подзаголовок "+300 000 клиентов", двойной CTA, бейдж Trustpilot (4,6/5, 1700+ отзывов) - всё видно без скролла.
Липкая панель доверия/срочности над хедером ("60 дней возврат денег" / "Оплата в 3 платежа с Klarna"), снижающая воспринимаемый риск ещё до достижения hero-блока.
Баннер преимуществ под hero (Эксперты с 2006 года / Достаточно 20 минут в день / Бесплатная доставка / 60 дней на передумать) усиливает сообщение о гарантии + простоте использования прямо на линии сгиба.
Цена и CTA быстро видны на мобильной версии карточки товара, без необходимости искать кнопку покупки.
Десктопная карточка товара хорошо структурирована: галерея с миниатюрами, список преимуществ, ценообразование по объёму (1/2/3 штуки с видимой скидкой), оценка доставки, миниатюры видео-отзывов ниже линии сгиба.
Стандартная гамбургер-навигация на мобильной версии, компактный хедер. Не замечено горизонтального скролла, сломанной вёрстки или перекрывающихся элементов на скриншотах.

Выводы (3)

Большие секции страницы рендерятся пустыми при скролл-захвате - требуется проверка надёжности анимаций, запускаемых скроллом

Высокая

На полностраничных скриншотах (home_desktop_full, home_mobile_full, product_mobile_full) примерно 30-40% общей высоты страницы - белое/градиентное пустое пространство без видимого контента. Паттерн повторяется на главной странице и карточке товара, на десктопе и мобильной версии: секция "Всё ещё думаете о лайтбоксе?" (вероятно, блок сравнения Luminette vs традиционная лампа) рендерится только с видимым заголовком и примерно 2000px пустого пространства под ним - ни сравнительная таблица/график/изображение не появляются ни на десктопе, ни на мобильной версии. Секция "Luminette позволит вам:" на мобильной карточке товара показывает тот же паттерн. Общая захваченная высота в результате очень велика: мобильная главная = 15518px (~19 высот мобильного экрана), мобильная карточка товара = 12278px (~15 высот экрана), значительная часть из которых пуста.

Этот паттерн согласуется с контентом, обусловленным анимациями reveal/fade-in, запускаемыми скроллом (GSAP ScrollTrigger, AOS, Intersection Observer), которые не сработали во время автоматизированного полностраничного захвата. Это важно по двум причинам: (1) если реальные пользователи на устройствах низкого уровня или с медленным JS переживают ту же задержку/сбой reveal, они сталкиваются с длинными пустотами при скролле перед решающим контентом (сравнительная таблица, список преимуществ) - реальный риск UX/конверсии для взвешенной покупки; (2) рендерер Google - тоже headless-инстанс Chromium и может быть подвержен похожим проблемам тайминга - если контент зависит от позиции скролла/тайминга JS, чтобы стать видимым/присутствующим в DOM, существует риск, что он не будет надёжно проиндексирован или засчитан странице.

Рекомендация: вручную и медленно проскроллить живой сайт, десктоп и мобильную версию, чтобы подтвердить, реальная ли это задержка рендеринга или чистый артефакт headless-захвата. Если контент обусловлен анимацией при скролле, перейти на анимации, раскрывающие контент, уже присутствующий в DOM (только opacity/transform, никогда display:none или инжектируемый при скролле контент), чтобы он оставался всегда краулируемым и независимым от срабатывания анимации. Рассмотреть снижение зависимости от reveal-эффектов при скролле для основного конверсионного контента (сравнительная таблица, список преимуществ), учитывая замеченный здесь риск сбоя.

Чрезмерная длина страницы относительно плотности контента

Средняя

Полностраничный мобильный скриншот главной страницы имеет высоту 15518px; мобильная карточка товара - 12278px - обе необычно длинные относительно числа отдельных выявленных секций контента (hero, "Осветите свою жизнь", статистика, "Технические характеристики", блок сравнения, отзывы, футер). Даже учитывая проблему пустого рендеринга из вывода #1, отступы между секциями кажутся щедрыми (большой вертикальный padding, градиентные переходы между блоками).

Рекомендация: после решения вывода #1 и подтверждения реальной высоты контента, проверить вертикальные отступы между секциями и сжать где уместно - более короткий путь к FAQ/составу/отзывам обычно улучшает мобильную вовлечённость для товаров взвешенной покупки.

Секции сравнения с традиционной лампой не хватает видимого контента на скриншоте

Средняя (зависит от вывода #1)

Секция "Всё ещё думаете о лайтбоксе?" - вероятно, задуманная как ключевой блок дифференциации/снятия возражений (очки Luminette vs традиционная лампа светотерапии) - не показывает никакого видимого сравнительного контента на скриншотах ни десктопа, ни мобильной версии. Это именно тот тип контента, который должен убедить скептически настроенного и глубоко исследующего покупателя (взвешенная wellness-покупка согласно брифу), поэтому если этот контент действительно не рендерится для сегмента реальных пользователей, это прямой удар по конверсии посетителей с наивысшим интентом, дочитавших до этого места.

Рекомендация: вручную проверить живой рендеринг; если подтверждено рабочим для реальных пользователей - никаких действий сверх фикса надёжности анимации из вывода #1. Если сломано - приоритизировать исправление, эта секция выполняет работу по убеждению в нижней части воронки.

Оценка контента выше линии сгиба и мобильной адаптивности

Главная страница и карточка товара обе проходят порог "выше линии сгиба": H1/название товара, основной CTA и сигнал доверия в виде звёзд (Trustpilot) все видны без скролла, на десктопе и мобильной версии - хорошо подходит для взвешенной покупки, где доверие должно устанавливаться немедленно. Не замечено разрывов вёрстки, перекрытий или горизонтального скролла ни на одном из наборов мобильных скриншотов. Главный открытый вопрос остаётся проблемой reveal-контента при скролле выше, требующей ручной проверки вживую (не только инструмента статического захвата) для подтверждения реального пользовательского влияния.

Производительность

55/100

TTFB отличный, а дисциплина загрузки ресурсов (preloaded шрифты, отложенный некритичный CSS, deferred JS) хороша - но DOM в 3,6 раза больше нормы и не преloaded hero-изображение нейтрализуют значительную часть этого преимущества.

Оговорка по методологии

API PageSpeed Insights вернул ошибку rate-limit 429 по обеим стратегиям (мобильная и десктоп) - данные CrUX/Lighthouse недоступны для этой сессии. Поэтому этот аудит основан на ручной проверке через curl сырого HTML/заголовков ответа для главной страницы и карточки товара, плюс статический анализ resource hints, размера DOM и разметки изображений. Все выводы ниже - оценки на основе статических доказательств/ответа сервера, а не лабораторных (Lighthouse) или полевых (CrUX) метрик. Повторно запустить PSI/CrUX после снятия rate-limit для подтверждения.

Метрика (прокси)	Главная страница /	Карточка товара /products/luminette-3
TTFB	0,112 с	0,190 с
Общее время отклика	0,303 с	0,611 с
Размер сырого HTML	866 Кб	941 Кб
Количество элементов DOM (прибл.)	~5 437	~5 603
Теги <img> с пустыми width/height	20	291

Сервер: Cloudflare перед Shopify (gcp-europe-west4), cf-cache-status: DYNAMIC. Обе страницы рендерятся на сервере (Shopify Online Store 2.0), не клиентское SPA.

Что работает хорошо

Отличный TTFB на обеих страницах (112мс главная, 190мс товар), значительно ниже рекомендованного порога в 200мс - комбинация Cloudflare edge + кэш платформы Shopify хорошо справляется, солидная база для LCP.
Шрифты корректно preloaded: все 5 файлов начертаний Gilroy используют <link rel='preload' as='font' crossorigin>.
Основной JS корректно deferred (bootstrap.bundle.min.js с defer), не блокирует рендеринг.
Некритичный CSS отложен через приём media='print', легитимный паттерн, чтобы избежать блокирующего рендеринг CSS.
preconnect к cdn.shopify.com присутствует, прогревая CDN-соединение.
Сторонний скрипт загружен как async, не блокирует. Изображения в основном с адаптивным srcset для нескольких ширин.

Выводы (4)

Чрезвычайно раздутый DOM - примерно 5400-5600 элементов на страницу

Высокая

Количество тегов: главная ≈5437 элементов, карточка товара ≈5603 элемента - в 3,6 раза выше часто упоминаемого порога в 1500 элементов, за которым размер DOM начинает реально влиять на стоимость пересчёта стилей/layout и оверхед обработчиков событий. Сырой HTML-payload составляет 866-941 Кб ещё до подсчёта байтов JS/CSS/изображений.

Влияние: напрямую повышает риск INP (большой DOM означает дорогой пересчёт стилей и layout при каждом взаимодействии - напр. открытие корзины, селектор варианта, фильтры) и замедляет начальный парсинг/рендеринг, косвенно отодвигая LCP.

Рекомендация: проверить секции темы Shopify на избыточную/дублированную разметку (напр. версии hero для десктопа+мобильной, обе отрендеренные дважды, повторяющиеся наборы иконок, слайды карусели, скрытые, но все отрендеренные в DOM одновременно). Ленивая загрузка секций вне экрана, использование content-visibility: auto в CSS для секций ниже линии сгиба, и удаление дублированных блоков SVG/разметки. Цель: <2000 элементов как первая веха.

Hero-изображение (кандидат LCP) не preloaded и обнаруживается очень поздно в документе

Высокая

Hero-изображение главной страницы (main-pic-L_...webp, класс main-page-hero-bg-desktop) появляется на строке ~14764 HTML-документа из 18107 строк - примерно 82% пути в исходном коде. Нет <link rel='preload' as='image' fetchpriority='high'> для него (только 5 файлов шрифтов preloaded). Блок preload/preconnect покрывает только шрифты и CDN-соединение, но не само LCP-изображение.

Влияние: сканер preload браузера не может обнаружить это изображение, пока не распарсит очень далеко в HTML, задерживая запуск запроса ресурса LCP - классическая причина "resource load delay" в разбивке LCP. Учитывая, что страница в остальном быстрая (хороший TTFB), это, вероятно, единственный самый важный рычаг для улучшения LCP.

Рекомендация: добавить явный <link rel="preload" as="image" href="[hero-desktop-webp]" fetchpriority="high" media="(min-width: 768px)"> (и мобильный эквивалент) в <head>, и добавить fetchpriority="high" напрямую на тег <img> hero. Переместить разметку hero раньше в DOM, если возможно, или как минимум убедиться, что она не отложена за несвязанными секциями.

Массово отсутствующие размеры изображений - высокий риск CLS

Высокая

20 тегов <img> на главной странице и 291 тег <img> на карточке товара имеют буквально пустые атрибуты width='' и height='' (не просто опущены - явно пусты), включая миниатюры товара, изображения аксессуаров nose-rest и иконки.

Влияние: без width/height (и без подтверждённого CSS-fallback aspect-ratio) браузер не может зарезервировать место layout до загрузки изображения, вызывая сдвиг макета при каждом появлении изображения - особенно вредно на карточке товара, где найдено 291 экземпляр (вероятно, свотчи вариантов / миниатюры галереи / сетки аксессуаров).

Рекомендация: заполнить реальные атрибуты width/height (или aspect-ratio в CSS) для каждого шаблонизированного <img>, особенно в галерее товара и сетках аксессуаров/апселлов карточек товара. Фикс с низкими усилиями и высоким влиянием, так как это системно (вероятно, один и тот же переиспользуемый сниппет Liquid).

Тяжёлый payload главной страницы: 8 встроенных видео + 5 preloaded начертаний шрифта конкурируют за пропускную способность

Средняя

8 отдельных источников cdn.shopify.com/videos/...mp4, встроенных в теги <video> (autoplay/loop/muted, используются для анимаций типа "как это работает"), плюс 5 отдельных файлов шрифтов woff2, все одновременно помеченные rel='preload'.

Влияние: видео используют preload='none', что смягчает начальную стоимость, но 5 конкурирующих высокоприоритетных preload шрифтов плюс hero-изображение борются за пропускную способность/ранние соединения на критическом пути, особенно на мобильной версии/условиях, эквивалентных 3G, используемых в скоринге мобильного CrUX.

Рекомендация: подтвердить, действительно ли все 5 начертаний Gilroy используются выше линии сгиба - если рендерятся только 2-3 начертания до взаимодействия, отложить загрузку остальных. Проверить, что font-display: swap корректно задан, чтобы избежать задержки невидимого текста.

Приоритетные рекомендации (в порядке влияния)

Preload hero-изображения LCP с fetchpriority="high" - напрямую устраняет "resource load delay" LCP, вероятно, изменение с лучшим ROI, учитывая, что TTFB уже быстрый.
Исправить пустые width/height на всех шаблонизированных изображениях, начиная с галереи карточки товара (291 экземпляр) - напрямую устраняет CLS.
Уменьшить размер DOM на шаблонах главной страницы и карточки товара - устраняет INP и даёт вторичные выигрыши LCP/времени парсинга.
Повторно запустить PSI/CrUX (или Lighthouse), когда станет доступно, чтобы получить реальные значения LCP, INP, CLS field/lab и подтвердить эти оценки.

5. Ссылочный профиль (backlinks)

Это измерение не удалось корректно замерить в этом проходе - рассматривать как пробел данных, который нужно закрыть в приоритете, а не как надёжный скор.

Ссылочный профиль

Не оценено

Прочитать перед любым выводом по этому измерению

Квота Ahrefs Enterprise API была исчерпана на каждом релевантном вызове для backlinks (domain-rating, metrics) - сбой на уровне аккаунта, а не домена. Резервных Moz или Bing Webmaster не было настроено. Единственный достигнутый источник - Common Crawl (Tier 0), который подтверждает, что домен проиндексирован и имеет некоторую измеримую входящую ссылочную ценность (ранг PageRank ~1 494 157), но вернул ноль образцов доменов-доноров - результат, который специалист явно квалифицирует как "направленно тревожный, но не окончательный", поскольку известно, что Common Crawl недобирает выборку для DTC/e-commerce сайтов среднего размера. Не считать цифру ~30-40 реальным скором. Повторно запустить это измерение с Ahrefs, как только квота pay-as-you-go обновится (2026-08-01), прежде чем делать какие-либо выводы об авторитетности ссылок.

Цель протестирована в голом виде (myluminette.com) и с www (www.myluminette.com), 24 июля 2026.

Опробованные источники

Источник	Статус	Примечание
Проверка уровня доступа	Выполнено	Подтверждён Tier 0 - ни ключа Moz, ни ключа Bing не настроено
Common Crawl (веб-граф)	Успех	Только на уровне домена, уверенность 0,50, релиз cc-main-2026-jan-feb-mar
Ahrefs API (domain-rating, metrics)	Сбой	"API units limit reached... API units left: 0" на обоих эндпоинтах, форматы bare и www
Moz API (metrics/domains/anchors/pages)	Не пробовано	Ключ MOZ_API_KEY не настроен
Bing Webmaster Tools	Не пробовано	Ключ не настроен
Краулер верификации backlinks	Не выполнено	Референсный список backlinks не предоставлен (новый клиент, нет baseline)

Что работает хорошо

Домен чисто резолвится в индексе Common Crawl (in_crawl: true, in_rankings: true) и распознан по 3 хостам (согласуется с канонической корневой + www + один дополнительный вариант) - никаких тревожных сигналов на уровне краулинга.
У домена ненулевой скор PageRank, классифицированный в графе CC (ранг ~1 494 157) - подтверждает некоторую измеримую входящую ссылочную ценность, не полностью изолированный/несвязанный узел.
Никаких признаков спама ссылок типа manual action в фактически полученных данных (слабый сигнал на этом Tier 0).

Выводы (4)

Премиум-данные backlinks недоступны в этом проходе - квота Ahrefs исчерпана в ходе аудита

Высокая

Прямые вызовы site-explorer/domain-rating и site-explorer/metrics для target=www.myluminette.com оба вернули {"error": "API units limit reached. Increase pay-as-you-go limit if you need more API units. Expected usage: 50, API units left: 0."}. Исчерпание квоты на уровне аккаунта (0 единиц осталось на всём Enterprise-токене), не проблема, специфичная для домена. В результате Domain Rating, общее число доменов-доноров, общее число backlinks, распределение анкоров и риск токсичных/спам-ссылок - основные результаты этого измерения - не удалось измерить, и они не оценены.

Рекомендация: пополнить баланс единиц pay-as-you-go Ahrefs (или дождаться следующего цикла сброса) и повторно запустить конкретно это измерение: domain-rating, backlinks-stats/refdomains, anchors, и backlinks для target=www.myluminette.com. До этого повторного запуска не указывать цифру ссылочной авторитетности для myluminette.com в кросс-измеренческом скоринге или в резюме для клиента - явно отмечать как ожидающее.

Не настроен бесплатный резерв (Moz/Bing) - у Tier 0 нет резервирования, когда премиум-источник даёт сбой

Средняя

Проверка уровня вернула tier: 0 с moz.available: false ("Ключ Moz API не найден") и bing.available: false ("Ключ Bing Webmaster API не найден"). Common Crawl был единственным рабочим источником после сбоя Ahrefs, и один только CC ограничивает уверенность на уровне 0,50 и не даёт ни DA/PA, ни анкоров, ни скоринга спама.

Рекомендация: зарегистрировать бесплатный ключ Moz API (moz.com/products/api, 2500 строк/месяц, без затрат) и проверить myluminette.com в Bing Webmaster Tools. Нулевая стоимость, даёт этому новому клиенту рабочий резерв Tier 1/2 каждый раз, когда токен Ahrefs достигает rate-limit или исчерпан - как в этом проходе. Разовая задача примерно на 15 минут.

Common Crawl показывает ноль образцов доменов-доноров - тревожно, но не окончательно

Средняя (ожидает подтверждения премиум-данными)

Оба вызова (myluminette.com и www.myluminette.com) вернули "top_referring_domains": [] и "referring_domains_sample": 0, несмотря на домен in_crawl: true с измеримым PageRank (ранг ~1 494 157) и рангом гармонической центральности ~3 376 827. Другими словами, граф CC признаёт, что сайт существует и имеет некоторый вес входящих ссылок, но его публичная выборка доменов-доноров не захватила ни одного для этого релиза.

Важная оговорка: граф ссылок Common Crawl выборочно охватывает лишь около 25-40% данных о ссылках домен-к-домену реального веба, и он известен тем, что недобирает выборку для DTC/e-commerce сайтов среднего размера по сравнению с крупными издателями. Выборка с нулём доменов CC - не доказательство нулевых реальных backlinks - это чаще всего отражает пробел покрытия CC для растущего одноязычного e-commerce бренда, а не реальное отсутствие ссылок.

Рекомендация: рассматривать как приоритет номер один для повторной проверки, как только кредиты Ahrefs будут восстановлены - получить в первую очередь refdomains и backlinks-stats для www.myluminette.com, поскольку это самая существенная нерешённая цифра всего измерения.

Распределение анкоров, риск токсичных/спам-ссылок и органическая видимость через backlinks полностью не оценены

Инфо - раскрытие пробела данных, не дефект сайта

Ни один из доступных в этом проходе источников (Common Crawl) не раскрывает распределение анкоров, скоринг спама/токсичности или органическую видимость, связанную с backlinks - для этого нужны Moz, Bing или Ahrefs, все недоступны или исчерпаны (см. выводы #1-2). В этом отчёте не делается никаких утверждений о естественности анкоров или доле токсичных ссылок; представление синтетической оценки для этих метрик нарушило бы правило "без вводящих в заблуждение числовых утверждений" на Tier 0.

Рекомендация: как только Ahrefs восстановлен, получить site-explorer/anchors (распределение анкоров) и сверить кандидатов на токсичные ссылки со стандартным чек-листом паттернов, уделяя особое внимание несоответствиям доменов на иностранных языках (myluminette.com продаёт на 20+ локализованных рынках - нормальный побочный продукт легитимной международной экспансии, не отмечать автоматически как токсичное без ручной проверки).

Приоритизированный план действий

Дедуплицированные и приоритизированные рекомендации из 11 специализированных файлов выводов. Каждая строка указывает что делать, почему (в одну строку), из какого измерения аудита это происходит, и оценку усилий. Клик по заголовку столбца сортирует таблицу.

Фаза 1 - Критические исправления

Неделя 1

Выводы с наивысшей серьёзностью, несущие прямой риск для дохода, доверия или приостановки на платформе. В основном шаблонные исправления или единичные правки значений с эффектом на весь сайт/высоким рычагом.

#	Что	Почему	Измерение	Усилия
1	Изменить `itemCondition` с `NewCondition` на `RefurbishedCondition` во всей schema восстановленных товаров (Luminette 3, и проверить Luminette 2 / Drive восстановленные на тот же шаблон)	Google Merchant Center может отклонить или приостановить карточки за несоответствие состояния товара	E-commerce	Низкие
2	Исправить противоречие robots.txt (Disallow /collections) vs sitemap (sitemap_collections_.xml подаёт те же URL) vs noindex на страницах коллекций - выбрать единый механизм	Google не может согласовать "краулить это" (sitemap) с "не краулить это" (robots.txt), тратит бюджет краулинга, риск предупреждений Search Console	Техническое SEO, Sitemap	Средние
3	Исправить утечку кода рынка/страны в теги <title> и meta description - единый баг Liquid-шаблона	Влияет на SERP-сниппет каждого URL сайта на 24 локалях; также риск geo-IP-зависимого заголовка, непоследовательно индексируемого Googlebot	Техническое SEO, E-commerce	Низкие
4	Подтвердить, инжектируют ли Okendo/Loox schema Review/AggregateRating на стороне клиента (проверка отрендеренного DOM); если нет, вручную добавить aggregateRating + реальные записи отзывов в schema товара	Самый повторяющийся вывод аудита (Schema, E-commerce, GEO, SXO - все независимо его отмечают); звёзды отзывов - главный рычаг доверия для взвешенной wellness-покупки и сейчас невидимы для Google/ИИ	Schema, E-commerce, GEO, SXO	Средние
5	Глобальный поиск/замена: `"@type": "Website"` -> `"@type": "WebSite"` во всех шаблонах schema	Невалидный тип schema.org (чувствителен к регистру) - подрывает право на sitelinks-searchbox и узел home каждой хлебной крошки	Schema	Низкие

Фаза 2 - Улучшения с высоким эффектом

Недели 2-3

Структурные исправления, требующие координации темы/шаблона и настройки Shopify Markets, но без производства нового контента.

#	Что	Почему	Измерение	Усилия
6	Добавить исключения robots.txt Allow: для /policies/* (и пересмотреть /collections) для ИИ-роботов	llms.txt явно просит агентов получать эти пути, пока robots.txt блокирует их для всех - самопротиворечие	GEO	Низкие
7	Добавить schema FAQPage к блоку FAQ карточки Luminette 3 и к флагманской статье "работает ли светотерапия"	Контент уже существует, не хватает только разметки; быстрый выигрыш высокой ценности для цитирования ИИ	Контент, Schema, GEO	Низкие
8	Переформатировать все даты статей JSON-LD в строгий формат ISO 8601 (разделитель T, не пробел)	Некорректные даты рискуют быть исключены из права на rich results свежести	Schema	Низкие
9	Задать ProductGroup.variesBy как ["https://schema.org/color"] (сейчас пустой массив - обязательное свойство)	Пустой variesBy может вызвать отклонение ProductGroup или обработку вариантов как несвязанных дублей	Schema	Низкие
10	Исправить некорректный, неабсолютный URL изображения во вложенном узле Article дублированного BreadcrumbList; в идеале прекратить дублировать полные данные Article в BreadcrumbList	Сломанный URL, а также нестандартное дублирование, увеличивающее поверхность багов	Schema	Низкие
11	Добавить явные width/height (или CSS aspect-ratio) ко всем шаблонизированным изображениям, начиная с галереи карточки товара (291 экземпляр) и изображений селектора главной страницы (26 экземпляров)	Серьёзный и системный риск CLS из общего сниппета Liquid для изображений	Производительность, Техническое SEO	Средние
12	Preload hero/LCP-изображения главной страницы (link rel="preload" as="image" fetchpriority="high") и пометить его loading="eager" вместо "lazy"	Hero-изображение обнаруживается на ~82% исходного HTML без подсказки preload - вероятно, самый крупный единый рычаг LCP, учитывая, что TTFB уже быстрый	Производительность	Низкие
13	Уменьшить размер DOM на шаблонах главной страницы и карточки товара (сейчас ~5400-5600 элементов, в 3,6 раза выше порога риска в 1500) - проверить дублированную/скрытую разметку, цель <2000	Большой DOM повышает риск INP (дорогой пересчёт стиля/layout при взаимодействии) и замедляет начальный парсинг	Производительность	Средние
14	Вручную проверить живой рендеринг секций с контентом, запускаемым скроллом, которые захватываются пустыми на скриншотах (~30-40% высоты страницы на главной и карточке товара)	Если реальные пользователи или headless-рендерер Googlebot переживают тот же сбой, решающий контент (сравнительная таблица, список преимуществ) может быть невидим или ненадёжно проиндексирован	Визуал	Низкие
15	Консолидировать title/meta карточки восстановленного товара, чтобы чётко отличить её от карточки нового товара (добавить "Восстановленный")	Почти идентичные заголовки сейчас рискуют внутренней каннибализацией запросов и плохим CTR для ищущих восстановленный товар	E-commerce	Низкие
16	Стандартизировать форматирование цены в schema ProductGroup в строки с двумя десятичными; подтвердить, что фид Merchant Center берётся из нативного API товара Shopify	Несогласованная типизация цены - частая причина отклонений "price mismatch" в фиде	E-commerce	Низкие
17	Подтвердить с клиентом, являются ли /nl/ vs /nl-nl/ намеренно отдельными рынками или legacy-дублем; консолидировать/перенаправить, если последнее	Избегает разбавления дублированным контентом между почти идентичными нидерландскими страницами	Sitemap	Низкие
18	Декодировать HTML-сущности (' и т.д.) перед вставкой текста в поля description/articleBody JSON-LD	Баг качества, видимый на любой поверхности, отображающей этот текст (сниппеты Google, AI Overviews)	Schema	Низкие
19	Снять с публикации или noindex + убрать из sitemap внутреннюю QA-страницу /pages/test-form	Забытая внутренняя страница, сейчас публично индексируемая	Техническое SEO	Низкие
20	Усилить HSTS (max-age до 31536000+, добавить includeSubDomains; preload) и добавить заголовки Referrer-Policy/Permissions-Policy	Постепенное усиление безопасности/приватности; правка конфигурации Cloudflare/Shopify	Техническое SEO	Низкие

Фаза 3 - Контент и авторитетность

Месяц 2

Работа по производству контента и информационной архитектуре - самый слабый слой сайта. Последовательность: сначала консолидировать, затем построить отсутствующие страницы с высоким интентом, затем наложить сигналы E-E-A-T.

#	Что	Почему	Измерение	Усилия
21	Консолидировать 4 параллельных силоса URL блога в единую каноническую структуру; объединить пересекающиеся тематические кластеры (8 постов "зимняя хандра", 6 постов "витамин D" и т.д.) в 1 pillar + 2-3 дифференцированных spoke, с 301-редиректами для остального	Самоканнибализация подтверждена поисками site:, показывающими 5+ URL сайта, конкурирующих за один запрос - доступный фикс контента с наибольшим влиянием	Кластеринг	Высокие
22	301-редирект осиротевших 404, всё ещё проиндексированных под legacy /light-therapy/* (фундаментальные pillar-страницы)	Тратит накопленную ссылочную ценность и создаёт тупики для внешних ссылок и закэшированных карточек SERP	Кластеринг	Средние
23	Построить медицински обрамлённую статью с указанным рецензентом, нацеленную на "светотерапия сезонная депрессия", цитируя Prof. Robert Poirrier (уже актив на сайте) и данные клинического испытания LUMIDEP/MDD	Сейчас ноль присутствия бренда по этому запросу с высоким интентом; 100% SERP - домены медицинского авторитета	SXO, Кластеринг	Средние
24	Построить настоящую страницу сравнения/гайда по покупке ("Лучшая лампа светотерапии в 2026 году"), включающую собственную лампу 2-в-1 Luminette, по паттерну Страница сравнения (таблица, плюсы/минусы, вердикт, критерии категории)	SERP по "лучшая лампа светотерапии" на 100% состоит из конкурирующего сравнительного контента; собственная лампа Luminette нигде не появляется	SXO	Средние
25	Создать выделенную категорийную/landing-страницу /collections/lunettes-de-luminotherapie для линейки очков (сейчас 404), со встроенными блоками контента гайда по покупке	Центральное товарное ключевое слово отвечается только общей и разбавленной главной страницей; SERP показывает гибридный паттерн Товар/Категория + Гайд	SXO	Средние
26	Связать каждое названное клиническое исследование на /pages/clinical-study и /pages/new-research с его источником PubMed/журнала; добавить пронумерованный список цитирований	Точные проценты эффективности сейчас заявлены как непроверяемые голые факты - сигнал доверия для отслеживания на YMYL-контенте и ограничение для цитируемости ИИ	Контент	Средние
27	Добавить видимый блок био автора/рецензента (credentials, напр. "проверено [специалистом]") со schema Person (jobTitle/worksFor) во флагманскую медицинскую статью блога, и повторить на контенте с заявлениями о здоровье	Названный автор сейчас не имеет видимых credentials на странице - фикс с наибольшим эффектом для взвешивания доверия ИИ на YMYL-контенте	Контент, GEO	Средние
28	Добавить секцию на главной странице из 200-400 слов, заявляющую о происхождении университетских исследований, названных учёных и сертификации безопасности	Главная страница сейчас - товарный/ценовой прайс-лист без нарратива доверия, недоиспользующий URL с наивысшей авторитетностью домена	Контент	Низкие
29	Переписать /pages/light-therapy из списка ссылок ~215 слов в настоящую pillar-страницу из 800+ слов	Сейчас тонкая и дублирует контент блога; должна быть якорем тематического кластера, а не просто ссылаться на него	Контент, Кластеринг	Средние
30	Заменить статичный модуль "Похожие статьи" компонентом, управляемым тегом/категорией, чтобы spoke-статьи перелинковывались внутри своего реального кластера	Сейчас показывает идентичный, неконтекстуальный контент на несвязанных типах статей	Кластеринг	Средние
31	Ввести таксономию категорий/тегов для блога (страницы архива, выступающие лёгкими хабами)	Блог - единый плоский хронологический список без тематической навигации; обнаружение полностью зависит от внутренних ссылок, сейчас неконтекстуальных	Кластеринг	Средние
32	Построить/консолидировать авторитетные страницы для выявленных пробелов интента: "очки светотерапии vs лампа SAD" (сравнение форматов, ни одной не существует) и "сколько времени использовать очки" (сейчас фрагментировано на 3 слабых поста)	Напрямую actionable пробелы с высоким интентом, для которых у бренда уже есть контент товара/FAQ для поддержки	Кластеринг	Средние
33	Снизить приоритет нового производства нерелевантного wellness-контента ("Тренировка за 7 минут", "Лучшие книги о сне" и т.д.); интегрировать существующие посты с настоящей связью со светотерапией или удалить/noindex	Конкурирует за бюджет краулинга/тематическую авторитетность против центрального корпуса о светотерапии без пути к квалифицированному трафику по товару	Кластеринг	Низкие
34	Локализовать URL-слаги блога по рынкам (напр. французский контент, перемещённый из английского слага /blogs/article/do-light-therapy-glasses-work)	Ноль сигнала французского ключевого слова в URL несмотря на полностью локализованный заголовок/мета/контент	SXO	Средние
35	Применить паттерн GEO флагманской статьи (H2 в форме вопроса, schema FAQPage, цитирования) к категориям блога light-therapy и light-therapy-applications	Только один пост из ~130 полностью оптимизирован под GEO; категорийные hub-страницы сейчас тонкие и не структурированы как вопросы	GEO	Средние
36	Создать или формально связать собственный YouTube-канал; стремиться к записи в Wikipedia для Lucimed/Luminette, если можно выполнить критерии заметности	Две самые сильные корреляции упоминания бренда с цитированием ИИ сейчас отсутствуют	GEO	Высокие
37	Добавить schema AggregateRating/Review на страницу /pages/customer-reviews на сайте и поддерживать её видимо свежей/датированной	Сейчас уступает пространство сниппета отзывов SERP Trustpilot (3 из 6 видимых результатов по "luminette avis")	SXO	Низкие

Фаза 4 - Отслеживание и итерация

Постоянно

#	Что	Почему	Измерение	Усилия
38	Повторно запустить аудит ссылочного профиля с Ahrefs (domain-rating, refdomains/backlinks-stats, anchors, backlinks), как только квота pay-as-you-go обновится (2026-08-01)	Текущий плейсхолдер (~30-40, уверенность 0,25) основан только на Common Crawl и явно отмечен как ненадёжный - это самая существенная нерешённая цифра всего аудита	Backlinks	Низкие (повторяющиеся)
39	Зарегистрировать бесплатный ключ Moz API и проверить myluminette.com в Bing Webmaster Tools	Бесплатный резерв Tier 1/2 для любого будущего аудита, где токен Ahrefs достигает rate-limit или исчерпан, как в этом проходе	Backlinks	Низкие (разово)
40	Повторно запустить PageSpeed Insights / CrUX / Lighthouse, как только rate-limit будет снят, для подтверждения реальных полевых процентилей LCP/INP/CLS	Текущие выводы по Производительности - оценки только на основе статических доказательств/ответа сервера, не живых лабораторных/полевых данных	Производительность	Низкие (повторяющиеся)
41	Как только станет доступен доступ к отрендеренному fetch/Playwright, подтвердить, инжектируют ли Okendo/Loox schema Review на стороне клиента	Аудит только статического HTML не смог это исключить; определяет, нужно ли элементу Фазы 1 #4 ручное добавление schema или просто переключение настройки приложения	Schema, E-commerce	Низкие
42	Выполнить полный diff crawl-vs-sitemap (напр. Screaming Frog в режиме списка против полного экспорта sitemap) на 24 sitemap локалей	Не выполнено в этом аудите из-за бюджета запросов; необходимо для подтверждения отсутствия осиротевших или лишних/рискованных страниц сверх уже найденной проблемы с коллекциями	Sitemap	Средние
43	Расширить анализ SXO до полной воронки из 15-20+ ключевых слов (очки, лампа, симптомы, сравнения, бренд) с живым отслеживанием позиций SERP	Этот проход охватил только 4 ключевых слова в проходе с ограниченным периметром; необходимо для подтверждения точных позиций ранжирования и живых функций SERP	SXO	Средние
44	Подтвердить с клиентом, должен ли рынок ru-ru оставаться онлайн, учитывая общий контекст санкций ЕС	Отмечено как бизнес/юридический вопрос, а не технический дефект	Техническое SEO	Низкие
45	Периодически пересматривать /agents.md, llms.txt и sitemap_agentic_discovery.xml по мере развития стандартов агентной ИИ-коммерции	Сайт сейчас опережает конкурентов на этом развивающемся направлении - преимущество, которое нужно защищать	GEO, Sitemap	Низкие (повторяющиеся)

Легенда усилий - Низкие: шаблонное исправление/правка единичного значения, несколько часов, без нового контента. Средние: работа с шаблоном на нескольких страницах, настройка Shopify Markets, или один новый/переписанный материал. Высокие: консолидация контента на нескольких страницах, перестройка информационной архитектуры, или запуск нового канала (напр. YouTube).