ugrás a tartalomhoz

Átirányítás: .htaccess vagy php?

doit · 2018. Már. 6. (K), 22.20
Sziasztok,

Új weboldalnál szeretném az alábbi dolgokat megvalósítani:
- friendly url használata
- non-www elérés kikényszerítése
- https elérés kikényszerítése
- trailing slash kezelése (eltávolítása)
- multiple slash kezelése (eltávolítása)

Ami rendelkezésemre áll:
- htaccess
- php
- canonical link

Napok óta olvasom a témába vágó cikkeket, de ahelyett, hogy egyszerűsödne a képlet, egyre több kérdés merül fel bennem. A cél az lenne, hogy minél kevesebb átirányítás történjen és SEO ügyileg rendben legyen az oldal. Friendly URL nem kérdés, oda kell htaccess és php is.

Amit kérdezni szeretnék:
1. Melyik szabályozásra mit érdemes használni? (Mit hol érdemes kezelni?)
2. Érdemes egyáltalán foglalkozni pl. a multiple slash problémával? Néhány helyen úgy láttam, hogy javítják (301) és betöltik a tartalmat, máshol meg 404-et dobnak rá.
3. Ha a non-www és https kikényszerítése nem htaccess szinten történik, nem lesz duplicate content minden létező img/css/stb. fájl?
4. Azt olvastam, hogy minél bonyolultabb/hosszabb egy htaccess fájl, annál jobban lassít(hat)ja a szerveren található fájlok betöltését. Ez vonatkozik a statikus tartalmak betöltési idejére is (font, css, img) is?

Minden segítséget köszönök előre is.
‹ PHP utf-8 enter probléma URL dekódolás ›
 ■
1

redirect + rewrite

Pepita · 2018. Már. 6. (K), 23.00
Azt gondolom, a legfontosabb ebben, hogy teljesen tisztában legyél a rewrite és a redirect közti különbséggel.
Ha valamit meg lehet oldani rewrite-al (friendly URL pl), azt oldd meg.
Minél kevesebb redirect, annál jobb.
SEO URL pofon egyszerű:
<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteCond $1 !^(index\.php|public|favicon\.ico)
  RewriteRule ^(.*)$ index.php?$1 [L]
</IfModule>
Amiben nem szerepel index.php, public (könyvtár) vagy a favicon, azt mind dolgozza csak fel az index.php illetve a keretrendszer routingja.
SEO ügyileg rendben legyen az oldal
Ehhez kimondottan SEO szaki (is) kéne, feltéve, ha van rá sok lóvé is..

1.: Rewrite és állandó átirányítás (nem túl sok) jobb, ha Apache (vagy nginx), mert többnyire gyorsabb, mint php-ból.
2.: Szerintem nem. Azért gondolom, mert néhány keretrendszer kitakarítja routing során, átirányítás nélkül. Szerintem "nem jár érte" SEO hibapont.
3.: non-www: egyszerűen nem veszed fel a www aldomaint. 2018-at írunk... Sima 404 a www-re. SSL-t szintén célszerű a webszerverre bízni. Nem lesz duplikált content, mert más a protokoll.
4.: Nyilván jobban terheli a kiszolgálót, de - többnyire - kevésbé, mintha ugyanazt php-ból követed el. Persze azért ne az üzleti logikát akard htaccess-be "leprogramozni". Static betöltési időt nem kéne, hogy lényegileg befolyásolja, ha igen, akkor ott már túl sok mindent szerettél volna kiszolgáló szinten megoldani. Ha ilyen problémába ütköznél, akkor az a projekt meghal már nagyon kevés egyidejű látogatónál is, tehát valami nagyon nem kerek.

Összességében egy elég nagy rendszer htaccess-e (nginx.conf-ja) sem több pár tíz sornál, és ebben már benne van az is, hogy esetleg többféle szolgáltatást különböző domainen szolgál ki egyetlen alkalmazás... :)

SEO "szagú" válaszaimhoz hozzá tartozik, hogy élesben nem up to date a tapasztalatom, egy ideje nem foglalkoztam olyan projektel, aminek számítana.
2

404 a www-re?

_subi_ · 2018. Már. 7. (Sze), 01.10
A 3-as pontra ez elfogadhatatlan "megoldás". A http-t szépen https-re kell irányítani, míg a www-t a www nélküli domain-re (vagy fordítva, attól függően, melyiket preferálja). És mindezt a vhost fájlokban érdemes megtenni és nem htaccess-el megoldani.

Rögtön nem lesz se duplikált tartalom (hiszen csak egy domain lesz), rögtön biztonságosabb lesz az oldal (csak https), és persze akár http-t, akár www-t ír a látogató a böngészősávba, célba ér. Ez sem mellékes szempont.

Persze azt is írta a kérdező, hogy a htaccess áll a rendelkezésére (és ebből következően esetleg a vhost bejegyzéseket nem tudja szerkeszteni), de akkor meg azzal kell megoldania mindezt. A 404 dobás a www-re elfogadhatatlan. Nem hiszem, hogy csak azért, mert 2018-at írunk, elfogadható lenne a látogatók egy részének az elvesztése.
3

Nem veszted el

Pepita · 2018. Már. 7. (Sze), 10.12
Előrebocsátom, hogy noha nem írtam, de feltételeztem, hogy új projektről van szó.
Legtöbb böngészőben van beállítva keresőmotor, és mivel ez default beállítás, többnyire mindenkinél működik is.
Tehát arra gondolok - ha félreérthető volt -, hogy létre se hozod a www-s aldomaint. Tehát ezt rosszul írtam: "Sima 404 a www-re", mert ha nincs az aldomain, sikertelen lesz a DNS feloldás is.
Ekkor jön képbe a beállított keresőmotor: szépen megtalálja a www nélküli domained (tartalmát) és beajánlja az elsők között a usernek.
Bekerül history-ba, legközelebb már címsávban ajánlja a javítást.
Nem hinném, hogy számottevő látogatót buknál el ezzel, új projektet én már évek óta így csinálok.
Persze ha valakinek ki van kapcsolva mindenféle kereső szolgáltatás, az lehet, hogy nem fog megtalálni téged, hacsak rá nem jön magától, hogy www nélkül próbálja meg. Szerinted hány ilyen ember van? :)

vhosts és egyéb confokat nem írt a kérdező, lehet, hogy valamilyen shared hosting, akkor nem fér hozzá.
Van bármiféle különbség Apache alatt vhosts.conf és docroot/.htaccess között akár sebességben / bármi másban?

Meglévő domain esetében persze nem ilyen egyszerű kivezetni a www-t, de az sem lehetetlen, megfelelő státuszkóddal kell átirányítani jó ideig (301 - Moved Permanently), aztán amikor a keresők "megszokták", le lehet venni véglegesen.
4

Káros

Hidvégi Gábor · 2018. Már. 7. (Sze), 10.32
Egy új szolgáltatásnál minden látogató számít, bár meglévőnél is, mert a mai nulla kamatszintek mellett bankban nem éri meg pénzt tartani, így célszerű, hogy ha már csinálunk valamit, az a lehető legtöbbet hozza.

A <link rel="canonical"> segítségével nem kerül semmibe, hogy a kereső egy oldalt www-vel és www nélkül is ne duplikált tartalomként kezeljen.

A web egyik alaptörvénye, hogy a kliens undefined, azaz nem tudod, hogy miben nyitják meg. Nem tudod, hogy van-e benne az az átirányítás, amit te feltételezel, nem tudod, hogy bekapcsolt javascripttel használják stb. Tehát célszerű minden eshetőségre felkészülni.

Emiatt az ötleted, hogy ne is vegyék fel a www-t a DNS-be nem csak szakmailag megalapozatlan, hanem a felhasználó és a weboldal tulajdonosának számára káros.
5

Ez azért fura

Pepita · 2018. Már. 7. (Sze), 10.55
Emiatt az ötleted, hogy ne is vegyék fel a www-t a DNS-be nem csak szakmailag megalapozatlan, hanem a felhasználó és a weboldal tulajdonosának számára káros.
Nemigazán az én ötletem... Az említett www kivezetést egy elég komoly SEO cég javasolta egy ügyfelünknek (kb 4 éve történt), több lépésből állt, de végül megduplázta a keresőből az oldalra jövők számát, és tartotta is stabilan a helyét. Ugyanők javasolták nekünk, hogy új projektnél ne vegyük fel a www-t.
Tekintve, hogy láttam (csináltam) a konkrét példákat és pozitív tapasztalat volt, ügyfelek is elégedettek voltak, így ez a mondatod teljesen hamis.

4 év alatt persze sokat változhatott a SEO világ, és mint jeleztem kb 2 éve engem nemigazán érint, de nem gondolnám, hogy ezalatt az idő alatt jött volna vissza a "divatba" a www.
6

látogatóvesztés

_subi_ · 2018. Már. 7. (Sze), 11.46
Ha csak a látogatók (adott esetben potenciális vásárlók) 5%-át bukod, az is 5% veszteség, de szerintem sokkal többen vannak, akik bepötyögik a www-t, és ámulva csodálkoznak, ha www nélkül írod be, és akkor is bejön a honlap.

De ezt magyarázni kell? Ezen őszintén szólva csodálkozom.

Az állítólag komoly SEO cég, állítólagos tette a www elhagyását illetően maximum arra bizonyíték, hogy még a látszólag komoly cégeknél is lehetnek hülyék. Nagyon jó, hogy állítólag megduplázták a honlap forgalmát. De képzeld csak el, az milyen szuper lett volna, ha a duplázás mellé még nyernek további 5-15% látogatót! :)
8

Látogató != vásárló

Pepita · 2018. Már. 7. (Sze), 12.46
Bocsi, de -5% látogató korántsem -5% forgalom. Nem mindegyik látogató vásárol és pláne nem ugyanannyiért.
De ezt magyarázni kell?
Nem, nem kell, személyes ismeretségi körömben is van jópár nagymami, akik épp csak odamerészkednek ülni a "masina" elé, szóval van fogalmam róla. Közülük kb a fele azt se tudja, mi az a www...

állítólag megduplázták a honlap forgalmát
Nem állítólag, és nem az összes forgalmat. Gugli első 10-ben szereplések számát és gugliból érkező napi látogatók számát kb duplázták az ötleteik. Biztos volt még rengeteg féle statisztikai eredmény, ezek engem nemigazán érdekeltek akkor sem, mert elsősorban én fejlesztő vagyok, nem SEO szaki.

milyen szuper lett volna, ha a duplázás mellé még nyernek további 5-15% látogatót!
Egy webshopban (és sok más vonalon is) nem a látogató hoz pénzt, hanem a vásárló. Ma már (és nem pont tegnaptól) vajmi kevés a sikeres üzlethez a sok látogató. El kell érned azt is, hogy vásároljon. Ha csak (szerinte) tévedésből vetődött oda, az neki negatív élmény a cégedről.
A legtöbb ilyen jellegű döntésnél nincs lehetőség statisztikát gyűjteni a másik lehetőségről, hogy "mi lett volna, ha". Kár is emiatt bárkit is hülyézni. Szerintem ezek a fontosak:
- Az ügyfeled megbízik egy ilyen 3. céget, akkor ez van, neked alkalmazkodni kell, ha szembe kerültök, akkor is az ügyfeled dönt, mi fog történni a shopjával / alkalmazásával.
- A SEO-s leír javaslatokat jópénzé' + ÁFA, ügyfeled eldönti, hogy miket kell belőle megvalósítani.
- Te ezeket megvalósítod vagy megbíz vele mást.
- Ügyfeled kifizeti neked a kért fejlesztéseket.
- Ügyfeled / Te leméritek a változásokat.
- Ha minden jól ment, üf elégedett veled és holnap is lesz munkád.
- Ha mégjobban ment, akkor igaza volt a SEO szakinak és a forgalom (pénzben) is nőtt.

Webshopoknál sose szabad azt se elfelejteni, hogy többnyire vannak más "versenyzők" is ugyanabban a kategóriában, szóval az ő szereplésüktől / változtatásaiktól ugyanannyira függ a te forgalmad is, mint a saját fejlesztésektől. Szóval nagyon nehéz megmondani egy konkrét fejlesztés százalékos hatását akár csak a látogatók számát tekintve is..
Épp ezért jelen pillanatban én már le is ...rom, hogy most jó a www vagy nem, ha üf kéri, kap, nem kéri, nem kap. :)

Azért annyi érdekelne, hogy jelenleg gugli tesó mit "mond" erről, "szereti" ha van www vagy nem.
Elég sok olyan igyekezetet / hitet / tévhitet láttam már, amiről később kiderült, hogy évek óta nincs jelentősége (pl. keywords is ilyen volt asszem), vagy akár soha nem is volt jelentősége. Sok pici (SEO) cég igyekszik "megoldani okosba" - én sose preferáltam a "gugli kedvéért" létrehozott tartalmat / feature-t. Legtöbb esetben gugli is lefejleszti idővel a saját algoritmusát ezek ellen, és akkor jön a sok bünti.. :)
11

utolsó segítség

_subi_ · 2018. Már. 7. (Sze), 12.50
Nem olvastam végig a mellébeszélésed, de a helyes válasz ilyenkor az, hogy elismered az orbitális tévedésedet.

Egy további - és egyben utolsó - mankó, hogy ne ess el, amikor a weben jársz:
Make your page work for both
14

Még mindig nem

Pepita · 2018. Már. 7. (Sze), 13.35
látom, hogy hol van az az "orbitális tévedésem", lehet kicsit érthetőbben kéne vitatkozni róla, én nem beszéltem mellé.
Köszi a linkelt 3 mondatot, látom Mozzilla egy véleményen van veled, ezért tettem egy próbát. Most én vagyok a Manyika néni.
"Szűz" Opera 51.0, gyári beállításokkal.
Beírtam, hogy www.{peldadomain}.hu, olyan címen, ahol tudom, hogy nincs www.
Erre ez a ... böngésző megjeleníti gond nélkül az oldalt, a címsávban pedig kiszürkíti a www-t. :-D
Bakker, milyen gagyi...
Na de tekintve, hogy ez egy shared hostingon lakik, lehet ott olyan beállítás, amiről nem tudok, ezért tettem még egy próbát.
Ezúttal kicsit bonyolultabb, eleve aldomainen lévő oldal, szintén nincs www-s megfelelője, másik szolgáltató hosting.
Tehát www.{aldomain}.{peldadomain}.hu
Oldal nem jelenik meg, helyette a (Google) kereső találati listája, melyben az első 6 db találat a keresett oldal...
Hoppá, itt vettem észre, hogy a hu elé vesszőt írtam véletlenül, ha pontra javítom, akkor ugyanaz, mint az első esetben.

Ez alapján azt gondolom, hogy a mellébeszélés az, hogy látogatót bukok ha nincs www...
Több böngészőben / több oldalon nincs kedvem most ezt próbálgatni.
15

te ezt gondolod...

_subi_ · 2018. Már. 7. (Sze), 14.00
Ez alapján azt gondolom, hogy a mellébeszélés az, hogy látogatót bukok ha nincs www...


Te ezt gondolod. A valóságban nem lehet semmilyen elvárásod a látogatóval vagy az általa használt böngészővel kapcsolatban.

Azért az valami egészen ijesztő, hogy a Mozillánál is kompetensebbnek gondolod magad...
16

Csak kipróbáltam :)

Pepita · 2018. Már. 7. (Sze), 14.12
Nem gondolom magam okosabbnak, pláne tapasztaltabbnak náluk, ezért próbáltam ki. :)
Az oldal utolsó frissítési idejét azonban nem láttam, továbbá - és ezzel le is zárnám a dolgot - az összegyűlt infók alapján azt mondanám, hogy ártani valószínűleg semmit nem árt, ha van www, az, hogy használ-e valamit vagy ártana a hiánya - hát ezt döntse el mindenki, mennyit akar rá áldozni.

A valóságban nem lehet semmilyen elvárásod a látogatóval vagy az általa használt böngészővel kapcsolatban.
Nem is volt. Pontosan ezért használtam szűz böngészőt, mert nem várom el senkitől sem, hogy bármit állítgasson rajta.
Ha van kedved, csinálj nagyobb statisztikát, ugyanerről.
18

Böngésző

Hidvégi Gábor · 2018. Már. 7. (Sze), 14.46
Ha akarsz, utánajárhatsz, hogy az Androidos mobillal rendelkező emberek 50%-a (20+30) L és M verziót használ, azaz legalább három éves az operációs rendszerük.

Mi garantálja, hogy ők a legújabb böngészőkkel szörföznek a világhálón?
19

1.5.28

Pepita · 2018. Már. 7. (Sze), 15.07
Épp volt kéznél fenti verziójú android böngésző, ugyanezt az eredményt produkálta, bár kicsit csúnya, hogy nem lett szürke a www. :)
Mi garantálja, hogy a 3+ éves mobil böngészőkkel látogatót veszítek?
Kérlek mutass egy példát, amelyik (akár mobil, akár asztali) böngészővel "eltéved", akkor annak függvényében (mennyien használnak olyat) van miről beszélni.

Kicsit kezd olyan érzésem lenni, hogy ez a www dolog is egy - egyébként a mi szakmánkban rendkívül káros - fixed mindset. Egyszer megtanultuk, beégett, és képtelenek vagyunk levetkőzni...
Egyelőre ez csak érzés, de mivel még nem sikerült reprodukálni a látogatóvesztést, egyre valószínűbb, hogy jogos.
12

Veszteség

Hidvégi Gábor · 2018. Már. 7. (Sze), 12.52
Honnan tudod, hogy az az elvesztett pár százaléknyi ember az nem potenciális vevő?

Mivel tényleg nem kerül semmibe betenni a <link rel="canonical">-t, ezért képtelen vagyok felfogni, hogy miért jó neked az elképzeléseden rugózni? Hisz az általad javasolt megoldással mindenképp veszít a honlap gazdája?

Ha pedig saját bevallásod szerint sem foglalkozol a témával már jóideje, akkor végképp nem értem, amit művelsz.
13

Nem tudom

Pepita · 2018. Már. 7. (Sze), 13.13
Honnan tudod, hogy az az elvesztett pár százaléknyi ember az nem potenciális vevő?
Nem tudom. Ahogyan azt sem, hogy vevő. Az világos, hogy ha oda se téved, akkor esélye sincs vásárolni, de az odatalálásban nem hinném, hogy akkora szerepe van a www-nek (már).
miért jó neked az elképzeléseden rugózni?
Nem jó nekem. Ha valami félre ment, akkor elnézést kérek. Leírtam egy megtörtént esetet, amiből én levontam a szerintem logikus következtetéseket.
Komolyan érdekelne már, feketén - fehéren (Pepitába' :) ), hogy most akkor tényleg ennyire Isten vagy legalábbis gugli ellen való vétek, ha nincs www-d?
Az a rész nem győzött meg, hogy a Manyika néni nem találja meg kézzel, mert a Manyika néni helyett megtalálja a keresője.
Az érdekel, hogy gugli díjazza-e +/- irányba, hogy van vagy nincs.
Csak azért, mert nem biztos, hogy a jövőben se fogok ilyennel foglalkozni.
17

nem hinném, hogy akkora

Hidvégi Gábor · 2018. Már. 7. (Sze), 14.42
nem hinném, hogy akkora szerepe van a www-nek
Ez üzlet, és senkit sem érdekel, hogy mit hiszel. Az viszont fontos, amit tudunk, hogy a felhasználó kliense undefined.

most akkor tényleg ennyire Isten vagy legalábbis gugli ellen való vétek, ha nincs www-d
Pepita, nem tudod vagy nem akarod felfogni, hogy üzemeltetői oldalról nem jár munkával, hogy legyen www-d is, felhasználói oldalról viszont biztosan vesztesz valamennyit, ha nincs? Itt teljesen lényegtelen, hogy a google-ban mi van, mert ha van canonical url, úgyis azt fogja használni. De sosem tudhatod, hogy egy ügyfél hogyan fog eltalálni az oldaladra, lehet, hogy hallomásból, lehet, hogy bookmarkból, lehet, hogy email-ben kap egy (esetleg hibás) linket.

A google-t nem érdekli, hogy van-e www vagy nincs. De ha van, akkor meg kell adni a html kódban a canonical url-t, különben hátrébb kerül az oldal a listában.
20

De, én akarom :)

Pepita · 2018. Már. 7. (Sze), 15.22
üzemeltetői oldalról nem jár munkával

vs
meg kell adni a html kódban a canonical url-t

Mindegy, hogy üzemeltetői vagy fejlesztői munka, kell vele foglalkozni, ha használod. Az pedig pénzbe kerül. Mivel ez üzlet és senkit nem érdekel, hogy mit hiszel, senki nem fog szívesen pénzt adni a feleslegesen végzett munkádért sem.

felhasználói oldalról viszont biztosan vesztesz valamennyit, ha nincs
Ezt próbáltam ki többször is (l. 19), és eddig csak elméleti felvetést kaptam rá vissza, azt is kipróbáltam, de konkrét példát még nem láttam rá.
Az a biztos, hogy ketten állítjátok a látogatóvesztést www hiánya miatt, de még egyikünk se tudta reprodukálni.

Mivel muszáj a canonical url (és jár érte "hibapont"), akkor egy picit mégis érdekli guglit, de nem feltétlen abba az irányba, hogy legyen www.

Pepita, nem tudod vagy nem akarod felfogni
De, akarom is és szerintem fel is fogtam, amit eddig írtatok, tényleg már csak az a fránya látogatóvesztés hiányzik...
Természetesen nem IE6 alatt, hanem legalább 5% által használt böngészőben (ha már ennyire taksáltátok a veszteséget).

Nyithatunk neki külön fórumtémát is, hogy ne ezt offoljuk teljesen szét, engem azért is érdekel továbbra is, mert tudom mekkora gondot tud okozni a fixed mindset.
21

meg kell adni a html kódban a

Hidvégi Gábor · 2018. Már. 7. (Sze), 17.07
meg kell adni a html kódban a canonical url-t

Mindegy, hogy üzemeltetői vagy fejlesztői munka, kell vele foglalkozni, ha használod. Az pedig pénzbe kerül. Mivel ez üzlet és senkit nem érdekel, hogy mit hiszel, senki nem fog szívesen pénzt adni a feleslegesen végzett munkádért sem.
Pepita, te nem vagy normális.

A html-ben egy sorról van szó, amit az ember egyszer berak a sablonba, és onnantól kezdve soha többé nem kell vele foglalkoznia, és te ezt úgy állítod be, hogy felesleges munka. Ehhez már egy bizonyos fokú kell, hogy ne tudd elismerni, tévedsz.

Megnéztem a volt munkáltatód oldalát, ott is van canonical. Akkor ők is dobják ki a pénzüket az ablakon?

Én itt most befejeztem veled mindenféle vitát, győzködj másokat, de ha lehet, ne osztogass tanácsokat olyan témában, amihez saját bevallásod szerint sem értesz.
22

De, normális vagyok,

Pepita · 2018. Már. 7. (Sze), 18.34
és baromira megköszönném, ha befejeznéd a személyeskedést.
Megnéztem a volt munkáltatód oldalát
Vagyis megnéztél egy weboltalt. Tökmindegy, kié.
egyszer berak a sablonba, és onnantól kezdve soha többé nem kell vele foglalkoznia
Feltéve, ha csak és kizárólag a www "odaragasztása" kell.

Én elismerem, hogy qrva nagy szükség van a www-re, amint látom, hogy valóban így van. Nem véletlen kérdeztem rá többször is.
Eddig egyetlen érthető indokot láttam rá tőletek, ez pedig a látogatóvesztés. Ezt kipróbáltam, invalid a félelem. Ti nem mutattátok meg, hogyan jön össze a -5% látogató, szerintem ma már bőven 1% alatt van.

ha lehet, ne osztogass tanácsokat olyan témában, amihez saját bevallásod szerint sem értesz
Azért teljesen hülye sem vagyok hozzá, és úgy tűnik egy régi beragadt fixed mindset csak, amiről vitatkozunk.

Mindezt én higgadtan, normálisan és logikus érvekkel és kérdésekkel tettem, veled ellentétben. Az nem is baj, ha nem akarsz velem vitatkozni, mert úgy tűnik erre képtelen vagy kulturált ember módján, én pedig nemigazán viselem jól, ha valaki monitor mögül emberkedik velem...
30

Nem mindig működik

vjanos · 2018. Már. 13. (K), 23.54
Lehet, hogy az Opera megtalálja az oldalt a tévesen beírt www-vel is, de éppen ma tapasztaltam, hogy a www.bachmindenkinek.hu oldalt nem találta meg a Chrome, hanem azt írta ki, hogy nem talál DNS bejegyzést. Ha töröltem a www-t, akkor megvolt az oldal. Ha simán beírtam www és hu nélkül, akkor a kereső (Google) is megtalálta első helyen.
Viszont este már a www-s verzió is normálisan működött, vagyis egyszerűen levette a www-t és a normál oldalra irányított. Gondolom .htacces-ből, de lehet, hogy php, mert valami CMS motor van mögötte.
A lényeg az, hogy rájöttek a hibájukra, és korrigálták. Nem várták meg, amig a Gizi néni valamilyen keresővel kikeresi.
Mellesleg a www-s linket levélben kaptam (ezek szerint hibásan), és elég sok linken szrepel a www, amit valamilyen plakáton, hírlevélben stb. tesznek közzé. Nem biztos, hogy szakemberek, de a lényeg az, hogy sok emberben él az a (tév)hit, hogy az internetcím www-vel kezdődik, még akkor is, ha valójában nem így van.
7

Hogy hívják?

Hidvégi Gábor · 2018. Már. 7. (Sze), 12.44
Megírhatnád annak a komoly SEO cégnek a nevét, így tudni fogjuk, hogy kit ne javasoljunk az ügyfeleinknek.
9

Engem is érdekel

_subi_ · 2018. Már. 7. (Sze), 12.46
Sőt, nem leszek lusta, még egy-két levelet is váltok velük. :)
10

Ha akarnám se

Pepita · 2018. Már. 7. (Sze), 12.50
tudnám ennyi év távlatából, de mint jeleztem, konkrét bevétel-növekedést hozott a bevonásuk és nem keveset. Ez alapján tényleg ne javasold senkinek. :)
23

Kezd tisztulni...

doit · 2018. Már. 8. (Cs), 16.17
Köszi mindenkinek a hozzászólásokat!

Bár nem akartam vitát szítani, hasznos volt megismerni a különböző nézőpontokat.

Korábban nem írtam, de jól sejtettétek, shared hostingról van/lesz szó.
Ez az oka annak, hogy csak htaccess-ig tudok nyújtózkodni.

A cél természetesen az, hogy amikor csak lehet, eljusson a felhasználóhoz a tartalom és ez minél gyorsabban történjen meg. Ezt szem előtt tartva, mi a véleményetek egy ilyen felépítésről?

www -> non-www >>> htaccess (301)
http -> https >>> htaccess (301)
friendly url >>> htaccess (rewrite)
létező oldal/cikk >>> php (200/404)
xx.hu/index.php -> xx.hu/ >>> canonical link
trailing slash >>> canonical link
multiple slash >>> canonical link
a-zA-Z >>> canonical link

Van valami buktatója, ha az egyszerűbb (mondjuk úgy, "gépelési") hibákat (trailing slash, multiple slash, nagy betű kis betű helyett) csak a keresők számára javítom ki? Így a felhasználónak max. 1 redirectet kéne kivárnia és elvileg a duplicate content kezelés is meg van oldva.
24

Nem értem

Hidvégi Gábor · 2018. Már. 8. (Cs), 17.03
A keresők a canonical url-ekkel dolgoznak. A gépelési hibát az emberek vétik, de a te scripted dolgozza fel. Ezért nem értem a kérdésed.
25

Törekvés a gyorsabb kiszolgálásra

doit · 2018. Már. 8. (Cs), 18.16
Arra gondoltam ezzel, hogy ha a címsorban hibás marad a cím, de a canonical link helyesen szerepel az oldalon, akkor a keresők felé rendben lesz az oldal és nem kell a felhasználót büntetni azzal, hogy átirányítom még egy alkalommal.
26

Igen

Hidvégi Gábor · 2018. Már. 9. (P), 08.59
Persze, nincs értelme. Sőt, most azon gondolkodom, hogy szerintem a www-re is fölösleges pont emiatt szabályt csinálni.
27

Több átirányítás

T.G · 2018. Már. 9. (P), 09.26
Miért gondoljuk azt, hogy az egynél több átirányítás káros?

Arról tudjuk, hogy ha a Google-nek mást adunk, mint a többieknek az káros. Ezt akár vehetjük ökölszabálynak is: Mindig ugyanazt adjuk a Google-nek, mint a többieknek.

Alapesetben, ha a hivatkozások jók, akkor sehol nem lesz felesleges átirányítás, ha valaki meg szándékosan megkeresi a legrosszabb url-t, akkor kap 4-5 átirányítást, ezt ne nevezzük még „büntetésnek”. Viszont, ha ő megoszt tartalmat ezután, akkor már a helyes url-t fogja ő is továbbosztani.


10 átirányítás és nem veszel észre semmit:

<?php

if (!isset($_GET{'n'})) {
    $_GET{'n'} = 0;
} elseif ($_GET{'n'} < 10) {
    $_GET{'n'}++;
} else {
    die(':)');
}

header('HTTP/1.1 301 Moved Permanently');
header('Status: 301 Moved Permanently', true, 301);
header('Location: ?n=' . $_GET{'n'});
Az általad felsorolt átirányítások többségénél nem kell még adatbázishoz sem nyúlni, nem kell előtte komoly előkészületeket tenni. Érzékelhetetlen lesz a felhasználónak, ha többször van átirányítva. Viszont mindig, mindenhol jók lesznek az url-ek. Ne ott optimalizáljunk, ahol nem kell!
28

Több átirányítás / kontra

doit · 2018. Már. 9. (P), 12.11
Hirtelen ezeket találtam...

[1] [2] [3]

Persze, ha pont erre keresek (pl. 'why avoid redirect'), akkor könnyen találok olyan oldalakat, ahol erről írnak, de a stackoverflow-n is sokszor olvastam már ilyet korábban.


"Viszont, ha ő megoszt tartalmat ezután, akkor már a helyes url-t fogja ő is továbbosztani."
Kivéve, ha ő maga írja le valahol hibásan, vagy a spell checker javítja ki.


Elképzelésem szerint... (de javítsatok ki, ha tévedek!)
- Ha a kereső felől jön a látogató, jó címet kap.
- Ha az oldal linkjeit követi, jó címet kap.
- Ha az oldal megosztás linkjeit használja, jó címet oszt meg.
- A maradék eseteket (máshol rosszul linkelték, vagy hibásan írták be a címsorba) viszont nem a linkre kattintóval akarom "megfizettetni", ha egyébként egyértelműen be tudom azonosítani, hogy hova akart menni.
29

Ne

Hidvégi Gábor · 2018. Már. 9. (P), 12.36
T.G-nek igaza van, ezen nem érdemes spórolni.
31

Oké

doit · 2018. Már. 29. (Cs), 23.01
Rendben, nem spórolok, haladjunk a "mindig ugyanazt adjuk a Google-nek, mint a többieknek" szabály mentén.

Közben én is olvasgattam és tényleg sok helyen írják azt, hogy ha megoldható, hibás cím esetén a redirect a preferált módja annak, hogy a megfelelő tartalmat adjuk a látogatónak (legyen az search engine vagy valódi felhasználó), mert a canonical link inkább amolyan ajánlás/kérés, amit egyéb tényezőktől függően akár ignorálhatnak is a keresők.

Ez eddig oké.

De hol érdemes meghúzni a határt? Azt a határt, ami megmondja, hogy mi az, amit még htaccess-ben érdemes megoldani, és mi az, amit már PHP-ben. Nincs erre valami best practice? Vagy egy feltételes elágazás alapú útmutató néhány elseif ággal? :)
32

Határ

Hidvégi Gábor · 2018. Már. 30. (P), 10.12
Általában úgy lehet venni, hogy amit lehet, .htaccess-ben érdemes megoldani, mert az gyorsabb.
33

Akkor is gyorsabb, ha több kört kell futni?

doit · 2018. Már. 30. (P), 12.32
Tegyünk fel egy olyan esetet, amikor több hiba is előfordul a címben.

Melyik a gyorsabb: 4-5 htaccess redirect vagy 1 htaccess + 1 php redirect?

Előbbi esetben talán le tudom kezelni az összes hibát (lásd 23. hsz) htaccess szinten, utóbbinál pedig csak a 'http://www.domain.hu' részt kezelné a htaccess, a request_uri pedig maradna a PHP-nak. PHP oldalon természetesen itt még semmi komolyabb művelet nincs, csak ellenőrzöm a request_uri összetételét, amire a friendly url miatt egyébként is szükség van.

És bocsi, hogy ennyit rugózok rajta, de főleg mobilos látogatókat várunk erre az oldalra és nem szívatnám őket feleslegesen. :)
34

Melyik a gyorsabb?

T.G · 2018. Már. 30. (P), 18.06
Szerintem ez összehasonlíthatatlan, de talán az a legjobb, hogy ha megpróbálod tényleg összehasonlítani:
<?php
$start = microtime(true);
file_get_contents('http://index.hu/');
$stop = microtime(true);
var_dump($stop - $start);
35

Micsoda?

Hidvégi Gábor · 2018. Ápr. 1. (V), 13.55
Ez pontosan mit bizonyít? Az az érdekes benne, hogy átdob https-re? Nem igazán lehet mérni, mert sokmindentől függ a kapott válasz sebebessége.

---

Az átirányítások a keresők és a címsorban elgépelők számára vannak, normál használat közben nincs rá igazán szükség.
36

Semmit. :)

T.G · 2018. Ápr. 2. (H), 08.43
Én bizonyítani nem szeretnék semmit. :) Kezdtem úgy, hogy szerintem ez az egész összehasonlíthatatlan. De, ha már nagyon szeretnénk bármit is összehasonlítani, mert a kérdező egyértelműen ezt szeretné, akkor ezt néhány sorral meg lehet tenni. Természetesen a példában írt hivatkozás csak egy minta, amit tetszőleges url-re ki lehet cserélni.

Szerintem az összehasonlításból az jönne ki, hogy akkora a hiba hátár, hogy ez az egész redirect optimalizálás egy felesleges valami. De ez csak az én érzésem, és nem csináltam meg az összehasonlítást, ha a kérdezőt továbbra is foglalkoztatja ez, akkor meg lehet csinálni.
37

Szerintem felesleges

Pepita · 2018. Ápr. 3. (K), 08.40
bármilyen "éles" határvonalat keresni, sokkal fontosabb az átlátható kód.
Én például .htaccess-ből / nginx.conf-ból nem szoktam url-t javítgatni, alapvetően átirányítást csak néhány fix szabály esetén használok kiszolgálóból (pl http -> https).
Az elgépelés / hibás request uri javítása szerintem már a routing feladata, ez pedig az alkalmazás egy jól körülhatárolt rétege.
38

+1 az átlátható kódra

doit · 2018. Ápr. 4. (Sze), 09.34
Ezek szerint nálad is vannak bizonyos funkciók, amiket még az alkalmazás routingja előtt végrehajtasz. Mi alapján választod külön ezeket? Erre vagyok kíváncsi.

Eddig úgy gondoltam, hogy a http -> https és www -> non-www átirányítást azért fontos még a php betöltése előtt elvégezni, hogy a szerverre feltöltött - önállóan is elérhető - elemek (pl. képek, letölthető programok, videófájlok, doksik) egyrészt ne legyenek duplikált tartalmak (lehetnek egyáltalán?), másrészt hogy ezek is csak titkosított kapcsolaton legyenek elérhetőek.
39

Mit nem írtam le pontosan?

Pepita · 2018. Ápr. 4. (Sze), 12.51
Nem értem a kérdésed, emellett valószínűleg ugyanott húzod meg a határt.
http -> https és www -> non-www

Kb ennyi, illetve pluszként egy icipici rewrite még, hogy ha a kérés nem egy bizonyos static könyvtárra mutat (ahol a css, js, kép "lakik"), akkor mindenképp az index.php kapja paraméterként.
Innentől már csak a routing (php) játszik.

SZERK:
Ezeket, amiket a kiszolgálóval valósítok meg, nem igazán hívnám funkcióknak. Azt már igen, amikor pl elgépelt URL-t próbálsz megfejteni, abban van némi funkcionalitás.