Здравейте, скъпи читатели на сайта на блога. Днес искам да засегна темата за създаването на уникати URL адресив Интернет и да говорим за принципите на създаване относителни и абсолютни връзки.

Разбира се, темата за формирането на Urls или тяхната по-разширена версия на URIs (uri) е доста сложна, ако копаете дълбоко и се опитате да стигнете до истината.

Но ние не се нуждаем от това, защото е достатъчно да разберем структурата на URL адреса в неговото приложение.

Е, също мисля, че ще бъде полезно да разберете защо и как можете да създавате относителни връзкиза вашия ресурс, а не да използвате абсолютни за тези цели, когато няма изрична необходимост от това.

URL адреси – какво представляват и как влияят върху индексирането на сайта

Така че, нека видим какво е URL, защо е необходим и от какви части се състои. Както знаете, търсачките не произвеждат като цяло, а като колекция от отделни страници. Тогава те ще бъдат различни заявки за търсене(прочетете повече за избора ключови думив Wordstat въз основа на .

URL и URI

Е, всеки документ (уеб страница) в Интернет има свой собствен уникален URL адрес, което означава Uniform Resource Locator (локатор на ресурси). Той, както и протоколът HTTP, но и как, е разработен и създаден от един и същ човек – Тим Бърнърс-Лий (баща на основателя на проекта).

Като цяло URL адресът е специален случай на друг идентификатор, наречен URI(Uniform Resource Identifier - единен идентификатор на ресурс), но вие и аз, всички тези тънкости най-вероятно няма да са необходими (ненужни) при работа с нашия сайт. Нека се опитаме да разберем най-общо какво представлява и от какви части се състои, след което да преминем към относителни и абсолютни връзки.

URL адресът еначин недвусмислено да посочите нещо в интернет. Използва се не само за работа със сайтове () чрез http протокола (също и чрез ftp), но ние, разбира се, ще се интересуваме от приложението на този идентификатор в мрежата (http и https протоколи). URL адресът в този случай ще изглежда така (малко по-надолу ще дам обща блок-схема на неговата конструкция, но засега бих искал да започна с прост, често срещан пример):

https://.html

В този пример за адрес частта „http“ обозначава протокол за пренос на данни или, ако следвате терминологията на спецификацията, схема (защото същото не е протокол за пренос на данни, за разлика от http или ftp, но също се използва в Url адрес x)..сайт") - или .

WWW и други огледални сайтове, които трябва да бъдат залепени заедно

Мрежата има спецификата да обозначава име на домейн в URL адреса на сайта, който може да бъде със или без WWW. За да имате успех, е много важно да слепите тези две огледала на вашия сайт. Често хостинг доставчикът може да извърши залепването на огледала вместо вас, но това определено трябва да се провери.

Тези. за търсачките сайтовете с WWW или без него са напълно различни и без да ги залепите, масата на връзките ще бъде разделена между тях в неизвестна пропорция. WWW в адреса по своята същност е вид атавизъм, който прави вашия Име на домейндомейн от второ ниво на трето.

Същото важи и при преместване на сайта на защитена https протокол с http- за търсачките ще е друг сайт.

Няма нищо лошо в използването www в URL адреса на сайтане, но трябва ясно да дефинирате основното огледало (през и през, както и чрез писане на вашата директива за сайт), което ще се индексира от търсачките и което ще участва в класирането.

Д. „без атавизъм“ и ако добавите този чудесен префикс към който и да е от моите URL адреси, тогава ще се получи автоматично пренасочване към адреса „без WWW“.

https://www..html

Можете да залепите не само описаните по-горе огледала, но и всякакви други имена на домейни, които принадлежат на вас. Например, ако е възможно различно изписване с латински букви на известна марка, тогава се купуват всички възможни домейни (варианти на изписване с грешки, в различни домейн зонии т.н.) и се слепват. След това, при достъп до сайта на който и да е от възможните URL адреси, ще се отвори главното огледало.

Например на reg.ru можете да видите потенциални огледала или безплатни домейни за регистрация (можете да въведете предложеното име на домейн директно във формуляра по-долу):

Откъде идват допълнителните URL адреси (дублиращи се страници) на вашия сайт в индекса на търсачката

Но да се върнем към нашите овце. Частта от URL адреса, която се намира след третата наклонена черта (/) - в нашия пример е "papka/fail.html" - се нарича път до конкретен обект (документ или файл). В нашия случай това е документът „fail.html“, който се намира в директорията „papka“, която от своя страна се намира в главната папка ( коренът в Url винаги съвпада с третата наклонена чертаналяво).

Но това не е всичко, което може да се напише в адреса. Чрез URL адреса различни предават така наречените GET параметри, които се добавят в самия му край след поставяне на въпросителен знак, например така:

https://www..html?print=yes

Цялата беда е в това търсачкидва такива URL адреса (със и без параметри Get) са напълно различни уеб документи и всеки от тях ще бъде индексиран от търсачките.

Колкото искате различни параметри на Get, можете да добавите към един и същ Url и всичко това ще бъде индексирано от Yandex и Google, ако не създадете подходящите забрани във файла robots.txt, връзката към статията, за която е дадена точно над. В противен случай търсачките могат за много дублирано съдържание(едно и също съдържание, достъпно на различни адреси).

Също така, например, към начална страницамоят ресурс може да бъде достъпен чрез два различни URL адреса:

https://сайт https://site/index.php

(дори три - също https: // сайт /) и във всеки случай ще се отвори главната страница. Това е доста лошо, защото търсачките ще намерят три различни страници(с различни URL адреси от тяхна гледна точка), но с едно и също съдържание, което те, о, не харесват.

Затова направих така, че когато въведете който и да е от URL адресите по-горе, ще се извърши пренасочване към URL във формата „https: // сайт /“. Това се прави, като правило, с помощта на 301 пренасочвания във файла .htaccess, или директно в настройките на сървъра от вас или от вашия хостър.

За повече информация прочетете публикацията, свързана с.

URL структура и прекодиране до URL-кодиран

В общи линии, пълна URL блокова диаграмаможе да се представи така:

В действителност, като правило, те не използват вход, парола и порт, въпреки че може да се наложи да бъдат посочени за достъп до платени сайтове:

http://вход: [имейл защитен]уебсайт/platniy-access.html

Също така е доста обичайно да се инсталира FTP пароли за влизане, където може да използва и нестандартен порт, но различен от стандартния за този протокол. След това, за достъп до ресурсите на такива ftp сървърще трябва да въведете URL като този:

ftp://вход: [имейл защитен]уебсайт:6789/samoe-nujnoe/cimus

За GET параметрите, които могат да бъдат записани в този адрес след въпросителния знак, вече казахме и споменахме, че е необходимо да се забрани индексирането на страници, в URL адресите на които има такива параметри (по-горе е връзка към статия за роботи, където всичко това е описано подробно).

Url адреси под формата на хеш връзки, които отварят страницата на правилното място

Но в допълнение към всички тези неща, които могат да бъдат включени в URL адреса, в горната блок-схема можете да видите т.нар. котва, който се добавя в самия край след разделителния знак "#" (URL адресите, съдържащи котви, обикновено се наричат хеш връзки).

Анкерите са предварително закрепени вътре html коддокумент (страница), като добавите атрибута ID="label" към желания Html таг (параграф, заглавие или друг подходящ) и след това добавите името на тази котва към URL адреса на страницата чрез знака "#", вие може да отиде в началото на тази уеб страница и веднага до мястото, където е поставена котвата (всеки автоматично ще превърти страницата на правилното място).

За и включително за организирането на навигацията на страницата с помощта, прочетете тези статии.

Какви знаци могат да се използват в URL адресите?

Също така си струва да споменем различните кодировки, които се използват в URL адресите. Без прекодиране могат да използватсамо ограничено количествогерои. Обикновено се препоръчва да се ограничите до набор от знаци: ,,,[_],[-].

Като цяло, за да избегнете грешки, бих ви посъветвал да зададете имената на файловете и URL адресите на страниците на вашия сайт с малки букви, тъй като за Unix-подобни системи (на които работят повечето уеб сървъри), знаците с главни и малки букви са различни (за разлика от Windows). Поради различните регистри може да възникне ненужно объркване.

Използването на всякакви други знаци (включително руски) в URL адресите е разрешено, но ще бъде прекодиранесъщите тези знаци (URL Encoding).

Това, което е тъжно, е несмилаемият вид на URL адреси със символи, например кирилица, които се получават след прекодиране. Всеки знак на кирилица е кодиран с помощта на два байта в , записани в шестнадесетичен знак и разделени със знак за процент "%". Например този URL адрес:

https://website/кой е нов/

след преобразуването ще изглежда така:

Http//site/%BA%D1%82%D0%BE%20%D0%BD%D0% B0%20%D0%BD%D0%BE%D0%B2%D0%B5%D0%BD%D1% 8C%D0%BA%D0 %BE%D0%B3%D0%BE

Като цяло се оказва, че не е много готино и планират да се справят с този несмилаем тип URL в националните кодировки, но това нещо не се движи толкова горещо.

Във връзка с всичко по-горе, бих посъветвал, когато на моя CMS не правете адреси на страници на руски, и особено след като според много промоутъри ще бъде по-добре по отношение на Seo оптимизацията за Yandex и Google.ru.

Относителни и абсолютни връзки в сайта

Да започнем с абсолютни връзки, защото в този случай няма да трябва да се казва нищо специално, освен това, което вече обсъдихме в тази статия. Че. абсолютната връзка трябва да отговаря на изискванията, които налагаме на URL адреса - протокола за трансфер на данни, името на домейна на сайта (хост) и пътя до желаната мрежадокумент. Всичко.

В Html абсолютна връзка се формира с помощта на специални A тагове (хипервръзки), т.е. за да го поставим, просто ще трябва да оградим желаното място в текста на документа (фраза или картина) с отварящия и затварящия тагове за хипервръзка и да напишем в отварящия таг A в атрибута „Href“ абсолютния път до документ, до който посетителят ще трябва да стигне, когато щракне върху него:

PHPMyAdmin

Всичко е много просто.

Предимства на относителните връзки и как можете да ги получите

Въпреки това, абсолютните хипервръзки обикновено се използват само когато искат да направят връзка към външни сайтове, а за вътрешни преходи повечето уебмастъри (умни и проницателни, не като мен 🙂) се опитват да използват относителни връзки. И има няколко причини за това:

1. Относителните връзки по дефиниция са по-кратки и не претрупват кода на сайта (в края на краищата всяко малко нещо е важно по този въпрос).
2. Освен това, когато се преместите в друг домейн или промените протокола на https, няма да се налага да променяте всички връзки на сайта.
3. В допълнение, някои дизайни на интернет проекти могат бързо и безболезнено да бъдат прехвърлени на друг ресурс, без да се променят вътрешните относителни връзки.

Така че, съдейки по името, адресът на уеб документа, към който те препращат, трябва да бъде написан спрямо документа на вашия сайт, от кода на който ще бъде поставена тази относителна връзка (танц от печката). Вторият вариант за настройването им е да използвате основната папка като отправна точка. Това са точно два начина за създаванеотносителни връзки, които сега ще разгледаме.

Създайте относителни връзки спрямо документа, от който са прикрепени

Най-простият и най-кратък начин за запис на относителен път (което означава стойността на атрибута Href на тага за хипервръзка) ще бъде получен, когато и двата уеб документа: донор (от който е прикрепен) и акцептор (файлът или уеб документът към които води) се намират в същата папка на сървъра.

котва

Сега нека приемем, че акцепторският документ е в папка, която се намира в същата директория като донорския документ.

Как би изглеждала относителната връзка в този случай? Всичко също е доста просто:

котва

Засега мисля, че всичко е ясно - предписваме пътя до файла или документа на акцептора (името на папката и чрез наклонената черта "/" името на файла или документа). Тези. за да стигнем от донора до акцептора, ще трябва да отворим папката, чието име посочваме в относителната връзка.

Сега нека разгледаме обратната ситуация, когато самият донорски документ се намира в папката, от която трябва да поставите относителна връзка към документа или файла на акцептора, който вече е едно ниво по-високо:

За да преминем от донорския документ към акцепторския файл (или документ), имаме нужда преминете ниво нагоре от тази папка. За това е предвиден специален елемент - две точки подред, а след това чрез наклонена черта се записва по-нататъшният път до акцептора. Така че за горния пример относителният път ще бъде:

Какво е URL

Ако трябва да преминете две нива нагоре, тогава записът ще изглежда така:

Какво е Url

Е, ако след това, за да зададете относителен път към акцептора, ще трябва да въведете и папка на второто горно (спрямо донорския документ) ниво:

Сложен дизайн на коловоза

Може да има колкото се може повече такива спускания до папки и изкачвания до ниво нагоре, най-важното е вие ​​самите да не се объркате.

Създайте връзка спрямо основната папка

Написахме всички връзки, обсъдени по-горе по отношение на дарителския документ, от който е поставена хипервръзката, но можете вземете главната папка като отправна точкасайт. Коренът в относителните пътища изглежда като единична наклонена черта "/".

Че. преходът към главната страница ще изглежда доста прост, но екстравагантен:

котва

Например, абсолютенпътят може да изглежда така:

котва

НО роднинакъм същия файл ще бъде малко по-кратък:

Текст

Как да се обърнете към папка в относителна и абсолютна форма

Искам да насоча вниманието ви към един нюанс, който трябва да се вземе предвид при създаването както на абсолютни, така и на относителни връзки. Ако искаш обърнете се към папката, тогава не забравяйте да поставите наклонена черта "/" в края на такава хипервръзка (след нейното име). Тоест, ако искам да отворя съдържанието на папка, тогава трябва да напиша:

котва

Не така:

текст

Във втория случай, по време на обработка, сървърът първо ще се опита да намери файл с име "uploads" (точно това без никакви разширения) и като не го намери, след това ще търси такава папка. Затова пишете веднага наклонена черта след името на папката, която искате, няма да вземете допълнителни ресурси от вашия сървър в търсене на това, което го няма.

Трябва също да сте наясно с това при контактв относителна или абсолютна препратка папка, ще се покаже уеб сървъръттака нареченият индексен файл, който се намира в него и който по правило се нарича или index.html, или index.php. Ако в папката няма индексен файл, тогава ако защитата е неправилно конфигурирана на сървъра, ще видите списък с неговото съдържание, което може да доведе до намаляване на сигурността на вашия ресурс.

Определено, ако го намерите.

Между другото, достъпът до главната страница на сайта също е по същество достъп до папката (root), като в същото време ще се стартира индексният файл, който се намира в root (в моя случай това е index.php ). Така че, ако имате достъп до папка, тогава за намаляване на натоварването на сървърапо-добре е да напишете наклонена черта след името на домейна:

Ето го, Михалич!

Късмет! Ще се видим скоро на сайта на страниците на блога

Може да се интересувате

ASCII кодиране на текст (Windows 1251, CP866, KOI8-R) и Unicode (UTF 8, 16, 32) - как да коригирате проблема с krakozyabry
Как увеличих трафика на уебсайта до 300 души на ден?
Yandex търсене в сайта и онлайн магазина
Sitemap на Sitemap xml форматза Yandex и Google - как да създадете карта на сайта в Joomla и WordPress или в онлайн генератор

всичко HTML връзкиразделени на външни и вътрешни. Външните връзки са връзки, които водят от един сайт към друг сайт или файл, разположен на друг сайт. Вътрешни връзки- това са връзки, които препращат от една страница на сайта към друга страница от същия сайт или към раздели на същата страница.

всичко външни връзкив атрибута href на етикета съдържат абсолютния път до документа, за който се отнасят. Вътрешните връзки от своя страна могат да съдържат както абсолютен път, така и относителен (в този случай зависи от вашите лични предпочитания).

Като граматическите правила в различни езици, в програмирането също има правила. Валидирането ви позволява да видите дали страницата отговаря на тези правила и ако има грешки и предупреждения, ще бъдат предоставени препоръки за отстраняването им. Повече подробности за необходимостта от такава проверка ще бъдат разгледани по-долу.

Какво влияе върху валидността на сайта

Чудили ли сте се някога как браузърите "четат" уеб страница? Те имат "двигатели", за да анализират кода и да го конвертират във визуална форма за хората. За съжаление всеки браузър има свой собствен механизъм за обработка на код и това може да доведе до различно показване на страниците ви.

Невалидна уеб страница може да бъде прочетена от браузърите по различни начини. Това ще доведе до възможност посетителите ви дори да не могат да видят правилно съдържанието на страницата в своите браузъри. Валидирането по-късно ще коригира почти всички основни разлики и ще направи вашата уеб страница четима от почти всички уеб браузъри (най-често изключение е Internet Explorerпо-стари версии). Това е мястото, където идва терминът „оформление между браузъри“. оформление, което е еднакво добро (съвместимо) за всички популярни браузъри.

Как това ще се отрази на SEO? Важно е да разберете, че ботовете на търсачките обичат семантичните уеб страници. Семантичното оформление, според Wikipedia, е подход за създаване на уеб страници на HTML език, базиран на използвайки HTMLтагове според тяхната семантика (предназначение). В допълнение, структурната семантична уеб страница позволява на роботите за търсене да определят по-точно значението както на отделните елементи на уеб страницата, така и на целия текст като цяло. Според Google валидният код не влияе по никакъв начин на класирането на страницата. Но в същото време наличието на грешки в кода може да повлияе негативно на сканирането на микроданните и адаптивността към мобилни устройства.

Инструменти за проверка на вашия сайт

Разбирайки необходимостта от липса на грешки при проверка на страниците на сайта, нека да разгледаме как да търсим тези грешки.

Има много безплатни услугиза валидиране на сайтове, като W3C Markup Validation Service, Web Page Analyzer, Browsershots и други.

Доцент доктор. Lavlinsky N.E., технически директор на Method Lab LLC

Наскоро публикувано нов стандартза предварително зареждане на технологията (връзка). Основната цел на тази спецификация беше да позволи прецизен контрол върху логиката на зареждане на ресурса на страницата от разработчика.

Предишни стандарти

Идеята за управление на натоварването не е нова. Преди това бяха разработени няколко опции за тагове връзкас атрибути подресурс, предварително изобразяванеи предварително извличане. Те обаче работят малко по-различно: с тяхна помощ можете да изтегляте елементи от страницата или цели страници, които може да са необходими при по-нататъшно навигиране в сайта. Тоест браузърът изпрати такива заявки с нисък приоритет и последни. Ако трябва да увеличите приоритета, тогава нямаше решения.

Зареждане на ресурси с предварително зареждане

Каква е новата спецификация? Първо, сега зареждането става със спецификация на това, което се зарежда. Въз основа на посочения тип ресурс, браузърът задава приоритета на изтегляне. Например:

Второ, типът ресурс ( като) позволява на браузъра да изпрати правилните заглавки, така че сървърът да може да изпрати съдържанието с най-добрата опция за компресиране (например изпращане на WebP изображения, ако браузърът ги поддържа).

Във втория пример зареждаме файл с шрифт, който посочва конкретен формат (WOFF2), който не се поддържа от всички браузъри. Въпреки това, докато поддръжката за механизма за предварително зареждане е същата като поддръжката за този формат, няма проблеми. Текущата поддръжка на механизма може да се види.

По-бързо зареждане на шрифта

Пример за ускоряване на сайт чрез предварително зареждане е зареждането на дълбоко заровени ресурси, като например шрифтове. В нормалния процес на изтегляне браузърът първо трябва да изтегли CSS файла, сочещ към шрифта, да анализира файла и едва след това да постави на опашка заявката за изтегляне на файла с шрифта.

Ако предварително заредим този шрифт в кода на HTML страницата, браузърът ще изпрати заявката веднага след анализиране на HTML документа, което може да е няколко секунди по-рано, отколкото в нормалния случай. И ние знаем, че pluggable шрифтове блокират елементи и забавят изобразяването на шрифта на страницата, така че те трябва да бъдат заредени възможно най-бързо. Този проблем е особено остър при използване на HTTP / 2, когато браузърът изпраща много заявки към сървъра наведнъж, в резултат на което някои снимки могат да запълнят честотната лента на клиента и зареждането на важни ресурси ще се забави.

Асинхронно зареждане на CSS

CSS файловете винаги блокират изобразяването на страницата, така че всички CSS ресурси, които могат да бъдат отложени, могат да бъдат заредени като нормални файлове и динамично свързани към страницата.

Това се прави по следния начин:

Зареждане на JS код без изпълнение

Може също да е полезно да заредите предварително кода на скрипта в JS, за да го изпълните по-късно.

Това може да стане със следния код:

Разгледахме основните начини за използване на механизма за предварително зареждане, но възможностите не се ограничават до това, направете свои собствени експерименти!

По правило много уебмастъри качват своите сайтове на хоста веднага след създаването им. В същото време те се фокусират най-вече върху коректността на смисъла на текстовото съдържание, отколкото върху коректността на вътрешния код на страниците.

Валидиране на сайта

Но има и други фактори, които могат и оказват влияние върху позицията на сайта. И те включват, наред с други неща, технически фактори. Е, валидирането на сайта също спада към техническите. И така, какво е това?

Ако с прости думи, тогава валидирането на сайта е проверка на кода на сайта за техническо съответствие и грешки. Е, например, забравихте да използвате затварящия таг - /html. В най-новия HTML5 визуално нищо няма да се промени. Това обаче е грешка в кода.

При писане на код са възможни и други грешки. И отново, модерен езикхипер маркирането ще издържи много. Например „забравяне“ на затварящия таг /head. Отново, няма да видите разликата. Но тя е))

Всъщност, когато пишете уебсайт, може да има доста грешки. И още по-лошо, някои от тези грешки може да се показват и визуално. Е, може би блоковете ще плават, може би подравняване или може би нещо друго. Потенциални грешки, хиляди. И не всички са фрапантни.

Каква е опасността?

Е, изглежда, добре, какво лошо има в това? Да, трябва да се каже, че често такива грешки не се виждат. Или по-скоро невидим за хората. Но страниците на нашия сайт могат да бъдат посещавани не само от хора, но и от паяци за търсене, които напълно сканират сайта. И всяка грешка, която открият на сайта, те предават на сървърите на търсачките като Yandex или Google.

И търсачките, от своя страна, виждайки, че има много грешки в кода на сайта, може да заключат, че сайтът е лош. И това означава, че няма да го вдигнат в търсенето. Е, това вече ще означава, че сбогом посетители от търсенето.

Да, трябва да се признае, че известно песимизиране на сайта поради грешки при валидиране е доста рядко. Но това е напълно възможно, което означава, че трябва да се работи върху валидирането. И какво трябва да се направи за това? Разбира се, първата стъпка е да откриете грешките.

Но тъй като ръчно това е много времеемък и ненадежден бизнес, тогава за търсене на грешки те използват специални услуги, така наречените „Валидатори“.

Услуга за валидиране на маркиране на валидатора.

Тази услуга проверява коректността на HTML и XHTML кодовете, които са в основата на повечето страници при създаването на почти всеки сайт и определят вътрешната му структура. Тази услуга за валидиране може да бъде достъпна, като следвате връзката http://validator.w3.org

Но тук има задължително условие, което важи и за други валидатори: проверяваният сайт или неговите проверени страници трябва да бъдат качени на хостинга. В противен случай валидаторът няма да "познае" адреса на сайта и няма да може да провери нищо. Сега вече можете да обмислите как да работите с този валидатор.

След като влезете в страницата на тази услуга, ще се покаже цялата й функционална картина. Но повечето от изобразеното и написано не се отнася за основната проверка и цялото ви внимание трябва да се обърне само на прозореца за въвеждане на адреса на проверяваната страница:

Точно оттам трябва да започнете.

Всъщност проверката на валидността на сайт е изключително проста, като целия ни смъртен свят: в адресния прозорец на услугата трябва да напишете адреса на сайта, т.е. неговия URL адрес и след това щракнете върху „Проверка“. След такова просто действие валидаторът ще „пухне“ за няколко секунди и ще издаде следното:

Това означава, че няма грешки в кода на страницата и можете да сте абсолютно спокойни.

Но може да има и такава нежелана опция:

Това вече е по-лошо и означава, че има някои грешки във вътрешния код на страницата, която се проверява. Това обаче изобщо не е фатално: просто трябва да превъртите страницата по-долу и всички грешки, открити по време на процеса на проверка, ще бъдат написани подробно там.

В допълнение, валидаторът не само ще изведе откритите грешки, но и ще покаже точно на кой ред от вътрешния код се намират тези грешки. Така че няма да се налага да ги търсите дълго време. Тук, без да преувеличаваме нищо, можем твърдо да кажем, че този валидор работи перфектно.

Но това не е всичко: валидаторът не само показва местоположението на откритата грешка в кода, но също така дава доста пълни препоръки как да се отстранят тези грешки. Разбира се, за това не е нужно да сте мързеливи и внимателно да прочетете всичко написано.

Като кратко и обобщено заключение можем да кажем следното:

1. тази услуга за валидиране работи чудесно и може да провери сайта много бързо.
2. Е, малко, но много приятно допълнение: валидирането на сайта е безплатно.
3. Сега можем да преминем към следващата стъпка: това е проверка на CSS кода.

Услуга за валидиране на CSS

Като цяло това е втората функция на горната услуга, но тя е „заточена“ не за проверка на HTML и XHTML код, а специално за проверка на коректността на кода css стилразположен на външната маса. А за да стигнете до страницата на услугата, трябва да следвате връзката http://jigsaw.w3.org/css-validator.

Между другото, тук си струва да отбележим нещо приятно: проверката на тази услуга е абсолютно безплатна. Така че не вадете пари от портфейла си - оставете ги да лежат до подходящия момент. Нека обаче да преминем към методологията на работа по тази втора услуга.

Като цяло цялата работа по валидатора на CSS е абсолютно идентична с проверката за чистота на кода. Следователно не е необходимо да предоставяте отделно изображение на адресната лента на валидатора. Малко по-надолу ще разгледаме накратко реда на самата проверка и това е всичко.

За това трябва да адресна лентанапишете URL CSS таблици, например "http://my site/style.css" и след това натиснете бутона с руски надпис "Проверка". Съответно, този валидатор също ще „пухне“ за няколко секунди и ще даде желания резултат:

Това означава, че CSS таблицата е написана правилно и в нея не са открити грешки.

И тук има и приятна изненада: ако превъртите страницата малко по-надолу, там ще бъде написан оптимизираният код за вашата CSS таблица, от който ще бъдат премахнати всички ненужни надписи и всички кодови тагове ще бъдат подредени в последователност който отговаря на оптималните работни изисквания на всички търсачки. Всичко, което остава, е да копирате този перфектен примерен код и да го поставите в CSS таблицата.

Напълно възможно е да се случи нещо подобно:

Това означава, че са открити някои грешки в CSS кода, но изобщо не трябва да се страхувате от това. Точно под тази червена линия, валидаторът ще ви каже точно кой етикет е неправилно изписан. Остава само да намерите тези тагове в листа със стилове и да направите необходимите корекции.

И разбира се, след това качете коригирания лист със стилове на хоста и, ако има зелена линия, можете щастливо да копирате стиловия код на оптимизираната CSS таблица. Съвсем ясно е, че тогава е най-добре да се промени стар кодкъм нов и оптимизиран.

Кратко обобщение.

Двете най-основни и задължителни проверки за валидиране на уебсайтове бяха обсъдени по-горе. Без тези проверки не трябва дори да отваряте индексиране за търсачки в robots.txt В противен случай сайтът може да бъде игнориран за индексиране търсачкии ще се считат за дефектни с подходящи санкции.

За да не се случи това, трябва да отделите само няколко минути, за да сте абсолютно спокойни и напълно уверени в техническото състояние на вашия сайт и всички негови страници. Разбира се, необходимо е да се направят и допълнителни проверки на връзките и анкорите, видимостта на сайта мобилни устройстваи параметри на други кодове. Само тогава сайтът може да се счита за готов за пълноценното си функциониране и за успешна и бърза промоцияв ТОП.

Бих искал да кажа предварително, че всички други проверки са толкова бързи и прости, колкото и тези, обсъдени по-горе - просто трябва внимателно да прочетете процедурата за работа с валидатора.

Добавен на 19.04.2018

Често срещани грешки във валидността при валидиране на HTML код

Реших да актуализирам статията. HTML грешкикодове, които често се срещат в сайтовете. Във всеки случай имах много от тях)). Валидаторът подчертава грешките в жълто.

1) Грешка: Препратката към символ не е завършена с точка и запетая.

Грешка: символът не е прекъснат от точка и запетая - съответно трябва да се добави.

2) Предупреждение: Разделът няма заглавие. Обмислете използването на елементи h2-h6, за да добавите идентифициращи заглавия към всички секции.

Предупреждение: Този раздел няма заглавие. Обмислете използването на елементи h2-h6, за да добавите идентифициращи заглавия към всички секции. Тук всичко е ясно, трябва да добавите поне един субтитър. Това дори не е грешка, а препоръка.

3) Грешка: Елементът noindex не е разрешен като дете на елемент p в този контекст.

Грешка: noindex елемент не е разрешен като дъщерен елемент p елемент в този контекст. (Потискане на допълнителни грешки от това поддърво.)
Решението е просто, трябва да коментирате етикета noindex, изгледът ще изглежда така:

4) Грешка: Централният елемент е остарял.

Грешка: тагът "center" е остарял - трябва да бъде заменен, ако говорим за img, тогава можете да използвате атрибута align. Ако нещо друго е центрирано, заменете го с div.

5) Елемент img трябва да има атрибут alt, освен при определени

Грешка: Елементът img трябва да има атрибут alt - тук всичко е ясно, трябва да добавите атрибут alt, дори и да е празен, грешката ще изчезне.

6) Атрибутът width на елемента td е остарял. Вместо това използвайте CSS.

Грешка: Атрибутът „width“ на елемент „td“ е отхвърлен

7) Атрибутът type не е необходим за ресурси на javascript

Грешка: Атрибутът type не е необходим за ресурси на javascript. Решението е просто да премахнете всичко ненужно и да оставите само етикета „script“.

8) Атрибутът align на елемента img е остарял.

Грешка: Атрибутът align на елемента img е отхвърлен. Направете divs за подравняване на изображението.