Kolejność metatagów HTML


16

Firma SEO proponował, żeby zmienić kolejność naszych HTML znaczniki meta, tak aby <title>i <meta name="description">są dwa pierwsze. Mówią, że ma to zapewnić wyszukiwarkom wykorzystanie tych dwóch tagów. Odniosłem wrażenie, że kolejność znaczników w głowie dokumentu nie jest znacząca. Czy się myliłem? Są tam naprawdę silniki, które zakładają, że pierwsze dwa znaczniki są zawsze szukać titlei descriptioni zrezygnować patrząc na nich, jeśli nie są one?


Odpowiedzi:


15

Masz rację. Kolejność tych tagów nie ma znaczenia dla SEO. Muszą tylko być obecni. Ktokolwiek powiedział, że jest to oczywiście brak pojęcia (i oczywiście prowadzenie firmy SEO. Westchnienie).


Czy możesz podać źródło lub studium przypadku?
s_hewitt

3
Tylko opinia oparta na doświadczeniu. Oto dyskusja SearchEngineWatch na ten temat - kolejność nie ma znaczenia: forums.searchenginewatch.com/showthread.php?t=16452
Ciaran

7

Chociaż dla celów SEO może być prawdą, że kolejność nie jest znacząca, nie jest to prawdą, gdy rozważa się inne rzeczy, takie jak bezpieczeństwo, wyświetlanie treści (znaków) lub szybkość ładowania. Dobrym pomysłem jest zgrubne uporządkowanie głowy strony (przy założeniu HTML5 pod względem składni):

<head>

Do tej pory w dokumencie nie powinieneś używać żadnych znaków spoza ASCII, więc kodowanie znaków nie jest jeszcze problemem. Ale prawdopodobieństwo użycia znaków spoza ASCII znacznie wzrasta po otwarciu tego tagu head. Odpowiednio (i zakładając, że nie deklarujesz kodowania znaków programowo lub na poziomie serwera), powinieneś uczynić następną instrukcję deklaracją kodowania znaków. Spełnia to również parsery / przeglądarki / agenty, które wąchałyby instrukcje kodowania znaków:

  <meta charset="utf-8">

Następujące dwa ( X-UA-Compatiblei viewport) są zalecane przez ludzi z Bootstrap (ostatnio w wersji 3.3.4). Chociaż jestem prawie pewien, że te zalecenia są oparte na wydajności, większość tego, co powiedziałbym, byłoby spekulacyjne:

  <meta http-equiv="X-UA-Compatible" content="IE=edge">

Jeśli zastanawiasz się nad projektowaniem / opracowywaniem zależnym od urządzenia (w tym mniejszych, niebędących komputerami klienckimi), powinieneś uwzględnić następujące elementy:

  <meta name="viewport" content="width=device-width, initial-scale=1">

Wreszcie tytuł:

  <title>Ingenious Page Title</title>

Następnie oferujesz CSS jak najszybciej po tytule (bez „światła dziennego” między nimi):

  <link rel="stylesheet" href="stylesheet-1.css">
  <link rel="stylesheet" href="stylesheet-2.css">

Jeśli używasz stylów na poziomie strony, przejdą one tutaj. Wynika to głównie z „kaskadowej” natury CSS: mianowicie ostatniej deklaracji stylu o identycznych poziomach specyficzności (takiej jak dwie instrukcje skierowane na akapit p). Aby ułatwić zastępowanie stylów zewnętrznych (tj. Bez stosowania większej specyficzności lub !important), należy umieszczać style na poziomie strony po stylach zewnętrznych <link>. Ponadto generalnie nie jest wskazane stosowanie dyrektywy @import w stylach na poziomie strony, ponieważ utrudni to jednoczesne pobieranie innych zasobów stylu:

  <style>body{color:black;}</style>

W tym miejscu najbardziej odpowiednie wydaje się umieszczanie metatagów, ulubionych i innych cruft. Można argumentować, że ulubione lub podobne zasoby (np. Obrazy aplikacji na iOS) byłyby ładowane przed większością metatagów, ponieważ pobieranie tych zasobów zaczyna się nieznacznie szybciej.

  <link rel="shortcut icon" href="favicon.ico">
  <link rel="apple-touch-icon" href="apple-icon.png">
  <meta name="description" content="Some information that is descriptive of the content">
  <meta name="generator" content="Microsoft FrontPage 2002">

Ponieważ blokuje / opóźnia renderowanie, jeśli zamierzasz wymagać skryptów, ładuj je tak późno, jak to możliwe. Jeśli muszą znajdować się w head, możesz je załadować przed zamknięciem head( </head>). Jeśli możesz je później załadować, umieść je przed zamknięciem bodytagu ( </body>).

  <script src="script-1.js"></script>
  <script src="script-2.js"></script>
</head>

W większości przypadków wydaje się nieważne zwracanie dużej uwagi na kolejność metatagów do celów SEO, biorąc pod uwagę, że roboty indeksujące (tj. Pająki wyszukiwarek) zajmą całą stronę. W przeciwnym razie, jak zaindeksowaliby treść strony lub zaktualizowali ten indeks później?

Godne uwagi jest to, że pomimo tego, co uważamy za znane, i wszystkich rekomendacji, które znajdujemy w Internecie (nawet z takich miejsc jak Google i Bing Webmaster Tools itp.), Witryn takich jak Amazon, Google i innych ludzi, którym wyraźnie zależy o takich niewielkich przyrostach wydajności nie przestrzegaj tych zasad.


Chociaż X-UA-Compatible, viewporta jabłko dotykowe ikony były nadal (stosunkowo) nowy w 2010 roku, wszystkie były w użyciu. HTML5 wpływał tylko na długość deklaracji zestawu znaków. Problemem było wówczas CSS, JS i potokowanie obrazu, a także (ponowne) renderowanie stron po zastosowaniu CSS i JS. Mimo to nie mogłem znaleźć tej informacji w jednym miejscu (poza heads dokumentów html), a po natknięciu się na to pytanie, dobrze było to zrobić tutaj.
David Eldridge

Dobra odpowiedź @DavidEldridge. Ale czy mógłbyś zaktualizować swoją odpowiedź, aby zawierała application/ld+jsonskrypty dla danych strukturalnych? Do celów prędkości. Gdzie najlepiej to położyć? Czy powinniśmy traktować to jako JavaScriptpliki zewnętrzne ?
Brendan Vogt,

2

Z funkcjonalnego punktu widzenia następująca pozycja z Bootstrap wydaje się być lepszą kolejnością metatagów:

    1) <meta charset="utf-8">
    2) <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
    3) <title></title>
    4) <meta name="description" content="">
    5) <meta name="viewport" content="width=device-width, initial-scale=1">

Według pracowników Google liczy się SEO

  1. być przyjaznym dla urządzeń mobilnych
  2. tytuł i opis
  3. unikalna i wartościowa treść

Jeśli Twoja witryna nie jest dostosowana do urządzeń przenośnych, nie patrzą nawet na 2) lub 3). Jeśli jest przyjazny dla urządzeń mobilnych, może użyć tytułu i opisu, umieszczając listę Twojej witryny. Nie ma na to żadnych gwarancji. Mogą zdecydować się na opracowanie własnego opisu na podstawie tego, co znajdą w Twojej witrynie.

Jeśli Twoje treści są plagiatowe lub powtarzalne i jeśli spróbujesz zapełnić je słowami kluczowymi lub użyjesz innych technik „BlackHat”, te rzeczy cię skrzywdzą i prawdopodobnie zablokują.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.