GLLmolfar

Сканування починається з домену чи розділу й знаходить URL-адреси посиланнями, через XML-карти сайту, обома способами разом або зі списку, який ви вставите. Кожну відповідь записано, а знахідки згруповано за важливістю у списку виправлень: чому це важливо, як виправити і яких адрес стосується. Групові виправлення збирають знахідки, які розв'язує одна зміна — на весь сайт, на шаблон чи на тему, — тож виправлення шаблону стає одним завданням, а не чотирмастами.

• Доступність та індексованість: коди відповіді, ланцюжки редиректів, robots.txt, meta robots, X-Robots-Tag, canonical, присутність у карті сайту, глибина кліків і ознаки сторінок-сиріт.
• Структура сторінки: заголовки title з їхньою шириною в пікселях, meta description, заголовки H1–H2, повтори й текст, який з'являється лише після виконання JavaScript.
• Посилання й ресурси: внутрішні й зовнішні посилання, анкори, биті адреси, посилання на редиректи, зображення без alt.
• Технічні деталі: hreflang, структуровані дані й перевірка JSON-LD, заголовки відповіді й безпеки.
• Одна адреса без сканування: сторінку завантажено, відрендерено, сфотографовано на десктопі й мобільному й перевірено — разом із перевірками доступності axe-core на відрендереній сторінці.

Після одноразового завантаження моделі GLLmolfar локально перетворює фрагменти сторінок на ембединги й використовує їх для чотирьох речей. Карта тем розкладає сайт за змістом, і кожну групу підписано її характерними словами. Канібалізація ставить поруч незвично схожі сторінки однією мовою з їхніми спільними фрагментами й трьома виходами: об'єднати з редиректом, canonical або розвести за змістом. Нагоди для посилань ставлять у пару сторінку, на яку мало внутрішніх посилань, і близькі за змістом сторінки, що на неї ще не посилаються. Семантичний пошук відповідає на введене питання сторінками й фрагментами, найближчими до нього.

Перегляд фрагментів показує, як одна сторінка ділиться на фрагменти, які зберігала б пошукова система, і наскільки кожен тримається теми заголовка та H1. Усе це — підказки для людини, а не позиції: дві близькі за змістом сторінки варто переглянути, але це не доказ, що вони конкурують у Google. З підключеним Search Console застосунок ще й показує запити, за якими Google справді показав дві чи більше ваших сторінок, — це вже те, що пошук зробив насправді.

Окремий перегляд з'ясовує, чи можуть ШІ-краулери зайти на сайт і прочитати знайдене: правила robots.txt для кожного ШІ-бота, чи є на сайті llms.txt, чи віддає він Markdown агентам, які його просять, і наскільки добре кожна сторінка читається фрагментами, які асистент міг би процитувати окремо. Коли GLLmolfar сканує з пресетом бота, як-от GPTBot, він дотримується власної групи цього бота в robots.txt.

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

Після входу застосунок може запустити локальний MCP-сервер. Тоді Claude Code, Codex, Cursor чи інший MCP-клієнт може запускати сканування, читати список виправлень і адреси за кожним виправленням, перевіряти сторінку, шукати за змістом і зберігати звіти. Дістатися до сервера можуть лише програми на тому самому комп'ютері й лише з токеном, а кожен крок агента видно у вікні застосунку.

У застосунку також є 18 навичок для агентів — готові завдання: технічний аудит, перевірка готовності до ШІ, розчищення канібалізації, план внутрішніх посилань, чернетка llms.txt тощо. Кожна навичка каже агентові, які інструменти GLLmolfar викликати, у якому порядку і що повернути. Будь-яке виправлення можна перетворити на задачу в Jira — із застосунку або руками агента.

Збережені сканування сайту зібрано в одну історію, і будь-які два можна порівняти: адреси, коди, title, заголовки, індексованість, canonical і зміст. Звіти експортуються в HTML або PDF — для клієнта, для розробника чи короткий. Сканування можна запланувати щодня, щотижня чи щомісяця; вони йдуть на вашому комп'ютері, поки застосунок відкритий або згорнутий у трей, і після кожного застосунок каже, що погіршилося відтоді, — зокрема ШІ-ботів, яких щойно заблоковано в robots.txt. Будь-яку таблицю можна вивантажити в нову Google Таблицю у вашому власному Drive.

Записи сканувань та їхня історія лежать у локальній базі в теці даних застосунку. Ембединги рахуються на пристрої. Сканування, звісно, надсилає звичайні запити на сайт, який сканують, а необов'язкова перевірка зовнішніх посилань звертається до сайтів, на які вони ведуть. Сканування не надсилається в жоден хмарний ШІ-сервіс.

На getlooploop.com застосунок надсилає небагато й названого на сторінці продукту: анонімну статистику використання (випадковий ідентифікатор встановлення, версію застосунку, версію операційної системи, мову й час роботи) і перевірку нової версії. Обидва можна вимкнути в Налаштуваннях. Дані Search Console йдуть від Google прямо на ваш комп'ютер.

GLLmolfar зараз у попередній версії: він сканує справжні сайти й знаходить справжні проблеми, але функції, ліміти й формати файлів можуть змінюватися від версії до версії. Збірки ще не підписані сертифікатом, тож Windows і macOS попереджають перед першим запуском. Збірки для Linux і для Mac на Intel немає.

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

• Це не трекер позицій і не прогноз позицій; оцінка здоров'я сайту підсумовує зважені перевірки й не є оцінкою Google.
• Схожість за змістом — підказка для перевірки, а не доказ канібалізації ключових слів.
• Він не вимірює, чи цитують або згадують сайт ШІ-асистенти.
• Він нічого не змінює на сайті, який сканує.

Той самий термін словами, якими про нього питають асистента, а не набирають у рядку пошуку — написано із ситуації, тому кожне питання несе ту ситуацію, з якої виникло.

• GLLmolfar — сторінка продукту
• Model Context Protocol
• axe-core — рушій перевірки доступності
• Файл /llms.txt