Тег прив’язки всередині <h1> або <h1> всередині тега прив’язки: що краще?


52

Я намагаюся використовувати <h1>теги в своєму блозі для назви посади і зіткнувся з однією проблемою. Назва гіперпосилання.

Випадок 1:

<h1> <a href=""> xyz </a> </h1>

випадок 2:

<a href=""> <h1> xyz</h1> </a> 

Який із SEO краще?

Відповіді:


57

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

Все інше (XHTML, HTML4 тощо), а друге - просто неправильно. Це не був би дійсним кодом, і на певному рівні це погано для оптимізації пошуку [Вставте стандартну відмову про те, наскільки якесь одне злочин насправді впливає на що-небудь тощо].


У мене питання: <h1> привіт <h1> // 5 символів <h1> <a> привіт </a> </h1> // 5 символів чи Google читає його як 12 символів?
hfarazm

11

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


3
Насправді вбудовані елементи не повинні містити блокових елементів відповідно до специфікації HTML.
НевдоволенийGoat

3
@DisgruntledGoat Не зовсім. Доктіп потрібно враховувати.
Су '

@Su ', які доктити дозволяють блокувати елементи всередині вбудованих елементів?
НезадоволенняГота

4
@DisgruntledGoat HTML5 дозволяє посиланням (раніше просто вбудованим елементам) оточувати елементи блоку, такі як заголовки та теги абзацу. Тут важливий доктіп. Якщо ви використовуєте HTML5, будь ласка, використовуйте шаблон <a><h1></h1></a>. В іншому випадку використовуйте традиційний візерунок <h1><a></a></h1>. Google однаково приділить увагу обом методам, але деякі веб-переглядачі можуть не грати добре з нестандартним шаблоном.
Тіна Белл Венс

тому вищезазначене стосується і названих тегів якоря. чи не так? добре мати <h1> <a name='intro'> Вступ </a> </h1> крім <a name='intro'> <h1> Введення </h1> </a>.
Джаяпал Чандран

6

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

Це не вибір дійсності, а перевага в інтерфейсі користувача:

  • Якщо ви обмотаєте заголовок навколо якоря, ви створите великий якір, на нього можна натискати лише текст.
  • Коли ви обмотуєте якір навколо заголовка, весь рядок можна натискати.

Я зробив вам приклад на jsFiddle.net


4

Я вважаю, що у випадку 2 hrefвставка часто не відповідає решті моєї сторінки. Але це міг бути так, як я встановлював свої поля у своєму .css. Таким чином, я віддав би перевагу випадку 1.


1

Сказане тут - це розуміння, дякую всім. Давайте візьмемо це ще на один рівень: додавання мікроданих та подібних до рівняння.

Скажімо, у нас є

<h1 itemprop="name"><a href="http://goldenage.com/maths.html"
itemprop="url">Mathematics in The Muslim Golden Age</a></h1>

змагаючись з

<a href="http://goldenage.com/maths.html" itemprop="url"><h1
itemprop="name">Mathematics in The Muslim Golden Age</h1></a>

Для мене приклад 2 має більше сенсу. Тому що посилання ніколи не є частиною назви. Різниця зводиться до різниці міжHTML та textContent, DOMwise. Дивлячись на нього через innerHTML, якір стає на шляху. Якби текстContent був таким, теги були б позбавлені. Отже, це також ставить питання: innerHTML або textContent.

Тому я б сказав, якщо врахувати мікродані, наявність якоря на зовнішній стороні є більш чистим.

на основі: http://thenewcode.com/617/How-To-Add-Microdata-To-Your-Blog



0

Потрібно уникати посилань на рівні блоків для цілей SEO - з вуст коня: https://www.seroundtable.com/block-level-links-google-seo-16369.html

Оновлення: витяг із посилання ...

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

Джон Мюллер (аналітик тенденцій веб-майстрів в Google) продовжує говорити ...

Це використання було б добре у нас (Google) - ми все одно підберемо посилання і зможемо пов’язати ваш текст як прив’язку до цього. Ми досить гнучкі з розбором HTML, тому ви, ймовірно, можете навіть використовувати це з HTML4. Однак, чим ясніше ви зробите текст прив’язки, тим простіше нам зрозуміти контекст посилання, тому я не обов'язково завжди використовую цілий абзац як прив’язку до всіх ваших внутрішніх посилань.

TL; DR Для SEO не використовуйте блокове посилання.


Маючи надію, що ви оновите свою відповідь, вона частково показує, чому обидва приклади НЕ еквівалентні, як казали інші.
Роб

-1

Якщо метою є додаткові елементи, які можна натиснути всередині посилання (наприклад, зображення тощо) і все-таки підтверджуватись html <5, ви можете мати його обома способами за допомогою JavaScript:

<div onclick="if (this.getElementsByTagName('a')[0]) location=this.getElementsByTagName('a')[0].href;">
<img src="/foo" alt="" />
<h1>
<a href="#">
linked-heading
</a>
</h1>
</div>

інше, просто:

<h1 onclick="if (this.getElementsByTagName('a')[0]) location=this.getElementsByTagName('a')[0].href;">
<a href="#">
linked-heading
</a>
</h1>

додати cursor:pointerдо css батьківського елемента, щоб завершити трюк.


1
Вбудований javascript? Ми ще у 1999 році? ;)
Мартійн

Навіщо ти це навіть робив? Просто загорніть заголовок у якір. Це просто погана практика
Martijn

Уважно прочитайте коментар, ви знайдете свою відповідь, написану саме там;) Html 4.01 насправді вік 1999 року. Коли ви спробуєте перевірити свою пропозицію відповідно до цього дотипу, ви отримаєте таку помилку: "Тип окументації [D] не дозволити елемент "H1" тут (...) Однією з можливих причин цього повідомлення є те, що ви намагалися ввести елемент рівня рівня (наприклад, "<p>" або "<table>") всередині вбудованого елемента ( наприклад "<a>", "<span>" або "<font>"). " Звичайно, абсолютно не потрібно дбати про те, що говорять валідатори, отже, "якщо" на самому початку коментаря.
Лучан Давідеску
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.