📼 Програмне SEO: Як корпоративні та великі сайти динамічно масштабують своє сео

За час моєї роботи в якості SEO, я повільно, але впевнено відточував свою спеціалізацію – програмне/динамічне SEO.

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

Однак, я бачив велику прогалину в розумінні багатьма SEO-спеціалістами того, що таке динамічне SEO, як воно працює, і що найголовніше – як про нього думати.

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

Отже, пробіжімось по тому, що це таке, як про це думати, динамічні стратегії та кілька прикладів для натхнення.

Що таке програмне SEO?

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

Ви можете створювати систему або просто оптимізувати існуючу систему.

При “звичайному” SEO ви вносите одну зміну, і вона впливає на одну сторінку.

Динамічне SEO означає внесення однієї зміни, яка впливає на сотні, тисячі або навіть сотні тисяч сторінок.

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

Прокат автомобілів <місцезнаходження> – Пропозиції по оренді автомобілів в <місцезнаходження>.

Тоді кожна сторінка розташування буде динамічно вставляти своє місцезнаходження, і ви отримаєте;

Прокат автомобілів Мельбурн – Пропозиції по прокату автомобілів в Мельбурні

Оренда авто в Сіднеї – Пропозиції по прокату авто в Сіднеї

Прокат автомобілів у Брісбені – Пропозиції на прокат автомобілів у Брісбені

Але тоді, можливо, ви хочете, щоб там також були комбінації типу транспортного засобу, ви б подивились на такий заголовок, як;

<тип транспортного засобу> найняти <місцезнаходження> – Пропозиції щодо прокату <тип транспортного засобу у множині> в <місцезнаходження

Що дасть вам:

Прокат автомобілів в Мельбурні – Пропозиції по прокату автомобілів в Мельбурні

Оренда вантажівок Мельбурн – Пропозиції по прокату вантажівок у Мельбурні

Прокат мікроавтобусів Мельбурн – Пропозиції по прокату мікроавтобусів в Мельбурні

4WD прокат Мельбурн – Пропозиції по прокату 4WD у Мельбурні

При цьому це відтворюється у всіх місцях та типах транспортних засобів у базі даних.

Ще одним хорошим прикладом є веб-сайт нерухомості.

Уявіть собі всі різні сторінки результатів пошуку, доступні при пошуку нерухомості.

Там є два ключові елементи, які майже завжди повинні бути оптимізовані – канал, тип власності та місце розташування.

Отже, якщо ми використовуємо шаблон заголовка сторінки;

<тип нерухомості> для <канал> в <географічне місце> – <канал Вторинний> <тип нерухомості> з <ціна> – <канал Вторинний> <тип нерухомості> з <ціна>.

Це викине такі заголовки, як:

Продаж квартир в Річмонді – Купити квартири від $499,000

Продаж будинків в Річмонді – купити будинки від 499 000 доларів

Оренда квартир в Південній Яррі – оренда квартир від $ 599,000

Зняти квартири в Річмонді – Оренда квартир від $325 за тиждень

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

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

Це і є динамічне SEO в найпростішій формі.

Типи веб-сайтів, які можуть використовувати динамічне SEO

Існує те, що я вважаю поширеною помилкою, коли мова йде про програмне SEO, і це те, що воно містить в собі повністю JS-сайти, які постійно динамічно оновлюються.

В основному це погано оптимізоване, по суті, клієнтське лайно на JS. І це те, що я думав раніше, тому що я ніколи не розумів цього.

Але це набагато більше, ніж просто так!

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

Так само, як і багато інших веб-сайтів.

Отже, хто може використовувати динамічне SEO?

Будь-хто, хто має базу даних з якимось контентом. Для початку це може бути навіть проста електронна таблиця.

Щось, що можна використовувати для створення сторінки.

Мій улюблений приклад – портали, ринки та веб-сайти оголошень.

Ви можете використовувати вміст своїх споживачів та клієнтів для ранжування!

Вам не потрібно створювати контент. Просто потрібно організувати вміст БД найбільш ефективно.

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

Ці сайти мають лістингові дані. Ці дані є надзвичайно цінними, але не тільки для самої сторінки лістингу.

Ці дані стають цінними для інформації, пов’язаної з цим списком.

Категорії, місцезнаходження, характеристики… список можна продовжувати!

Скажімо, для порталу нерухомості.

Оголошення може ранжуватися за адресою, але такий термін, як “нерухомість Сіднея”, нерозумно ранжувати за одним оголошенням.

Споживачі хочуть, щоб під час пошуку їм показувалося кілька варіантів.

Отже, ви створюєте сторінки результатів пошуку (SRP).

Сторінки результатів пошуку, які динамічно оптимізуються, оскільки вони насправді не “створюються” одна за одною.

Використовуючи всі дані списку, ви агрегуєте свої списки на основі факторів, за якими має сенс ранжування.

Місцезнаходження – “Нерухомість Сідней”

Тип нерухомості – “Квартири”

Канал – “Нерухомість на продаж”

Розташування + Тип нерухомості – “Квартири Сідней”

Розташування + Тип нерухомості + Канал – “Продаж квартир в Сіднеї”

Список можна продовжувати.

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

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

URL-адреса /buy/sydney/, очевидно, представлятиме всі об’єкти нерухомості, що продаються в Сіднеї, тому це те, що поверне база даних.

URL-адреса /buy/sydney/apartments/ буде представляти всі квартири, що продаються в Сіднеї, і, таким чином, це те, що буде запитуватися з бази даних.

Самої сторінки /buy/sydney/apartments/ не існує, система просто знає конкретні значення.

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

Динамічний процес мислення в SEO

Найголовніше, про що потрібно думати при динамічному SEO, – це те, що ви не завжди будете робити все на 100% правильно.

Вам доведеться йти на жертви.

Жертви, які можуть перешкоджати частині сторінок, але принесуть користь більшості.

Одна оптимізація, яка піде на користь одним, не піде на користь іншим.

Потрібно просто думати про більшість і оптимізувати для більшості.

З часом ви можете повільно вдосконалювати свою стратегію, щоб зменшити жертви, які приносяться.

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

Отже, ви можете запустити щось, що допомагає 80% сторінок, чудово! Але ці нещасні 20% залишаться наодинці. Наступного разу ви можете повернутися і спеціально налаштувати ці 20% так, щоб допомогти 80% з них. Кожна зміна менш цінна окремо, але все одно може допомогти вам рости в цілому, як тільки всі швидкі перемоги будуть відзначені галочкою.

Що я маю на увазі під цим?

Ну, скажімо, у вас є список з 1 000 локацій. Назви цих міст мають різну довжину.

“Сідней” має довжину 6 символів, а от передмістя “Сіднейський олімпійський парк” – 29 символів.

Якщо ви намагаєтеся придумати заголовок для однієї сторінки, який враховує довжину обох, ви можете втратити можливості ключових слів / CTR для коротшого розташування, але також скоротити довший.

Продаж квартир в Сіднеї – купити квартири від $ 499,000

Продаж квартир в Олімпійському парку Сіднея – купити квартири від $ 499,000

Інший варіант може бути, коли “Квартири на продаж в Сіднеї” є головним ключовим словом для Сіднея, але тоді для Мельбурна ключовим словом може бути “Квартири на продаж в Мельбурні”.

Вам доведеться вибрати один, на який ви хочете націлитися як на основний формат.

Згодом, можливо, ви зможете налаштувати систему, щоб дозволити обидва формати. Вам також потрібно буде переглянути та призначити формати для кожного з них, тому це далеко не так просто, як просто вибрати один формат для роботи.

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

Це означає, що вам потрібно буде чимось жертвувати, але просто пам’ятайте – ви хочете спробувати оптимізувати для 80%, докладаючи 20% зусиль. Нехай це буде просто, для початку.

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

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

Через деякий час ви можете зайти та зробити резервні копії для цих заголовків.

Таким чином, у вас може бути один формат, якщо місце розташування менше x символів, і інший формат, якщо місце розташування довше цього.

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

Ви також отримаєте додатковий внесок від зацікавлених сторін, якщо зможете знайти швидкі перемоги в рамках ваших оптимізацій.

Далі поговоримо про оптимізацію програмної збірки.

Оптимізація програмної збірки

• До яких змінних ви маєте доступ.

Точки даних, до яких ви фактично маєте доступ і які можете використовувати.

Для порталу нерухомості це можуть бути такі речі, як: місце розташування, тип нерухомості, ціна, кількість спалень, ванних кімнат і т.д.

Вам слід почати з перерахування їх усіх десь, щоб ви могли з’ясувати, чи є якісь прогалини, які ви, можливо, захочете оптимізувати.

• За якими змінними ви насправді хочете ранжуватися.

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

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

• За якими змінними ви повинні намагатися ранжуватися – не всі вони однакові.

Не всі змінні рівні. З деякими ви отримаєте більше “вигоди за гроші”, ніж з іншими. Для багатьох змінних ви просто створите значну кількість сканованих/неіндексованих URL-адрес, які будуть витрачати час Googlebot і давати мінімальну або нульову цінність.

Дуже важливо ретельно вибирати змінні.

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

Використовуючи ціноутворення існує дуже багато різних цінових фільтрів, які можна встановити. Якщо сайт пропонує 50 тис. кроків для фільтра, а ціна починається з 200 тис., вона може сягнути низьких мільйонів, що означає, що може бути 50+ варіантів одного фільтра. Це стає великою проблемою, коли ви поєднуєте це з набором локацій, скажімо, 10 000 локацій, і в кінцевому підсумку створюєте 500 000 індексованих URL-адрес, пов’язаних з ціною, коли лише кілька ключових слів, таких як “нерухомість на продаж до 500 тис.”, можуть мати сенс для оптимізації.

Аналогічна ситуація зі спальнями. Так, будинки з 3 спальнями в <largeCity> можуть того варті, але “будинки з 3 спальнями в <middleOfNowhereTown>”, коли у вас понад 10 000 таких міст, разом з 5-6 варіантами фільтрів для спалень, ви створюєте 60 000+ URL-адрес тільки для цього одного додаткового фільтра.

Ви можете додати до них правила і створити більше “ручних” сторінок, щоб націлити їх на конкретні версії змінних, але в цілому, слід уникати всього, що створює значно більше URL-адрес, ніж ті, які фактично будуть використовуватися для ранжирування.

Багатоваріантність – кілька варіантів

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

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

Чому занадто багато низькоцінних URL-адрес може стати проблемою?

Є кілька причин, чому занадто багато URL-адрес не завжди добре, і перша з них зводиться до сканування. Хоча Google намагатиметься визначити пріоритетність певних URL-адрес якнайкраще, ви в кінцевому підсумку просто витратите свій бюджет на сканування, якщо значний відсоток ваших URL-адрес, що скануються, не мають практично ніякої цінності.

Інша причина полягає в тому, що контент, який використовується на цих сторінках, починає відображатися на сотнях і тисячах подібних сторінок, що призводить до того, що Google бачить по суті дублікати сторінок. Якщо він продовжує бачити один і той же вміст сторінка за сторінкою, він може не ставитися до нього однаково і почне знецінювати ці конкретні URL-адреси. Тоді у вас залишаться URL-адреси, які все ще доступні для сканування, але з мінімальними шансами на ранжування.

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

Програмні правила

Створення правил для сторінок значно допоможе динамічній системі в ранжируванні. Правила можуть допомогти визначити, що саме “створює” сторінки, обмежуючи вміст, на який ви посилаєтесь.

Налаштування цих правил значно покращить продуктивність сканування, оскільки ви, по суті, визначаєте, чи “існує” сторінка чи ні. Якщо вона “існує”, ви включаєте її в карту сайту разом з внутрішніми посиланнями. Це, по суті, приховує сторінки з низькою цінністю в темній дірі, оскільки ви не хочете, щоб їх знаходили пошукові роботи.

Правило SERP з нульовим результатом

Одне з основних правил, над яким я працюю зі своїми клієнтами при налаштуванні, – це правило 0 результатів. Google часто позначає сторінки з 0 результатами як soft-404, оскільки він може зрозуміти, що сторінка може бути і 404, оскільки результати “не знайдено”. Коли сторінка пошуку повертає 0 результатів, вона повинна бути виключена з карт сайтів і посилань, щоб не витрачати бюджет на сканування URL-адреси, які повертають текст типу “результатів не знайдено”. Google часто навіть позначає їх як м’які помилки 404.

Правила зі змінною відповідністю

Ще одне правило, яке ви можете створити, – це правило, яке “створює” сторінки тільки тоді, коли змінна збігається з однією зі списку. Ви могли б створити 20 типів властивостей, але, можливо, 5 з них дуже близько збігаються або перетинаються з іншими типами властивостей. Використовуючи таке правило збігу, ви можете змусити розробників виключити деякі типи властивостей з красивої URL-адреси і замість цього просто використовувати їх як параметр запиту.

Правила прив’язки змінних до красивих URL-адрес

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

Обхідні шляхи

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

По суті, це просто загальне правило, яке використовується тільки тоді, коли інше правило не працює. Це для крайніх випадків.

Простим прикладом є речення з підрахунком результатів. На SRP ви можете мати текст “У нас є 10 властивостей, які відповідають вашому пошуку”.

Це все добре і добре, поки у вас немає жодного. Вам слід уникати просто сказати: “У нас є 0 об’єктів, які відповідають вашому пошуку”.

Це банально і пропонує користувачам (… і Google) нульову цінність.

Але можна додати запасний варіант, який буде приблизно таким: “Наразі у нас немає об’єктів нерухомості, що відповідають вашому запиту, але є кілька дуже схожих об’єктів” з деякими списками, включеними нижче, або з посиланням на пов’язані списки.

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

Я дотримуюся методології SEO “використовуйте те, що у вас є”.

Навіть якщо 10% вашого контенту має певний елемент, який можна оптимізувати, навіщо обмежувати ці 10%, не використовуючи його? – Окрім додаткового часу, який це може зайняти, звичайно 🙂

Просто візьміть за правило використовувати його, а потім використовуйте запасний варіант, щоб зловити і обробити інші 90%. Потрібен час, щоб досягти цього рівня, але воно того варте, щоб забезпечити постійне зростання.

Найкраще в цьому те, що навіть якщо, скажімо, спочатку 90% потребують цього резерву, у міру зростання сайту, можливо, це буде лише 80% через місяць, потім 70, 60 і т.д. Як тільки ваші правила будуть встановлені, вони будуть жити там назавжди.

Внутрішня перелінковка для динамічного SEO

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

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

Встановлюйте перехресні посилання між типами сторінок, коли це має сенс.

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

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

Нарешті, при створенні посилань уникайте посилань на сторінки з нульовою цінністю. Такого роду налаштування можуть бути створені для автоматичного створення посилань на нові сторінки, коли вони отримують достатньо контенту, щоб вважатися “сторінкою”. Новий контент, розміщений на сайті, означає створення нових сторінок. Створення цих нових сторінок означає, що ці системи можуть автоматично зростати в міру зростання бізнесу.

Динамічна генерація контенту

В ідеалі, у вас є вручну створений фрагмент контенту для кожної сторінки. Коли у вас понад 10 000 сторінок з динамічним налаштуванням, це не завжди можливо.

Саме тут динамічні системи можуть блищати, і багато вебсайтів не використовують свій динамічний сайт в повній мірі.

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

Одним з найкращих прикладів цього є багато веб-сайтів для порівняння подорожей.

Наприклад, на сайті booking внизу ви знайдете розгорнутий список поширених запитань.

Одне з них звучить так

Скільки коштує проживання в готелі в Сіднеї?

Що по суті просто:

Скільки коштує проживання в готелі в <місцезнаходження>?

Вони дають відповідь на нього:

В середньому, 3-зірковий готель в Сідней коштує 273 AUD за добу, а 4-зірковий готель в Сідней – 388 AUD за добу. Якщо ви шукаєте щось дійсно особливе, 5-зірковий готель в Сіднеї в середньому можна знайти за AUD 568 за ніч (на основі цін Booking).

Цей шматок тексту можна розбити на шаблони, наприклад;

В середньому, 3-зірковий готель в <місцезнаходження> коштує <валюта> <3starAverageCost> за ніч, а 4-зірковий готель в <місцезнаходження> – <валюта> <4starAverageCost> за ніч. Якщо ви шукаєте щось дійсно особливе, <propertyType> в <location> в середньому можна знайти за <currency> <5starAverageCost> за ніч (на основі цін Booking).

Потім будуть додані правила, що якщо в цьому місці немає 5-зіркових готелів, то просто не включати це речення. Так що, можливо, в місті будуть тільки 4-зіркові готелі, тоді буде додано тільки це речення.

Тільки не забувайте, що ви завжди можете замінити цей динамічний текстовий розділ розділом, написаним вручну, коли це має сенс. Таким чином, можливо, ваші найкращі 1% сторінок будуть “оновлені”. Інша стратегія полягає в тому, щоб використовувати динамічний текст для початку, а потім, коли сторінки починають набирати певну популярність, ви оновлюєте їх за допомогою ручного контенту.

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

Якщо ви тільки починаєте, вам може допомогти мій шаблон динамічної генерації контенту в Google Таблицях.

Розширення динамічної генерації контенту за допомогою spintax

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

Тож замість єдиної версії:

В середньому, 3-зірковий <тип нерухомості> в <місцезнаходження> коштує <валюта> <3starAverageCost> за ніч

Можна було б працювати в варіації

<3-зіркові готелі в <location> мають середню вартість проживання в середньому в <currency> <3starAverageCost> за ніч.

Spintax, очевидно, не творить тих чудес, які він творив у 2010 році, але шар динамічних змінних в тексті трохи змінює ситуацію. Коли у вас понад 10 000 сторінок, на яких використовуються досить схожі речення, трохи змішати речі, безумовно, не зашкодить!

Однак, тут є досить велике застереження. Якщо ви робите щось подібне, вам обов’язково потрібно переконатися, що текст не генерується кожного разу при створенні сторінки.

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

Додавання “ручного” елемента сторінки до динамічної збірки

Збірка програмного SEO не обов’язково повинна на 100% складатися з динамічно згенерованих сторінок. Ви можете додати більше ручного шару в суміш.

Я схиляюся до того, щоб назвати їх більш “користувацькими” сторінками, і вони, по суті, існують для того, щоб зловити залишки, які динамічна збірка не може ефективно зловити.

Використовуючи фільтр цін як приклад, не кожна ціна потребує чистої URL-адреси.

Однак, провідні міста можуть отримати вигоду від наявності сторінок з кількістю відвідувачів менш як 300 тис., менше ніж 500 тис., менш як 1 млн. Отже, можливо, 5 сторінок, можливо, для 10 міст.

Так, ви можете ввести деякі правила, щоб обмежити створення сторінок до того, що вам потрібно.

Однак, іноді може бути простіше буквально перерахувати 50 сторінок, а потім мати якесь правило фільтрації сторінок, щоб обмежити вміст до того, що ви хочете.

У цьому випадку це може бути:

Будинки вартістю менш як 500 тис. У Мельбурні

З фільтрами:

propertyType = house

ціна < 500000

розташування = Мельбурн (або альтернативно, “розташування МІСТИТЬ Мельбурн”, залежно від ваших налаштувань та змінних)

Таке налаштування також дозволить створювати сторінки на кшталт “Будинки на узбережжі в Мельбурні”, якщо у вас є якась особливість нерухомості “на узбережжі”. Можливо, ви не захочете, щоб це було створено для всього, тому це може бути способом зберегти певну гнучкість.

Оптимізація пошуку та створення окремих цільових сторінок

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

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

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

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

Поширені помилки динамічного SEO

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

Однак є деякі помилки, про які слід пам’ятати при роботі з цими системами.

Надмірне створення індексованих красивих URL-адрес

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

Цього можна уникнути, в першу чергу, контролюючи, які змінні отримують гарні URL-адреси, а які змінні прилипають до параметрів. Це пов’язано з тим, що параметри запиту трохи легше контролювати під час сканування.

Надмірна індексація URL-адрес параметрів запиту

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

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

Дозвіл сканерам розгулювати на повну

Навіть якщо ви значно зменшили кількість змінних, що створюють індексовані URL-адреси, посилання на них все одно можуть створити серйозні проблеми з надмірною індексацією. Скажімо, у вас є змінна місцезнаходження, в якій міститься 10 000 місць. Можливо, тільки 1,000 з цих місць є досить цінними або навіть мають контент.

Таким чином, хоча “красива” URL-адреса може бути створена для всіх 10 000, вона технічно не буде існувати для Google, якщо на неї не буде посилання.

Забезпечення належних правил, встановлених для всіх віджетів посилань, допоможе обмежити те, що сканується, що потім, очевидно, обмежить те, що індексується. Те ж саме стосується і будь-яких XML-карт сайту, які у вас є. Виключіть все, що ви вважаєте “менш цінним”.

Якщо ви вже зіткнулися з цією проблемою і шукаєте рішення, перенаправлення 301 або 404/410 URL-адреси були єдиним способом, який я бачив, щоб ефективно виправити цю проблему. Жоден канонічний хак або інший трюк, схоже, не працює.

Забуваючи встановити ієрархію

“А ось плоска архітектура працює краще”. Для 100-сторінкового контент-сайту, можливо! Для сайту на 1000+ сторінок вам потрібно встановити ієрархію за допомогою структури сайту.

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

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

Ієрархія корисна для сканування, але надзвичайно корисна для визначення того, що є що на веб-сайті, і яка сторінка є по суті “відфільтрованою” версією іншої сторінки.

Якщо у вас є URL-адреси типу нерухомості, наприклад, “квартири на продаж в Сіднеї”, вам дійсно потрібно, щоб вони були пов’язані з “sydney real estate” в ієрархії. Відфільтрована сторінка з квартирами вже буде використовувати контент, знайдений на загальній сторінці нерухомості, тому чіткий показ того, що ця сторінка знаходиться нижче загальної, допоможе Google зрозуміти взаємозв’язок між ними.

Так, це, ймовірно, можна зробити і без встановлення чіткої ієрархії. Але навіщо ускладнювати життя Google? Спростіть їм життя, і, можливо, вони спростять ваше.

Недостатнє розуміння змінних у грі

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

Простим прикладом тут є слова, які є множиною проти однини. Якщо у вас є типи нерухомості, деякі з яких є множиною, а деякі одниною, ваше речення вмісту, яке використовує ці змінні, не матиме сенсу.

Знайти квартиру на продаж в Сіднеї

Знайти квартиру на продаж в Сіднеї

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

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

Іншим прикладом є ситуація, коли точка даних може містити кілька варіантів. Наприклад, для типів нерухомості точка даних може мати вигляд “квартири, земля”, а не типи нерухомості окремо.

Тому вам потрібно буде врахувати це, розділивши їх, інакше ви можете отримати додаткові несподівані сторінки та/або дивні формулювання в контенті.

Ця стаття – вільний переклад матеріалу з блогу sammyseo. Авторські фотографії та посилання у цьому перекладі не включені, якщо цікавлять, то завітайте на вищевказаний блог і у пошуку зробіть запит на “PROGRAMMATIC SEO”. Там ще є і приклади програмного SEO, які я не додав, тому що, без скріншотів буде мало що зрозуміло.

Взагалі, там на цю тему досить багато думок і експериментів.