Fasetové hledání. Nalezení správné cesty: jak fasetovaná navigace ovlivňuje SEO (překlad)

Domov / Windows 7

V tomto článku (úroveň webmaster - pokročilý) si povíme o tzv. protínání různými způsoby. „fasetovaná“ navigace. Pro zjednodušení asimilace materiálu doporučuji projít si článek Wikipedie „Klasifikace fazet“ a publikace na angličtina(ale s obrázky!) "Navrhněte pro své webové stránky lepší navigaci."

Facetová navigace, která filtruje podle barvy nebo cenového rozpětí, může být pro vaše návštěvníky užitečná, ale často poškozuje výsledky vyhledávání, protože vytváří více kombinací adres URL s duplicitním obsahem. Kvůli duplicitám nebudou vyhledávače schopny rychle vyhledávat aktualizace obsahu na webu, což odpovídajícím způsobem ovlivňuje indexování. Abychom tento problém minimalizovali a pomohli webmasterům usnadnit vyhledávání fasetové navigace, rádi bychom:

Ideální pro uživatele a vyhledávání Google

Vymazat cestu ke stránkám produktů/článků:

Reprezentace adresy URL pro stránku kategorie:
http://www.example.com/category.php?category=gumove-bonbony

Reprezentace adresy URL konkrétního produktu:
http://www.example.com/product.php?item=svedska-ryba

Nežádoucí duplikáty způsobené fasetovanou navigací

Stejná stránka je přístupná z různých webových adres:

Kanonická stránka



URL: example.com/product.php? předmět=švédská-ryba

Duplicitní stránka



URL:example.com/produkt.php? item=svedska-ryba&kategorie=gumove-bonbony&cena=5-10


kategorie=gumové-bonbony&chuť=kyselá&cena=5-10

chyby:

  • Pro Google to nemá smysl, protože uživatelé zřídka hledají [marmeláda za 9:55 $].
  • Zbytečné pro vyhledávací roboty, který najde stejnou položku ("ovocný salát") ze stránek nadřazené kategorie (buď "Jummy" nebo "Sour Gummy").
  • Negativní bod pro vlastníka webu, protože požadavky na indexování jsou zředěny mnoha verzemi stejné kategorie.
  • Negativní bod pro vlastníka webu, protože je to zbytečné a navíc zatěžuje šířku pásma webu
Prázdné stránky:


URL: example.com/category.php? kategorie=gumové-bonbony&chuť=kyselá&cena=nad-10

chyby:

  • Kód pro vyhledávače(v tomto případě by stránka měla vrátit kód 404)
  • Prázdná stránka pro uživatele


Nejhorší řešení (není přátelské k vyhledávání) pro fasetovanou navigaci

Příklad č. 1: Nepoužívá se jako součást adresy URL standardní parametry: místo toho čárky a závorky klíč=hodnota&:

  • example.com/kategorie? [ kategorie:gumové-bonbony ][ řazení:cena-od nejnižší po nejvyšší ][ sid:789 ]
  • example.com/category?category , gummy-candy , sort , lowtohigh , sid , 789
Jak na to:
example.com/kategorie? category=gummy-candy&sort=low-to-high&sid=789

Příklad č. 2: Použití adresářů nebo cest k souborům namísto parametrů v seznamech hodnot, které nemění obsah stránky:
example.com/c123 /s789/ produkt?svedska-ryba
(kde /c123/ kategorie, /s789/ ID relace, které nemění obsah stránky)

Dobré řešení:

  • example.com /gumové-bonbóny/ product?item=swedish-fish&sid=789(adresář /gummy-candy/ mění obsah stránky smysluplným způsobem)
Nejlepší řešení:
  • example.com/product?item=svedska-ryba& kategorie=gumové-bonbóny&sid=789 (Parametry adresy URL poskytují vyhledávačům větší flexibilitu při rozhodování, jak efektivně procházet)
Pro prohledávače je obtížné odlišit užitečné hodnoty (například „gummy-candy“) od neužitečných (jako je „SESSIONID“), když jsou tyto hodnoty umístěny přímo v cestách odkazů. Na druhou stranu parametry adresy URL poskytují vyhledávačům flexibilitu pro rychlé testování a určení, kdy daná hodnota nevyžaduje přístup prohledávače ke všem možnostem.

Mezi běžné hodnoty, které nemění obsah stránky a musí být uvedeny jako parametry adresy URL, patří:

  • ID relace
  • Sledování ID
  • ID refererů
  • Časová razítka
Příklad č. 3: Převeďte uživatelem generované hodnoty (případně nekonečné) na parametry adresy URL, které lze procházet a indexovat, ale jsou neužitečné pro vyhledávání.
Použití menších dat generovaných uživateli webu (jako je zeměpisná délka/šířka nebo „před dny“) v procházených a indexovaných adresách:
  • example.com/najít-lékaře? poloměr=15&zeměpisná šířka=40,7565068&délka=-73,9668408
  • example.com/article?category=health& před dny=7
Jak na to:
  • example.com/najít-lékaře? město=san-francisco&neighborhood=soma
  • example.com/articles?category=health& datum = 10. ledna 2014
Namísto toho, abyste uživateli umožnili generovat hodnoty pro vytváření procházet URL adres (což má za následek nekonečné možnosti s velmi malou hodnotou pro návštěvníky), je lepší publikovat kategorii stránek pro nejoblíbenější hodnoty, navíc můžete zahrnout další informace takže stránka poskytuje větší hodnotu než běžná stránka s výsledky vyhledávání. Případně můžete zvážit umístění uživatelem generovaných hodnot do samostatného adresáře a poté pomocí robots.txt zabránit procházení z tohoto adresáře.
  • example.com /filtrování/ find-a-doctor?radius=15&latitude=40.7565068&longitude=-73.9668408
  • example.com /filtrování/články?category=health&days-ago=7
A v souboru robots.txt:
User-agent: *
Disallow: /filtrování/

Příklad č. 4. Přidávání parametrů URL bez logiky.

  • example.com /gumový-bonbón/lízátka/gumový-bonbón/ gumový-bonbón/produkt?švédská-ryba
  • example.com/produkt? cat=gummy-candy&cat=lízátka&cat=gummy-candy&cat=gummy-candy&item=švédská-ryba
Dobré řešení:
  • example.com /gumové-bonbóny/ product?item=swedish-fish
Nejlepší řešení:
  • example.com/produkt? item=swedish-fish&category=gummy-candy
Nadbytečné parametry adresy URL pouze zvyšují duplicitu, což způsobuje, že je procházení a indexování webu méně efektivní. Proto je nutné se před generováním nových URL zbavit zbytečných parametrů URL a pravidelně čistit nevyžádané odkazy. Pokud je pro uživatelskou relaci potřeba mnoho parametrů, můžete skrýt informace v souborech cookie namísto neustálého přidávání hodnot jako cat=gummy-candy&cat=lízátka&cat=gummy-candy& ...

Příklad č. 5: Navrhněte další upřesnění (filtrování), pokud jsou výsledky null.

Špatně:
Umožnit uživatelům vybrat filtry, pokud existují prázdné položky k upřesnění.


Objasnění na stránku s nulovými výsledky (například cena=nad-10), které uživatele frustruje a způsobuje zbytečné požadavky pro vyhledávače.

Jak na to:
Vytvářejte odkazy pouze v případě, že existují prvky, které může uživatel vybrat. Pokud je výsledek nula, odkaz je označen jako „šedý“ (tj. nelze na něj kliknout). Chcete-li dále zlepšit použitelnost, zvažte přidání indikátoru počtu dostupných položek vedle každého filtru.


Zobrazení stránky s nulovými výsledky (například cena=nad-10) není povoleno, navíc uživatelům zakazuje zbytečná kliknutí a vyhledávače tuto stránku neprocházejí užitečná stránka.

Je nutné zabránit vzniku zbytečných adres a minimalizovat prostor pro návštěvníka vytvářením URL pouze tehdy, když jsou produkty dostupné. To pomůže udržet pozornost uživatelů na vašem webu (méně kliknutí na tlačítko Zpět, když nejsou nalezeny žádné produkty) a sníží počet možných adres URL známých vyhledávačům. Kromě toho, pokud stránka není pouze „dočasně vyprodaná“, ale je nepravděpodobné, že by někdy obsahovala relevantní informace, můžete zvážit přidělení kódu odpovědi 404. Na stránce 404 můžete vytvořit užitečná zpráva pro uživatele s více možnostmi v navigačním nebo vyhledávacím poli, aby uživatelé mohli najít související produkty.

Pro nové weby, jejichž webmasteři zvažují implementaci fasetové navigace, existuje několik možností, jak optimalizovat procházení (soubor adres na vašem webu, které Google zná) stránek s jedinečným obsahem a omezit duplicitní stránky, aby se dostaly do indexu vyhledávače (konsolidace indexování signály).

Určete, jaké parametry adresy URL jsou vyžadovány, aby vyhledávače procházely každou jednotlivou stránku s obsahem (tj. určete, jaké parametry jsou potřeba k vytvoření alespoň jedné cesty kliknutí ke každé položce). Požadované parametry mohou zahrnovat item-id , category-id , page atd.

Určete, které parametry budou užitečné pro návštěvníky s jejich dotazy a které pravděpodobně způsobí duplicitu při procházení a indexování. V příkladu cukrovinky (marmeláda) by parametr adresy URL „chuť“ mohl být cenný pro uživatele s dotazy v příkladu chuť=kyselá . Je však logické považovat parametr „cena“ za způsobující zbytečnou duplicitu kategorie=gumové-bonbony&chuť=kyselá& cena=nad-10 . Další běžné příklady:

  • Hodnotné parametry pro vyhledávače: item-id , category-id , name , brand ...
  • Zbytečné parametry: session-id , cenový rozsah ...
Podívejme se na implementaci jedné z několika možností konfigurace pro adresy URL, které obsahují zbytečné parametry. Jen se ujistěte, že „zbytečné“ parametry adresy URL nejsou ve skutečnosti vyžadovány pro prohledávače vyhledávačů nebo pro uživatele k nalezení každého jednotlivého produktu!

Možnost 1: a interní odkazy

Všechny nepotřebné adresy URL označte příponou . To sníží mzdové náklady vyhledávacího robota a zabrání snížení frekvence procházení. Skenování musíte spravovat globálně prostřednictvím souboru robots.txt (poznámka překladatele: viz článek „ “).
Pomocí atributu rel="canonical" oddělte stránky pro index vyhledávání od stránek, které tam nejsou potřeba (například na stránce cena = 5-10 můžete přidat atribut rel="canonical" označující kategorii všech kyselých marmelád example.com/category.php?category=gummy-bonbony&chut=kysele& strana=vše ).

Možnost 2: Robots.txt a Disallow

Adresy URL s nepotřebnými parametry jsou zahrnuty v adresáři /filtring/, který bude uzavřen v souboru robots.txt (zakázat). To umožní všem vyhledávačům procházet pouze „správný“ in-link (obsah) webu, ale zablokuje procházení nežádoucích adres URL najednou. Například ( example.com/category.php?category=gumove-bonbony), pokud by hodnotnými parametry byly položka, kategorie a chuť a identifikátor relace a cena byly nadbytečné, pak by adresa URL chuti vypadala takto:
example.com/category.php?category=gumove-bonbony& chuť=kyselá, ale všechny nepotřebné parametry, jako je cena, budou obsaženy v URL v předdefinovaném adresáři - /filtring/:
example.com /filtrování/ category.php?category=gumove-bonbony&cena=5-10,
což pak bude zakázáno prostřednictvím souboru robots.txt:
User-agent: *
Disallow: /filtrování/

Možnost 3: Samostatní hostitelé

Ujistěte se nejlepší řešení, uvedené výše (například pro nepotřebné adresy) stále platí. V jinak vyhledávače již vytvořily velké množství odkazů v indexu. Vaše práce se tedy zaměří na snížení dalšího nárůstu nepotřebných stránek procházených Googlebotem a na konsolidaci indexovacích signálů.

Používejte parametry se standardním kódováním a formátem klíč=hodnota.

Ujistěte se, že hodnoty, které nemění obsah stránky, jako jsou ID relace, jsou implementovány jako klíč=hodnota spíše než adresáře.

Nepovolovat kliknutí ani generovat adresy URL, pokud nejsou k dispozici žádné prvky k filtrování.

Přidejte do mapování parametrů URL logiku: místo neustálého přidávání hodnot odstraňte nepotřebné parametry (vyhněte se například generování odkazů takto: example.com/product?cat=gummy-candy&cat=lízátka &cat=gummy-candy&item=svedska-ryba).

Hodnotné parametry ukládejte do adres URL tak, že je uvedete jako první (protože adresy URL jsou viditelné ve výsledcích vyhledávání) a méně relevantní parametry jako poslední (například ID relace).
Vyhněte se této struktuře odkazů: example.com/category.php? session-id=123&tracking-id=456&category=gumové-bonbony&chuť=kyselé
Pokud jasně rozumíte tomu, jak odkazy na vašem webu fungují, nakonfigurujte parametry adresy URL v Nástrojích pro webmastery.

Ujistěte se, že při použití JavaScriptu k dynamické manipulaci s obsahem (třídění/filtrování/skrytí) bez aktualizace adresy URL jsou na vašem webu skutečné webové adresy, které mají hodnotu pro vyhledávání, jako jsou hlavní kategorie a stránky produktů, které lze procházet a indexovat . Snažte se nepoužívat pouze domovskou stránku(tj. jedna URL) pro celý váš web a prostřednictvím JavaScriptu dynamicky měnit obsah s navigací – to bohužel uživatelům poskytne pouze jednu URL ve vyhledávání. Kromě toho zkontrolujte, zda výkon neovlivňuje výkon dynamického filtrování k horšímu, protože bude narušovat schopnost uživatele pracovat s webem.

Zlepšete indexování různých stránek stejného obsahu zadáním atributu rel="canonical" na privilegované verzi stránky. Atribut rel="canonical" lze použít v rámci jedné nebo více domén.

Optimalizujte indexování stránkovaného obsahu (například stránka=1 a stránka=2 z kategorie „gumové bonbóny“) buď:

  • Přidejte atribut rel="canonical" na řadu stránek označující kanonickou kategorii pomocí parametru „view-all“ (například page=1, page=2 a page=3 z kategorie „gumové bonbóny“ s rel=”canonical” on category=gummy-bonbony&page=all), ujistěte se, že stránka je pro uživatele relevantní a rychle se načítá.
  • K označení vztahu mezi jednotlivými stránkami použijte značku stránkování rel="next" a rel="prev" (viz "Paginaton s rel="next" a rel="prev" ").
Zahrňte do svých souborů Sitemap pouze kanonické odkazy.

Rychle jsme se podívali na instalaci a základní syntaxi PINQ, portu LINQ na PHP. V tomto článku se podíváme na to, jak pomocí PINQ simulovat funkci fasetovaného vyhledávání v MySQL.

V tomto článku se nebudeme zabývat všemi aspekty fasetovaného vyhledávání. Zájemci si mohou vyhledat vhodné informace na internetu.

Typické fasetové vyhledávání funguje takto:

  • Uživatel zadá klíčové slovo nebo několik klíčových slov pro vyhledávání. Například „router“ pro vyhledávání produktů, ve kterých se slovo „router“ vyskytuje v popisu, klíčových slovech, názvu kategorie, značkách atd.
  • Stránka vrátí seznam produktů, které splňují tato kritéria.
  • Stránka poskytuje několik odkazů pro přizpůsobení hledaných výrazů. Může vám například umožnit specifikovat konkrétní výrobce routerů nebo nastavit cenové rozpětí nebo jiné funkce.
  • Uživatel může pokračovat v zadávání dalších vyhledávacích kritérií, aby získal soubor dat, který ho zajímá.

Fasetové vyhledávání je velmi oblíbené a je mocný nástroj, lze jej pozorovat téměř na všech webových stránkách souvisejících s elektronickým obchodem.

Bohužel fasetové vyhledávání není zabudováno do MySQL. Co bychom tedy měli dělat, pokud stále používáme MySQL, ale chceme dát uživateli tuto příležitost?

S PINQ, který má podobný, výkonný a jednoduchý přístup, můžeme dosáhnout stejného chování, jako bychom používali jiné databázové stroje.

Rozšíření dema z prvního dílu

Komentář: Veškerý kód z této části az první části lze nalézt v úložišti.

V tomto článku rozšíříme ukázku z 1. části s výrazným vylepšením v podobě fasetovaného vyhledávání.

Začněme s index.php a přidejte k němu následující řádky:

$app->get("demo2", function () use ($app) ( global $demo; $test2 = new pinqDemo\Demo($app); return $test2->test2($app, $demo->test1) ($app)); $app->get("demo2/facet/(key)/(value)", funkce ($key, $value) use ($app) ( global $demo; $test3 = new pinqDemo\Demo($app); return $test3->test3($app, $demo->test1($app), $key, $value ));

První cesta nás zavede na stránku, kde si zobrazíme všechny příspěvky, které odpovídají vyhledávání klíčových slov. Aby byl příklad jednoduchý, vybereme všechny knihy z tabulky kniha_kniha. Zobrazí také výslednou datovou sadu a sadu odkazů pro specifikaci vyhledávacích kritérií.

V reálných aplikacích se po kliknutí na takové odkazy všechny fasetové filtry přizpůsobí hraničním hodnotám výsledné datové sady. Uživatel tak bude moci postupně přidávat nové podmínky vyhledávání, například nejprve vybrat výrobce, poté zadat cenové rozpětí atd.

Ale v tomto příkladu nebudeme toto chování implementovat - všechny filtry budou odrážet hraniční hodnoty původní datové sady. Toto je první omezení a první kandidát na vylepšení v našem demu.

Jak můžete vidět v kódu výše, skutečné funkce jsou umístěny v jiném souboru s názvem pinqDemo.php. Pojďme se podívat na odpovídající kód, který poskytuje funkci fasetovaného vyhledávání.

Třída aspektů

Nejprve vytvořte třídu, která reprezentuje aspekt. Obecně by aspekt měl obsahovat několik vlastností:

  • Data, se kterými pracuje ( $data)
  • Klíč, kterým se seskupení provádí ( $klíč)
  • Typ klíče ($type). Může být jedna z následujících:
    • zadejte celý řetězec pro přesnou shodu
    • zadejte část řetězce (obvykle počáteční) pro vyhledávání podle vzoru
    • označte rozsah hodnot pro seskupení podle rozsahu
  • je-li typem klíče rozsah hodnot, musíte definovat hodnotový krok, abyste určili dolní a horní hranici rozsahu; nebo pokud je typ součástí řetězce, musíte určit, kolik prvních písmen bude použito pro seskupení (rozsah $)

Seskupování- nejkritičtější část aspektu. Všechny agregované informace, které může být aspekt schopen vrátit, závisí na kritériích seskupení. Nejpoužívanějšími vyhledávacími kritérii jsou obvykle „Full String“, „Part of String“ nebo „Range of Values“.

Jmenný prostor classFacet ( použijte Pinq\ITraversable, Pinq\Traversable; class Facet ( public $data; // Původní datová sada veřejný $klíč; // pole, podle kterého se má seskupit veřejný $typ; // F: celý řádek; S: počáteční řetězce ; R: rozsah public $rozsah; // hraje roli pouze pokud $typ != F ... public function getFacet() ( $filter = ""; if ($this->type == "F") / ; / celý řádek ( ... ) elseif ($this->type == "S") // začátek řádku ( ... ) elseif ($this->type == "R") // rozsah hodnot ​​( $ filter = $this->data ->groupBy(function($row) ( return floor($row[$this->key] / $this->range) * $this->range; )) -> select(funkce (ITtraversable $data) ( return ["key" => $data->last()[$this->key], "count" => $data->count()]; )); filtr;))

Hlavní funkcí této třídy je vrátit filtrovanou datovou sadu na základě původní datové sady a vlastností aspektů. Z kódu je zřejmé, že pro různé typyúčty se používají různými způsoby seskupování dat. Ve výše uvedeném kódu jsme ukázali, jak může kód vypadat, pokud data seskupíme podle rozsahu hodnot v přírůstcích zadaných v $rozsah.

Nastavení aspektů a zobrazení zdrojových dat

Veřejná funkce test2($app, $data) ( $facet = $this->getFacet($data); return $app["twig"]->render("demo2.html.twig", array("facet" = > $facet, "data" => $data)); soukromá funkce getFacet($originalData) ( $facet = array(); $data = \Pinq\Traversable::from($originalData); // 3 různé příklady vytvoření objekty aspektů a vrátí aspekty $filter1 = new \classFacet\Facet($data, "autor", "F"" $filter2 = new \classFacet\Facet($data, "title", "S", 6) ; $filtr3 = new \classFacet\Facet($data, "cena", "R", 10) $filter1->klíč] = $filtr1->getFacet(); ); $fazeta[$filtr3->klíč] = $filtr3->getFacet();

V metodě getFacet() provádíme následující:

  • Převeďte původní data na objekt Pinq\Traversable pro další zpracování
  • Vytváříme tři aspekty. Aspekt 'autor' se seskupí podle pole autora a implementuje seskupení podle celého řádku; aspekt 'název' - podle pole názvu se seskupením podle části řádku (po prvních 6 znacích); aspekt 'cena' - podle pole ceny se seskupením podle rozsahu (v krocích po 10)
  • Nakonec extrahujeme aspekty a vrátíme je do funkce test2, aby mohly být výstupem do šablony pro zobrazení

Výstupní aspekty a filtrovaná data

Ve většině případů se filtry zobrazí jako čára a dovedou vás k zobrazení filtrovaného výsledku.

Již jsme vytvořili trasu ("demo2/facet/(key)/(value)") k zobrazení výsledků vyhledávání a filtrování odkazů.

Trasa má dva parametry v závislosti na klíči, který je filtrován, a hodnotě tohoto klíče. Funkce test3, která je svázána s touto cestou, je zobrazena níže:

Test veřejné funkce3($app, $originalData, $key, $value) ( ​​​​$data = \Pinq\Traversable::from($originalData); $facet = $this->getFacet($data); $filter = null; if ($key == "autor") ( $filter = $data ->where(funkce($row) use ($value) (​return $row["author"] == $hodnota; )) ->orderByAscending( function($row) use ($key) ( return $row["price"]; )) ) elseif ($key == "cena") ( ... ) else //$key== title ( .. . ) return $app["twig"]->render("demo2.html.twig", array("facet" => $facet, "data" => $filter) )

V podstatě v závislosti na klíči aplikujeme filtrování (anonymní funkce v příkazu where) podle předané hodnoty a získáme následující sadu filtrovaných dat. Můžeme také nastavit pořadí filtrování dat.

Nakonec zobrazíme nezpracovaná data (spolu s filtry) v šabloně. Tato cesta používá stejný vzor, ​​jaký jsme použili v "demo2".

Panel vyhledávání

    (% pro k, v ve fazetě %)
  • ((k|velká písmena))
    • (% pro vv v %)
    • ((vv.count))((vv.key))
    • (%endfor%)
    (%endfor%)

Musíme si pamatovat, že aspekty generované naší aplikací jsou vnořená pole. Na první úrovni se jedná o pole všech aspektů a v našem případě jsou tři (u autora, názvu, ceny).

Každý aspekt má pole klíč–hodnota, takže jej můžeme iterovat pomocí běžných metod.

Všimněte si, jak vytváříme adresy URL pro naše odkazy. Jako parametry pro cestu ("demo2/facet/(key)/(value)" používáme jak klíč vnější smyčky (k), tak klíč vnitřní smyčky (vv.key). Pro zobrazení v šabloně se používá velikost polí (vv.count).

První obrázek ukazuje původní soubor dat a druhý obrázek je filtrován podle cenového rozpětí od 0 do 10 $ a seřazený podle autora.

Skvělé, dokázali jsme v naší aplikaci simulovat fasetové vyhledávání!

Před uzavřením tohoto článku se musíme naposledy podívat na náš příklad a určit, co lze zlepšit a jaká máme omezení.

Možná vylepšení

Obecně se jedná o velmi základní příklad. Právě jsme prošli základní syntaxi a koncepty a implementovali je jako pracovní příklad. Jak již bylo řečeno, máme několik oblastí, které by mohly být vylepšeny pro větší flexibilitu.

Potřebujeme implementovat „překryvná“ vyhledávací kritéria, protože aktuální příklad nás omezuje na možnost použít filtrování vyhledávání pouze na původní soubor dat, nemůžeme použít fasetové vyhledávání na již filtrovaný výsledek. To je největší zlepšení, jaké si dokážu představit.

Omezení

Hledání faset implementované v tomto článku má vážná omezení (která se mohou týkat i jiných implementací hledání faset):

Pokaždé načítáme data z MySQL

Tato aplikace používá rámec Silex. Stejně jako u jakéhokoli rámce s jedním vstupním bodem, jako je Silex, Symfony, Laravel, je jeho soubor index.php (nebo app.php) volán pokaždé, když je analyzována trasa a jsou vykonávány funkce ovladače.

Pokud se podíváte na kód v našem index.php, všimnete si, že následující řádek kódu:

$demo = new pinqDemo\Demo($app);

je voláno při každém vykreslení stránky aplikace, což znamená, že se pokaždé provedou následující řádky kódu:

Ukázka třídy ( private $books = ""; veřejná funkce __construct($app) ( $sql = "vyberte * z book_book order by id"; $this->books = $app["db"]->fetchAll($sql ;

Bude lepší, když nebudeme používat framework? Navzdory skutečnosti, že vývoj aplikací bez frameworků není dobrý nápad, mohu říci, že narazíme na stejné problémy: data (a stav) nejsou zachována mezi různými požadavky HTTP. To je základní charakteristika HTTP. Tomu se lze vyhnout použitím mechanismů ukládání do mezipaměti.

Některé jsme zachránili SQL dotazy pomocí aspektů. Namísto předání jednoho výběrového dotazu k načtení dat a tří seskupených dotazů s odpovídajícími klauzulemi where jsme spustili pouze jeden dotaz where a použili PINQ k získání agregovaných informací.

Závěr

V této části jsme implementovali možnost fasetového prohledávání sbírky knih. Jak jsem řekl, toto je jen malý příklad, který má prostor pro zlepšení a který má řadu omezení.

Facetová navigace je problémem všech internetových obchodů. Nadměrný počet stránek, které se používají pro různé varianty stejného prvku, představuje hrozbu pro efektivitu vyhledávání. To může negativně ovlivnit SEO a uživatelskou zkušenost. Odborníci z blogu SEO Hacker vysvětlili, co je fasetovaná navigace a jak ji vylepšit.

Faceted Navigation: Definice

Tento typ navigace se obvykle nachází na postranních panelech webů elektronického obchodu a obsahuje filtry a fazety – parametry, které si uživatel nastavuje podle potřeby. umožňuje zákazníkům internetového obchodu vyhledat produkt, který chtějí, pomocí kombinace atributů, které budou produkty filtrovat, dokud uživatelé nenajdou to, co potřebují.

Fazety a filtry se od sebe liší. Zde je rozdíl:

  • Fazety jsou indexované kategorie. Pomáhají zpřesňovat seznamy produktů a fungují jako rozšíření základních kategorií. Fazety přidávají jedinečný význam každé volbě, kterou uživatel udělá. Vzhledem k tomu, že jsou aspekty indexovány, musí do vyhledávače posílat relevantní signály a zajistit, aby stránka obsahovala všechny důležité atributy.

  • Filtry se používají k řazení a zpřesňování položek v seznamech. Jsou nezbytné pro uživatele, ale ne pro vyhledávače. Filtry nejsou indexovány, protože nemění obsah stránky, ale pouze třídí v jiném pořadí. Výsledkem je duplicitní obsah více adres URL.

Potenciální problémy

Každá možná kombinace faset má svou vlastní jedinečnou adresu URL. Z pohledu SEO to může způsobit určité problémy. Zde jsou ty hlavní:

  • Duplicitní obsah.
  • Plýtvání rozpočtem na skenování.
  • Odstraňte rozdíly mezi odkazy.

S růstem vašeho webu roste i počet duplicitních stránek. Příchozí odkazy mohou směřovat na různé duplicitní stránky. To snižuje hodnotu odkazů a omezuje schopnost stránek hodnotit.

Zvyšuje se také pravděpodobnost kanibalizace klíčových slov. Více stránek se pokouší o hodnocení pro stejná klíčová slova, což má za následek méně konzistentní a nižší hodnocení. Tomuto problému by se dalo předejít, kdyby bylo každé klíčové slovo zacíleno pouze na jednu stránku.

Facetová navigační řešení

Při výběru řešení pro fasetovou navigaci zvažte svůj konečný cíl: zvýšit počet indexovaných stránek nebo snížit počet stránek, které indexovat nechcete. Zde jsou některá řešení, která pro vás mohou být užitečná:

AJAX

Pokud používáte AJAX, nová adresa URL se nevytvoří, když uživatel klikne na fasetu nebo filtr. Protože nebudou existovat žádné jedinečné adresy URL pro každou možnou kombinaci aspektů, problém duplicitního obsahu, kanibalizace klíčových slov a zbytečných nákladů na indexování je potenciálně eliminován.

AJAX může být účinný pouze před spuštěním webu elektronického obchodu. Nepoužívá se k řešení problémů stávajících zdrojů. Tato metoda také vyžaduje určité výdaje z vaší strany.

značka noindex

Značka noindex se používá k tomu, aby robotům řekla, aby vyloučili konkrétní stránku z indexu. Tímto způsobem se nezobrazí ve výsledcích vyhledávání Google. To pomáhá snížit množství duplicitního obsahu, který se objevuje v indexu a výsledcích vyhledávání.

To nevyřeší problém s rozpočtem procházení, protože roboti budou vaši stránku stále navštěvovat. Také to nepomáhá distribuovat hodnotu odkazů.

Atribut rel=canonical

Pomocí tohoto atributu sdělujete Googlu, že máte jednu hlavní preferovanou stránku k indexování a hodnocení a všechny ostatní verze obsahu z této stránky jsou pouze duplikáty, které není třeba indexovat.

Sofie Ibragimová

Content Marketer

Pokud se na stejnou stránku na vašem webu dostanete z více adres URL, vyhledávací roboti budou každou adresu URL považovat za samostatnou stránku. Boti usoudí, že obsah na vašem webu není jedinečný, a to negativně ovlivní hodnocení a sníží vaši pozici ve výsledcích vyhledávání. Abyste tomu zabránili, určete hlavní kanonickou stránku vložením následující sekvence znaků do bloku HEAD:

K vyřešení problému duplicitního obsahu můžete použít kanonické stránky a odkaz pro sdílení bude sloučen s vaší hlavní stránkou. Existuje však šance, že roboti budou stále procházet duplicitní stránky, což je plýtvání rozpočtem na procházení.

Robots.txt

Zavření některých stránek z indexování vám umožní dosáhnout dobrých výsledků. Jedná se o jednoduchý, rychlý a spolehlivý způsob. Nejpohodlnější je nastavit vlastní parametr pro určení všech možné kombinace fasety a filtry, které chcete blokovat. Uveďte jej na konec každé adresy URL, kterou chcete skrýt (http://úplná adresa stránky/robots.txt), nebo použijte metaznačku Robots v oblasti HEAD kódu stránky.

Při provádění změn adresy URL mějte na paměti, že robotům trvá 3–4 týdny, než si těchto změn všimnou a zareagují na ně.

I zde jsou určité problémy. Hodnota odkazů bude omezená a blokovaná adresa URL může být indexována kvůli přítomnosti externích odkazů.

Google Search Console

Je to skvělý způsob, jak dočasně vyřešit své problémy, zatímco pracujete na vytváření lepšího a uživatelsky přívětivějšího navigačního systému. Můžete použít konzoli Vyhledávání Google sdělit vyhledávači, jak procházet vaše stránky.

  • Přihlaste se účet konzole a vyberte sekci „Procházení“:

  • Klikněte na tlačítko „Parametry URL“:

  • Uveďte, jaký dopad bude mít každé z vašich nastavení na stránku a jak chcete, aby Google s těmito stránkami zacházel.

Pamatujte, že tato metoda skryje pouze duplicitní obsah před prohledávači Google. Stránky se budou stále zobrazovat v Bingu a Yahoo.

Jak zlepšit fasetovou navigaci

Podívejme se krátce na všechny metody, které vám umožňují vytvořit správnou fasetovou navigaci:

  • Pomocí AJAX
  • Odstraňte nebo skryjte odkazy na kategorie nebo filtrujte stránky, na kterých chybí obsah.
  • Povolit indexování určitých kombinací aspektů, které mají vysoký objem vyhledávání
  • Nastavení hierarchie webu pomocí drobečkové navigace v kategoriích a podkategoriích.
  • Vytváření kanonických (hlavních) stránek pro duplicitní obsah.
  • Konsolidujte vlastnosti indexování z dílčích stránek v celé řadě pomocí označení stránek pomocí rel="next" a rel="prev" .

Závěr

Každé ze zmíněných řešení má své výhody a nevýhody. Univerzální řešení neexistuje, vše závisí na specifikách vašeho podnikání a konkrétním případu. Optimalizovaná fasetová navigace umožní vašemu webu cílit na širší škálu klíčových slov. Abyste se vyhnuli riziku, ujistěte se, že navigace nejen splňuje požadavky vyhledávacích robotů, ale také poskytuje dobrou uživatelskou zkušenost.

Inteligentní filtr nebo Faceted search je filtr podle kategorie produktů, který lze vidět ve velkých internetových obchodech a na stejném trhu Yandex. Pomáhá vám konzistentně třídit produkty pro uživatele nezbytné vlastnosti, odplevelení všeho nepotřebného. Jedná se o velmi pohodlnou možnost, která vám umožní rychle najít požadovaný produkt nebo materiál na webu.

A tak přejděme přímo k instalaci a konfiguraci modulů, které potřebujeme

Nejprve si budeme muset stáhnout a nainstalovat následující moduly: Search API, Search API Database Search, Entity API a Views.

Na stránce modulů povolíme:

  • Search API
  • Vyhledávání zobrazení
  • Vyhledávání v databázi
  • Entity API
  • Pohledy
  • Zobrazení uživatelského rozhraní
  • Ctools

Vytvoření vyhledávacího serveru

Pojďme na Konfigurace > Vyhledávání a metadata > Search API(/admin/config/search/search_api) a klikněte Přidat server.
Poté zadejte název serveru do rozevíracího seznamu Servisní třída vybrat Databázová služba a uložit.

Vytvoření indexu

Pojďme na Konfigurace > Vyhledávání a metadata > Search API(/admin/config/search/search_api), klikněte Přidat server (Přidat index).
Do pole zadejte název indexu Typ položky (typ položky) vybrat ‘ Materiál‘, v terénu Server vybrat Databázový server, klikněte Vytvoření indexu.


Ve formuláři, který se otevře, zaškrtněte políčka, podle kterých se bude řazení provádět, a uložte.
Abyste mohli třídit podle názvu uzlu, zapněte název a v rozevíracím seznamu vyberte typ naproti němu řetězec, ne plný text. Nelze třídit podle fulltextu.

V dalším formuláři, který se otevře Filtry(pracovní postup) Vše jsem nechal jako výchozí, přejděte na kartu Pohled (Postavení) a stiskněte Indexujte nyní (Indexujte nyní).
Po dokončení indexování vytvoříme vyhledávací stránku.

Vytvoření vyhledávací stránky

Pojďme na Struktura > Pohledy a klikněte Přidat nový pohled (Přidat nový pohled).
V novém zobrazení v rozevíracím seznamu Show (Show) vyberte index, který jsme dříve vytvořili, vyplňte zbývající pole (jméno, název a cestu), jak potřebujete.


Dále klikněte Uložit a nakonfigurovat(Pokračovat a upravit) Nastavte zobrazení jako obvykle. Do filtrovacích kritérií jsem přidal zobrazování pouze publikovaných materiálů a požadovaný typ uzlu a nakonfiguroval zobrazení potřebných polí (tato pole je potřeba přidat do indexu, abyste podle nich mohli filtrovat).

V této fázi jsme s nastavením pohledu hotovi; nyní se přesuneme přímo k filtru faset.

A/search_api_ranges.module +++ b/search_api_ranges.module @@ -144,11 +144,8 @@ funkce search_api_ranges_minmax($variables, $order = "ASC") ( // jinak by se naše min/max vždy rovnalo uživateli vstup. $filtry = &$query->getFilter()->getFilters(); - if (is_array($filter)) ( - if ($filter == $proměnné["pole_rozsahu"] || ($filter != $proměnné["pole_rozsahu"] && $filtr == "")) ( - $ current_filter = $filtry[$klíč] + if(isset($filter->tags) && is_array($filter->tags))( + if(in_array("facet:".$variables["rozsah_pole"], $); filter->tags))( unset($filters[$key]); ) )

Patching JQuery UI Slider: nastavení přesměrování

Ve verzi 7x-1.5 modulu jsem se setkal s tím, že pokud se slider widget nacházel na jiné stránce než na stránce vyhledávání, tak po změně cenového rozpětí došlo k přesměrování směru na aktuální stránku, nikoli na vyhledávání strana.
Chyba je ve funkci search_api_ranges_block_slider_view_form_submit()(soubor search_api_ranges.module, řádek 364).
Opravdu jsem nezkoumal, co tam je a proč, jen jsem trochu změnil kód na řádku 427:

Drupal_goto($path, array("query" => array($params), "language" => $language)); + drupal_goto($values["cesta"], array("dotaz" => pole($params), "jazyk" => $jazyk));

po kterém byl problém vyřešen.

© 2024 ermake.ru -- O opravě PC - Informační portál