wordpress - WordPress Master

wordpress

blank
2020.06.10.
swift-performance-a-sebessegbajnok_5ee106230afd5.jpeg

A weboldalak sebesség optimalizálása ma már kötelező, ezzel valószínűleg mindenki egyetért. A folyamatos online jelenlét következtében a felhasználók egyre türelmetlenebbek és egyáltalán nem szeretnek várni. Ha egy oldal vég nélkül csak tölt és várakozik, akkor inkább bezárják és továbblépnek a következő találatra (ezzel pedig a konkurencia malmára hajtjuk a vizet). Aztán ott van még az az ugyancsak fontos tényező is, hogy a keresők bonyolult rangsorolási mechanizmusának az egyik – és egyre lényegesebb – faktora a weboldalak betöltési sebessége. Ugyanúgy, ahogy legalább egy alap ingyenes SSL tanúsítvány is kötelező manapság, fontos az is, hogy optimalizáljuk WordPress weboldalunkat a minél gyorsabb betöltés érdekében.

Ahogyan szinte minden területen, itt is könnyű elveszni a lehetőségek között. A hétköznapi WordPress felhasználó számára rengeteg bővítmény áll rendelkezésre, ezek között pedig nagyon nehéz megtalálni azokat, amelyek tényleg segítenek és hasznosak. Az internet is rengeteg anyagot és cikket tartalmaz a témában és mi is írtunk már sebesség optimalizálásról és a népszerű W3Total Cache beállításáról is. Ahogyan utóbbi cikkünkből is látszik ez a bővítmény pont az összetettsége miatt nem felhasználóbarát. Hozzáértés és megfelelő ismeret nélkül könnyedén okozhatunk vele nagyobb kárt, mint hasznot, hiszen például egy helytelenül beállított JavaScript vagy CSS összevonás/tömörítés következtében teljesen szét is eshet az oldal. A legtöbben fel is adják az első kudarcok után, mert ide sajnos nagyon sok türelem, kitartás és próbálkozás kell, hiszen minden oldal egyedi, így hiába a temérdek beállítási útmutató és cikk, senki nem fogja leírni azt, hogy mi az, amit nekünk éppen végre kell hajtanunk a saját oldalunk pontszámainak és sebességének növelése érdekében.

Mi is az tehát, amit minden felhasználó szeretne? Minél kevesebb beállítást, minél kevesebb kudarcélményt és vég nélküli próbálkozást, egy könnyen kezelhető, átlátható felületet. Egy olyan sebesség optimalizáló bővítményt, ami végigvezeti a felhasználót egy egyszerű varázsló segítségével a legfontosabb beállításokon, aztán teszi a dolgát szépen csendben a háttérben. Ennek eredményeképpen pedig az oldal szárnyra kap, a betöltési idő jelentősen csökken, a GTMetrix/PageSpeed pontszámok pedig a magasba emelkednek. Túl szépen hangzik, hogy igaz legyen? Nos, ez a valóság, ráadásul magyar vonatkozásban, ugyanis két hazai fejlesztő észrevette ezt a piaci rést és megalkották a Swift Performance névre hallgató kis bővítményt, ami valóban a felhasználó keze alá dolgozik. Jómagam már korábban is csak pozitív véleményeket olvastam róla, most azonban lehetőséget is kaptam élesben tesztelni, mégpedig itt, a WPSzaki.hu motorházteteje alatt. Elöljáróban csak annyit mondanék el, hogy végleg leváltottam a hosszú évek alatt finomhangolt W3Total Cache-t, és nem bántam meg. A tapasztalataimat és beállítási útmutatómat lentebb olvashatod.

A fejlesztők neve talán nem lesz ismeretlen, ugyanis Molnár Péter és Rigó Roland a szülőatyja a méltán népszerű Fevr WordPress sablonnak is, ezt itthon és külföldön is rengetegen használják teljes megelégedéssel. Elmondható tehát, hogy nem ma kezdték a programozást és ez a munkáikon is látszik.

Az alapok bemutatása

A bővítmény egyik legnagyobb újítása az úgynevezett kritikus CSS generálása, ez a funkció egyetlen konkurens sebesség optimalizáló pluginben sem található meg. A “Critical CSS” lényege az, hogy a plugin összeolvasztja az összes CSS-t ami az oldalon található, ezután végigmegy rajtuk, és kiválogatja azokat a CSS szabályokat, amik valóban megtalálhatóak az oldalon. Ebből lesz a “Critical CSS”, ami gyakorlatilag ahhoz kell, hogy a böngészőben megjelenjen az oldal. Mivel a sablonok/pluginek CSS fájljai sokszor olyan CSS szabályokat is tartalmaznak amiket az adott oldalon nem használ a böngésző, a renderelésig ezeket felesleges betölteni.

A Swift Performance legfontosabb funkciói a következők:

  • Teljes körű automatikus gyorsítótárazás
  • JavaScript/CSS kombinálása, és tömörítése
  • HTML tömörítése
  • Képek optimalizálása
  • Böngésző gyorsítótár beállítása
  • Gzip tömörítés beállítása
  • Szerver válaszidejének csökkentése
  • A megjelenítést gátló elemek kizárása a hajtás feletti (above the fold) tartalomban
  • Külső forrásból betöltött elemek (például JS&CSS) klónozása és helyi optimalizálása (például lejárati idők)
  • Képek szükség szerinti betöltése (lazy load)
  • CDN támogatás

A fentiek már ismerősek lehetnek, hiszen szinte minden sebesség optimalizáló bővítmény velük operál. A különbség csak ott ütközik ki, hogy ezeket milyen hatékonysággal és korlátozásokkal integrálták. A W3Total Cache ingyenes verziója például nem ad lehetőséget a hajtás feletti tartalomban lévő gátló elemek kizárására, ez pedig a PageSpeed Insights pontszámok egyik lényeges faktora. Enélkül a 100/100-as érték elérése sem lehetséges. Aztán az sem mindegy, hogy az automatikus JavaScript/CSS összevonás és tömörítés mennyire megbízhatóan működik, hiszen az átlag felhasználó nem fogja egyesével hozzáadogatni a fájlokat és kikeresni, hogy melyik az, amelyiket kivételként kell kezelni ahhoz, hogy ne essen szét az oldal. Ideális esetben ezt megoldja a bővítmény.

A Swift Performance telepítése után rögtön a beállítás varázsló átlátható felülete fogad minket. A plugin ugyan még angol nyelven kommunikál, de már készül a hivatalos magyar fordítás is. Amíg ez meg nem jelenik addig a lentebb található beállítási útmutató lehet az angolul nem tudó olvasók segítségére.

blank

A “Start Wizard” megnyomása után első lépésként a vásárláskor kapott egyedi kulcsunkat kell bemásolnunk, ezután jöhet az oldal elemzése. Még a folyamat megkezdése előtt kapunk egy aktuális PageSpeed pontszámot, ezt a varázsló futtatásának végén újra lekéri a bővítmény, így majd rögtön látni is fogjuk, hogy mennyit sikerült javítani a korábbi eredményen.

blank

blank

Ideális esetben négy zöld pipát fogunk látni. Az első az esetleges bővítmény ütközéseket figyeli (van-e másik optimalizáló plugin telepítve), a második a szükséges Apache modulok meglétét ellenőrzi, a harmadik pedig akkor jelenik meg, ha a .htaccess fájlunk írható. A fenti kép esetében ez felkiáltójeles, mert az iThemes Security Segítségével tiltottam a teszt oldalon ennek a módosítását. Az utolsó zöld pipa érvényes vásárlási kulcs megadása esetén látszik, nálam azért felkiáltójeles, mert a képek készítésekor a teszt oldalhoz nem adtam meg érvényes kulcsot.

blank

Jöhet a gyorsítótárazás “beállítása”. Alapesetben ezekhez hozzá sem kell nyúlni, hiszen legtöbbször tökéletesen megfelelő a “Time based mode”. Csak akkor lehet szükség az “Intelligent mode” kiválasztására, ha az oldalaink tartalma nagyon sűrűn változik. A kis kockákat is hagyjuk kipipálva, az első a gyorsítótár automatikus felépítését engedélyezi, a második a böngésző gyorsítótárazását kapcsolja be, a harmadik pedig a Gzip tömörítést engedélyezi. Ezek fontosak és szükségesek is a sikeres optimalizáláshoz.

blank

Jöhet a statikus tartalmak konfigurálása. A “Cache only” opció csak az oldalaink/bejegyzéseink gyorsítótárazását engedélyezi, a “Minimal optimization” ezen túl még a statikus tartalmakat is optimalizálja. A legjobb eredmény elérése érdekében válasszuk a “Full optimization” lehetőséget. A “Bypass CSS Import” tesz róla, hogy az importált CSS fájlokat is tartalmazza az összevonás, a “Merge Assets in Background” bekapcsolása esetén pedig a háttérben végzi el az összevonást, enélkül irreálisan magas lehet az első betöltési idő engedélyezett Critical CSS esetén, ez pedig nem ideális. Ilyenkor addig, amíg nincs felépített cache, az oldal eredeti, optimalizálatlan weboldalát szolgálja ki a szerver a látogatóknak. A “Limit Simultaneous Threads” opciót akkor engedélyezzük, ha osztott tárhelyen vagyunk és 508-as hibákat kapunk túl sok egyidejű folyamatszál futása esetén.

blank

A képek beállításai következnek. Az “Enable LazyLoad” lehetővé teszi, hogy az oldalon található képek csak akkor kerüljenek betöltésre, amikor a felhasználó valóban megtekinti őket (például oda görget). Az “Optimize images on upload” pedig arra szolgál, hogy feltöltéskör automatikusan újra legyenek tömörítve a képek, ezáltal csökkentve a méretüket látható minőségromlás nélkül. Sok ingyenes kép optimalizáló bővítménytől eltérően ez a szolgáltatás korlátlan mind fájlméretben, mind a képek számában, sőt, akár a teljes média tárat is újra tudjuk tömöríttetni a Swift Performance-al.

blank

Ha idáig eljutottunk, akkor lényegében készen is vagyunk, megnézhetjük a friss pontszámainkat és a biztonság kedvéért ellenőrizzük az oldal működését is. Aki pedig nem elégedett az automatikus optimalizálás eredményével az kattintson a “Swift Performance Settings” gombra és manuálisan szabja testre a bővítmény mélyebben megbúvó beállításait. Lentebb igyekeztem összeszedni a sikeres optimalizáláshoz elengedhetetlen opciókat, legalább is én a következők engedélyezésével értem el a legnagyobb pontszámot (erről bővebben a cikk végén).

General fül:

Normalize Static Resources: Engedélyezése igen hasznos, eltávolítja a JavaScript/CSS fájlok és egyes képek végéről a verzió számozást (A GTMetrix esetén ez is pontozási faktor).

Use Compute API: Segítségével felgyorsul az összevonási folyamat és csökken a processzor használat a szerveren. Engedélyezése erősen ajánlott.

Prefetch DNS: Előtölti a DNS-t. Kapcsoljuk be.

Collect domains from scripts: Összegyűjti a szkriptek domainjeit a DNS előtöltéshez. Ez is legyen engedélyezve.

Images fül:

Optimize Images: A feltöltött képeink automatikus optimalizálása (kisebb fájlméret -> gyorsabb oldalbetöltés). A médiatárba korábban feltöltött képek is optimalizálhatók a “Média / Image Optimizer” alatt.

Inline Small Images: A kis méretű képek base64-ben tárolva kódrészletként kerülnek beillesztésre valódi képek betöltése helyett.

Lazy Load: Képek betöltése csak szükség esetén (például ha oda görget a látogató).

Inline Lazy Load Images: Base64 kódolt beágyazott képek használata a LazyLoad-hoz.

Asset Manager fül:

Merge Scripts: A JavaScript fájlok kombinálása a HTML lekérések számának csökkentése végett.

Minify JavaScripts: A JavaScript fájlok tömörítésének engedélyezése.

Proxy 3rd Party Assets: Külső hivatkozásból betöltött JavaScript és CSS fájlok (például Google Analytics) klónozása

Merge Styles: A CSS fájlok kombinálása egy fájlba a HTML lekérések számának csökkentése végett.

Generate Critical CSS: Kritikus CSS generálása. A bővítmény egyik alapköve.

Remove Keyframes: CSS animációk eltávolítása a kritikus CSS-ből.

Print Critical CSS Inline: Bekapcsolása esetén a kritikus CSS a fejrészbe kerül egy külön CSS fájl létrehozása helyett.

Print Full CSS Inline: Az összevont CSS a lábrészbe kerül egy külön CSS fájl helyett.

Minify CSS: A CSS fájlok tömörítésének engedélyezése.

Merge Assets In the Background: A háttérben történik az elemek összevonása.

Minify HTML: A HTML kód tömörítése.

Caching fül:

Enable Caching: Itt kapcsoljuk be az oldalak/bejegyzések gyorsítótárazását.

Caching mode: A leggyorsabb kiszolgálás érdekében válasszuk a “Disk Cache with Rewrites” opciót. Ha valamilyen oknál fogva nem írható a .htaccess, akkor másodlagos opcióként még mindig használhatjuk a “Disk Cache with PHP” lehetőséget, bár ez kicsit lassabb. Ha a szerveren elérhető és engedélyezve van a memcached PHP kiegészítő, akkor rendelkezésünkre áll a “Memcached with PHP” mód is, ahol a memóriából szolgálja ki a rendszer a gyorsítótárazott lekéréseket.

Cache Expiry Mode: Time based mode. A legtöbb oldalhoz ez a megfelelő beállítás, kivéve gyakran változó tartalmak esetén.

Prebuild Cache Automatically: Ürítés esetén automatikusan újraépíti a rendszer a gyorsítótárat.

Enable Browser Cache: A böngésző gyorsítótárazás engedélyezése. Mindenképp kapcsoljuk be.

Enable Gzip: A Gzip tömörítés engedélyezése. Szintén kötelező.

Cache 404 Pages: A 404-es hibaoldalakat is gyorsítótárazza a plugin, ha ezt engedélyezzük.

CDN fül:

Ha rendelkezünk bármilyen “pull” CDN előfizetéssel, akkor itt tudjuk ezt részletesen konfigurálni. MaxCDN előfizetés esetén a gyorsítótárat is tudjuk üríteni.

Konklúzió

A saját tapasztalataim a Swift Performance-al több, mint meggyőzőek. A fentiek engedélyezése után a WPSzaki.hu sikeresen elérte a 95+-os pontszámot mind a Google PageSpeed Insights, mind a GTMetrix tesztekben a korábbi 60 körüli pontszámok helyett, mindezt bárminemű strukturális változtatás és a meglévő bővítmények kikapcsolása nélkül. A JavaScript és CSS összevonás miatt kérések száma is jelentősen csökkent, csak úgy, mint az oldal mérete és természetesen a betöltési idő is. Úgy gondolom ez igen szép eredmény, tekintve, hogy a folyamat lényegi része teljesen automatikus és nem szükséges a felhasználó manuális beavatkozása. A 100/100-as pontszám elérése sem lenne lehetetlen pár apróbb módosítással, de per pillanat tökéletesen elégedett vagyok a jelenlegi eredménnyel. A beépített képtömörítő is megfelelő hatékonysággal dolgozik és igen örvendetes, hogy minden szempontból korlátlan. Hibát a tesztelés alatt egyszer sem tapasztaltam, minden gond nélkül működött. Ha valaki egy igazán megbízható, hatékony és nem utolsó sorban felhasználóbarát sebesség optimalizáló bővítményt keres, akkor a Swift Performance a tökéletes választás.

Természetesen nem lenne értelme a bemutatónak anélkül, hogy össze ne hasonlítanánk a Swift Performance tudását a többi népszerű optimalizáló bővítménnyel, szerencsére ezt megtették helyettem a készítők, így elegendő csak ide kattintani a megtekintéshez: [link]

Az egy weboldalra vonatkozó licensz megvásárlása mellé jár 12 hónap fejlesztői támogatás, korlátlan frissítés, valamint korlátlan Compute API és Image Optimizer API használat. Mivel a fejlesztők is tisztában vannak a bővítmény hatékonyságával, ezért 14 nap pénz visszafizetési garanciát is biztosítanak minden vásárlás mellé!

Forrás: wpszaki.hu


blank
2018.02.13.
wordpress-weboldal-keszites2.jpg

A weboldalak és kiemelten a webáruházak biztonságára egyre több figyelmet fordít a Google. A Google Chrome böngésző fejlesztése során ezt is figyelembe veszik. A webhelyek minősítésének fokozatos átalakításával abba az irányba terelik a fejlesztőket és a weboldal, webáruház tulajdonosokat, hogy álljanak át a biztonságos HTTPS protokoll használatára a látogatók biztonsága érdekében.

Kezdetekkor csak a biztonságos oldalak esetén jelent meg a bizalomépítő zöld lakat, aztán a 2017 januárjában kiadott, 56-os verziószámú Chrome böngésző már a “nem biztonságos” jelzéssel látta el azokat a weboldalakat, webáruházakat amelyek nem titkosított HTTP protokollon személyes adatokat kértek el a felhasználóktól.

A múlt héten napvilágot látott információk szerint a 2018 júliusában megjelenő 68-as verzió már minden olyan oldal esetén figyelmeztetést fog megjeleníteni, amely HTTP kapcsolaton keresztül kommunikál, attól függetlenül hogy éppen kér-e adatokat a látogatóktól.

 

Nagy valószínűséggel a többi böngésző is hasonlóan fogja a jövőben “minősíteni” a weboldalakat, webáruházakat.

 

Kasza Norbert
WordPress Szakértő
+36203536848
info@wpmaster.hu


blank
2017.08.03.

Ha megkérdezel egy webshop vagy egy egyszerű weblap tulajdonos, hogy mik a céljai, amit az online marketingben el szeretne érni, a követezőket válaszokat szoktam kapni:

„Szeretném a tartalmamat a fő kulcsszavamra optimalizálni”

„Az én oldalam legyen első helyen a Google-ben”

„Nagyobb forgalmat akarok terelni a weboldalamra”

Hogy ezeket a célokat elérjük vagy megközelítsük eléggé mélyre kell ásni a keresőoptimalizálásban.

Először is mi az a SEO?

Egy nagyon leegyszerűsített válasz:

A weboldal optimalizálása a keresők számára.

A Google-nek és a többi keresőnek úgynevezett feltérképező robotjai vannak. Ezek a kis botok átkutatják az oldalunk minden szegletét és ha valami újat, szokatlant vagy éppen hibát találnak rajta, akkor azt jelzik nekünk vagy a helyzetnek megfelelően cselekszenek. (Büntetnek, figyelmeztetnek, vagy éppen jutalmaznak.)

Tehát meg kell ismernünk, hogyan térképezik fel a keresőkrobotok (crawl robotok) az oldalunkat.

A keresőrobotok tanulmányozása persze nem tartozik a főbb folyamatokhoz, viszont érdemes tudni, hogyan gondolkodnak ők.

Sajnos csak felületesen ismerjük a robotok működését, mivel a Google évente kb. 600 szor változtat az algoritmusán. De, hogy mit változtat, persze azt nem köti az orrunkra. Az a legféltettebb üzleti titkokhoz tartozik.

A Google Crawl Budget – avagy az oldal feltérképezési hányadosa

2017 januárjában Gary Illyes Google alkalmazott ki posztolta, hogy minden oldalnak van egy úgynevezett crawl budget-je.

A Google két részre osztja a crawl budget-t:

– A feltérképezés gyakorisága

– A feltérképezés intenzitása vagy a tempója.

 

Azt viszont tudnunk kell, amikor a robotok az oldalunkat vizsgálják,akkor valamilyen szinten megterhelik a szervert, ezáltal lassul az oldal.
A Google nem akarja az oldalunkat túlterhelni a feltérképezési folyamatával ezért kinek milyen technikai háttere van szerver részről, annak függvényében lesznek a robotok aktívak vagy éppen visszafogottak.

Crawl Rate Limit – vagyis a feltérképezés intenzitása

blank

A rate limit fékentartja a keresőrobotot, hogy ne lassítsa az oldalt és ne végezzen túl sok műveletet (request) az oldalon egy időben.

Ha az oldalad nem annyira népszerű, akkor a robot hamar végezni fog a munkájával, mert tudja, hogy nem lesz baj, ha lelassúl – úgysem nézi sajnos senki.

Crawl Demand vagyis a feltérképezés intenzitás

blank

 

Ez egy fontos tényező a keresőoptimalizálásban. Mivel a keresőóriás azt mondja:
ha egy tartalom népszerű és friss, akkor a robotnak nagyobb az „igénye” arra, hogy beszkennelje az új tartalmat.

Itt egy összefoglalás, hogy miről is van szó:

A feltérképezési arány és a feltérképezés iránti kereslet együtt határozza meg a crawl büdzsét, ami arányos a Googlebot által keresett és feltérképezendő URL-címek számával.

Egyértelműen azt akarod, mint weblap tulajdonos, hogy a robotok az oldalad minden szegletét térképezzék fel és persze azt is akarjuk, hogy a robotok is akarják a mi oldalunkat.

Hogyan használhatjuk ki a crawl büdzsénket, hogy javítsunk a SEO-n?

A Google egyet akar: a legjobb keresési eredményeket adni a felhasználóknak.
Ha tudsz neki segíteni ebben, meg fog téged jutalmazni.

1: Gyorsítsd fel az oldalad

A webhely gyorsasága kulcsfontosságú a keresőoptimalizálásban és az oldal feltérképezésében egyaránt.

Mindenképpen dolgozz rajta, hogy a weboldal betöltési ideje és a szerver teljesítménye gyorsabb és jobb legyen az átlagtól.

Ezáltal a robotok nagyobb intenzitással tudják az oldalad feltérképezni, mert marad még bőven a teljesítményből annyi, hogy a felhasználói élmény ne csökkenjen.

blank

Tehát ha gyorsul az oldalad, azáltal nő a crawl budgeted is.

Mielőtt bármit is tennél végezz el egy pingdom tesztet.

blankItt a hozzánk legközelebb eső tesztelési helyszín az Stockholmban van. Így emiatt a betöltési idő nem lesz teljesen pontos, viszont közelítő értéknek tökéletes.

Az optimális betöltési idő 0,5 és 2 másodperc között van.

Mennyit tesz 1 másodperccel hosszabb betöltési idő?

blank

Ne feledd! 2 másodperc a tűréshatár. Igyekezz ettől jobb eredményt elérni, hogy a robotok minél intenzívebben dolgozhassanak az oldaladon.

Szerver lekérdezés (request)

Az oldaladnak lehetőleg kevés requestnek kell lennie. Az átlag érték itt 99.

Ha ettől kevesebb van, az szintén jó pont.

blankHa a 99-es érték alatt vagy az jó, viszont ha 0-50 között az meg még jobb.

Így érhetsz el optimális vagy annál jobb lekérdezési értéket.

Hogyan lesz az oldalad még gyorsabb?

1: A design

A trendi csilli villi design ugyan szép, de nem praktikus.

Legyen praktikus és egyszerű a weboldalad!

– Az első lépés a gyorsítás felé, hogy engedélyezed a gzip tömörítést.

  • Redukáld a képek számát, ami nem fontos azt töröld le.
  • Optimalizáld a weblapodon lévő képeket méret és felbontás szerint (Image SEO)Mielőtt feltöltöd a weboldaladra a képeket, tömörítsd őket ezzel a webes tool-al vagy ha már felkerültek a weblapra, akkor ezzel a WordPress pluginnal tudsz zsonglőrködni.

Végül a weblapod kódolását kell átnézni javascript és css optimalizálás miatt. A legjobb, ha erre megkérsz egy programozót és kifizeted az 1-2 óra munkáját. Vagy ha bevállalós vagy, akkor magad is kipróbálhasz WordPress pluginokat. Wp-Rocket (magyar fejlesztés) vagy a W3 Total Cach-t.

2: Feltérképezési hibák (crawl errors)

Google Search Console-ban tudsz utána nézni, hogy a robot tapasztalt-e valamilyen szerver vagy oldallal kapcsolatos hibát.

Ha belépsz a search consolba akkor a jobb oldalon lesz a crawling menüponton belül a crawling error almenü.

blankHa a google szerver hibát talál, pl. túl sok volt a szerver válaszideje és emiatt nem sikerült a vizsgálat, akkor azt meg tudod nézni.

Hogy ezeket a hibákat elkerüljük, ugyanebben a menüpontban a Fetch as Google menüpontot használva beszkennelhetjük az oldalunkat, úgy, mintha azt a Google robotjai tennék.
Ha a teszt szimuláció után minden rendben van, akkor valószínűleg nem lesz bajunk, amikor a Googlebotok élesben mászkálnak majd az oldalunkon.

3. Óvakodj a duplikált tartalomtól

A Google nem szereti ezért harcol is ellene.
Gondolom kitaláltad, hogy ez sem tesz jót a crawl büdzsédnek.

4. Növeld a népszerűséged:

Minden oldal fő célja, hogy minél több látogatója legyen, ezáltal nőjön a népszerűsége.

Tehát minél jobb a tartalmad és annak a népszerűsítése, annál jobb lesz a crawl büdzséd is.

A tartalmad népszerűsítése történhet a közösségi médiában vagy linkek szerzésével más oldalakról. (Linkbuilding startégiák)

– A népszerűség egyik fő eleme, hogy legyen mindig friss, rendszeres tartalmad. Ez nem azt jelenti, hogy minden nap szükséges posztolnod.
Vannak persze olyan iparágak, ahol ez fontos, de átlagosan ez nem szükséges. A hangsúly a rendszerességen van.

blank

Pár trükk, amivel frissen tarthatod az oldalad:

  • Írj friss tartalmakat. Ez a leghatásosabb módja, hogy „friss” legyen az oldalad.
  • Legyen rendszeres az írásod. Ami egyszer frissnek számított az idővel elavult lesz.
  • Frissítsd a meglévő tartalmad. Adj hozzá kiegészítéseket, videókat, új képeket vagy linkeket. A robotok észlelni fogják, hogy valami változás történt és újra be fogják olvasni az oldalt.
  • Csinálj új aloldalakat. A Google a fejlődés elkötelezettje és azt szereti látni, ha más is az. A jól menő oldalak növekednek fejlődnek. Hozz létre te is új témájú aloldalakat, hogy a te oldalad is növekedjen.
  • Szerezz rendszeresen frissített oldalakról linkeket, így a te oldalad is fog kapni egy kicsit ebből a frisseségből.

Konklúzió

A Google a legjobb tartalmat akarja a felhasználóinak adni. Erre keres társakat (oldalakat). Tehát  Ő segíteni szeretne neked, hogy több emberhez eljuss, mert a célotok közös.

Viszont ha akadályokba ütközik, akkor keresni fog olyan partnereket, akikkel könnyebben el tudja érni a közös célt. Ha benne vagy a játékban és megadsz minden támogatást a Googlebot-oknak, ők is fognak neked segíteni, hogy a büdzséd nagyobb legyen. Ez a te érdeked is.

A bejegyzést írta:

Szakál Zsolt

https://bergluftmarketing.ch

https://seo-kepzes.hu


blank
2017.06.16.
wordpress-honlap.png

Szeretnénk lerántani a leplet a WordPress weboldalakat övező városi legendákról, miszerint nem biztonságos rendszer és „bárki feltudja törni” a WordPress oldalunkat.

Most bemutatunk egy olyan bővítményt, amit bárki ingyenesen letölthet a WordPress bővítménytárból. A telepítésre most itt nem térnénk ki, remélhetőleg ez senkinek sem okoz gondot.

A bővítményünk, amit telepíteni fogunk az All In One WP Security plugin.

Lépjünk be a WP Security menübe, a kezdő képernyő, ami fog minket, egy összefoglaló oldal WordPress weboldalunk biztonsági beállításairól. Első ránézésre siralmas lesz a látvány, de néhány egyszerű beállítással jelentősen javíthatunk a helyzetünkön.

Nézzük is a beállításokat:

Lépjünk át a User Login almenüben, itt pipáljuk be a következő mezőket

  • Enable Login Lockdown Feature (engedélyezzük a belépési funkciók felülbírálatát)
  • Allow Unlock Requests (engedélyezzük a felhasználóknak a feloldási kérelmet)
  • Display Generic Error Message (letiltjuk a hibaüzenetek megjelenítését pl.: helytelen felhasználó név vagy jelszó)
  • Instantly Lockout Invalid Usernames (ismeretlen felhasználónév azonnali tiltása)

A gyári időzítések és próbálkozások száma általában elégséges, ezeket nem feltétlenül kell változtatni.

Következő menüponttal óvatosan bánjunk, ha oldalunkon regisztrálni lehet, mert ezzel megtiltjuk az oldalon a regisztációt!

Lépjünk be a User Registration almenübe és pipáljuk be a „Enable manual approval of new registrations” mezőt. Ezzel a beállítással elérjük, hogy csak jóváhagyás után tud a felhasználó belépni az oldalra.

Következő almenünk a „Database Security” mező.

Érdemes a biztonság kedvéért egy database backup-ot készíteni mielőtt ezt a biztonsági opciót is aktiváljuk. Ezzel átnevezzük a WordPress adatbázis tábla előtagját egy random karaktersorra.

Pipáljuk be a „Generate New DB Table Prefix” mezőt és mentsük el a beállítást. Ha minden rendben van, kapunk pár sor zöld pipás visszajelzést.

Térjünk át a fájlok védelmére. A „Filesystem Security” almenüben a tárhelyünk mappa jogait tudjuk módosítani (ha nem blokkolja ezek módosítását a tárhelyszolgáltatónk). Ma már elmondható, hogy a tárhelyszolgáltatót zöme helyesen kezeli alapértelmezetten ezeket a beállításokat, ha minden rendben van, akkor semmi tennivaló nincs.

Váltunk át a „PHP File Editing” mezőre és pipáljuk be a „Disable Ability To Edit PHP Files” mezőt. Ezzel az opcióval megtiltjuk, hogy illetéktelen személyek vagy programok módosításokat hajtsanak végre a php fájlainkban.

A következő tiltásunk a WordPress telepítési fájlainak kívülről történő elérésének tiltása. Menjünk át a „ WP File Access” fülre és pipáljuk be a „Prevent Access to WP Default Install Files” mezőt.

Következő két fő kategóriánk amit beállítunk a tűzfal és az admin felület elrejtése.

Beállítások a következők:

„Firewall” almenü, pipáljuk be az összes lehetőséget, amit felajánl a rendszer. Itt most nem térnék ki a „mi-micsodára”.

Tegyünk ugyan így a „Additional Firewall Rules”, „6G Blacklist Firewall Rules” és az „ Internet Bots” mezökkel is.

A wp-admin felület elérésével bánjuk körültekintően, mert ha elfelejtjük mire neveztük át az admin felületet, csak körülményesen tudjuk újra elérni. J

Nyissuk meg a „Brute Force” almenüt és pipáljuk be a „Enable Rename Login Page Feature” mezőt. Alatta találunk egy „Login Page URL” mezőt, ide kell beírnunk azt a nevet amire átszeretnénk nevezni a wp-admin linket. Csak nevet kell beírni, NEM KELL „/” jel!

Ezzel máris sokkal nagyobb biztonságban vagyunk az általános támadásokkal szemben, de hangsúlyozom, hogy a célzott támadások ellen ezek a beállítások nem jelentenek 100%-os védelmet!

 

Következő írásunkban megmutatjuk hogyan tudjátok a nem kívánatos országokat és botokat kitiltani az oldalatokról, ha a tárhelyszolgáltató nem teszi meg ezt helyettetek.

 

Kasza Norbert
WordPress Szakértő
+36203536848
info@wpmaster.hu


blank
2017.01.31.

 

Folytatva az előző cikkünket, (WordPress Google Pagespeed beállítása) most megmutatjuk hogyan lehet szinte tökéletes oldal betöltést és cache-elést elérni WordPress oldallal.

Hangsúlyozom ezek a beállítások webáruház esetén nem minden esetben megfelelőek, mert például a kosár oldal hibásan generálódhat le!

Röviden miért is szükséges a cache-elés (gyorsítás) a WordPress weboldalaknál. A válasz röviden javíthatjuk vele a felhasználói élményt és a Google is jobb helyezéssel honorálja ezt a pár beállítást, amit bárki megtud csinálni minimális WordPress tudással.

Cache-elés lényegében nem mást, mint pillanat felvétel a weboldalunkról, amit statikus html fájlként tárol el a tárhelyünk és ha megnyitjuk a weboldalt, akkor ezeket a fájlokat tölti be a böngésző. Így megspórolva azt az időt amig a szerver generálja a weboldalt a dinamikus állományokból. Ezzel a megoldással jelentősen csökkenthető a betöltési idő és a lekérések száma is. A cache pluginok tovább szolgáltatása a CSS és JS fájlok optimalizálása és egyesítése. Ha engedélyezzük ezt az opciót, akkor a bővítmény megpróbálja egy nagy fájlá alakítani a sok kisebb CSS és JS fájlt, amivel szintén a betöltési időt lehet csökkenteni, mert így nem kell a fájlokat keresgetni a szerveren, hanem egy fájlban letölti azokat a böngésző. Valóságban elég ritkán sikerült egy fájlba összegyűjteni minden adatot, de már az is javulás, ha pl. 45 CSS fájl helyett csak 5 nagyobb CSS fájlt kell mozgatni. Ugyan ez vonatkozik a JS fájlokra is.

Cache-hez szükségünk lesz 3 db ingyenes pluginra:

Autoptimize

Async Javascript

Cache Enabler

A 3 bővítmény telepítési és beállítási sorrendjét érdemes betartani, mert egymásra épül a működésük.

WordPress bővítménytárból telepítsük a plugin-okat, elsőként az Autoptimize bővítményt és kapcsoljuk be.

Beállítások:

Váltsunk át Advanced mode-ra (jobb felső sarok)

Pipáljuk be az alábbi opciókat:

Optimize HTML Code

Optimize JavaScript Code

Optimize CSS Code

Inline all CSS

 

Töltsük ki az alábbi mezőket ha nem töltené ki a bővítmény automatikusan:

Exclude scripts from Autoptimize: seal.js, js/jquery/jquery.js (ha nem lenne kitöltve)

Exclude CSS from Autoptimize: admin-bar.min.css, dashicons.min.css

 

Második plugin az Async Javascript
(Beállítások menü alatt találod a bővítményt)

Beállítások:

Pipáljuk be a Enable Async JavaScript-t opciót. Method-nál válasszuk az As Per Selected Method lehetőséget.
Lap alján engedélyezzük az együtt működést az Autoptimize pluginnel, pipáljuk be a Enable Autoptimize Support opciót és itt a Method-nál válasszuk az Async opciót.

Harmadik egyben utolsó bővítmény, amit használni kell a Cache Enabler. Ez a plugin nem igényel semmilyen beállítást

Negyedik lehetőség, amihez nem szüksége plugin, a htaccess fájlban a fájlok lejárati idejének beállítása. Ezzel a pár sorral tudjuk megmondani a böngészőnek, hogy melyik statikus fájlt mennyi ideig tárolja a böngésző gyorsító tárában és ha legközelebb felkeressük az adott WordPress oldalt, akkor ezeket a fájlok nem tölti le újra a böngészőnk, hanem a saját merevlemezen tárolt gyorsítótárából tölti be, ami lényegesen gyorsabb elérést tesz lehetővé.

Mi az alábbi lejárati időket állítjuk be a weboldalaknál:
(csak másold ki és illezd be a saját .htaccess fájlodba)

<IfModule mod_headers.c>
<FilesMatch “\.(js|css|xml|gz)$”>
Header append Vary: Accept-Encoding
</FilesMatch>
</IfModule>
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault “access plus 10 seconds”
ExpiresByType text/cache-manifest “access plus 0 seconds”
ExpiresByType text/xml “access plus 0 seconds”
ExpiresByType application/xml “access plus 0 seconds”
ExpiresByType text/json “access plus 0 seconds”
ExpiresByType application/json “access plus 0 seconds”
ExpiresByType application/rss+xml “access plus 3600 seconds”
ExpiresByType application/atom+xml “access plus 3600 seconds”
ExpiresByType image/x-icon “access plus 31536000 seconds”
ExpiresByType image/gif “access plus 31536000 seconds”
ExpiresByType image/webp “access plus 31536000 seconds”
ExpiresByType image/png “access plus 31536000 seconds”
ExpiresByType image/jpeg “access plus 31536000 seconds”
ExpiresByType image/jpg “access plus 31536000 seconds”
ExpiresByType video/ogg “access plus 31536000 seconds”
ExpiresByType audio/ogg “access plus 31536000 seconds”
ExpiresByType video/mp4 “access plus 31536000 seconds”
ExpiresByType video/webm “access plus 31536000 seconds”
ExpiresByType text/x-component “access plus 31536000 seconds”
ExpiresByType application/x-font-ttf “access plus 31536000 seconds”
ExpiresByType font/opentype “access plus 31536000 seconds”
ExpiresByType font/woff2 “access plus 31536000 seconds”
ExpiresByType application/x-font-woff “access plus 31536000 seconds”
ExpiresByType image/svg+xml “access plus 31536000 seconds”
ExpiresByType application/vnd.ms-fontobject “access plus 31536000 seconds”
ExpiresByType text/css “access plus 31536000 seconds”
ExpiresByType application/javascript “access plus 31536000 seconds”
ExpiresByType text/javascript “access plus 31536000 seconds”
ExpiresByType application/javascript “access plus 31536000 seconds”
ExpiresByType application/x-javascript “access plus 31536000 seconds”
ExpiresByType application/x-shockwave-flash “access plus 31536000 seconds”
ExpiresByType application/octet-stream “access plus 31536000 seconds”
ExpiresByType font/truetype “access plus 1 year”
ExpiresByType font/opentype “access plus 1 year”
ExpiresByType application/x-font-woff   “access plus 1 year”
ExpiresByType image/svg+xml “access plus 1 year”
ExpiresByType application/vnd.ms-fontobject “access plus 1 year”
# Add correct content-type for fonts
AddType application/vnd.ms-fontobject .eot
AddType application/x-font-ttf .ttf
AddType application/x-font-opentype .otf
AddType application/x-font-woff .woff
AddType image/svg+xml .svg
# Compress compressible fonts
AddOutputFilterByType DEFLATE application/x-font-ttf application/x-font-opentype image/svg+xml
ExpiresActive on
# Add a far future Expires header for fonts
ExpiresByType application/vnd.ms-fontobject “access plus 1 year”
ExpiresByType application/x-font-ttf “access plus 1 year”
ExpiresByType application/x-font-opentype “access plus 1 year”
ExpiresByType application/x-font-woff “access plus 1 year”
ExpiresByType application/x-font-woff2 “access plus 1 year”
ExpiresByType image/svg+xml “access plus 1 year”
</IfModule>

 

Kasza Norbert
WordPress Szakértő
+36203536848
info@wpmaster.hu


blank
2017.01.28.

Az alábbi leírásban szeretnénk megmutatni, hogyan lehet a Google irányelveinek és technikai elvárásainak megfelelő WordPress oldalt beállítani. Az alábbi szűrőkkel jelentősen javíthatjuk weboldalunk betöltési idejét, amivel javul a felhasználói élmény és a keresőoptimalizálása az oldalunknak.

 

De nézzük milyen beállítások szükségesek egy Wordpres oldalhoz:

 

  1. Tárhelyszolgáltatótól meg kell kérdeni, hogy a szerver apache és/vagy nginx webszerverben telepítve van-e a google pagespeed modul. (jobb szolgáltatónál ez nem szokott gond lenni, de találkoztunk már mi is olyan szolgáltatóval aki vissza kérdezett, hogy mi az a pagespeed 🙂 )
  2. Ha pozitív választ kaptunk az első pontra, keressük meg a tárhelyünk gyökér mappájában (pl.:/httpdocs vagy /web) a .htaccess fájlt. Ez általában rejtett fájl biztonsági okokból. A legtöbb FTP kliens programban van lehetőség a rejtett fájlok listázására.
    FONTOS: MIELŐTT BÁRMIT MÓDOSíTUNK A .HTACCESS FÁJLBAN, KÉSZíTSÜNK RÓLA BIZTONSÁGI MÁSOLATOT!
  3. Következő lépés a htaccess fájl szerkesztése, a szükséges parancsok elhelyezése.
    Teljességi igénye nélkül a következő szűrőket használhatjuk:
  • Modpagesspeed On vagy Off – modul be/ki kapcsolása
  • ModePagespeedEnableFilters – ezután kell beírni azokat a szűrőket amit engedélyezni szeretnénk
  • ModePagespeedDisableFilters – ezután kell beírni azokat a szűrőket amit tiltani szeretnénk
  • Combine_css – css fáljok egyesítése
  • Combine_javascript – js fájlok egyesítése
  • Rewrite_css – css fájlok optimalizálása
  • Rewrite_javascript – js fájlok optimalizálása
  • Extended_cache – bővített cache lehetőségek
  • Rewrite_images – képek optimalizálása
  • Insert_image_dimensions – kép méretének beágyazása a programozásba
  • Recompress_images – képek tömörítése
  • Resize_images – képek átméretezése

Az itt felsorolt szűrők csak töredéke a lehetőségeknek, amit a Google folyamatosan bővít.

Teljes lista: https://modpagespeed.com
Google ellenőrző: https://developers.google.com/

Vannak speciális esetek, mikor a sablon vagy bővítmény nem kompatibilis a fent említett programmal és ilyenkor megesik, hogy az oldal meghibásodik. Ebben az esetben sajnos le kell mondanunk a pagespeed használatáról jelen oldalunkon. Vagy más megoldást kell keresünk.

Ha megtörténik a baj, nem kell kétségbe esni, egyszerűen töröljük a beírt kód sorokat vagy a Modpagespeed kapcsoló után az ON-t írjuk át OFF-ra és frissítsük az oldalt.

 

Következő írásunkban a cache beállításokhoz adunk tippeket.

Kasza Norbert
WordPress Szakértő
+36203536848
info@wpmaster.hu


blank
2016.10.24.

Mi az a WordPress?
A WordPress fejlesztése 2001-ben kezdődött, de csak az elmúlt években lett népszerű a kezdő és haladó webfejlesztők körében. Alapvetően a WordPress (WP) egy nyíltforráskódú, azaz bárki számára ingyenesen elérhető tartalomkezelő és blog rendszer.
Ingyenes vagy nem?
Felmerül a kérdés, hogy ha nyíltforráskódú rendszerről van szó, akkor miért is kerül pénzbe egy WordPress oldal elkészítése. A válasz egyszerű: maga a keret rendszer ingyenes, de ez csak egy alap vázat biztosít a weboldalunkhoz. Ahhoz, hogy honlapunk megjelenése és működése felvegye a versenyt a konkurenciával, ismerni és alkalmazni kell a különböző szerkesztési, beállítási lehetőségeket, a bővítmények kezelését. Sokszor a programozásba is módosítások szükségesek, melyeket csak tapasztalt WordPress szakemberek tudnak elvégezni.
Miért ilyen népszerű a WordPress?
Felmérések szerint a világon található weboldalak 4,5 százaléka WordPress alapú. A CMS (Content Management System – Tartalom Menedzsment Rendszer) alapú weboldalaknál ez a szám már 50-60 százalék között van, webáruházaknál is hasonló százalékos arányt találunk. Ezt a nagy népszerűséget annak köszönheti, hogy egy komplett iparág épül a WP oldalak felhasználóira, fejlesztőire. Mivel a WP nyíltforráskódú, ezért bárki hozzá tehet, kiegészítheti a saját ötleteivel, funkcióival az alap motort, amit előszeretettel alkalmaznak is a fejlesztők világszerte. Ezzel akár több havi időt és pénzt spórólnak meg az ügyfeleknek az egyedi programozású weboldalakhoz képest.
Milyen a jó WordPress sablon?
Nagyon sok olyan cég van a világon, akik kimondottan WordPress sablonok készítésével foglalkoznak.  legnépszerűbb sablon gyűjtőoldal a Themeforest. Itt jelenleg 11651 db sablon közül választhatunk pár dolláros ártól a komolyabb összegig, funkcióktól és felhasználástól függően. Ha röviden szeretnénk jellemezni, hogy milyen a jó WordPress sablon, akkor nézzen ki jól és működjön. J Persze ennél azért több szempontot kell figyelembe venni a sablon kiválasztáskor. Érdemes először több olyan sablont keresni, mely kinézetében közel áll hozzánk és elképzeléseinkhez. Érdemes arra is figyelni, hogy mikor készült a sablon, illetve mikor lett frissítve utoljára. Ha például a választott sablon 3 éve készült és azóta nem lett fejlesztve, frissítve, akkor nagy valószínűséggel gondjaink lesznek vele, ilyen tipikus hibák például:

  • Nem kompatibilis a jelenlegi WordPressel
  • Nem vagy csak részben reszponzív
  • Nem kompatibilis a használni kívánt bővítményekkel, stb.

Egy jól működő WordPress sablonnak, az alábbi követelményeknek kell megfelelni:

  • WordPress 5.0.3 kompatibilis
  • 100%-ban reszponzív
  • Kompatibilis a legnépszerűbb bővítményekkel
  • Kompatibilis a népszerű böngészőkkel
  • Kezeli és megfelelően méretezi a nagy felbontású képeket
  • Könnyen áttekinthető admin felület
  • Rendelkezik demó adatokkal
  • Van saját nyelvi fájlja

Természetesen ezek csak az alap dolgok, ezen felül még sok egyedi igénynek is meg kell felelnie a sablonnak a zökkenőmentes működéshez. Legközelebb a WordPress Bővítmények (Plugin-ok) alkalmazásáról, lehetőségeiről és típusairól írok.
Addig is, ha bármi kérdésed van, hívj vagy írj üzenetet!
Kasza Norbert
WordPress Szakértő
+36203536848
info@wpmaster.hu


blank
2016.09.28.
wordpress-weboldal-keszites1-1280x720.jpg

A 7 leggyakoribb hiba honlapoknál


Sok kisvállalkozás küzd azzal a problémával, hogy nem jönnek a megrendelések és a vevők. Ha Te is közéjük tartozol, akkor neked szól írásunk! De akkor is érdemes elolvasni, ha már sok ügyfeled van és szeretnéd őket hosszú távon megtartani.

Mi lehet az oka, hogy nem úgy alakulnak a dolgok, ahogy eltervezted? Sok esetben a sikertelenség egyik oka a nem megfelelő online megjelenés.

Vajon mi a 7 leggyakoribb hiba honlapok esetén?


1. Túl hosszú domain név: hogyan jegyezzék meg az éncégem.marinéniszolgáltató.hu domain nevet a látogatók?

2. Egyediség hiánya: miért téged válasszanak 500 másik ugyanolyan honlappal rendelkező cég közül? Hiszen éppen ugyanolyan olcsó havidíjas vagy ingyenes oldalad van, mint a többieknek…

3. Túl sok szín, forma, vizuális esztétika hiánya: szerinted mit gondolnak a termékeidről és szolgáltatásaidról, ha 10 szín és 5 betűtípus van a honlapodon?

4. Túl sok vagy kevés információ, adat, kép: hogyan találjon meg bármit is a látogató, ha te magad sem tudod, hogy hol van, ha egyáltalán rajta van a honlapon?

5. Keresőoptimalizálás hiánya: hogyan találjanak meg a potenciális ügyfelek az Interneten, ha a Google sem tudja, hogy hol vagy?

6. Frissítés hiánya: miért nézzék meg újra a honlapodat és miért keressék újra a termékeidet, ha te hátradőlsz és várod a sült galambot?

7. Nem reszponzív a honlap: az emberek 60-70 %-a mobil eszközön internetezik, ha az oldalad nem megfelelően jelenik telefonon vagy tableten, szerinted mit fognak gondolni cégedről vagy termékedről?

Ha mindezeket a hibákat elkerülöd, kijavítod, akkor honlapod segíteni fog, hogy több ügyfeled és megrendelésed legyen!


blank
2016.09.28.
wordpress-weboldal-webaruhaz.png

A webáruházakat négy típusba soroljuk: bérelt, egyedi programozású, ingyenes webáruház motorral készített és fizetős webáruház motorral készített. Ahhoz, hogy elemezni tudjuk melyik típusnak mik az előnyei és hátrányai, ismerni kell azokat a szempontokat, melyek befolyásolják a működést és a költségeket.

A költségek között fontos megkülönböztetni kezdeti és üzemeltetési költségeket. A kezdeti költségekhez tartozik a licenc díj, mely a webáruház szoftver díja. A kezdeti költségek másik része a testre szabási költség, mely a tervezés (például grafika) és az egyedi igények megvalósításának költsége. A harmadik rész a feltöltési költségeket tartalmazza, azaz a termékadatbázis létrehozását. A folyamatos, üzemeltetési költségek három részből állnak. A domain és szerver költség általában a legalacsonyabb költségek. A tartalmi karbantartás (pl. új termékek feltöltése, hírek) és az informatikai karbantartás (folyamatos fejlesztés) költségei, mint hosszú távú költségek jelennek meg. Az egyes webáruház típusok elemzésénél a következő szempontokat vesszük figyelembe: kezdeti licenc költség, testre szabás, fejlesztői támogatás, egyedi funkciók, folyamatos fejlődés, garancia. Az 1. táblázatban jól látható, hogy melyik típusú webáruház, milyen előnyökkel és hátrányokkal jár. Egy kezdő vállalkozásnak lehetséges, hogy az alacsony kezdeti költségek miatt bérelt vagy ingyenes motorral működő webáruház tűnik a legjobb megoldásnak. Ha viszont hosszú távon gondolkodnak, akkor egy kicsit nagyobb befektetéssel fizetős motorral működő webáruházat készítettnek, mely az előzőekhez képest több egyedi funkciót és magasabb szintű fejlődést tesz lehetővé. Az egyedi programozású webáruházakat általában olyan tőkeerős vállalatok alkalmazzák, akik a magas kezdeti és működtetési költségeket tudják finanszírozni. Ezek a webáruházak, ahogy a nevükben is szerepel, egyediek, egyetlen hátrányuk – saját tapasztalat alapján – hogy ha a programozó cég valamilyen oknál fogva nem tudja tovább működtetni, akkor nehézkes tovább fejleszteni, hiszen ettől egyedi programozású.

  1. táblázat: A webáruház típusok jellemzői
Bérelt Egyediprogramozású Ingyenes webáruházmotor Fizetős webáruházmotor
Kezdeti licenc költség nincs magas nincs közepes
Testre szabás egyszerű bonyolult közepes közepes
Fejlesztőitámogatás van van nincs van
Egyedifunkciók korlátozott van korlátozott van
Folyamatos fejlődés korlátozott korlátozott korlátozott van
Garancia van van nincs van

Webáruházakkal szemben támasztott követelmények, elvárások

A webáruházakkal szemben támasztott követelmények közül először a jogi szempontokat vizsgáljuk. Nagyon fontos, hogy az üzemeltetéshez szükség van egy vállalkozásra és olyan tevékenységi körre, mellyel az e-kereskedelem végezhető. Speciális termék forgalmazása esetén szükség van szakhatósági engedélyre is. Az áruház üzemeltetőjének beazonosítására és az ügyfélszolgálat eléréséhez szolgáló adatokat, valamint a vásárolással kapcsolatos információkat is elérhetővé kell tenni, a vevők számára, melyek a következők:

  • Név, székhely, levelezési cím.
  • Nem természetes személy esetén a kereskedést képviselő neve és telefonszáma, e-mail címe.
  • Adószám, cégjegyzék szám, vállalkozói igazolvány szám, nyilvántartó cégbíróság neve.
  • Az áruházban megvásárolható termékek, vagy szolgáltatások ismertetése.
  • Rendelési, szerződési feltételek:
    • termék házhoz szállításának költsége,
    • szállítási határidő, szállítás mód,
    • a regisztráció és vásárlás menete,
    • garanciális feltételek,
    • 14 napon belüli, indoklás nélküli elállás lehetősége,
    • az elállási jog gyakorlásának menete,
    • felhasználó által megadott adatok kezelése.

Ahhoz, hogy a webáruház vásárlókat is hozzon, számos más követelménynek kell megfelelnie. Nagyon fontos, hogy jól áttekinthető és könnyen kezelhető legyen. Ehhez elengedhetetlen az egyszerű és a forgalmazott termékekkel összhangban levő design. A szövegezés során figyelni kell a helyesírásra, a stilisztikára és a tipográfiára, hiszen ezek nagyban hozzájárulnak a működés sikeréhez. A kezelhetőségnél figyelembe kell venni az ergonómiát: a lényeges részek, mint például regisztráció, termék kategóriák, könnyen elérhetőek legyenek, a megrendelés során az egyes lépéseknek egyértelműek legyenek, stb. Ahhoz, hogy a potenciális vásárlók megtalálják a webáruházat, nagyon fontos a keresőoptimalizálás és a folyamatos marketing tevékenység, valamint mivel egyre többen vásárolnak mobil telefonon vagy tableten, a reszponzivitás is elengedhetetlen.

e-kereskedelem trendek

Egy kutatás szerint az online vásárlók száma 2014-ben Magyarországon 3,4 millió fő volt, mely az összes internetező 72 százaléka. A hazai kiskereskedelem több mint 3 százalékát teszi ki az e-kereskedelem, leginkább számítástechnikai eszközöket, könyveket, ajándékokat és ruházati termékeket vásárolnak a fogyasztók online módon. A vásárláshoz a legtöbben asztali számítógépet vagy notebookot használnak, de egyre többen intézik online vásárlásaikat mobil eszközön. 2013-ban a magyarok 10 százaléka használt valamilyen mobil eszközt internetes vásárláshoz, de ez az arány gyorsan változik. A PayPal és az Ipsos legújabb kutatása szerint a mobilis kereskedelem 2013 és 2016 között 42 százalékkal bővül világviszonylatban, míg ez az érték a teljes e-kereskedelem tekintetében 13 százalék. A kutatásban 22 országból 17500 főt kérdeztek meg.
https://www.webshopexperts.hu/webaruhaz_sajat_vagy_berelt_rendszer
https://startuzlet.hu/blog/webaruhaz_nyitas_jogi_feltetelei_fontos_tudnivaloi


A weboldalon cookie-kat ("sütiket") használunk, hogy a legjobb felhasználói élményt nyújthassuk látogatóinknak. A cookie beállítások igény esetén bármikor megváltoztathatók a böngésző beállításaiban.

Adatvédelmi beállítások elmentve!
Adatvédelmi beállítások

Amikor meglátogat egy webhelyet az tárolhat vagy lekérhet információkat a böngészőben, főként sütik formájában. Itt beállíthatja személyes cookie szolgáltatásokat.

Ezek a cookie-k szükségesek ahhoz, hogy a webhely működjön, és nem kapcsolható ki a rendszerünkben.

Az oldal működtetéséhez az alábbi technikai cookie-ek szükségesek
  • wordpress_test_cookie
  • wordpress_logged_in_
  • wordpress_sec

Összes tiltása
Összes engedélyezése