Фасетний пошук Gone Wild: Ефективно використовуючи Endeca & Lucene для SEO

Фасетний пошук був досить рідкісним. Тепер це, здається, скрізь! Отримання інформації про помилки щодо того, як ви обговорюєте видимість сайтів із цією функцією, є однією з найпоширеніших подій у сайтах електронної комерції сьогодні. Ми стикаємося з тими ж проблемами тут і знову на Flying Point Digital, і з точки зору SEO, це не просто "зробити кращі сторінки категорії". Хоча це важлива частина виправлення, це лише половина історії.

Дякую, капітан Очевидний

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

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

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

Мільйонні Каталоги Продуктів

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

Фасетний пошук - це лише всі фільтри, на які можна натиснути, щоб уточнити ваш пошук, окрім підключення ключових слів або розгортання навігації. Тут є деякі формальні визначення, а також непідвладна чутливість до порядку (що не існує при навігації за допомогою дрилінгу). Буріння меню з чутливістю до замовлень (наприклад, веб-гіперпосилання) передбачає певну завершеність вашого дослідження. Все, що ви "знайдете" аналогічно файлам на жорсткому диску або вузлах дерева. Хоча це можливо, просто важче створити павуки-пастки з деталізованою навігацією. Саме тому веб працює в основному, і це те, що зробило пошук та індекс Google настільки геніальною та ефективною системою. Це також те, що надало Google несправедливу репутацію для "не подобається" динамічних сайтів.

Павуки-пастки і змішані повідомлення

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

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

У цій статті ми зосереджуємо увагу на одному конкретному типі динамічного павука-пастки, що генерується навігаційною схемою, яку часто називають гранованим пошуком. Забавне слово, грані. Змушує вас думати про вирізані обличчя коштовності. Думаю, що електронна комерція працює просто добре, і це простіше, ніж говорити про довільну параметризацію або атрибуцію, або багатовимірний або польовий фільтр. Не всі параметризовані пошуки є гранями. Грані, як правило, дозволяють собі йти в різних порядках і, здавалося б, у нескінченних перестановках - і те, що робить їх «гранями» і таким особливо неприємним павуком-пасткою.

Ендека і Лучене

Частіше ми помічаємо проблеми з ограненими пошуковими сайтами, тому що зараз легше створювати сайти, які його використовують. Ця технологія навігації була значно рідше через витрати та експертизу, необхідні для її налаштування, а також на вимоги серйозних серверів, що забезпечують цю функцію (з точними даними) у масштабі. Це змінюється. Незалежно від того, які ваші дані заблоковані, деякі продукти, такі як Endeca (тепер, з Oracle) або Lucene (проект Apache), можуть пройти через неї і побудувати базу даних і індекси, необхідні для підключення до компонентів створення сайту, які мають пласт пошук на сайті.

Endeca вже давно є домінуючим комерційним програмним забезпеченням для корпоративного класу, що пропонує фасетований пошук - саме тому ви чули, як їх ім'я викликається так сильно, коли ця тема виникає. Ви, звичайно, будете платити за цю впевненість. Але якщо у вас є власна впевненість, і сильна команда розробників, є альтернатива програмного стека Lucene, яка не є власністю (вільним і відкритим вихідним кодом).

Як мені сказали, Lucene, як я не розробник досвіду з цим програмним стеком, робить майже все, що робить Endeca, навіть з продуктивністю на рівні підприємства, але безкоштовно. Як і у Endeca, є справді цілий набір індивідуальних продуктів, які працюють разом у своєрідній екосистемі. Вершиною цієї екосистеми є Apache Software Foundation (еквівалент компанії), потім проект Lucene (еквівалент продукту) і після цього частина, що робить фактичний веб-інтерфейс, про який ми говоримо - або Solr, або Elastic Search.

Так що все це Lucene і Endeca речі, за загальним визнанням, що ІТ-інфраструктура, що "Хмара", як передбачається, щоб утримати вас від того, щоб мати справу з, і є трохи старої школи DIY-почуття до них. Якщо ви є компанією з меншими розмірами або просто не бажаєте реалізації завдань, і хочете використовувати найбільш узгоджені найкращі практики, які все ще вважаються корпоративними, завжди існує Demandware, або безліч інших продуктів, які заповнюють ніші між Endeca / Lucene в одному екстремальному випадку і самостійно розміщеним екземпляром WooCommerce на WordPress на іншому.

Крім того, всі дійсно великі технологічні гравці, такі як IBM, Microsoft і SAP, пропонують щось, щоб вирішити проблему веб-пошуку. Endeca і Lucene - це імена, які виникають знову і знову, коли ви займаєтеся SEO такими проблемами, так що це простий спосіб сформулювати це обговорене обговорення, але майте на увазі, що дійсно є інші на кожному кінці спектру, і незліченну кількість між ними. Якщо, наприклад, ви хочете, щоб хмара-легкість Demandware, але з можливістю прийняти все це в будинку коли-небудь, щоб почати накладення в екстремальних налаштування для конкурентної переваги, є Hybris на високому кінці, і Magento на низькому рівні.

Два екстремальних сценарію

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

  1. Повністю невидимий для пошуку з тієї чи іншої причини
  2. Видимий для пошуку, але створює сайт, який Googlebot ніколи не закінчить сканування та вивчення

У першому сценарії фасетовані пошукові сайти, які є невидимими для пошуку, або є невидимими, оскільки інтерфейс користувача побудований з елементами старомодної форми CGI і вимагає представлення або виконання JavaScript для виконання пошуку, або фактично сканування, але власники сайтів "вимкнули" здатність Google сканувати / індексувати сайт через файл robots.txt або інший механізм, як правило, через те, що вони зазнали біль ситуації номер два.

У ситуації другий, весь гранований пошуковий сайт і всі потенційні сторінки, які він може створити, повністю скануються Google. Однак сторінки нескінченні, і 99% цього нескінченного сканування - це дубльований вміст. Іншими словами, це павук-пастка. Google бачить весь ваш сайт, але через нерозуміння поставленого перед ним завдання він відмовиться і перейде на наступний сайт.

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

Подумайте про умови реальних дерев реального життя

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

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

І це лише один з підходів до контролю за павуковими пастками - нехай все покаже ... нехай павук-пастка продовжує існувати ... але зрозумійте Google про те, що відбувається, і як будь-яке повзе повз Очевидним ядром / важливим набором є надмірна і, можливо, непотрібна робота. Google-пошук з модифікатором сайту повинен повертатися приблизно з кількістю канонічних основних сторінок, які ви зараз чітко рекламуєте, а НЕ інше, що ви допускаєте, є перестановками з низьким пріоритетом.

Найкращими рішеннями завжди є ті, на яких сайт може генерувати лише обмежену кількість сторінок, і Google може прокручувати їх через кілька днів. Спробуйте запустити Кричала жаба на сайті (з великою кількістю пам'яті). Якщо він ніколи не закінчується, ви можете мати павуку пастку.

Це як на будь-якому дереві, це може бути важко, але ви можете насправді порахувати листя! Це можливо, але ви закінчите. Так само буде Screaming Frog закінчити повзати правильно кінцевий сайт.

Порядок має значення - скорочення перестановок

Певна гібридизація фасетів може допомогти отримати ситуацію під контролем, наприклад, зробити певні аспекти здатними лише активувати їх у поєднанні з деякими іншими аспектами, щоб відобразити та нав'язати обмеження відносин даних. Можна вважати, що це поєднання набагато більш обмеженої схеми навігації з гранями вниз. (Грані представлені конкретно на певних рівнях). Навігація за дрилінгами має тенденцію до виконання певного порядку в параметрах рядка запиту (заплутані як папки чи ні).

Ви також можете конструювати ваші URL-адреси ретельно, з певним примусовим порядком до граней, так що ви маєте справу тільки з комбінаціями замість перестановок. (Виконайте пошук "комбінацій проти перестановок"). Зокрема, якщо ви обираєте грань А, а потім фасет B в одному випадку, а потім фасет В, а потім аспект А в іншому, URL-адреси будуть різними, але результуючий сторінка однакова. Це можна виправити лише за допомогою алфавітного вводу або використання попередньо встановленого порядку для відображення параметрів у URL-адресі.

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

Художнє формування сайту

Як було сказано в цій статті, більшість гранітних пошукових сайтів роблять їх невидимими для пошуку або неможливим повзанням. Реальна відповідь десь посередині - художнє формування. Існує багато способів вимкнення, від внесення змін до файлу robots.txt до налаштування параметрів консолі пошуку Google (раніше інструментів для веб-майстрів) до зміни мета-тегів у джерелі перегляду.

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