Sziasztok, a blogoldal kedves olvasói. Ma az egyedi alkotás témáját szeretném érinteni URL-ek az interneten, és beszéljünk az alkotás alapelveiről relatív és abszolút kapcsolatokat.

Természetesen az URL-ek létrehozásának témája vagy az URI-k (uri) kiterjesztett változata meglehetősen bonyolult, ha mélyre ásunk és megpróbálunk eljutni az igazsághoz.

De erre nincs szükségünk, mert elég megérteni az URL szerkezetét az alkalmazásában.

Nos, azt hiszem, hasznos lesz megérteni, miért és hogyan lehet létrehozni relatív linkek erőforrása számára, és ne használjon abszolút értékeket ezekre a célokra, ha erre nincs kifejezett szükség.

URL-címek – mik ezek, és hogyan befolyásolják a webhelyindexelést

Lássuk tehát, mi az URL, miért van rá szükség, és milyen részekből áll. Mint ismeretes, a keresőmotorok nem egy egészként, hanem egyes oldalak gyűjteményében készítenek. Akkor mások lesznek keresési lekérdezések(további információ a választásról kulcsszavakat alapján a Wordstatban.

URL és URI

Nos, bármilyen dokumentum (weboldal) az interneten saját egyedi URL-lel rendelkezik, ami az Uniform Resource Locator (erőforrás-kereső) rövidítése. Őt, valamint a HTTP protokollt, de azt is, hogyan, ugyanaz a személy fejlesztette ki és hozta létre - Tim Berners-Lee (a projekt alapítójának apja).

Általában véve az URL egy másik azonosító speciális esete URI(Uniform Resource Identifier - egységes erőforrás-azonosító), de Ön és én mindezekre a finomságokra valószínűleg nem lesz szükség (felesleges), amikor webhelyünkön dolgozik. Próbáljuk meg általánosságban megérteni, mi ez és milyen részekből áll, majd térjünk át a relatív és abszolút hivatkozásokra.

Az URL cím az egy módja annak, hogy egyértelműen rámutasson valamire az interneten. Nemcsak a webhelyekkel () való munkavégzésre szolgál a http protokollon keresztül (ftp-n keresztül is), de természetesen érdekelni fogunk ennek az azonosítónak a weben való alkalmazása iránt (http és https protokollok). Az URL ebben az esetben valahogy így fog kinézni (alább egy általános folyamatábrát adok a felépítéséről, de most egy egyszerű gyakori példával kezdeném):

https://.html

Ebben a címpéldában a „http” jelű rész egy adatátviteli protokollt jelöl, vagy ha követjük a specifikáció terminológiáját, akkor egy sémát (mert ez nem adatátviteli protokoll, ellentétben a http-vel vagy az ftp-vel, hanem használt URL cím x)..site") - vagy .

WWW és egyéb oldaltükrök, amelyeket össze kell ragasztani

A web sajátosságaival rendelkezik egy domain név kijelölésére a webhely URL-jében, amely lehet WWW-vel vagy anélkül. A siker érdekében nagyon fontos, hogy ezt a két tükröt ragasszuk fel webhelyünkre. A tükrök ragasztását gyakran a tárhelyszolgáltató végezheti el helyetted, de ezt mindenképpen ellenőrizni kell.

Azok. keresőknél teljesen mások a WWW-vel vagy a nélkül lévő oldalak és ezek ragasztása nélkül a linktömeg ismeretlen arányban oszlik meg közöttük. A címben szereplő WWW eredendően egyfajta atavizmus, amely az Ön Domain név a harmadik második szintű tartománya.

Ugyanez vonatkozik a webhely biztonságos helyre történő áthelyezésére is https protokoll http-vel- a keresőmotorok számára ez egy másik webhely lesz.

Nincs semmi baj a használattal www a webhely url-jében nem, de világosan meg kell határoznia a fő tükröt (átmenőleg, valamint a webhely irányelvének megírásával), amelyet a keresőmotorok indexelnek, és amely részt vesz a rangsorolásban.

E. „atavizmus nélkül”, és ha bármelyik URL-emhez hozzáadja ezt a csodálatos előtagot, akkor automatikus átirányítás történik a „WWW nélküli” címre.

https://www..html

Nemcsak a fent leírt tükröket ragaszthatja, hanem bármilyen más domain nevet is, amely hozzá tartozik. Például, ha egy jól ismert márka latin betűivel különböző írásmódok lehetségesek, akkor az összes lehetséges domain megvásárlásra kerül (hibás helyesírási változatok, különböző domain zónák stb.) és ragaszkodjanak egymáshoz. Ezután, amikor bármelyik lehetséges URL-címen eléri a webhelyet, megnyílik a fő tükör.

Például a reg.ru oldalon megtekintheti a lehetséges tükröket vagy ingyenes domaineket a regisztrációhoz (a javasolt domain nevet közvetlenül megadhatja az alábbi űrlapon):

Honnan származnak webhelyének további URL-jei (ismétlődő oldalai) a keresőmotor indexében

De térjünk vissza a mi juhainkhoz. Az URL-nek azt a részét, amely a harmadik perjel (/) után található - példánkban "papka/fail.html" - egy adott objektum (dokumentum vagy fájl) elérési útjának nevezzük. Esetünkben ez a „fail.html” dokumentum, amely a „papka” könyvtárban található, ami viszont a gyökérmappában ( az URL-ben lévő gyökér mindig megegyezik a harmadik perjellel bal).

De ez nem minden, amit a címbe lehet írni. Az URL-en keresztül különbözőek átadják az úgynevezett GET paramétereket, amelyek egy kérdőjel elhelyezése után a legvégére kerülnek, például így:

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

Az egész baj az kereső motorok két ilyen URL (Get paraméterekkel és anélkül) teljesen különböző webdokumentum, és mindegyiket indexelni fogják a keresők.

Ugyanahhoz az URL-hez tetszőleges számú Get paramétert lehet hozzáadni, és mindezt a Yandex és a Google indexeli, ha nem hozza létre a megfelelő tiltásokat a robots.txt fájlban, amelyről a cikk linkje található. csak fent. Ellenkező esetben a keresőmotorok sok ismétlődő tartalomhoz(ugyanaz a tartalom különböző címeken érhető el).

Azt is például, hogy kezdőlap az erőforrásom két különböző URL-en érhető el:

https://site https://site/index.php

(akár három - szintén https: // site /), és minden esetben megnyílik a főoldal. Ez elég rossz, mert a keresők hármat találnak különböző oldalak(szempontjukból eltérő URL-ekkel), de ugyanazzal a tartalommal, ami nekik, ó, nem tetszik.

Ezért úgy hoztam létre, hogy a fenti URL-ek bármelyikének megadásakor a rendszer egy „https: // site /” formátumú URL-re irányít át. Ez általában 301-es átirányítással történik a .htaccess fájlban, akár közvetlenül a kiszolgáló beállításaiban, akár Ön, akár a tárhelyszolgáltató.

További információért olvassa el a linkelt bejegyzést.

URL szerkezete és átkódolása URL-kódolásúvá

Általában, teljes URL blokkdiagramígy ábrázolható:

A valóságban általában nem használnak bejelentkezést, jelszót és portot, bár előfordulhat, hogy ezeket meg kell adni a fizetős oldalak eléréséhez:

http://bejelentkezés: [e-mail védett] website/platniy-access.html

A telepítés is meglehetősen gyakori FTP bejelentkezési jelszavak, ahol nem szabványos portot is használhat, de eltér az ehhez a protokollhoz tartozó alapértelmezett porttól. Aztán, hogy hozzáférjen az ilyen forrásokhoz ftp szerver ehhez hasonló URL-t kell megadnia:

ftp://bejelentkezés: [e-mail védett] weboldal:6789/samoe-nujnoe/cimus

Az ezen a címen a kérdőjel után írható GET paraméterekről már szóltunk és említettük, hogy meg kell tiltani az olyan oldalak indexelését, amelyek URL-jében vannak ilyen paraméterek (fent egy cikk linkje robotok, ahol mindezt részletesen leírják).

URL címek hash linkek formájában, amelyek a megfelelő helyen nyitják meg az oldalt

De mindezen, az URL-be foglalható dolgokon kívül a fenti folyamatábrán látható az ún. horgony, amely a legvégére kerül a határoló "#" font jel után (a horgonyokat tartalmazó URL-eket általában ún. hash linkek).

A horgonyok belül előre rögzítve vannak html kódot dokumentumot (oldalt) úgy, hogy hozzáadja az ID="label" attribútumot a kívánt HTML címkéhez (bekezdés, címsor vagy más megfelelő), majd hozzáadja ennek a horgonynak a nevét az oldal URL-jéhez a "#" hash szimbólumon keresztül. ne az elejére ugorjon ezen a weboldalon, hanem azonnal arra a helyre, ahol a horgonyt elhelyezték (mindenki automatikusan görgeti az oldalt a megfelelő helyre).

Olvassa el ezeket a cikkeket a navigáció megszervezéséről és a navigáció megszervezéséről az oldalon.

Milyen karakterek használhatók az URL-ekben?

Érdemes megemlíteni az URL-ekben használt különféle kódolásokat is. Átkódolás nélkül használhatják csak korlátozott mennyiség karakterek. Általában azt javasoljuk, hogy korlátozza magát egy karakterkészletre: ,,,[_],[-].

Általánosságban elmondható, hogy a hibák elkerülése érdekében azt tanácsolom, hogy az oldalad fájljainak és URL-címeinek neveit kisbetűvel állítsd be, mert a Unix-szerű rendszerekben (amelyeken a legtöbb webszerver működik) a karakterek nagybetűsek. és a kisbetűk különböznek (a Windowstól eltérően). A különböző regiszterek miatt szükségtelen zűrzavar keletkezhet.

Bármilyen más karakter (beleértve az oroszt is) használata engedélyezett az URL-ekben, de ez így lesz átkódolás ugyanazokat a karaktereket (URL kódolás).

Ami szomorú, az az URL-ek emészthetetlen megjelenése szimbólumokkal, például cirill betűkkel, amelyeket átkódolás után kapunk. Minden cirill karakter két bájttal van kódolva a -ban, hexadecimálisan írva, és százalékjellel „%” elválasztva. Például ez az URL:

https://weboldal/ki az új/

átalakítás után így fog kinézni:

Http//webhely/%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

Általánosságban elmondható, hogy nem túl menő, és azt tervezik, hogy nemzeti kódolásban kezelik ezt az emészthetetlen URL-t, de ez a dolog nem megy annyira.

A fentiekkel kapcsolatban tanácsot adnék, hogy mikor a CMS-emen ne készítsen oldalcímeket oroszul, és különösen azért, mert sok promóter szerint jobb lesz a SEO optimalizálása szempontjából a Yandex és a Google.ru számára.

Relatív és abszolút linkek az oldalon

Kezdjük azzal abszolút linkek, mert ebben az esetben semmi különöset nem kell mondani azon túl, amit ebben a cikkben már tárgyaltunk. Hogy. az abszolút hivatkozásnak meg kell felelnie az URL-címmel szemben támasztott követelményeknek - az adatátviteli protokollnak, a webhely domain nevének (host) és az elérési útnak. kívánt web dokumentum. Összes.

A HTML-ben egy abszolút linket képeznek speciális A tagek (hiperhivatkozások) segítségével, pl. lerakásához egyszerűen körül kell ölelnünk a kívánt helyet a dokumentum szövegében (kifejezés vagy kép) a nyitó és záró hiperhivatkozási címkékkel, és a nyitó A címkébe be kell írni a „Href” attribútumban a dokumentum abszolút elérési útját. dokumentum, amelyhez a látogatónak el kell jutnia, ha rákattint:

PHPMyAdmin

Minden nagyon egyszerű.

A relatív hivatkozások előnyei és beszerzésük módja

Az abszolút hiperhivatkozásokat azonban általában csak akkor használják, ha külső webhelyekre szeretnének hivatkozni, és a belső átmenetekhez a legtöbb webmester (okos és áttekintő, nem úgy, mint én 🙂) ezt próbálja használni. relatív linkek. És ennek több oka is van:

1. A relatív linkek értelemszerűen rövidebbek, és nem zsúfolják össze a webhely kódját (végül is minden apróság fontos ebben a kérdésben).
2. Ezen túlmenően, ha másik tartományra költözik, vagy a protokollt https-re módosítja, nem kell módosítania az oldalon található összes hivatkozást.
3. Ezenkívül egyes internetes projekttervek gyorsan és fájdalommentesen átvihetők egy másik erőforrásba a belső relatív hivatkozások megváltoztatása nélkül.

Tehát a névből ítélve annak a webdokumentumnak a címét, amelyre hivatkoznak, az Ön webhelyének dokumentumához képest kell írni, amelynek kódjából ez a relatív link kerül elhelyezésre (tánc a tűzhelyről). A második beállítási lehetőség a gyökérmappa használata kiindulási pontként. Ezek pontosan létrehozásának két módja relatív kapcsolatokat fogunk most megvizsgálni.

Hozzon létre relatív hivatkozásokat ahhoz a dokumentumhoz képest, amelyhez hozzá vannak ragasztva

A legegyszerűbb és legrövidebb módja a relatív elérési út (ami a hiperhivatkozási címke Href attribútumának értékét jelenti) írásának akkor érhető el, ha mindkét webdokumentum: az adományozó (amelyhez hozzá van ragasztva) és az elfogadó (a fájl vagy webdokumentum amelyhez vezet) ugyanabban a mappában találhatók a szerveren.

horgony

Most tegyük fel, hogy az elfogadó dokumentum egy olyan mappában található, amely ugyanabban a könyvtárban található, mint az adományozó dokumentum.

Hogyan nézne ki egy relatív link ebben az esetben? Ráadásul minden nagyon egyszerű:

horgony

Egyelőre úgy gondolom, hogy minden világos - megadjuk az elfogadó fájl vagy dokumentumának elérési útját (a mappa nevét, és a közvetlen perjelen keresztül a fájl vagy dokumentum nevét). Azok. ahhoz, hogy az adományozótól az elfogadóhoz jussunk, meg kell nyitnunk a mappát, amelynek nevét a relatív linkben feltüntetjük.

Most nézzük meg az ellenkező helyzetet, amikor maga az adományozó dokumentum a mappában található, ahonnan egy relatív hivatkozást kell helyeznie az elfogadó dokumentumra vagy fájlra, amely már egy szinttel feljebb található:

Ahhoz, hogy az adományozó dokumentumtól az elfogadó aktáig (vagy dokumentumig) eljuthassunk, szükségünk van egy szinttel feljebb léphet ebből a mappából. Ehhez egy speciális elemet biztosítanak - két pont egymás után, majd egy perjelen keresztül beírjuk az elfogadóhoz vezető további utat. Tehát a fenti példában a relatív elérési út a következő lenne:

Mi az az URL

Ha két szinttel feljebb kell lépnie, akkor a bejegyzés így fog kinézni:

Mi az az URL

Nos, ha ezután az elfogadó relatív elérési útjának beállításához meg kell adnia egy mappát a második felső (a donor dokumentumhoz viszonyítva) szinten:

Komplex pálya kialakítás

Ahány ilyen ereszkedés a mappákba és emelkedés a szintre lehet, a lényeg, hogy te magad ne keveredj össze.

Hozzon létre egy hivatkozást a gyökérmappához

Az összes fent tárgyalt linket megírtuk az adományozó dokumentumra vonatkozóan, amelyre a hiperhivatkozás felkerül, de megteheti vegyük a gyökérmappát kiindulási pontnak webhely. A relatív útvonalak gyökérje úgy néz ki, mint egy perjel "/".

Hogy. a főoldalra való áttérés meglehetősen egyszerűnek tűnik, de extravagáns:

horgony

Például, abszolút az útvonal így nézhet ki:

horgony

DE relatív ugyanahhoz a fájlhoz valamivel rövidebb lesz:

Szöveg

Hogyan hivatkozhatunk egy mappára relatív és abszolút formában

Szeretném felhívni a figyelmet egy árnyalatra, amelyet figyelembe kell venni mind az abszolút, mind a relatív linkek létrehozásakor. Ha akarod mappára hivatkozni, akkor ügyeljen arra, hogy egy ilyen hiperhivatkozás végére (a neve után) tegyen egy perjelet "/" Vagyis ha meg akarom nyitni egy mappa tartalmát, akkor ezt kell írnom:

horgony

Így nem:

szöveg

A második esetben a feldolgozás során a szerver először egy "feltöltések" nevű fájlt próbál megkeresni (pontosan ezt minden kiterjesztés nélkül), és nem találja, majd egy ilyen mappát keres. Ezért azonnal írni perjel a kívánt mappa neve után, akkor nem vesz el többlet erőforrásokat a szerveréről, ha azt keresi, ami nincs.

Ezzel is tisztában kell lennie kapcsolatfelvételkor relatív vagy abszolút vonatkozásban mappát, a webszerver megjelenik a benne található úgynevezett indexfájl, amelyet általában index.html vagy index.php néven hívnak. Ha nincs indexfájl a mappában, akkor ha a biztonság helytelenül van beállítva a kiszolgálón, megjelenik a tartalom listája, ami az erőforrás biztonságának csökkenéséhez vezethet.

Ha találsz, mindenképpen.

Egyébként az oldal főoldalának elérése lényegében a mappa (root) elérése is egyben, és ezzel egyidejűleg elindul a gyökérben található indexfájl (esetemben ez az index.php ). Tehát, ha egy mappához fér hozzá, akkor a szerverterhelés csökkentése érdekében jobb, ha a domain név után perjelet írunk:

Itt van, Mikhalych!

Sok szerencsét! Hamarosan találkozunk a blogoldalak oldalán

Lehet, hogy érdekel

ASCII szövegkódolás (Windows 1251, CP866, KOI8-R) és Unicode (UTF 8, 16, 32) - hogyan lehet megoldani a problémát a krakozyabry segítségével
Hogyan növeltem a webhely forgalmát napi 300 főre?
Yandex keresés a webhelyen és az online áruházban
Webhelytérkép webhelytérképe xml formátumban a Yandex és a Google számára - hogyan lehet webhelytérképet létrehozni a Joomlában és a WordPressben vagy egy online generátorban

Összes HTML hivatkozások külsőre és belsőre osztva. A külső hivatkozások olyan hivatkozások, amelyek egyik webhelyről egy másik webhelyre vagy egy másik webhelyen található fájlra vezetnek. Belső linkek- ezek olyan hivatkozások, amelyek a webhely egyik oldaláról ugyanannak a webhelynek egy másik oldalára vagy ugyanazon oldal szakaszaira hivatkoznak.

Összes Külső linkek a címke href attribútumában tartalmazzák az általuk hivatkozott dokumentum abszolút elérési útját. A belső hivatkozások viszont tartalmazhatnak abszolút és relatív útvonalat is (ebben az esetben ez az Ön személyes preferenciáitól függ).

Mint a nyelvtani szabályok különböző nyelvek, a programozásban is vannak szabályok. Az érvényesítés lehetővé teszi, hogy megnézze, hogy az oldal megfelel-e ezeknek a szabályoknak, és ha vannak hibák és figyelmeztetések, javaslatokat teszünk ezek kiküszöbölésére. Az ilyen ellenőrzés szükségességével kapcsolatos további részleteket az alábbiakban tárgyaljuk.

Mi befolyásolja az oldal érvényességét

Elgondolkozott már azon, hogy a böngészők hogyan „olvasnak” egy weboldalt? Vannak "motorjaik" a kód elemzésére, és az emberek számára vizuális formává alakítására. Sajnos minden böngészőnek megvan a saját kódkezelési mechanizmusa, és emiatt az oldalak eltérően jelenhetnek meg.

Az érvénytelen weboldalt a böngészők többféleképpen is elolvashatják. Ez azt eredményezi, hogy látogatói valószínűleg nem is látják megfelelően az oldal tartalmát a böngészőjükben. Az érvényesítés később szinte minden lényeges eltérést kijavít, és szinte minden webböngészővel olvashatóvá teszi a weboldalt (leggyakrabban a kivétel internet böngésző régebbi verziók). Innen származik a „böngészők közötti elrendezés” kifejezés. elrendezés, amely egyformán jó (kompatibilis) minden népszerű böngészővel.

Hogyan érinti ez a SEO-t? Fontos megérteni, hogy a keresőrobotok szeretik a szemantikus weboldalakat. A szemantikus elrendezés a Wikipédia szerint a weboldalak létrehozásának egyik megközelítése HTML nyelv, alapján HTML használatával címkéket szemantikája (célja) szerint. Ezenkívül a strukturális szemantikai weboldal lehetővé teszi a keresőrobotok számára, hogy pontosabban meghatározzák a weboldal egyes elemeinek és a teljes szöveg egészének jelentőségét. A Google szerint az érvényes kód semmilyen módon nem befolyásolja az oldal rangsorolását. Ugyanakkor a kódban lévő hibák negatívan befolyásolhatják a mikroadatok beolvasását és a mobileszközökhöz való alkalmazkodást.

Ellenőrző eszközök webhelyéhez

Megértve annak szükségességét, hogy a webhely oldalain ne legyenek érvényesítési hibák, nézzük meg, hogyan keressük ezeket a hibákat.

Sokan vannak ingyenes szolgáltatások a webhelyek ellenőrzéséhez, mint például a W3C Markup Validation Service , a Web Page Analyzer , a Browsershots és mások.

Ph.D. Lavlinsky N. E., a Method Lab LLC műszaki igazgatója

Nemrég megjelent új szabvány előtöltési technológiához (link). Ennek a specifikációnak a fő célja az volt, hogy lehetővé tegye a fejlesztő számára az oldalerőforrás-betöltési logika finom vezérlését.

Korábbi szabványok

A terheléskezelés ötlete nem új. Korábban számos címkelehetőséget fejlesztettek ki link attribútumokkal alforrás, előrenderelésés előhívni. Ezek azonban egy kicsit másképp működtek: segítségükkel olyan oldalelemeket vagy teljes oldalakat tölthet le, amelyekre szükség lehet az oldalon való további navigáció során. Vagyis a böngésző alacsony prioritással és utolsóként küldte az ilyen kéréseket. Ha növelni kell a prioritást, akkor nem volt megoldás.

Erőforrások betöltése előtöltéssel

Mi az új specifikáció? Először is, most a betöltés a betöltendő adatok specifikációjával történik. A megadott erőforrástípus alapján a böngésző beállítja a letöltési prioritást. Például:

Másodszor, az erőforrás típusa ( mint) lehetővé teszi a böngésző számára, hogy a megfelelő fejléceket küldje el, hogy a szerver a legjobb tömörítési opcióval tudja elküldeni a tartalmat (például WebP-képek küldése, ha a böngésző támogatja őket).

A második példában egy betűtípusfájlt töltünk be, amely egy adott formátumot (WOFF2) határoz meg, amelyet nem minden böngésző támogat. Mindaddig azonban, amíg az előtöltési mechanizmus támogatása megegyezik ennek a formátumnak a támogatásával, nincs probléma. A jelenlegi mechanizmus támogatás megtekinthető.

Gyorsabb betűtípus betöltés

A webhely előtöltéssel történő felgyorsítására példa a mélyen eltemetett erőforrások, például a betűtípusok betöltése. A normál letöltési folyamat során a böngészőnek először le kell töltenie a betűtípusra mutató CSS-fájlt, elemeznie kell a fájlt, és csak ezután kell sorba állítania a betűtípusfájl letöltésére vonatkozó kérést.

Ha ezt a betűtípust előre betöltjük a HTML oldal kódjába, akkor a böngésző azonnal elküldi a kérést a HTML dokumentum elemzése után, ami néhány másodperccel korábban is előfordulhat, mint normál esetben. És tudjuk, hogy a csatlakoztatható betűtípusok blokkolják az elemeket, és késleltetik a betűtípus megjelenítését az oldalon, ezért a lehető leggyorsabban be kell tölteni őket. Ez a probléma különösen akut HTTP / 2 használatakor, amikor a böngésző egyszerre több kérést küld a szervernek, aminek következtében egyes képek kitölthetik a kliens sávszélességét, és a fontos erőforrások betöltése késik.

Aszinkron CSS betöltés

A CSS-fájlok mindig blokkolják az oldalmegjelenítést, így minden késleltetett CSS-erőforrás normál fájlként betölthető, és dinamikusan összekapcsolható az oldallal.

Ez a következőképpen történik:

JS-kód betöltése végrehajtás nélkül

Hasznos lehet az is, ha előre betölti a szkript kódját JS-ben, hogy később végre lehessen hajtani.

Ezt a következő kóddal lehet megtenni:

Áttekintettük az előtöltési mechanizmus használatának főbb módjait, de a lehetőségek nem korlátozódnak erre, végezzen saját kísérleteket!

Általános szabály, hogy sok webmester azonnal feltölti webhelyét a gazdagépre azok létrehozása után. Ugyanakkor leginkább a szövegtartalom jelentésének helyességére helyezik a hangsúlyt, nem pedig az oldalak belső kódjának helyességére.

Webhely érvényesítése

De vannak más tényezők is, amelyek befolyásolhatják és befolyásolják a webhely helyzetét. És többek között technikai tényezőket is tartalmaznak. Nos, az oldal érvényesítése is a technikaiakhoz tartozik. Tehát mi az?

Ha egy egyszerű szavakkal, akkor a webhely érvényesítése a webhely kódjának ellenőrzése a műszaki megfelelőség és a hibák szempontjából. Nos, például elfelejtetted használni a záró címkét - /html. A legújabb HTML5-ben vizuálisan semmi sem fog változni. Ez azonban kódhiba.

Kódíráskor egyéb hibák is előfordulhatnak. És újra, modern nyelv A hiperjelölés sokat fog bírni. Például "elfelejti" a /head záró címkét. Ismét nem fogod látni a különbséget. De ő az))

Valójában egy weboldal írásakor elég sok hiba történhet. És ami még rosszabb, ezeknek a hibáknak egy része vizuálisan is megjelenhet. Nos, lehet, hogy a blokkok lebegnek, talán igazodás, vagy valami más. Lehetséges hibák, ezrek. És nem mindegyik feltűnő.

Mi a veszély?

Nos, úgy tűnik, mi a baj ezzel? Igen, azt kell mondani, hogy az ilyen hibák gyakran nem láthatók. Vagy inkább láthatatlan az emberek számára. De oldalunk oldalait nem csak emberek látogathatják, hanem az oldalt teljesen átvizsgáló keresőpókok is. És minden hibát, amit a webhelyen találnak, továbbítják a keresőmotorok, például a Yandex vagy a Google szervereihez.

A keresőmotorok pedig, látva, hogy az oldal sok kódhibát tartalmaz, arra a következtetésre juthatnak, hogy az oldal rossz. Ez pedig azt jelenti, hogy nem vetik fel a keresés során. Nos, ez már azt jelenti, hogy viszlát a látogatók a kereséstől.

Igen, el kell ismerni, hogy elég ritka az oldal bizonyos pesszimizálása az érvényesítési hibák miatt. De ez teljesen lehetséges, ami azt jelenti, hogy az érvényesítésen dolgozni kell. És mit kell ehhez tenni? Természetesen az első lépés a hibák feltárása.

De mivel ez manuálisan nagyon időigényes és megbízhatatlan üzlet, a hibák kereséséhez a speciális szolgáltatások, az úgynevezett „Validátorok”.

Validator Markup Validation Service.

Ez a szolgáltatás szinte minden oldal létrehozásakor ellenőrzi a HTML és XHTML kódok helyességét, amelyek a legtöbb oldal alapját képezik, és meghatározza annak belső szerkezetét. Ez az érvényesítő szolgáltatás a http://validator.w3.org hivatkozás segítségével érhető el

De itt van egy előfeltétel, ami más érvényesítőkre is vonatkozik: az ellenőrzött oldalt vagy annak ellenőrzött oldalait fel kell tölteni a tárhelyre. Ellenkező esetben az érvényesítő nem "tudja" a webhely címét, és nem tud semmit ellenőrizni. Most már átgondolhatja, hogyan dolgozzon ezen a validátoron.

A szolgáltatás oldalára való belépés után a teljes funkcionális képe megjelenik. De az ábrázolt és leírtak nagy része nem vonatkozik a fő ellenőrzésre, és minden figyelmet csak az ellenőrzött oldal címének beviteli ablakára kell fordítani:

Pontosan itt kell kezdeni.

Valójában egy oldal érvényességének ellenőrzése rendkívül egyszerű, akárcsak az egész halandó világunk: a szolgáltatás címablakába be kell írni az oldal címét, pl. URL-címét, majd kattintson az „Ellenőrzés” gombra. Egy ilyen egyszerű művelet után a validátor néhány másodpercig „puffad”, és kiadja a következőket:

Ez azt jelenti, hogy nincs hiba az oldal kódjában, és teljesen nyugodt lehet.

De előfordulhat egy ilyen nemkívánatos lehetőség is:

Ez már rosszabb, és azt jelenti, hogy az ellenőrzött oldal belső kódjában vannak hibák. Ez azonban egyáltalán nem végzetes: csak görgetni kell az alábbi oldalt, és az ellenőrzési folyamat során talált hibákat ott részletesen leírjuk.

Ráadásul a validátor nem csak a talált hibákat listázza ki, hanem azt is pontosan megmutatja, hogy a belső kód melyik sorában találhatók ezek a hibák. Így nem kell sokáig keresgélned őket. Itt minden túlzás nélkül határozottan kijelenthetjük, hogy ez a validor tökéletesen működik.

De ez még nem minden: a validátor nemcsak az észlelt kódhiba helyét jelzi, hanem meglehetősen teljes körű ajánlásokat is ad ezeknek a hibáknak a kiküszöbölésére. Természetesen ehhez nem kell lustának lenni, és figyelmesen elolvasni mindent, ami írva van.

Rövid és általános következtetésként a következőket mondhatjuk:

1. ez az érvényesítő szolgáltatás kiválóan működik, és nagyon gyorsan tudja ellenőrizni a webhelyet.
2. Nos, egy kicsi, de nagyon szép kiegészítés: a webhely érvényesítése ingyenes.
3. Most léphetünk a következő lépésre: ez a CSS-kód ellenőrzése.

CSS-érvényesítési szolgáltatás

Általánosságban elmondható, hogy ez a fenti szolgáltatás második funkciója, de nem a HTML és XHTML kód ellenőrzésére van „kihegyezve”, hanem kifejezetten a kód helyességének ellenőrzésére css stílusban a külső asztalon található. A szolgáltatási oldal eléréséhez pedig követnie kell a http://jigsaw.w3.org/css-validator hivatkozást.

Mellesleg itt érdemes megjegyezni valami kellemeset: ennek a szolgáltatásnak az ellenőrzése teljesen ingyenes. Tehát ne húzzon ki pénzt a pénztárcájából - hagyja, hogy a megfelelő pillanatig feküdjön. Térjünk azonban át a második szolgáltatáson végzett munka módszertanára.

Általánosságban elmondható, hogy a CSS-ellenőrzőn végzett minden munka teljesen megegyezik a kód tisztaságának ellenőrzésével. Ezért nem szükséges külön képet megadni az érvényesítő címsoráról. Csak egy kicsit lejjebb röviden átgondoljuk magának az ellenőrzésnek a sorrendjét, és ennyi.

Ehhez kell címsorírj URL-t CSS táblázatok, például "http://my site/style.css", majd nyomja meg az orosz "Check" feliratú gombot. Ennek megfelelően ez a validátor is „puffad” néhány másodpercig, és a kívánt eredményt adja:

Ez azt jelenti, hogy a CSS tábla helyesen van megírva, és nem található benne hiba.

És van itt egy kellemes meglepetés is: ha egy kicsit lejjebb görgetsz az oldalon, akkor oda íródik a CSS-tábládhoz optimalizált kód, amelyről minden felesleges felirat eltávolítódik, és minden kódcímke sorrendbe kerül. amely megfelel az összes keresőmotor optimális működési követelményeinek. Nincs más hátra, mint kimásolni ezt a tökéletes kódmintát, és beilleszteni a CSS-táblába.

Nagyon valószínű, hogy valami ilyesmi történhet:

Ez azt jelenti, hogy néhány hibát találtak a CSS-kódban, de ettől egyáltalán nem kell félni. Közvetlenül a piros vonal alatt az érvényesítő pontosan megmondja, melyik címke van elgépelve. Már csak meg kell találni ezeket a címkéket a stíluslapon, és elvégezni a szükséges javításokat.

És persze ezek után töltsd fel a javított stíluslapot a gazdagépre, és ha van zöld vonal, akkor boldogan másolhatod az optimalizált CSS-tábla stíluskódját. Teljesen egyértelmű, hogy akkor a legjobb változtatni régi kód egy új és optimalizált.

Rövid összefoglaló.

A két legalapvetőbb és legkötelezőbb webhelyérvényesítési ellenőrzést fentebb tárgyaltuk. Ezen ellenőrzések nélkül ne is nyissa meg az indexelést a keresőmotorok számára a robots.txt fájlban. Ellenkező esetben előfordulhat, hogy a webhely figyelmen kívül hagyja az indexelést. kereső motorokés megfelelő szankciókkal hibásnak minősül.

Ennek elkerülése érdekében csak néhány percet kell töltenie, hogy teljesen nyugodt legyen, és teljesen magabiztos legyen webhelye és minden oldala műszaki állapotában. Természetesen szükség van a linkek és horgonyok további ellenőrzésére, az oldal láthatóságára is mobil eszközökés más kódok paraméterei. Csak ezután tekinthető az oldal késznek a teljes körű működésre és a sikeres és gyors promóció a TOP-ban.

Előre szeretném elmondani, hogy az összes többi ellenőrzés ugyanolyan gyors és egyszerű, mint a fentebb tárgyaltak - csak figyelmesen el kell olvasnia az érvényesítővel való munkafolyamatot.

Hozzáadva: 2018.04.19

Gyakori érvényességi hibák a HTML-kód érvényesítésekor

Úgy döntött, frissíti a cikket. HTML hibák kódok, amelyek gyakran megtalálhatók a webhelyeken. Mindenesetre sok volt belőlük)). Az érvényesítő sárgával kiemeli a hibákat.

1) Hiba: A karakterhivatkozást nem pontosvessző fejezte be.

Hiba: a karaktert nem szakította meg pontosvessző – ennek megfelelően hozzá kell adni.

2) Figyelmeztetés: A szakasz címsora hiányzik. Fontolja meg a h2-h6 elemek használatát az összes szakaszhoz azonosító címsorok hozzáadásához.

Figyelmeztetés: Ennek a szakasznak nincs címe. Fontolja meg a h2-h6 elemek használatát az összes szakaszhoz azonosító címsorok hozzáadásához. Itt minden világos, hozzá kell adni legalább egy feliratot. Ez nem is hiba, hanem ajánlás.

3) Hiba: A noindex elem ebben az összefüggésben nem engedélyezett a p elem gyermekeként.

Hiba: a noindex elem nem engedélyezett mint gyermek elem p elem ebben az összefüggésben. (A további hibák letiltása erről a részfáról.)
A megoldás egyszerű, megjegyzésbe kell írnia a noindex címkét, a nézet így fog kinézni:

4) Hiba: A középső elem elavult.

Hiba: a "center" címke elavult - le kell cserélni, ha img-ről beszélünk, akkor használhatja az align attribútumot. Ha valami más van középen, akkor cserélje ki div-re.

5) Az img elemnek alt attribútumot kell tartalmaznia, kivéve bizonyos alatt

Hiba: Az img elemnek alt attribútumnak kell lennie - itt minden világos, hozzá kell adni egy alt attribútumot, még ha üres is, a hiba eltűnik.

6) A td elem szélesség attribútuma elavult. Használjon helyette CSS-t.

Hiba: A „td” elem „width” attribútuma elavult

7) A type attribútum nem szükséges a JavaScript erőforrásokhoz

Hiba: A type attribútum nem szükséges a JavaScript erőforrásokhoz. A megoldás egyszerűen az, hogy eltávolítunk mindent, ami felesleges, és csak a „script” címkét hagyjuk meg.

8) Az img elem align attribútuma elavult.

Hiba: Az img elem align attribútuma elavult. Készítsen képigazítási diveket.