- Заміна тегів заголовків і метаописів за допомогою Менеджера тегів Google
- Деіндексація сторінок з тегами "noindex", реалізованими за допомогою менеджера тегів Google
- Додавання канонічних тегів до менеджера тегів Google
- Чи Google дотримується внутрішніх посилань, доданих за допомогою Менеджера тегів Google?
- Чи індексує Google URL-адреси, включені лише до скриптів JSON-LD, доданих за допомогою Менеджера тегів Google?
- Висновки: Ви можете додати все з GTM, але це може зайняти деякий час, поки зміни не почнуть показуватися.
Після нашого маленького JavaScript експеримент SEO с налаштування hreflang з Менеджером тегів Google , ми вирішили виконати ще кілька тестів, щоб проаналізувати, як Google має справу зі змінами, внесеними до веб-сайтів із JavaScript, за допомогою менеджера тегів Google
- Чи визнає Google зміни тегів назв і метаописів, реалізованих за допомогою Менеджера тегів Google?
- Google деіндекує сторінки, встановлені на "noindex" за допомогою менеджера тегів Google?
- Чи поважає Google канонічні теги, додані за допомогою Менеджера тегів Google?
- Індексується сторінками Google, пов’язаними лише через внутрішні посилання, вбудовані в Менеджер тегів Google?
- Чи індексує Google URL-адреси, які пов’язані лише через розмітку JSON-LD, реалізовану за допомогою Менеджера тегів Google?
Якщо вам цікаво отримати відповіді на ці запитання, і якщо ви бажаєте точно знати, як налаштувати все це за допомогою Менеджера тегів Google, продовжуйте читати.
TL; DR - Всі ці тести відпрацьовували належним чином, але деякі зміни вимагали дуже багато часу, щоб показати в результатах Google. Перейти прямо до висновки якщо ви поспішаєте.
Прямий доступ до різних частин тесту:
Заміна тегів заголовків і метаописів за допомогою Менеджера тегів Google
Тег заголовка та мета-опис домашньої сторінки англійської мови нашої компанії, https://www.searchviu.com/en/ , виглядають так у вихідному документі HTML сторінки:
Ми використовували наступний сценарій у спеціальному тезі HTML в менеджері тегів Google, щоб замінити тег заголовка та опис мета, так що інший текст відображається у візуалізованому HTML:
Зверніть увагу, що для тега заголовка ми змінили лише великі літери, а в описі мета замінили пару слів.
Тепер оригінальний тег заголовка та мета-опис все ще відображаються у вихідному документі HTML, але якщо ви перевіряєте HTML з допомогою інструментів розробника Chrome, ви побачите, що GTM замінює їх новою версією, яку ми визначили:
Через вісім днів після того, як ми опублікували цю зміну в GTM, Google почав показувати теги заголовків і мета опис, які ми додали з GTM, замість вихідних даних з вихідного документа HTML, і з тих пір їх показують:
Ми не були дійсно здивовані цим результатом, оскільки ми раніше проводили експеримент, який запропонував Google використовує наданий HTML інтерпретувати hreflang і ігнорує вихідний документ HTML. Таким чином, ми очікували того самого поведінки для тегів заголовків і метаописів.
Той факт, що зміни з'явилися лише через вісім днів, теж не здивували нас, оскільки Google надає сторінки менш регулярно, ніж вони сканують. Було б потрібно більше досліджень, щоб зробити більш тверду заяву про відмінності між скануванням і частотою візуалізації, так що це лише бічна нота.
Давайте тепер подивимося на деякі складніші речі! Наступна зупинка: “noindex”.
Деіндексація сторінок з тегами "noindex", реалізованими за допомогою менеджера тегів Google
Під час налаштування цих тестів ми натрапили на кілька URL-адрес з нашого домену, які не хотіли індексувати:
Наведений нижче сценарій, який використовується в тезі Custom HTML в GTM, з тригером, який робить його виконанням на сторінках, які ми хочемо деіндексировать, додає мета-тег "noindex" до запитуваних сторінок:
А потім ми чекали. І чекали. І чекали. І втратила надію. Google просто не збирав її.
На даний момент, я повинен визнати, що я недбалий дослідник. Я не можу сказати, як довго це тривало. Десь між 6 та 3 місяцями. Але одного разу, Google вирішив відобразити потрібні сторінки з деіндексацією та BOOM (всі п'ять сторінок успішно деіндексировані):
Ось пошуковий запит, який я використав у наведеному вище знімку вікна, якщо ви хочете перевірити його самостійно:
site: searchviu.com/uk/we-are-going-to-miss-you/ OR сайт: searchviu.com/de/wir-werden-dich-vermissen/ АБО сайт: searchviu.com/uk/author/ana- cidre / OR сайт: searchviu.com/uk/thank-getting-contact/ АБО сайт: searchviu.com/en/embed/
Отже, це також спрацювало дуже добре, але це зайняло набагато більше часу, ніж зміни в заголовку та мета опису. Зараз наша теорія полягає в тому, що менш важливі сторінки отримуються ще рідше. Але, як я вже говорив вище, нам потрібно більше досліджень щодо відмінностей між частотою сканування та частотою рендерінгу, перш ніж ми зможемо прийти до будь-яких твердих висновків щодо цієї теми.
Подивимося, чи працює те ж саме з канонічними тегами.
Додавання канонічних тегів до менеджера тегів Google
Канонічні теги складні, тому що незалежно від того, як ви їх реалізуєте, Google часто просто вирішує ігноруйте канонічні теги, якщо є інші сигнали, які конфліктують з ними . Тому ми повинні були знайти можливість для канонічного тегу, який ми впевнені, що Google не буде ігнорувати.
Одним з найважливіших вимог до правильного використання канонічних тегів є те, що весь вміст сторінки, на якому є канонічний тег, буде включено на сторінку, на яку вказує канонічний тег. З цієї причини ми вирішили встановити канонічний тег з моя сторінка автора до головна сторінка блогу , оскільки весь зміст першого доступний на останньому.
Нижче описано, як налаштувати це в GTM:
Коротше кажучи, це спрацювало дуже добре, але це зайняло стільки часу, скільки змінилося “noindex”.
Ось результат пошуку для пошукового запиту "eoghan henn searchviu", перш ніж додати канонічний тег з GTM:
І ось поточний результат. Сторінка зникла (і, по суті, рейтинг був втрачений - просто ще одна цікава бічна примітка) :
Таким чином, Google поважає канонічні теги, додані за допомогою Менеджера тегів Google (якщо вони використовуються в правильному контексті).
Я знаю, що ви в основному тут для отримання інформації про посилання, додані за допомогою JavaScript, так що давайте подивимося на це зараз.
Чи Google дотримується внутрішніх посилань, доданих за допомогою Менеджера тегів Google?
Одна справа, про яку нас дуже цікавило під час налаштування цього тесту, полягала в тому, чи буде Google сканувати внутрішні посилання, які не можна знайти у вихідному документі HTML, але вони були додані у JavaScript за допомогою менеджера тегів Google. Тому ми створили наступний маленький експеримент.
Перш за все, ми створили дві ідентичні сторінки на нашому веб-сайті WordPress, одну з яких ми хотіли б зв'язати внутрішньо з посиланням, доданим через GTM, а інший, який ми не будемо посилати на внутрішню адресу:
Чому ми створили другу сторінку? Ну, якщо перша сторінка індексується, ми повинні переконатися, що це через внутрішнє посилання, яке ми ввели, а не через щось інше. Ми переконалися, що сторінка не відображатиметься в будь-яких картах сайтів і що не було жодного пінга або інших фонових механізмів, коли ми її публікували. Але щоб бути на безпечній стороні, ми вирішили створити другу сторінку як контрольну сторінку. Результат тесту може бути позитивним, лише якщо перша сторінка індексована, а друга - не.
Можливо, я ж не такий недбалий дослідник ...
Отже, давайте швидко подивимося, як ми встановили це в GTM. Ми вибрали гарну неважлива сторінка з нашого веб-сайту, шукали посилання, на яку ніхто ніколи не натискатиме (сподіваюся), і використовував наступний сценарій у GTM, щоб замінити цільову URL-адресу посилання на першу з наших двох тестових сторінок:
Ось результат. Сторінка, яка була пов'язана лише за допомогою посилання, введеного GTM, була проіндексована, а на сторінці керування не було. Це, як і попередні зміни, тривало дуже довго, поки не було показано (приблизно два місяці):
Якщо вам цікаво, що частина -sameas в пошуковому запиті вище, будь ласка, прочитайте наступний біт цієї статті. Ми створили іншу тестову сторінку, яку ми з'єднали лише через JSON-LD, інжековані GTM, щоб дізнатися, як Google обробляє таку ситуацію.
Чи індексує Google URL-адреси, включені лише до скриптів JSON-LD, доданих за допомогою Менеджера тегів Google?
Якщо ви знаєте мене, ви, напевно, знаєте, що я дійсно в реалізація структурованих даних (schema.org) у форматі JSON-LD за допомогою менеджера тегів Google . Крім того, раніше я помітив, що URL-адреси з одного домену, включених до скриптів JSON-LD на іншому домені, відображалися як зовнішні посилання на перший домен у консолі пошуку Google . Google робить це дивні речі з інформацією, яку він знаходить у структурованих даних, тому я хотів дізнатися більше.
Ми вирішили створити іншу тестову сторінку, подібну тій, що описана у тесті внутрішнього зв’язку вище, але цього разу ми включили б лише URL-адресу в сценарії JSON-LD і ніде більше. Це налаштування в Менеджері тегів Google:
Я думаю, що на цьому етапі не дивно, що це також спрацювало. Google проіндексував тестову сторінку, яка була пов'язана лише за допомогою сценарію JSON-LD, на першій тестовій сторінці:
Тому сценарії JSON-LD - це ще одне джерело даних, яке Google використовує для пошуку URL-адрес.
Висновки: Ви можете додати все з GTM, але це може зайняти деякий час, поки зміни не почнуть показуватися.
Результати цих тестів показали, що Google буде обробляти та використовувати теги заголовків, мета описи, теги "noindex" і канонічні теги, додані або змінені за допомогою менеджера тегів Google . Вихідний документ HTML ігнорується, і розглядається лише візуалізований HTML.
Крім того, внутрішні посилання можна додавати з Менеджером тегів Google, а Google індексуватиме URL-адреси, які пов'язані таким чином . Навіть URL-адреси, включені лише до сценаріїв JSON-LD, доданих за допомогою менеджера тегів Google, будуть проіндексовані.
На жаль, цей експеримент не був створений для того, щоб визначити, скільки часу потрібно, щоб зміни відображалися в результатах Google . Ми не встановили моніторинг, щоб регулярно перевіряти результати. Ми знаємо, що зміни у назві та мета описі домашньої сторінки з'явилися після восьми днів. Всі інші зміни пройшли приблизно за два місяці, поки вони не показали.
Здається очевидним, що Google надає сторінки рідше і більш регулярно сканує їхні вихідні документи HTML. Подальші дослідження щодо відмінностей між скануванням і частотою візуалізації були б дуже цінними .
Колишні тести SEO SEO, які не враховували цих величезних затримок, могли мати негативні результати, оскільки тести не працювали досить довго, особливо якщо вони проводилися на сторінках, які були створені лише для цілей експерименту. Здається, що важливі сторінки (як, наприклад, наша домашня сторінка у вищеописаному випадку) відображаються частіше, ніж менш важливі (як і всі інші сторінки, на яких ми робили тести, що зайняли приблизно два місяці, щоб показати результати).
Ми сподіваємося, що ви знайшли наш маленький JavaScript SEO експеримент корисним, і багато інших створить подібні тести, так що вся індустрія SEO зможе дізнатися більше про те, як Google має справу зі сторінками, які покладаються на JavaScript. Будь-які питання або зауваження? Просто напишіть нам коментар!
Чи індексує Google URL-адреси, включені лише до скриптів JSON-LD, доданих за допомогою Менеджера тегів Google?Чи Google дотримується внутрішніх посилань, доданих за допомогою Менеджера тегів Google?
Чи індексує Google URL-адреси, включені лише до скриптів JSON-LD, доданих за допомогою Менеджера тегів Google?
Будь-які питання або зауваження?
