На моєму останньому посту я дав три причини, щоб уникнути прискорених мобільних магів (AMP). Прискорені сторінки для мобільних пристроїв - це плоскі веб-сторінки HTML, які слідують Google Керівні принципи Google і розміщуються Google для підвищення продуктивності завантаження сторінок на мобільних пристроях. Оскільки час завантаження є фактором ранжування, AMPs має підвищити SEO. Три причини, щоб уникнути AMPs зводитися до одного: вам потрібно JavaScript для відстеження та вимірювання ефективності маркетингу, а також для створення більш персоналізованого досвіду вмісту. AMP не дозволяють JavaScript. Таким чином, для великої кількості маркетингового контенту AMPs є нетрансляторським.
Існує четверта причина, чому ви потребуєте JavaScript на своїх сторінках: міжнародний SEO. Якщо ви намагаєтеся обслуговувати плаский вміст HTML, розроблений для кожної з країн, де ви займаєтеся бізнесом, ви будете переживати власний агресивний алгоритм фільтрації анти-дублювання Google. Ця стаття розповідає про те, як ми виявили цей очевидний конфлікт у стандартах Google на IBM . Зрештою, нам було зрозуміло, що AMP не сумісні з міжнародними SEO. Після того, як я розповім історію, я сподіваюся, що ви також зробите цей висновок.
Боротьба IBM з міжнародним SEO
Великі підприємства, які намагаються обслуговувати один і той же контент користувачам у різних країнах, давно намагалися зробити це ефективно. У IBM ми намагалися майже кожну тактику повідомити Google, що певна країна та мовна версія сторінки є унікальною для цієї країни. На початку ми намагалися Dublin Core метадані. Google проігнорував його, оскільки робить більшість метаданих у елементі <head> сторінки HTML.
Далі ми спробували ввести код країни та мови (cc-lc) у URL-адресу. Google також проігнорував наші коди країн і мов. Як наслідок, якщо дві сторінки на одній мові були орієнтовані на різні країни, Google вирішив би класифікувати те, що було визнано найбільш релевантним для запиту. У більшості випадків для англійської мови, це була сторінка США, оскільки вміст виникла в США і частіше оновлювалася в США. Таким чином, органічні користувачі пошуку у Великобританії отримають американські сторінки.
Це було проблемою, коли на сторінках розміщувалися спеціальні пропозиції США. Це було особливо проблемою, коли на американській сторінці були контактні модулі США та ціноутворення. Наша британська організація з маркетингу мала витрачати на платні пошуки набагато більше грошей, щоб отримати необхідні результати, оскільки вони просто не могли перевершити наші американські сторінки в органічному пошуку.
Зовсім недавно ми спробували перенести цей код cc-lc на передню частину рядка URL і зареєструвати його Консоль пошуку Google . Google Правила для веб-майстрів запропонувати таку тактику, особливо для сторінок продукту, де в їхніх інтересах надати правильну сторінку правильному користувачеві в правильній країні. З причин, які будуть зрозумілі, це спрацювало досить довго, якби сторінки не мали дубльованого вмісту.
Звичайно, ми поєднували тактику URL HREFLANG і канонічний теги. Разом вони, здавалося, працювали для ранжирування сторінок. Іншими словами, якщо сторінка була в індексі Google, і ці коди були виконані належним чином, Google буде служити правильною сторінкою в потрібній країні та мові в результатах пошуку.
Але на початку цього року компанія Google почала агресивно видаляти сторінки зі свого індексу, які вони вважали дублікатами. Це видалення відбувається за межами алгоритму рейтингу, тому коди, які ви використовуєте, щоб спробувати повідомити Google про сторінку, не стосуються конкретної країни
Відповідно до Google, алгоритм порівнює текст на сторінці . Якщо дві сторінки мають багато дубльованих блоків вмісту, алгоритм позначає їх як дублікати. Google не публікує свої алгоритми, тому що це дало б чорним капелюхам SEO рецепт для маніпулювання результатами пошуку. Але консенсус серед SEO-орієнтованих компаній полягає в тому, що якщо дві сторінки мають понад 70 відсотків однакових слів, він вважає їх дублікатами і націлює їх на видалення з індексу. За останній рік компанія Google відфільтрувала мільйони сторінок IBM.com зі свого індексу.
Коли ми зв'язалися з Google, щоб запитати, чому вони відфільтрували стільки наших сторінок, вони називали дубльований вміст проблемою. Вони рекомендували створити унікальний контент для кожної мови та країни. Це не дійсно варіант для компанії, яка веде бізнес в 150 країнах і десятках мов. Зазвичай ми створюємо один набір контенту і локалізуємо його на всіх відповідних ринках. На англо- та іспаномовних ринках це означає створення функціональних дублікатів.
Клініка була божевільним аспектом фільтрування індексів Google. Коли він знайшов дублікати в індексі, він залишив в індексі один випадковий дублікат, і це було б тим, що обслуговувалося на всіх ринках, які говорять на цій мові. Для деяких з наших найважливіших пошукових запитів продукту ця сторінка служила для Багамських островів усім англомовним ринкам, включаючи США. Коли ми дізналися про це, ми знали, що нам доведеться знайти рішення для проблеми дубльованого контенту.
Мова спочатку
Рішення можна знайти в офіційному керівництві на сторінці веб-майстра, на яку посилається вище:
Якщо у вас є багато схожих сторінок, розглянути можливість розширення кожної сторінки або об'єднання сторінок в одну. Наприклад, якщо у вас є туристичний сайт з окремими сторінками для двох міст, але однакова інформація на обох сторінках, ви можете або об'єднати сторінки на одній сторінці про обидва міста, або ви можете розширити кожну сторінку, щоб вона містила унікальний вміст про кожне місто. [акцент мій]
Рішення насправді досить просте. Як я вже сказав, для нас не дуже важливо розробити такий унікальний контент на кожному ринку. Це займе більшу армію копірайтерів і редакторів, ніж ми можемо собі дозволити. Тому ми зосередимося на об'єднанні сторінок на одну канонічну сторінку.
Замість публікації іншої URL-адреси для кожної комбінації мов і країн, ми спробуємо опублікувати одну URL-адресу для кожної мови для кожної маркетингової сторінки. Потім ми будемо використовувати динамічні системи для завантаження унікальних аспектів цього досвіду користувачам конкретних країн.
Наприклад, користувачі в США отримають всю інформацію про валюту в доларах після того, як система виявить їх розташування IP-адреси. Все, що хоче просувати місцевий ринок на цій сторінці, можна завантажувати одночасно, включаючи місцеві пропозиції, події або партнерів. Для IBM мова в першу чергу також зменшить наш вміст в 10 разів. Це величезна вигода, незалежна від SEO.
Оскільки на одній мові існує лише одна сторінка, ця система не зможе зіткнутися з дублюючим фільтром вмісту Google. Але проблема полягає в динамічно завантаженому вмісті. Очевидно, нам потрібно використовувати JavaScript для завантаження контенту для конкретної країни. Оскільки AMP-специфікації Google забороняють JavaScript, ви просто не можете вперше використовувати мову AMP.
Якщо ви запускаєте невелике підприємство, ви, можливо, створите унікальний контент для кожної країни та комбінації мов, а також подайте їх через AMP Google. Але для підприємства з тисячами маркетологів, що створюють зміст щодня, існує лише одна стійка модель: перша мова.
Подобається ця посада?
Зареєструйтеся на наші листи тут.
Про Джеймс Метьюсон
Джеймс Метьюсон - шановний технічний маркетинг IBM для пошуку. Він має 20-річний досвід роботи у веб-редакціях, стратегії змісту та SEO для великих і малих компаній. Частим спікером, лектором і блогером, Джеймс опублікував більше 1600 статей і дві книги про те, як веб-технології та досвід користувачів змінюють характер ефективного контенту. Джеймс має два вищі ступені з відповідних предметів з Університету Міннесоти.
Подобається ця посада?