🎰 Монобренд SOP

Мінімальна частотність по гео — 100+ запитів/міс. Але якщо бренд має низьку частотність в цільовому гео але високу в інших країнах — це теж ок.

Де перевіряти:

• Ahrefs Keywords Explorer → вводиш назву бренду → фільтр по країні

• Google Trends → дивись тренд зростання, не лише обсяг

Гугли [brand] casino [geo] в браузері з потрібною країною (або через VPN/proxy).

У старих брендів видача вже забита і є офіційний сайт з купою лінків. У свіжих брендів (1-2 роки) Google ще не знає хто є офіційним — і легше ранжує монобренди.

Як перевірити вік:

• Пошукай в Ahrefs коли домен офіційного сайту з'явився
• Або просто погугли — новий бренд буде з недавніми новинами про запуск

Домен = частина ранжування. Чистий домен з назвою бренду в регіональній зоні — найкращий варіант.

Пріоритет доменів (від кращого до гіршого):

• betspino.fr — ccTLD, чистий ✅✅ найкращий
• betspino-casino.fr — ccTLD, з словом casino ✅
• betspino-fr.com — .com з гео в домені 👍
• betspino.com — загальна зона, слабше для FR ⚡
• betspino.online / .bet / .casino — ❌ не рекомендується

Зони для перевірки (United Kingdom / UK):

Зони для перевірки (France / FR):

Зони для перевірки (Germany / DE):

Зони для перевірки (Italy / IT):

Зони для перевірки (Spain / ES):

Зони для перевірки (Poland / PL):

Зони для перевірки (Romania / RO):

Зони для перевірки (Portugal / PT):

Зони для перевірки (Netherlands / NL):

Зони для перевірки (Belgium / BE):

Зони для перевірки (Austria / AT):

Зони для перевірки (Switzerland / CH):

Зони для перевірки (Sweden / SE):

Зони для перевірки (Norway / NO):

Зони для перевірки (Denmark / DK):

Зони для перевірки (Finland / FI):

Зони для перевірки (Czech Republic / CZ):

Зони для перевірки (Slovakia / SK):

Зони для перевірки (Hungary / HU):

Зони для перевірки (Greece / GR):

Зони для перевірки (Ireland / IE):

Для кожного бренду потрібно зібрати всі варіанти ключів і розподілити по сторінках. Сторінки діляться на трафікові (приносять візити) і трастові (сигнал офіційного сайту для Google).

Трафікові сторінки — приклад для бренду "mystbet":

Трастові сторінки — трафік не дають, але сайт виглядає офіційним:

Найкраще реєструвати домен одразу в Cloudflare Registrar — тоді NS вже будуть правильні і не треба нічого змінювати.

Варіанти реєстраторів:

• Cloudflare Registrar — registrar.cloudflare.com (найзручніше, ціна за собівартістю)
• Namecheap — популярний, дешевий
• Porkbun — часто дешевше ніж Namecheap

Кроки:

1. Заходь на cloudflare.com → Add a site
2. Вводиш домен → вибираєш безкоштовний план
3. Cloudflare сканує DNS і показує поточні записи
4. Копіюєш два NS сервера які дає Cloudflare
5. Йдеш до реєстратора → вставляєш ці NS замість старих

Кроки:

1. Workers & Pages → Create application
2. Вкладка Pages → Upload assets
3. Вводиш назву проєкту (наприклад: betspino-fr)
4. Перетягуєш папку з index.html
5. Натискаєш Deploy site

Кроки:

1. В проєкті Pages → вкладка Custom domains
2. Set up a custom domain
3. Вводиш свій домен: betspino-casino.fr
4. Якщо домен вже на Cloudflare → підключиться автоматично за хвилину
5. SSL сертифікат видається автоматично

Що потрібно підготувати перед генерацією:

Заповни поля нижче і натисни кнопку — отримаєш готовий промпт для Claude. Вставляєш в claude.ai → отримуєш повний HTML файл.

Правила контенту (we/our стиль):

• ✅ "In our casino, we offer..." — офіційний сайт
• ✅ "We provide our players with..." — від першої особи
• ❌ НЕ "The casino offers..." — це стиль огляду
• ❌ НЕ "Pros and Cons" та "Conclusion" секції

Мінімум 12 сторінок на сайт: 8 трафікових + 4 трастових. Кожна = окремий URL = окрема можливість потрапити в топ.

Трастові сторінки (один шаблон для всіх сайтів):

• /about/ → коротка сторінка "About Us"
• /terms/ → Terms & Conditions
• /privacy-policy/ → Privacy Policy
• /responsible-gambling/ → Responsible Gambling

Перед деплоєм відкрий HTML файл в текстовому редакторі і перевір що всі посилання ведуть на твою рефку.

Що перевірити:

• Кнопка "GET YOUR BONUS NOW" у hero
• Кнопки на бонусних картках
• CTA кнопки всередині SEO тексту
• Кнопки на внутрішніх сторінках

Sitemap допомагає Google швидше знайти і проіндексувати всі сторінки сайту.

Зберігай як sitemap.xml і клади в корінь папки поруч з index.html.

Структура папки перед деплоєм:

1. Workers & Pages → твій проєкт → Create new deployment
2. Перетягни всю папку betspino-fr/ в вікно
3. Натисни Deploy site
4. Через 10-30 секунд сайт живий на *.pages.dev

Чеклист перевірки:

• Головна сторінка відкривається ✓
• Всі внутрішні сторінки /login/ /bonus/ тощо ✓
• Кнопки ведуть на рефку (не на #) ✓
• Сайт виглядає нормально на мобільному ✓
• HTTPS замочок є в браузері ✓

1. В проєкті Pages → вкладка Custom domains
2. Set up a custom domain → вводиш домен
3. Якщо домен на Cloudflare — підключається автоматично
4. Якщо на іншому реєстраторі — зміни NS на Cloudflare NS

1. Заходиш на search.google.com/search-console
2. Add property → вибираєш Domain (не URL prefix)
3. Вводиш домен: betspino-casino.fr
4. Google дає TXT запис для верифікації

1. Копіюєш TXT запис який дає Google (вигляд: google-site-verification=xxxxx)
2. Йдеш в Cloudflare → свій домен → DNS → Add record
3. Type: TXT, Name: @, Content: вставляєш TXT рядок
4. Save → повертаєшся в Search Console → Verify

1. В Search Console → ліве меню → Sitemaps
2. В поле вводиш: sitemap.xml
3. Натискаєш Submit

Для кожної сторінки можна запросити індексацію вручну — це прискорює появу в пошуку.

1. URL Inspection (верхній рядок пошуку) → вставляєш URL
2. Google перевіряє сторінку → натискаєш Request Indexing
3. Повторюєш для кожної сторінки: /login/ /bonus/ /register/ /app/ /slots/ /games/ /payments/ тощо

Щоб перевірити чи сайт проіндексований — використовуй оператор site: в Google.

Якщо Google показує сторінки — сайт проіндексований. В Search Console також буде видно покази і кліки.

Title сторінки — один з головних факторів чи Google взагалі вирішить індексувати сторінку. Занадто загальний title = Google вважає сторінку дублем тисяч подібних і не індексує.

Формула яка працює:

В Search Console → Pages звіт можна побачити статус "Crawled — currently not indexed". Новачки часто думають що це технічна проблема — насправді це сигнал від Google що сторінка переглянута, але визнана недостатньо цінною щоб додати її в індекс.

Чому це відбувається:

• Контент занадто схожий на тисячі інших монобренд сторінок
• Title занадто загальний (див. попередній крок)
• Сторінка занадто тонка — мало унікального тексту
• Немає внутрішніх посилань на цю сторінку (дивись Фазу 7 — Перелінковка)

Що робити:

1. Перепиши title по формулі [ключ + вигода + бренд]
2. Додай більше унікального контенту — мінімум 300-400 слів тексту
3. Перевір що на сторінку ведуть внутрішні посилання з головної і суміжних сторінок
4. Повтори Request Indexing через 1-2 тижні після змін

На початку не варто надто зациклюватись на виборі партнерки. Головне — щоб гео підходило.

Як знайти партнерку для бренду:

• Гугли: [brand] affiliate program
• Або: [brand] partners
• Або пиши в тематичні Telegram чати — прийдуть 10+ пропозицій

Нормальні ставки CPA:

Що зазвичай питають при реєстрації:

• Сайт (вказуєш свій домен)
• Тип трафіку (SEO/organic)
• Гео (France, Netherlands тощо)
• Очікуваний обсяг трафіку

Після підтвердження акаунту в партнерці — отримуєш посилання виду:

Як вставити в усі файли:

• Відкрий кожен HTML файл в VS Code або Notepad++
• Ctrl+H (замінити) → шукай href="#" → замінюй на свою рефку
• Зроби для index.html і всіх внутрішніх сторінок
• Завантаж оновлені файли на Cloudflare Pages (Create new deployment)

1. Відкрий свій сайт
2. Клікни на кнопку "Get Your Bonus Now"
3. Перевір що відкрився сайт казино (не 404)
4. В партнерці через 5-10 хвилин має з'явитись 1 клік

Головна сторінка збирає найбільше зовнішніх лінків і має найбільшу вагу. Через внутрішні посилання ця вага передається на внутрішні сторінки — /login/, /bonus/ тощо. Без перелінковки Google бачить їх як ізольовані сторінки.

Правильна схема перелінковки:

Навігаційне меню в хедері є на кожній сторінці — це автоматично створює перелінковку між усіма сторінками сайту.

Що має бути в nav меню:

Контекстні посилання в тексті передають більше ваги ніж навігаційні. Вставляй їх природно в SEO-текст кожної сторінки.

Приклади контекстних посилань:

Футер є на кожній сторінці — тому посилання в футері автоматично зв'язують весь сайт. Особливо важливо для трастових сторінок.

Після деплою оновленого сайту можна перевірити що Google бачить внутрішні посилання правильно.

Де перевіряти:

1. Search Console → ліве меню → Links
2. Розділ Internal links — показує скільки внутрішніх лінків веде на кожну сторінку
3. Головна має мати найбільше вхідних посилань
4. /bonus/, /register/, /login/ мають бути в топі після головної

Не починай будувати лінки на "порожній" сайт без позицій. Чекай поки сайт:

• Отримує стабільні покази в Search Console
• Ранжується по релевантних ключах (хоча б на 30-60 позиції)
• Пройшло мінімум 40-60 днів після запуску

Покрокова стратегія:

1. Старт: ~400 дешевих лінків/місяць ($200-300)
2. Якщо росте: збільшуй до ~600/місяць наступного місяця
3. Продовжуй: і так поки не буде топових позицій
4. Застрял в топ-10: до 1000 лінків + 10-20 морд
5. Після топу: підтримуй динаміку приросту (менший обсяг, але стабільно)

Коли сайт вже в топ-10 — цей трюк може швидко дати топ-3 або вище.

Як працює:

1. Створи копію головної на підпапку: /en-gb/
2. На головній зміни canonical на підпапку
3. Додай hreflang теги

Якщо сайт раптово вивалився з позицій без явної причини:

Алгоритм реанімації:

1. Залий повністю новий контент (перегенеруй через Claude)
2. Онови дату в мета-тегах і в тексті
3. Створи нову підпапку і налаштуй hreflang+canonical
4. Відправ на переіндексацію в Search Console

Що перевіряти щотижня:

• Search Console: покази, кліки, середня позиція по ключах
• Ahrefs: зміна позицій по брендовим ключам
• Партнерка: реги, депи, виплати

Google любить свіжий контент. Раз на місяць оновлюй:

• Дату в мета-тегах і в тексті
• Актуальні умови бонусу (якщо змінились)
• Додай новий FAQ питання або секцію

Коли процес відпрацьований — запускай паралельно нові бренди. Головне розуміти реальні часові рамки.

Правильна модель роботи — "сніжний ком":

1. Запускаєш пачку сайтів
2. Забуваєш про неї на пів року
3. Паралельно сетапиш нові пачки
4. Через рік вже є стабільна база ожилих сайтів

Мета по масштабу:

• Місяць 1-2: 5-10 сайтів, вивчаєш процес
• Місяць 3-4: 20-30 сайтів, продовжуєш без зупинки
• Місяць 6-7: перші стабільні результати з перших пачок
• Місяць 12+: 50+ сайтів, команда, автоматизація

Перед кожним новим сайтом перевір:

• ✅ Частотність бренду 100+ в потрібному гео
• ✅ Топ-5 не зайнятий вкаченим офіційним сайтом
• ✅ Домен в регіональній зоні зареєстрований
• ✅ index.html з правильним we/our контентом
• ✅ Трафікові сторінки: /login/ /bonus/ /register/ /app/ /slots/ /games/ /payments/
• ✅ Трастові сторінки: /about/ /terms/ /privacy-policy/ /responsible-gambling/
• ✅ Рефка вставлена у ВСІ кнопки на всіх сторінках
• ✅ sitemap.xml з усіма 12 сторінками готовий
• ✅ Деплой на Cloudflare Pages, домен підключений
• ✅ Search Console — верифікований, sitemap надісланий
• ✅ Запит індексації зроблений для всіх сторінок

Частий страх новачків: "якщо я додам всі сайти в один Google акаунт — Google побачить що це сітка і забанить все відразу". Це міф.

Чому це безпечно:

• Search Console — це інструмент для власника сайту, не сигнал ранжування
• Google офіційно не використовує дані з GSC для виявлення сеток монобрендів
• Google вже бачить зв'язки між сайтами через інші сигнали — IP хостингу, шаблони коду, реєстратора — задовго до того як ти відкриєш GSC
• Один акаунт = простіше керувати моніторингом 50+ сайтів в одному місці

Ручний моніторинг працює добре до 10-20 сайтів. Коли сітка росте — варто переходити на автоматизацію. Це не обов'язковий крок зараз, але орієнтир куди рухатись далі.

Що можна автоматизувати на наступному рівні:

• Автовиливка статистики — скрипт що тягне дані з GSC API по всіх сайтах в одну таблицю щодня
• Авто-алерти — сповіщення коли позиції сайту різко падають (можливий DMCA/абуз)
• Автоматичні авто-фікси — наприклад автоматична переіндексація при виявленні падіння
• Авторозширення сітки — коли сайт показує перші позитивні сигнали, скрипт сам додає його в черга на лінкбілдинг

Чим успішніший сайт — тим вища ймовірність атаки. Скарги приходять з трьох основних джерел:

Головне правило захисту — дублер має бути готовий заздалегідь, а не в момент коли основний сайт вже впав. Готувати після вильоту — занадто пізно.

Що готувати разом з основним сайтом:

1. Реєструєш другий домен (інша зона, інший реєстратор) — наприклад betspino-fr.com якщо основний betspino.fr
2. Деплоїш на нього точну копію сайту (та сама структура, той самий контент)
3. Підключаєш окремий Cloudflare акаунт — не той самий що для основного домену
4. Додаєш дублер в Search Console одразу, не чекаючи проблем
5. Тримаєш дублер "у сплячці" — без активного просування, просто готовий до підміни

Якщо основний домен раптово зник з видачі (DMCA, абуз реєстратору, блокування) — діяти потрібно швидко, по чіткому алгоритму.

Покрокова дія:

1. Підтвердь причину — перевір email реєстратора/хостингу на скаргу, перевір сайт чи відкривається
2. Зроби дублер основним — поміняй ролі: дублер-домен стає видимим, основний (проблемний) йде в alternate
3. Онови canonical і hreflang — на дублері canonical вказує на себе, не на старий проблемний домен
4. Відправ на переіндексацію в Search Console дублера — Request Indexing для всіх ключових сторінок
5. Пінгуй основний (новий) домен зовнішніми індексаторами для прискорення

Щоб Google швидше "повірив" що новий (раніше дублер) домен — це продовження того ж сайту, варто підсилити його посиланнями.

Що робити:

• Якщо є власна PBN мережа — поставити кілька сквозних посилань на новий основний домен
• Якщо лінки вже були на старому домені — частина з них може автоматично оновитись через редірект (якщо встиг налаштувати)
• Можна замовити швидкий пакет дешевих лінків (пироги) для прискорення визнання нового домену

Namecheap і подібні західні реєстратори часто блокують домен по скарзі без попередження і без можливості оскарження до моменту блокування.

Альтернативний підхід:

• Переїзд домену до китайського реєстратора (наприклад через Alibaba Cloud / West.cn) знімає частину абузів — вони повільніше і не так суворо реагують на західні DMCA скарги
• Дублери варто реєструвати в інших реєстраторах ніж основні домени — щоб одна скарга не зачепила відразу всю пачку
• Не тримай всі домени сітки в одному акаунті реєстратора — розподіляй

Перед тим як вкладати бюджет в лінки — перевір:

• ✅ Домен-дублер зареєстрований і готовий (інша зона/реєстратор)
• ✅ Дублер задеплоєний з точною копією сайту
• ✅ Дублер додано в Search Console заздалегідь
• ✅ Основний і дублер на різних Cloudflare акаунтах
• ✅ Домени сітки розподілені по кількох реєстраторах
• ✅ Домени і сервери не зареєстровані на твої особисті документи
• ✅ Знаєш алгоритм підміни напам'ять — не доведеться шукати інструкцію в момент паніки

Гемблінг-афіліатка в багатьох юрисдикціях знаходиться в сірій зоні. Реєстрація десятків доменів і серверів напряму на свої особисті дані створює зайвий ризик.

Що робити:

• Готуй окремий "робочий" набір даних — пошта, телефон — не пов'язаний з основними особистими акаунтами
• Для оплати реєстрацій використовуй віртуальні картки, не основну банківську картку
• Якщо команда росте — розглядай реєстрацію через окрему юридичну особу

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

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

• Банки можуть блокувати картки за "підозрілі" транзакції з гемблінг-партнерок — окремий рахунок ізолює ризик
• Окремий криптогаманець для кожної партнерки або групи партнерок — якщо один скомпрометований, інші в безпеці
• Простіше вести облік доходів по кожному напрямку коли гроші не змішані

Коли сітка росте до десятків сайтів — паролів від доменів, Cloudflare акаунтів, партнерок, хостингів стає забагато щоб тримати в голові. Найчастіша помилка — складати їх в звичайний Excel файл або Notes без шифрування.

Що використовувати замість цього:

• Password manager (Bitwarden, 1Password, KeePass) — шифрований сейф паролів
• Двофакторна автентифікація на всіх ключових акаунтах (Cloudflare, партнерки, реєстратори)
• Не пересилай паролі в Telegram чи email у відкритому вигляді — навіть собі

Зручно тримати все в одному Cloudflare акаунті — але це створює єдину точку відмови. Якщо акаунт заблокують (за скаргою на один із сайтів) — постраждає вся сітка одночасно.

Рекомендований підхід:

• Групуй сайти по кілька (5-10) на один Cloudflare акаунт, не всі в одному
• Для дублерів (Фаза 10 — Захист від абузів) — окремий акаунт від основного домену
• Використовуй різні email для реєстрації різних груп акаунтів

Так само як з Cloudflare акаунтами — не реєструй всі домени сітки в одного реєстратора. Один масовий абуз або блокування акаунту реєстратора може забрати весь портфель доменів одночасно.

Як розподіляти:

• 3-5 реєстраторів в обігу (наприклад: Namecheap, Porkbun, Cloudflare Registrar, регіональний реєстратор)
• Дублери — завжди на іншому реєстраторі ніж основний домен (детальніше в Фазі 10 — Захист від абузів)
• Не більше 10-15 доменів на один акаунт реєстратора для топових/прибуткових сайтів