Relaunch-tarkastuslista verkkokaupoille, varaus- & yrityssivustoille

Sinulla on edessä verkkosivuston uudistus? Onneksi olkoon, että löysit tämän artikkelin. Seuraavat selitykset saattavat olla ratkaiseva panos siihen, että uudistuksesi onnistuu ja saavutat upean tuloksen. Nimittäin se ei aina toteudu. Olen toimiston omistaja ja paljastan sinulle tarkalleen sen, mikä asettaa sinut tilanteeseen, jossa vaaditaan erityisen hyvää työtä minun kaltaiseni ammattilaisen suorittamiseksi ja tavallisten virheiden välttämiseksi uudistuksissa. Mutta aloitetaan alusta.

Verkkosivuston uudistus on olemassa olevan verkkosivuston uudistaminen ja muokkaaminen. Siinä voidaan muuttaa sekä suunnittelua, sisältöä että tekniikkaa. Verkkosivuston uudistuksen tavoitteena on parantaa verkkosivustoa ja sopeuttaa se nykyisiin vaatimuksiin.

Tietyt ulkoiset laukaisijat saavat yritykset julistamaan uudistuksen tavoitteen: vastikään palkattu työntekijä tuo mukanaan hienoja ideoita, uusi pomo tulee ja haluaa myös siivota digitaalisesti kunnolla, kilpailulla on uusi verkkosivusto tai myynti laskee. Ehkä pomo vaimollekaan ei vanha sivusto miellytä tai Z-sukupolvi ei pidä sivustoa tarpeeksi "lit". Tunnet ehkä tilanteen. Sekä se, että on taas aika päivittää uusi verkkosivusto, että henkilökohtaiset mielipiteet eivät kuitenkaan ole peruste uudistamiselle.

On kuitenkin joitain parempia syitä, miksi yritykset tai organisaatiot haluavat suorittaa verkkosivuston uudistuksen. Näistä keskeisimmät ovat:

• Vanhentunut suunnittelu ja/tai brändäys: Vanhentunut verkkosivusto voi antaa vaikutelman siitä, että yritys ei seuraa aikaansa tai ei enää ole aktiivinen. Raikas, moderni suunnittelu pyrkii siten parantamaan kuvaa. Myös silloin kun brändi-imago tai yrityksen identiteetti muuttuu, verkkosivuston uudistus on usein toivottu muutoksen heijastamiseen.
• Parempi käyttäjäkokemus: Jos verkkosivuston käytettävyys on huono, se voi johtaa korkeaan poistumisprosenttiin. Uudistus voi palvella käyttäjäkokemuksen parantamista ja tehdä verkkosivustosta helpommin navigoitavan.
• Mobiilioptimointi: Koska yhä useammat ihmiset käyttävät verkkosivustoja mobiililaitteilla, on tärkeää varmistaa, että verkkosivusto toimii hyvin eri näyttökooissa ja laitteissa.
• Hakukoneoptimointi (SEO): Vanhalla verkkosivustolla voi olla SEO-suorituskykyyn liittyviä ongelmia. Uudistus mahdollistaa SEO-ystävällisten muutosten tekemisen verkkosivuston näkyvyyden parantamiseksi hakukoneissa.
• Sisällön päivittäminen: Jos yrityksen tiedot, palvelut tai tuotteet muuttuvat, verkkosivustoa on päivitettävä muutosten heijastamiseksi.
• Turvallisuuden parantaminen: Vanhemmat verkkosivustot ovat usein alttiimpia tietoturvariskeille. Uudistus voi toimia verkkosivuston turvallisuuden parantamiseksi ja suojautua kyberhyökkäyksiltä.
• Teknologian päivittäminen: Vanhentuneiden teknologioiden käyttö voi vaikuttaa verkkosivuston suorituskykyyn. Uudistus voi tarjota mahdollisuuden siirtyä nykyaikaisiin verkkoteknologioihin ja -alustoihin.
• Saavutettavuus: Esteettömyyden parantaminen on monille verkkosivustoille tärkeä asia varmistaakseen, että ne ovat saavutettavissa ihmisille, joilla on erityistarpeita.
• Kilpailukyky: Kilpailun tahdissa pysyminen vaatii modernia ja tehokasta verkkosivustoa. Uudistus voi auttaa ylläpitämään tai kasvattamaan kilpailukykyä.
• Analytiikan parantaminen: Parempien analysointityökalujen käyttöönotto ja tietojen kerääminen voivat auttaa yrityksiä ymmärtämään paremmin verkkosivustonsa suorituskykyä ja optimoimaan sitä.
• Lakisääteisten vaatimusten noudattaminen: Tietosuojaa, esteettömyyttä ja turvallisuutta koskevat lait ja määräykset muuttuvat säännöllisesti. Uudistus saattaa olla tarpeen varmistaakseen, että verkkosivusto täyttää nämä vaatimukset.

Nämä syynyt voivat esiintyä yksinään tai yhdistelmänä ja vaihdella yrityksen tavoitteiden ja tarpeiden mukaan. Verkkosivuston uudistus on usein strateginen päätös, jonka tarkoituksena on parantaa verkkoläsnäoloa ja saavuttaa yrityksen tavoitteet. Kun tarkastellaan yllä olevia kohtia erikseen, käy ilmi, että useimmat syynyt voidaan toteuttaa pienissä osissa sprintteinä eikä ne vaadi suurta uudistusta.

Erotamme siis, mikä uudistus on ja mikä se ei ole: Uusi suunnittelu olemassa olevan teknisen perustan kanssa on pikemminkin kasvojenkohotus. Uudistus tapahtuu vasta, kun uudistuksen tavoitteena on todellinen muutos käyttäjäkokemuksessa, toiminnallisuudessa ja teknisellä perustalla. 

Uudistuksen tulisi aina perustua faktoihin (esim. teknologia on umpikujassa eikä sitä voi enää päivittää), mittareihin sekä tietoihin ja vertailutietoihin.

Tämä on tässä vaiheessa ensimmäinen suositukseni, jonka haluan antaa: Evolutio ennen vallankumousta! Vältä uudistusta niin kauan kuin mahdollista ja yritä toteuttaa kaikki ne asiat, jotka on toistaiseksi esitetty uudistukseen liittyvänä, yksitellen tai vaiheittain. Parasta esimerkkiä edustaa Amazon, joka todella muuttuu ja kehittyy vain vähän ja on jo monien vuosien ajan välttänyt suuria uudistusmuutoksia. 

Uudistus on aina suuri riski näkyvyydellesi Googlessa. Kaikki kiinnittävät huomionsa parannuksiin, mutta harvat riskiin. Varmasti käyttöliittymä paranee, positiivinen käyttäjäkokemus kasvaa, teknisesti ollaan taas ajan tasalla. Silti: Jos yrityksesi menestys perustuu vahvaan orgaaniseen näkyvyyteen, uudistus on viimeinen keino ja sitä on harkittava vain silloin, kun kipusi on tarpeeksi suuri kombinaatiolla edellä mainituista syistä, jotka eivät ole enää korjattavissa yksittäisissä osaprojekteissa. Miksi? Katso täältä, mitä tapahtui näiden neljän verkkosivuston uudistusten jälkeen niiden online-näkyvyydessä:

Suunnittele uudelleenkäynnistys huolellisesti ja varmista sen onnistunut toteutus tarkistuslistalla. Aseta itsellesi erityisesti kaksi tavoitetta: yhtäältä ylläpitää verkkonäkyvyyttäsi ja toisaalta löytää mahdollisuuksia luoda perusta verkonäkyvyytesi parantamiselle uudelleenkäynnistyksen yhteydessä. Tätä varten tämä artikkeli on olemassa, jotta saat uudelleenkäynnistysoppaan ja autat minimoimaan riskit uudelleenkäynnistyksessä sekä saamaan todella erinomaisen työsuorituksen mahdollisuuksilla kestäviin, orgaanisiin SEO-menestyksiin.

Uudelleenkäynnistyksen aikataulu

Verkkosivuston uudelleenkäynnistyksen suunnittelu on tehtävä huolellisesti. On tärkeää ottaa huomioon seuraavat vaiheet:

• Olemassa olevan verkkosivuston analysointi ja nykytilan määrittäminen: On ensin analysoitava olemassa oleva verkkosivusto tunnistaaksesi sen vahvuudet ja heikkoudet.
• Tavoitteiden asettaminen: Verkkosivuston uudelleenkäynnistyksen tavoitteet on määriteltävä selkeästi. Näihin voi kuulua esimerkiksi konversioprosentin parantaminen, vierailijamäärien kasvattaminen tai siirtyminen uuteen CMS:ään paremmalla sisältönhallinnalla ja ylläpidettävyydellä.
• Konseptin kehittäminen: Analyysin, tavoitteiden ja kilpailija-analyysin perusteella verkkosivuston uudelleenkäynnistyksen konsepti tulisi kehittää. Konseptin tulisi kattaa seuraavat näkökohdat: suunnittelu, sisällöt, tekniikka ja SEO/markkinointi.
• Toteutus: Konsepti toteutetaan. Tähän kuuluu suunnittelun kehittäminen, sisältöjen luominen/muokkaus ja teknisten muutosten toteuttaminen.
• Testaus: Uusi verkkosivusto tulisi testata perusteellisesti ennen julkaisua varmistaaksesi sen virheettömän toiminnan. Tähän kuuluu myös selkeä tarkistuslista.
• Julkaisu: Uusi verkkosivusto julkaistaan sitten. Ja sitä testataan, arvioidaan ja mukautetaan edelleen reaaliajassa.

Tavoitteiden ja uudelleenkäynnistyksen strategian määrittäminen

Määritä tarkasti, mitä tavoitteita uudelleenkäynnistys tavoittelee. Tavoitteet voivat olla (ylempien syiden lisäksi): 

• Käyttäjäkokemuksen parantaminen
• Yleiskuvan selkeyttäminen
• Sisällön tarjonnan laajentaminen
• Designin modernisointi
• Myynnin ja ostoskorin arvon lisääminen 
• Siirtyminen toiseen CMS:ään helpommalla sisältönhallinnalla ja teknisellä ylläpidettävyydellä
• Tulevaisuuden helppo laajennettavuus ja päivitettävyys.

Ehdotus: Ensimmäisten kick-off-kokousten jälkeen tiimin kanssa yrityksessä – ennen kuin aloitat keskustelut toteuttavien virastojen kanssa – jokaisen projektin osapuolen tulisi kirjoittaa tavoitteet uudelleenkäynnistyksestä muistilappuun tai syöttää ne viestintätyökaluusi (esim. Slack). Kun kaikki osoittavat samanaikaisesti mainitsemansa tavoitteet, yllätyt siitä, kuinka eriävät mielipiteet ovat, vaikka tavoitteet on jo keskusteltu verbaalisesti kokouksissa aiemmin. Siksi on tärkeää kiinnittää tavoitteet myös kirjallisesti. Kun tunnet tavoitteesi tarkasti, voit tarkistaa jo varhaisessa vaiheessa UI-prototyypin, onko ne otettu huomioon konseptin mukaisesti.

Vaatimustenmäärittely antaa selvyyttä uudelleenkäynnistystilaukseen

Virasto tarvitsee tarjouksen laatimiseen kattavan projektibriefingin asiakkaalta. Yrityksillä on yleensä Word-dokumentti tai PDF valmiina, jossa hahmotellaan enemmän tai vähemmän yksityiskohtaisesti hanke. Sitten on lomakkeita tai järjestetään työpajoja, joissa virastot tuovat paremmin esiin asiakkaan kipupisteet tarjouksen tekemiseksi. Suurempia projekteja varten laaditaan vaatimustenmäärittely. Mitä yksityiskohtaisempi, sitä parempi. 

Vaatimustenmäärittely on tärkeä asiakirja verkkosivuston uudelleenkäynnistyksessä. Sen tarkoituksena on kirjata vaatimukset, tavoitteet ja odotukset uudelleenkäynnistykseen kirjallisessa muodossa. Hyvin laadittu vaatimustenmäärittely auttaa varmistamaan, että kaikki osapuolet – olivatpa se sitten kehitystiimi, suunnittelutiimi tai asiakas – ymmärtävät selvästi, mitä uudelleenkäynnistyksen aikana tulisi saavuttaa. Se on myös lähtökohta hyvin laskettulle ja sitovalle tarjoukselle toteuttavalta virastolta. Tässä ovat tiedot ja osat, jotka yleensä voidaan sisällyttää verkkosivuston uudelleenkäynnistyksen vaatimusmäärittelyyn:

• Tavoitteet ja tarkoitukset: Kuvaus uudelleenkäynnistyksen päämääristä, esim. käyttäjäkokemuksen parantaminen, näkyvyyden lisääminen hakukoneissa tai CMS:n vaihto suunnittelun päivittämisellä.
• Projektin laajuus: Selkeä määritelmä siitä, mikä sisältyy uudelleenkäynnistyksen puitteisiin ja mikä ei. Tämä voi kattaa sivujen lukumäärän, kolmansien osapuolien työkalujen integroinnin tai sisältöjen uudelleenjärjestelyn.
• Design-vaatimukset: Tiedot halutusta visuaalisesta suunnittelusta verkkosivustolle, mukaan lukien layouts ja yritysilmeohjeiden noudattaminen väreissä, fonteissa ja kuvissa.
• Toiminnallisuusvaatimukset: Haluttujen toimintojen ja käyttäytymisten yksityiskohtainen erittely verkkosivustolla, kuten yhteydenottolomakkeet, hakutoiminnot, sähköisen kaupankäynnin toiminnot jne.
• Tekniset vaatimukset: Teknologioiden määritykset, joita uudelleenkäynnistyksessä on käytettävä, kuten sisällönhallintajärjestelmän (CMS) valinta tai tiettyjen toimintojen toteuttaminen. Myös modernien kuvamuotojen (WebP, AVIF, SVG) käyttö kuuluu tähän.
• Manuaaliset ja automatisoidut varmuuskopiot ja revisiot sisällön muokkaamisesta.
• Sisältövaatimukset: Selkeät ohjeet sisältöjen tarkistamiseen, päivittämiseen tai uudelleenluomiseen, mukaan lukien teksti, kuvat, videot ja muut mediat. Metatietojen käsittely ja strukturoitujen tietojen käsittely.
• SEO-vaatimukset: viimeksi mainitusta kohdasta enemmän.
• Aikataulu ja merkkipaalut: Aikataulu, joka määrittelee suunnitellut aloitus- ja valmistumisajat uudelleenkäynnistykselle sekä tärkeät välitavoitteet.
• Budjetti: Tiedot uudelleenkäynnistyksen budjetista, mukaan lukien suunnittelu-, kehitys-, hosting- ja mahdolliset kolmannen osapuolen palvelujen kustannukset.
• Laadunvarmistus testityökaluilla: Testit ja laadunvalvontamenettelyt, jotka on suoritettava uudelleenkäynnistyksen aikana varmistaaksesi, että verkkosivusto toimii moitteettomasti.
• Ylläpito- ja tukivaatimukset: Jatkuvan ylläpidon ja verkkosivuston tuen vaatimukset uudelleenkäynnistyksen jälkeen.

Hyvin strukturoitu vaatimustenmäärittely on ratkaisevan tärkeä väärinkäsitysten välttämiseksi, projektin tehokkaan hallinnoinnin varmistamiseksi ja kaikkien sidosryhmien odotusten täyttämiseksi. Se toimii suuntaviivana ja viiteasiakirjana koko projekti tiimille ja auttaa varmistamaan verkkosivuston uudistuksen onnistumisen.

Kun suunnittelimme TutKit.com:n uudistusta siirtyessä kokonaan CodIgniter-kehyksestä Laraveliin, vaatimustenmäärittelymme käsitti 220 sivua – ei ainakaan houkutteleva näkymä toimistolle työstää.

Huomautus: Konseptista, suunnittelusta, toiminnoista ja käytetyistä tekniikoista ei käsitellä yksityiskohtaisesti artikkelissani. Uusi verkkosivusto tulee varmasti olemaan hieno. Suurin vaara uudistuksessa on itse asiassa teknisen käyttäjäkokemuksen ja OnPage-laadun heikkeneminen puuttuvien 301-ohjauksen jne. takia, mikä johtaa sitten sijoitus- ja näkyvyystappioon. Tätä estääkseen seuraavassa keskitytään erityisesti projektin onnistumisen turvaamiseen käyttäjäkokemuksen ja SEO-näkökulmasta.

SEO-vaatimusten määrittely uudelle verkkosivustolle

Asiakkaan briefing tai yksityiskohtaisempi vaatimustenmäärittely säätelee jo, mitä visuaalisesti, sisällöllisesti, toiminnallisesti ja teknisesti halutaan, ja on perusta sille, että toimisto voi laatia kustannusarvion.

SEO-näkökulmasta Relaunch-tarkistuslistan turvaamiseksi on tarkasteltava yksittäisiä kohtia. Erityisiä SEO-vaatimuksia aiheutuu esimerkiksi seuraavista:

• muuttuva URL-rakenne (URL-ohjauskartta!) ja muuttuvat linkkipolut
• muuttuva navigointi (tärkeää sisäistä linkitystä ja linkkihierarkiaa varten)
• muuttuvat teknologiat (CMS, JavaScript-kehykset, palvelimet, …)
• muuttuvat sisällöt (mahdollisia näkyvyyden menetyksiä hyvin sijoitetuista sivuista)

Sivut sijoittuvat Googlessa hyvin niiden sisällöllisen relevanssin vuoksi, minkä vuoksi kysymykset ovat tärkeitä: muuttuvatko olemassa olevat sisällöt tai yhdistyvätkö ne, häviävätkö sisällöt ja/tai lisätäänkö uusia? Muuttuuko sivustojen tai kategorioiden sisällöllinen rakenne? Nämä näkökohdat on johdettava SEO-vaatimuksiksi, jotka kuuluvat uudistusohjeistoon.

Siirretäänkö vanhojen sisältöjen metatietoja ja muuttuvatko ne? Miten sisältöä ylläpidetään ja ovatko sivuston sisällöt linkitetty strukturoituihin tietoihin?

Sijoitetaanko olemassa olevat tai uudet kuvat moderneihin kuvamuotoihin verkkosivustoille (WebP/Avif) ja kiinnitetäänkö huomiota kuvien SEO:on, jotta ne sisältäisivät puhuvat URL-osoitteet pienillä kirjaimilla, eli sijaan 1234.jpg => hotel-ostsee-warnemuende_suite-nachtigall.avif.

Samoin on varmistettava, että kuvatiedostoja käsitellään strukturoiduilla tiedoilla (ImageObject) ja <meta>-thumbnailit luovutetaan Googlille lisätäkseen kuvien upottamisen hakutulosten ja Googlen kuvien luettelointiin.

Mielenkiintoista on myös, miten käyttäjäsignaaleita voidaan parantaa. Esimerkiksi sisältösivuilla voitaisiin upottaa kuvavideoita, selitys- ja ohjevideoita. Jos Googleen tuleva käyttäjä napsauttaa videota ja katsoo sen, kasvaa käyttäjän viipymä (hyvä käyttäjäsignaali), paluu SERP-sivulle paranee myös (hyvä käyttäjäsignaali).

On myös tarkasteltava, miten sisällöllisiä osioita integroidaan sivuille, jotka täyttävät Googlen vaatimukset hyödyllisestä sisällöstä ja E-A-A-T-periaatteesta.

Googlelle ”hyödyllinen sisältö” on sisältöä, joka on käyttäjille relevanttia ja hyödyllistä. Se vastaa käyttäjän kysymyksiin kattavasti ja informatiivisesti, tarjoaa ratkaisuja ongelmiin ja tarjoaa arvoa, joka menee pelkkien markkinointiviestien yli.

Tässä on joitakin esimerkkejä hyödyllisestä sisällöstä:

• Ohjeet ja tutoriaalit: Nämä sisällöt auttavat käyttäjiä oppimaan uusia tehtäviä tai ratkaisemaan olemassa olevia ongelmia.
• Arvostelut ja vertailut: Nämä sisällöt auttavat käyttäjiä valitsemaan oikean tuotteen tai palvelun.
• Uutiset ja päivitykset: Nämä sisällöt pitävät käyttäjät ajan tasalla ajankohtaisista tapahtumista ja trendeistä.
• Infografiikat ja kartat: Nämä sisällöt voivat auttaa visualisoimaan monimutkaisia tietoja ja informaatioita.
• Blogikirjoitukset ja artikkelit: Nämä sisällöt tarjoavat syvemmän käsityksen tietystä aiheesta.

Google käyttää erilaisia signaaleja tunnistaakseen hyödyllisen sisällön. Niihin kuuluvat muun muassa:

• Käyttäjäkäyttäytyminen: Google seuraa, miten käyttäjät vuorovaikuttavat sisältöön, esimerkiksi kuinka kauan he viipyvät sivulla, miten usein he jakavat sen ja kuinka usein he arvioivat sen.
• Laatumerkit: Google arvioi sisällön laatua tekijöiden kuten relevanssin, kattavuuden ja ajankohtaisuuden perusteella.
• Käyttäjien palaute: Google ottaa huomioon myös käyttäjien palautteen, kuten arvostelut ja kommentit.
• Verkkosivuston ylläpitäjien tulisi huomioida nämä signaalit voidakseen lisätä mahdollisuuksiaan, että heidän sisältönsä luokitellaan hyödylliseksi.

EEAT-periaate on Googlen kehittämä käsite, joka arvioi verkkosivustojen ja verkkosisältöjen laatua. Se tarkoittaa asiantuntemusta, kokemusta, arvovaltaa ja luotettavuutta, eli asiantuntemusta, kokemusta, auktoriteettia ja luotettavuutta.

• Asiantuntemus viittaa siihen tietoon ja kokemukseen, jonka henkilöt, jotka luovat sisällön, omaavat. Google arvioi asiantuntemuksen koulutuksen, työkokemuksen ja palkintojen perusteella.
• Kokemus vahvistuu, kun sisältöä on luotu myös tietyn kokemuksen pohjalta, esimerkiksi todellisen tuotteen käytön, paikan todellisen vierailun tai jonkin tapahtuman kuvauksen perusteella?
• Arvovalta liittyy verkkosivuston tai verkkosisällön maineeseen ja maineeseen. Google arvioi arvovaltaa tekijöiden kuten takaisinlinkkien, sosiaalisen median toiminnan ja käyttäjien arvostelujen perusteella.
• Luotettavuus liittyy verkkosivuston tai verkkosisällön luotettavuuteen ja uskottavuuteen. Google arvioi luotettavuutta tekijöiden kuten yksityisyyden, turvallisuuden ja läpinäkyvyyden perusteella.

Mitkä SEO-vaatimukset liittyvät olemassa oleviin ja uusiin toimintoihin frontend- ja backend-suhteen? Tässä on esimerkiksi mainittu:  

• Indeksöitävyys (merkityksellisen sisällön on oltava näkyvissä ja indeksoitavissa myös ilman JavaScriptiä)
• Verkkosivuston tavoitteen selkeys ja selkeys Call-to-Actionista (toivotut toimet kohderyhmältä sivuilla)
• Dublikaattisisällön välttäminen esimerkiksi automatisoidusti luoduilla kategoria- tai sivukopioilla vaihtoehtoisilla artikkeleilla
• Tehokkaan PageSpeedin varmistaminen välttämällä liian monia JavaScript- ja CSS-tiedostoja sekä käyttämällä moderneja kuvamuotoja (WebP/AVIF)

Nämä SEO-vaatimukset kuuluvat projektin määrittelyyn ja erittelyyn, mutta ne tulisi myös sisällyttää testityökaluun perustuvaan tarkistuslistaan tai IST-SOLL-vertailuun projektin laadunvarmistuksessa sekä lisäksi toimistopalvelun hyväksymiskriteeriksi. Lisätietoja alla.

Sisäisten ja ulkoisten projektiosapuolten määrittely

Määritä projektiosapuolet - tässä asiakkaan tai verkkosivuston omistajan näkökulmasta:

• Kuka vastaa projektin johtamisesta ja tekee lopulliset päätökset?
• Kuka on vastuussa yhteistyöstä ja viestinnästä toimiston tai asiakkaan kanssa?
• Kuka vastaa sisäisestä projektinhallinnasta?
• Kuka valmistelee sisäisesti sisällöt ja avustukset toimistolle?
• Kuka toteuttaa käyttäjäkokemussuunnittelun?
• Kuka toteuttaa kehityksen?
• Kuka raportoi toimistopuolelta asiakkaalle sovituin väliajoin?
• Kuka vastaa toimiston/asiakkaan testauksesta ja laadunvarmistuksesta?
• Onko ulkopuolista konsulttia otettu mukaan (esim. SEO- tai oikeudelliset vaatimukset)?
• Kuka hyväksyy tehtävät? Kuka hyväksyy tehtävät lippujärjestelmässä niiden käsittelyn jälkeen?
• Kuka on informoitava mihinkin aikaan (työntekijät, asiakkaat, kumppanit, mainoskampanjan hoitajat, …)?

Neljä tärkeää kohtaa ulkoisten projektinjärjestäjien valinnassa

1. Onko toimisto toteuttanut yhden tai useamman vastaavan projektin? Onko olemassa referenssejä? Onko asiakaslausuntoja ja olisiko myös mahdollista pitää asiakastapaaminen toimiston kanssa – mikä on suositeltavaa suurissa yksilöllisissä kehityshankkeissa?
   
2. Tarjoaako palvelu ja tekninen toteutus (CMS/verkkokauppa/framework) jo nyt kaikki vaatimukset, jotka liittyvät uudelleenkäynnistykseen? Onko olemassa yksilöllisiä toimintoja tai vaatimuksia, jotka on vielä ohjelmoitava (myös liitännäisten tai moduulien avulla)? Onko tarjouksessa joitakin palveluita jätetty pois tai merkitty myöhemmin huomioitaviksi, mutta jotka ovat ratkaisevia projektin onnistumisen kannalta? Tärkeintä on, ettei tule uusia ongelmia, jotka ovat suurempia kuin relaunchin todellinen syy.
   
3. Sopiiko toteuttava toimisto tai palveluntarjoaja niin tiiminsä koon, alueellisen sijainnin kuin (mahdollisesti Kununusta arvioiden selvitettyjen) työntekijävaihtuvuuden suhteen myös jatkossakin yritykselle?
   
4. Onko suora yhteys toteuttavaan suunnittelu- ja kehitystiimiin mahdollista? On järkevää tutustua todelliseen, toimiston puolelta työskentelevään projektitiimiin. Hyväntuuliset ja taivaasta lupaavat myyntiammattilaiset saavat toimeksiannon ja eivät ole enää myöhemmin vastuussa. Siksi suoran yhteydenpidon toteuttavaan tiimiin tulisi olla sovittu.

Neljä vinkkiä omaksi turvaksi tässä yhteydessä

1. Asiakkaana kiinnostaisin toimiston käyttämää teknologiaa. Sitä, mitä tarjousasiakirjassa lukee, kannattaa googlata ”CMS + Haitat” tai ”CMS + Kokemukset”. Sinun tulisi tietää tarkkaan, mihin ryhdyt. Järkevää on luottaa avointen lähdekoodiratkaisujen käyttämiseen. Ymmärrän, ettei se aina ole mahdollista. Parasta olisi varmistaa, että käytetyllä tekniikalla on mahdollisimman suuri kehittäjäyhteisö, jotta et lopulta päädy toimiston omistamaan erilliseen ratkaisuun, jota vain toimisto voi käsitellä, mikä saattaa ajan myötä aiheuttaa merkittäviä haasteita.
   
2. Varmista myös, että saat rajoittamattomat käyttämis- ja muokkausoikeudet toimiston suorittamaan työhön, jotta sinulla on jatkuvasti oikeus kehittää verkkosivustoasi sisäisesti tai ulkoisesti. Tällainen ehto kuuluu työsopimukseen.
   
3. Jos yrityksessäsi on teknistä osaamista ja tiimilläsi on järjestelmänvalvojia, ohjelmistokehittäjiä tai vastaavia, on järkevää perustaa GIT versiohallintaan ja käyttää JIRAA (tai vastaavaa työkalua) projektinhallintaan tai lippujärjestelmään ensin itse omalla tililläsi. Sitten annat toimistolle täydet käyttöoikeudet ja työ voi alkaa. Mitä suurempi projekti on, sitä karkeammaksi ja tuskaa aiheuttavammaksi se voi muodostua. Siksi on hyvä, että sinä olet ratkaisevien kirjautumistietojen ja tiliensä omistaja. Tiedän kuitenkin, että tämä suositus toimialallisesti voidaan noudattaa vain harvojen asiakkaiden toimesta.
   
4. Toisinaan niin on, että toimistot tarjoavat suoraan asiakkaille webhotellipalvelua. Me emme itse ole sen faneja, koska se lisää riippuvuutta asiakassuhteessa, toisaalta ajattelemme, että webhotellit ovat parhaiten sopivia webhotellipalveluihin, koska ne ovat erikoistuneet siihen. Olemme myös itse asentaneet ja ylläpitäneet palvelimiamme ja käyttäneet paljon henkilöresursseja ja aikaa. Palaamme takaisin. Nyt järjestelmämme toimivat Saksan suuren webhotellin pilvipalvelimilla ja olemme onnellisia. Kiinnitä webhotellipalvelussa ehdottomasti huomiota siihen, että mukana on jo palvelinsivuston varmuuskopioita, jotka voidaan palauttaa muutamalla napsautuksella.

Ajanjakson ja julkaisupäivän määrittäminen

Uudelleenkäynnistys tapahtuu useissa projektisprinteissä. Nämä voivat meidän virasto- kokemuksemme mukaan olla:

• Nykytila kirjataan muistiin (testityökalujen avulla, mutta myös kirjallisesti huomioiden asiakaspalautteet siitä, mikä toimii hyvin ja missä on parannettavaa)
• Tutkimusvaihe kilpailuanalyysillä ja ratkaisujen/inspiraation etsimisellä
• Rautalangasta vääntäminen
• Sovelluksen käyttöliittymäsuunnittelun toteuttaminen
• Frontend- ja backend-kehitys
• Tietomigraatio tai sisällön tuonti (automatisoitu/käsityönä)
• Rakenteelliset ja sisällölliset sisältöoptimoinnit (teksti ja kuva) & SEO-sprintti

Projektisprintit menevät päällekkäin, koska projektin käsittelyssä uusia projektiosapuolia tulee mukaan.

On tärkeää määrittää yksittäisten projektisprinttien aikataulu ja sopia siitä osallisten kanssa.

Asentaako toimisto asiakasta varten suurempaa projektia varten oman Slack-kanavan nopeampaan kommunikointiin?

Vinkki tässä vaiheessa: On hyvä, jos toimisto käyttää erittäin varhaisessa vaiheessa napsautettavia prototyyppejä, siis jo langanmuotoisen suunnittelun aikana ja erityisesti käyttöliittymäsuunnittelun esittelyssä ja tarkistuksessa. Asiakkaat pääsevät siten paremmin tuntemaan sivuston kokemuksen. Yksinkertaiset JPG- tai PNG-tiedostot ehdotuksina taitavat olla nykyään vanhentuneita. Niiden sijaan tulisi olla napsautettavia prototyyppejä, jotka on laadittu Sketch-, Figma-, Adobe XD- tai muulla ammattityökalulla.

Tässä varhaisessa vaiheessa muutokset ovat helppoja toteuttaa. Jos sivuston toimintoja ja osioita on jo kehitetty, muutokset ovat huomattavasti vaivalloisempia ja johtavat ehkä uusiin neuvotteluihin, jotka eivät ole lainkaan houkuttelevia.

Tässä on kerran nähtävissä, miltä tällainen prototyyppi voi näyttää mobiilikäyttöliittymäsuunnittelussa klikkausreittien yhteenvedossa:

On selvitettävä, millä tavalla asiakkaan puolella käynnissä olevia testejä voidaan tehdä. Kehittäjien on testattava paikallisia töitään myös yhdistämisen jälkeen vaihejärjestelmään. Se saattaa kuulostaa banaalilta, mutta jokainen kehittäjää kanssa työskennellyt tietää heti, mitä tarkoitan. Sitten sen, joka vastaa toimisto puolen laadunvarmistuksesta, pitäisi testata lippu tai toiminto. Vasta sen jälkeen lippu vapautetaan asiakkaan testausta varten. Asiakkaan ei tulisi tuntea itseään alfa-testaajaksi, vaan tulisi jo löytää toimiva järjestelmä neljän silmäparin toimesta. Toimisto on alfa testaaja, ja asiakas on beta testaaja! Onko toimiston lipputietojärjestelmään edes pääsyä?

On myös syytä määritellä kirjallisesti, että toimiston raportit asiakkaalle tapahtuvat tietyllä taajuudella. Esimerkiksi joka perjantai voisi lähettää sähköpostin nykyisestä työn tilanteesta, tarvittavista palautteen silmukoista tai avustuspyynnöistä. Tämä on myös vinkki virasto kokemuksestamme: On hyvä, ettei asiakasta jätetä epätietoiseksi viikonlopusta. Silloin hän käy vain huonoja ajatuksia. Parempi informoida hyvin, mitä on tapahtunut ja mitä on tulossa seuraavalla viikolla. Selkeys auttaa kaikkia pysymään mukana hyvillä mielin.

Julkaisupäivä tulisi myös määrittää. Parkinsonin laki sanoo, että työ täyttää käytettävissä olevan ajan sen suorittamiseen. Toisin sanoen mitä enemmän aikaa tehtävän suorittamiseen on käytettävissä, sitä enemmän aikaa siihen kuluu, riippumatta tehtävän todellisesta monimutkaisuudesta tai työmäärästä. Suunniteltu valmistuminen olisi kirjattava myös urakkasopimukseen. Päivämäärän laiminlyönti voi jopa sisältyä sopimussakon määräämiseen sopimukseen. Yleisenä periaatteena on, että viivästymisestä voidaan määrätä sopimussakkoja, jotka vastaavat 0,2 % sopimussummasta jokaista viivästyspäivää kohden, ja enintään 5 % sopimussummasta. Sopimussakkoa ei välttämättä tarvitse vaatia asiakkaalta, mutta se antaa joustovaraa saada toimistolta muutamia erityistoiveita korvauksena.

Tärkeää: Älä julkaise perjantaina. Älä myöskään pyhien välillä tai yrityksen päätösaikaan. Suosittelemme itse asiassa suuria uudelleenkäynnistyksiä sunnuntai-iltana maanantaiaamuna, erityisesti jos IP-osoite muuttuu, jotta DNS-asetukset päivittyvät useimpiin tarjoajiin maanantaina, mikä tapahtuu usein myöhään aamupäivällä, jos DNS-kirjaus on tehty yöllä. Näin jää käytännössä vielä 4,5 työpäivää Live-testaukseen ja virheiden korjaamiseen.

Verkkosivustosi nykytilan kirjaaminen

Nykytila on otettava huomioon työn aloittamisen yhteydessä. Nykytilassa kirjataan ylös, millaiset ovat tekniset mittaukset parametreille. Oikealla voit kirjata tavoitteet:

Luettelossa loeydaet meidaen suosiman SEO-tyoeoealyn Seobilityn OnPage-tekijoiden tarkastukseen, josta olen myoes julkaisnut SEO-koulutuksen. Siella on monia vastaavia tyoeoeae kuten Sistrix, Semrush, Ryte, SE Ranking, Screamingfrog jne. SEO-tyoeoealan tyoeoealyn tarkoituksena on erityisesti tunnistaa ja korjata tyypilliset OnPage-virheet. Taellae Seobility rakentaa arvioinnit kahteen taerkeaempaeaen osa-alueeseen: Tekniikka & meta, rakenne ja sisaaltoe, kuten Seobilityssa arvioidaan. Loeydaet samanlaisina myoes muissa SEO-tyoeoevalineissae. On taerkeaeae, ettae aina suoritetaan kattava tarkistus, joten KAERKIEN sivut kootaan eivaet pelkkae alku Sivut kootaan SEO-tyoeoevaelineeseen, joten on taerkeaetae sisaeltaeae kaikki sivut ja ei vain kotisivu, Sitten arvioi olemassaolevan tuloksen pisteet tai virheen arvosta ja tavoitearvo on taemaen jaetaeksi tarkistuksen ja optimoinnin jaetaeksi. Seobilityssa on toivottavaa, ettae arvo on 90 tai sitae korkeampi. Lisaeksi loeydaet muita tarkoituksia vaestoeenmukaisia tyoeoevalineitae. Oleellista on, ettae kaetetaeaen korkeat tiedot.

Taemae on esimerkiksi vointimme OnPage-laadun suhteen:

Ja seuraa voimme mitata kaeeyttajien signaalit tilastollisilla mittareilla kuten poistumisprosentti, sivut/kaeeynti, aika jne. Jos Google Analytics tai muu analyysityoeoevaline on asetettu tietosuojakonformisti, naemae tiedot tulisi ottaa huomioon olemassaolotilan kirjaamisessa. 

Myoes taellainen taetulee luoda, joka voidaan generoida taellae ilmaiseksi: https://www.seobility.net/de/backlinkcheck/

vanha sitemap.xml varmuuskopioidaan sekae Full-Backup sivustosta Seuraavaksi kaikki asiaan liittyvaet sivustot tulisi siirtaeae Google Sheetiin, joka toimii laehtoeitilanteena URL-ohjauskartalle. Taellainen CSV-luettelo voidaan helposti viedae SEO-tyoeoevalineen, kuten Seobilityn avulla. URL-ohjauskartassa on kaikki taerkeaet sivustot ja ulkoisista backlinkkeista (ks. Backlink-Liste) ohjatut sivustot, jotka on ohjattava myoehemmin johtuen muuttuvista sivujen URL-osoitteista. Ohjautuvat URL-osoitteet on suunnattava uusiin vastaaviin URL-osoitteisiin. On taerkeae, ettae estetaeaen ohjelusketjuttaminen! Vaenhyvaet ohjat tulisi osoittaa suoraan uuteen loppu URL-osoitteeseen. Myoes PDF-tiedosta ja kuvista tulisi huolehtia, joihin linkki viittaa, jotta ne ohjautuvat oikein ja eivaet johda virheilmoituksiin.

Tuloksia mittaavat ohjaukset perustuvat URL-ohjauskarttaan 301-ohjauksina, .htaccess-tiedostossa, kautta Redirect-Karttojen kautta Vhost-konfiguraatioon tai tietokantaratkaisuun. Asiakkaan tulisi pystyaehoidlae itseaen oaen. On myoes taerkeaetae varmistaa, ettae ohjaukset ovat pysyviae.

Se olisi myoes suositeltavaa, ettae jokainen sivutyyppi varmennetaan koko sivun kaappaamisella . Taellae tavalla voi varmistaa, ettae vanha sisaaltoe on kopioitu yliv ja jos sivutyyppejae ei siirretaey kaeytoennoenneen jne.

Olemassa olevien sivujen, toimintojen ja sisaollon perusteella ja mittaus tuloksien perusteella on nimettvae, mitae katsotaan jo hyvae sekae mitkae alueet on tunnistettu potentiaaliksi optimointiin, mika paranneltava uudelleenkaeyttoe

Tarkistuslista: Ennen uudelleenlanseerausta

Kun kaeyttoeoenliittymaesuunnitelma on vahvistettu ja toimisto on kehitysvaarassa, seuraa taemae tarkistuslista, joka listaar olennaiset kohdat ennen lanseerauspaeivaeae taemae lista luetteloon:

1. Dev-ympaeistoekseen kannettu kaikille osallistujille testattavaksi
2. Dev-ympaeistoet pyoerivae noindeksoitu
3. Paeaesyoikeus testintekoesarjoille Dev-ympaeistoeoessae (IP-osoitteensuojaus tai http-kirjautuminen) on otettu kaeyttoeon
4. Dev-ympaeistoemisen kokoonpano vastaa mahdollisimman paljon live-jaerjestelmaen kokoonpanoa
5. Dev-ympaeistoen sivurakenne vastaa myoes tulevaa live-sivua
6. Vanhojen tietojen siirto on suoritettu
7. Unionilappieiden sovellukset on tehdyt
8. Kuva-SEO on tehnyt
9. 301-ohjaukset perustuvat URL-ohjauskarttaan
10. OnPage-tarkistus Seobilityssa suoritettu, virheet korjattu, tavoitetta arvot saavutettu
11. Open Graph -tiedot ovat kelvolliset
12. Rakenteelliset tiedot ovat kelvolliset
13. Sivujen nopeustarkistus on suoritettu kaikille sivumalleille, tavoitetta arvot saavutettu
14. Sisaeltoe evaeiskseaevae toimii
15. Turvalisyyshelpot ovat asennettu
16. Esteettoemyys on annettu, tavoitetta arvot saavutettu
17. Hreflang on kelvollinen (kieliversioille)
18. Laillisiet tekstit (kayttoaehdot, yhteystiedot, peruutusoikeusilmoitus, tietosuoja) on paivitetty, GDPR-yhteensopivuus on annettu
19. CMS:n, kehysohjelmien, kaeytetyt kokoonpanot ja moduulit on ajan tasalla
20. Lopullinenselain- ja laitekohteinen toiminnantarkistus ei tuottanut virheita
21. Lopullinen asema ja lanseerauspaeivaet on idea
22. Taeysi varmuuskopiota on luotu

Strukturoidun datan kaeyttoe (Schema-Markup) - ks. kohta 12 luettelossa - ei taella heijastele riittaevaesti. Tutustu aiheeseen ja lue, mitae Google sanoo rakenteellisista tiedoista haun tuloksissa. Google arvottaa entistae enemmaen validia tietoa tehdassuunnittelun mukaisesti SGE: n aikana, joka on Kiin tuottama hakutulokset. Myoes Googlen Helpful Content Update edellyttaa, ettae sisaalto on paljon vahvempi asiantuntemuksen, kokemuksen, auktoriteetin ja uskottavuuden kautta. Rakenteelliset tiedot ovat osa ratkaisua, joka yhaedistae helpottaa Googleen validoiti tietoa. Kaeytae strukturoitujen tietoihin liitettyjae, kun otat strukturoituja tietoja kaeytoeen, kaeytae Schema-Markup-Validatora, mutta tarkista sivusi myoes Structed Data Linterin avulla, jotka Google suosittelee ja linkittaa myoes PageSpeed Insightsiin antaan laajempia tietoja koodivirheistae, joita liittyy strukturoitujen tietojesi kaeytoennoen.

Rakenteisten tietojen käyttö verkkosivustoilla ei ole enää vaihtoehto, vaan välttämättömyys. Google haluaa sinulta päteviä ja uskottavia sisältöjä. Jos et halua jäädä jälkeen tekoälyavusteisissa hakutuloksissa, huolehdi skeeman merkinnöistä sivuillasi!

Kohdan 16 yhteydessä esteettömyys mainitaan ensimmäistä kertaa tässä artikkelissa. PageSpeed Insights -analyysien yhteydessä esteettömyydellä on oma osionsa, ja vihreät numerot sen kohdalla ovat toivottavia. Testi siitä, onko sivu esteetön vai ei, tulisi tehdä PageSpeed Insights -analyysien lisäksi myös osoitteessa https://www.accessibilitychecker.org ja/tai https://wave.webaim.org. Erityisesti jos uudistus on tulossa, tämä kohta tulisi ottaa huomioon pakollisena, koska esteettömyyttä vahvistavasta laista tulee 2025 alkaen ongelman ydin verkkosivustoille. Tarkista tällä työkalulla ei vain aloitussivua vaan jokaista sivutyyppiä - sama pätee PageSpeed-testauksiin!

Uudistuksen yhteydessä tulee usein muutoksia ja päivityksiä oikeusteksteihin. On tärkeää muistaa tämä hyvissä ajoin, että tekstien tulisi olla saatavilla mahdollisesti lakimiehen kautta tai oikeusgeneraattoreilla. Samoin tulisi ottaa huomioon tilaussopimukset, jos esimerkiksi uusi webhotelli on käytössä tai uutiskirjepalvelu muuttuu. 

Kohdan 18 päivitykset sisältöhallintajärjestelmään, käytettyihin JavaScript-kirjastoihin, sekä asennettuihin moduuleihin ja liitännäisiin ovat yhtä aliarvostettuja kuin tärkeitä. Uudistus voi kestää useita kuukausia ja pidempään. WordPress-järjestelmässä on helppoa havaita, että ennen uudistuspäivää saatavilla on ehkä useita päivityksiä. Asiakkaiden tulisi varmistaa, että uusimmat versiot ovat käytössä Going-Live -hetkellä.  

Kun ulkopuoliset palvelut muuttuvat, tulee mukaan lisää tehtäviä, jotka tulisi mainita tarkastuslistalla, kuten esimerkiksi uutiskirjepalvelun muutoksen yhteydessä: 

• Uutiskirjekontaktien tuonti uuteen NL-palveluun
• Yhdistäminen uutiskirjepalveluun sivustolla rekisteröitymiskaavakkeessa
• Käyttöoikeussopimus
• Uusien postausten luominen
• ja niin edelleen 

Koko kehityssprintin ajan suoritetaan luonnollisesti jatkuvaa testausta toiminnoille jne. On järkevää tehdä erittäin yksityiskohtainen tarkastuslista testeihin, jotta mikään ei unohdu. Ei riitä, että sekä toteuttava toimisto että asiakas klikkailevat vähän sinne päin. Relaunchimme jälkeen TutKit.comilla meidän hyväksymistarkastuslistassamme oli varmasti 1 000 riviä. Ja näin toimimme edelleen: tärkeiden merkittävien päivitysten jälkeen tarkastamme noin 70 vuorovaikutusta tarkastuslistan avulla Chromella, Safarilla ja Androidilla.

Tarkastuslista: Uudistuspäivä ja seuraavat päivät

Uudistuspäivä on koittanut eikä ole perjantai eikä päivä pyhäpäivien välissä. Uusi verkkosivusto menee liveksi, DNS-asetukset ovat päivitetty. Nyt on aika tarkistaa ja arvioida kaikki uudelleen. Tarkista seuraavat asiat: 

1. tarkista robots.txt:stä, että roboteita ei ole estetty 
2. Liven ympäristö toimii indeksillä, seuraa.  
3. Canonical-tagit on asetettu oikein
4. Tarkista sivun lähdekoodista absoluuttiset polut (Linkkipolut testiympäristöstä Live-sivulle)
5. Uudelleenohjaus http - https toimii ilman/with www kohti kohdesivua aloitussivulle ja alisivuille
6. Tarkista ohjaukset URL-ohjauskartalla, samoin uudelleenojennusketjujen olemassaolo
7. OnPage-tarkastuksen Live-sivulla Seobilitylle tekniikkaan & Metaan, rakenteeseen ja sisältöön liittyen ... erityisesti tarkistettava Noindex-sivut, jotka Seobility antaa
8. Open-Graph-tiedot ovat päteviä
9. Rakenteiset tiedot ovat päteviä
10. Pagespeedin tarkistus kaikille sivutyypeille on suoritettu, tavoitearvot on saavutettu
11. Cookie-käytäntö Consent-Cookie-Toolilla toimii, kuten pitääkin
12. Turvallisuusotsakkeet on asetettu
13. Esteettömyys on onnistunut
14. Hreflang-tarkastus monikielisillä sivustoilla (https://app.sistrix.com/de/hreflang-validator)
15. Lopullinen selain- ja laitetestaus osoitti virheettömyyden
16. Uusi sitemap.xml lähetetty Google Search Consoleen
17. Uudet kohdesivut päivitetty Google-Ads-kampanjoihin
18. Tiettyjen verkkotunnusmuutosten osalta ajattele linkkejä sosiaalisissa medioissa, sähköpostiallekirjoituksissa jne.

Käytämme dev-ympäristössämme Mailhogia testataksesi sähköposteja paikallisesti. Tällaisissa tapauksissa on tärkeää, että SMTP-tiedot oikeiden sähköpostien vastaanottoa varten live-järjestelmässä ovat asetettu oikein, jotta sähköpostit menevät sinne minne pitääkin.

Lisäksi tulisi huomioida, että maksupalveluntarjoajilla kuten Paypalissa dev-järjestelmässä on Sandbox -tila käytössä, kun taas livetilanteessa tulee olla oikea yhteys.

Seuraavina päivinä on erityisen tärkeää seurata Google Search Consolea. Kiinnostavaa on luonnollisesti nähdä, miten hakukoneresultaatit muuttuvat. Kiinnitä erityistä huomiota odottamattomiin muutoksiin ja virheilmoituksiin:

1. Rauballitus: Isäntätila ... robots.txt-pyyntö, DNS-tarkistus, palvelinyhteys
2. Rauballitus tilasto ... pyynnöt, latauskoko, keskimääräinen vasteaika
3. Klikkaukset SERP:issä
4. Ilmennykset SERP:issä
5. Keskimääräinen CTR SERP:issä
6. Keskimääräinen SERP-sijoitus
7. Core Web Vitalsin suorittaminen 

Etenkin Google Search Console varoittaa sinua virheistä kuten esim. URL-virheet, Href-Lang-virheet, sivujen indeksointi levittäen indeksoitu/ei indeksoitu. Ei-indeksoitua varten on oltava syy (ohjattu, noindex)…). Sieltä voit myös nähdä duplikaattisisällön tai muita ongelmia. Jos Search Console raportoi sinulle ongelmia rakenteellisissa tiedoissa tai Core Web Vitalsissa, tutki syytä tarkemmin. Live-tietojen avulla saat esimerkiksi tietää, että sivustollasi on Core Web Vitals -ongelmia korkean PageSpeedin huolimatta, esimerkiksi CLS-virheitä. Täältä näet hyvin, mitä hyppyjä on mahdollista tehdä sivuston muutostöiden yhteydessä:

Voit saada suoraan näkyviin huonoja tai optimoitavia URL-osoitteita. Valitse URL-osoite ja tee siitä PageSpeed-testi PageSpeed Insightsissä. Sieltä saat ohjeet siihen, miksi Core Web Vitalsia ei täytetä, ja mitä voit tehdä virheiden korjaamiseksi. Klikkaa lisätietoja varten alaspäin osoittavaa pientä nuolta. Näitä suosituksia pystyvät yleensä noudattamaan vain kehittäjät. On kuitenkin tärkeää, että pystyt tunnistamaan ongelmat, jotta voit käsitellä niitä sitten yhdessä virastosi kanssa.

Tarkastele myös analyysityökalujen tietojasi, esimerkiksi Google Analytics 4:ää. Pidä mielessäsi myös mittarit, jotka voit kerätä järjestelmätasolla, kuten varaukset, konversioaste, ostoskorin arvo, ostot/liikevaihto päivässä, uutiskirjautumiset, yhteydenottopyynnöt, tiettyjen sisältöjen lataukset tai video katselut. 

Rauballitus tilastot Google Search Consolesta ovat oleellisia tarkasteluja seuraaville päiville. Löydät ne asetusten kautta vasemmassa valikossa. Sinun pitäisi nähdä suoraan enemmän Raub-toimintaa. Jos näin ei tapahdu, ovatko Raub-virheet olemassa?

Isäntätunnus antaa sinulle suoraan näkyviin virheet, kuten tässä esimerkiksi Relaunjan jälkeen, jolloin Raubanpyynnöt robots.txt -tiedostoon ovat epäonnistuneet ja myös palvelinyhteys on ajoittain katkennut:

Mielenkiintoista on myös, mitä Raub-statiikka kertoo. Relaunchin jälkeen Raubanpyynnöissä tapahtuu yleensä herääminen. Näet myös, kartoitetaanko vieläkö 404-sivuja hakee. Jos jotkut eivät sovi kuvioon, keskustele niistä kehittäjien kanssa.

Huomaat, että palvelimesi, PageSpeedisi ja koodisi ovat suhteellisen hyviä, kun sivuston vasteaika on alle 400. Mitä lähemmäksi se pääsee 1000 ms, sitä suotavampaa on tehdä PageSpeed-optiointia, esimerkiksi vähentämällä tietokantakyselyjä ja vahvistamalla palvelimen tehoa (esim. lisäämällä laskentatehoa, päivittämällä uusimpaan palvelinohjelmistoon, siirtymällä HTTP2 tai HTTP3:lle (Nginx)).

Tulevaisuudessa yksittäisten verkkosivustojen Raub-budjetti on todennäköisesti rajoitetumpi, koska verkkosivustoilla on yhä enemmän (AI-)sisältöä, joten on hyvä pyrkiä saamaan hyvä arvo sivuston vastausajalle, jotta robotit pystyvät raappaamaan mahdollisimman paljon sivustoosi käytettävissä olevaan aikaan.

Relaunch-tarkistuslista lataus

Yllä olevat upotetut Relaunch-tarkistuslistat ovat saatavilla myös PDF-muodossa latausmahdollisuutena täällä. Lataa ne ja varmista projektisi menestys!

Muutaman virastonpitäjän tunnustukset

Seo-vaatimukset tarkistuslistalla voisivat myös saada yksityiskohtaisia ohjeita kuten H1:stä H6:een jne. Tavoitearvojen määrittäminen testityökaluissa lyhentää onneksi koko uudelleenkäynnistystarkistuslistan sisältöä, koska testityökalujen huippuarvojen saavuttaminen edellyttää puhtaan koodin, modernin teknologian ja SEO-OnPage-tekijöiden huomioon ottamista jne. Muuten uusimmat verkkostandardit ja tekniset sekä SEO-vaatimukset olisi muotoiltava erittäin yksityiskohtaisesti vaatimusselostukseen, johon asiakkaat eivät välttämättä ole ammatillisesti kykeneviä. Jos toimistojen on saavutettava korkeita arvoja testityökaluissa, niiden on työskenneltävä Best-Practicen mukaan - myös toimistoille uusi kokemus :-)

On aika tunnustaa. Seo-vaatimusten määrittäminen sekä tarkistuslistamainen toiminta tavoitearvojen varmistamisessa eri testityökaluissa edustavat ideaalia, jota todellisuudessa harvoin löytyy. Se riippuu:

• asiakkaan budjettirajoituksista
• toimiston voittoa tavoittelevista intresseistä
• rajoituksista käytettyjen teknologioiden osalta
• sekä valitettavasti: tietämättömyydestä ja osaamattomuudesta molemmilla puolilla

En voi syyttää asiakasta. He etsivät ammattitaitoista apua ja lähes jokainen digitoimisto mainostaa verkkosivuillaan ja white paperissaan, että hakukoneoptimointi on yksi heidän ydinosaamisalueistaan. Aina on myös referenssejä, jotka todistavat, että uudistuksen jälkeen verkkojulkisuus on kasvanut kolminkertaiseksi, viisinkertaiseksi tai jopa kymmenkertaiseksi. Se, että 10 kävijästä tulee nyt 100 päivässä, on toki 1000 prosentin kasvu, mutta ei vielä menestys. Monet hakukoneiden menestykset vaativat, että kilpailijat ovat digitaalisesti vielä paljon heikommin valmistautuneita.

Toimistot tekevät edelleen keskitasoista työtä vanhanaikaisten menetelmien avulla, koska he eivät vieläkään käytä moderneja työkaluja laadun varmistamiseksi, vaikka heidän postauksissaan, referensseissään ja hyvissä käytännöissä sanotaan, että heillä on SEO-osaamista. Ehkä tällaiset toimistot ovat tiedonjättiläisiä, mutta myös toiminnaltaan kääpiöitä. Se kuulostaa kovalta, mutta se on totuus. Todellakin. Tutustu tarkemmin! Ota yläpuolella oleva tarkastuslista ja syötä alueesi paras toimisto sen URL-osoitteella edellä mainittuihin työkaluihin. Ja sitten ota uusin verkkosivuviittaus, jonka löydät toimistosta, ja toista se. Mitä tuloksia näet? Aivan niitä, joita voit odottaa yhteistyössä. Voit tarkistaa myös omat referenssimme ja huomaat, että emme saavuta kaikkialla huippuarvoja. Tällainen lähestymistapa datalla ohjatun laadun varmistamiseen on kasvanut projektistamme toiseen ja on vakiintunut erityisesti töidemme kautta TutKit.com:ssa.

Tällaisia tarkastuksia voit tehdä melkein jokaisen toimiston kanssa, koska vain harvat todella työskentelevät datalla ohjatun laadun varmistamiseksi, koska kukaan ei pysy markkinoilla omien projektien kanssa vuosia ja kilpailee kovassa kilpailussa verkkojulkisuudesta kansainvälisten toimijoiden kanssa ja koska toimistoja voi olla lähes yhdentekevää, onnistuuko projekti vai ei, niin kauan kuin toimistolasku maksetaan ja asiakkaat voivat juhlia hienoja (mutta laadullisesti keskinkertaisia) verkkosivustojaan postauksissaan ja palkinnoilla. Erityinen ironia on siinä, että usein juuri SEO-toimistot pärjäävät huonoiten omilla verkkosivuillaan yllä mainittujen testityökalujen perusteella, koska heillä on usein vain yksi kikka valmiina ... asiakkaan avainsanoihin räätälöity sisältöpaketti verkkosivustolle. Muita teknisiä vaatimuksia varten puuttuu usein yksinkertaisesti pätevät kehittäjät.

Hyödyllistä on myös, jos toimisto sijaitsee muualla eikä asiakasta kohtaa kaupassa vastaava toimiston työntekijä, jolla on vastuussa kaksinumeroisista prosentuaalisista sijaisnäkösäädöistä uudistuksen jälkeen. Mutta tätä sijaisnäkösäädöstä asiakkaat tuskin tarkistavatkaan, sillä vaikka kaikilla on evästelausekebanneri, harvat todella analysoivat lukuja ja vedet niistä toimenpiteitä. Pahimmassa tapauksessa mainosmäärää on vain lisättävä. Onneksi asiakkaat eivät myöskään useinkaan tiedä, että organinen sijoittuminen nykyään riippuu tarjonnan ylitarjonnasta laadullisesti vertailukelpoisten verkkosivustojen osalta erityisesti teknisistä parametreistä, käyttäjäsignaaleista ja (edelleen) backlinkeistä. Älykkäiden tekstityökalujen avulla verkkosivustot tulevat sisällöllisesti vahvemmiksi kuin koskaan aiemmin ja pian saamme toivottaa tervetulleiksi monia uusia ulkomaisia verkkosivustoja omalla kielellämme hakutuloksissa, koska älykkäiden käännöstyökalujen ansiosta on yhä helpompaa kääntää verkkokauppoja, portaaleja, SAAS-palveluita ja muita verkkosivustoja hyökätäkseen digitaalisille kotimarkkinoille. Meidän on varauduttava kovaan kilpailuun. Se vasta alkaakin...

Johtopäätös datalla ohjatusta verkkosivustouudistus -tarkistuslistasta

Tällainen datalla ohjattu tarkistuslista on yksi harvoista tehokkaista tavoista velvoittaa toimistot tekemään hyvää työtä. On suositeltavaa tehdä jopa tiettyjen arvojen saavuttaminen testityökaluissa hyväksymiskriteeriksi. Sopimuksessa pitäisi olla määritelty, että osa maksusta voidaan laskuttaa vasta neljän viikon kuluttua uudistuksesta, kun kaikki tärkeät tiedot ovat käytettävissä ja huippuarvot on vahvistettu (kuten Core Web Vitals ja validoidut tuotteesiilot Schema-Markupilla Search Console -palvelussa). Tämän työnkulun avulla - kuten tässä kirjoituksessa on kuvattu - sijanmenetyksesi uudistuksen jälkeen vahvoilla sisällöllisillä, rakenteellisilla ja teknisillä muutoksilla pitäisi pysyä kurissa ja luot pohjan sille, että Google sijoittaa verkkosivustosi tai verkkokauppasi pian korkeammalle.

Jos artikkeli oli sinulle kiinnostava, tutustu myös mielellään muihin sisältöihimme:

1101,908,1066,1086

Mitä?	Lyhyt kuvaus	Testityökalu	Akt. (Nykyinen arvo)	Tavoitearvo
Tekniikka & Meta	Sivun otsikot, otsikot, metatiedot, vaihtotekstit, ...	Seobility
Rakenne	Uudelleenohjaukset, virheelliset linkit, sivukartat, ...	Seobility
Sisältö	Avainsanan tarkistus, kirjoitusvirheet, liian vähän tekstiä, ...	Seobility
Kuva-SEO	Puhuvat URL-osoitteet, moderneja Web-muotoja (WebP/AVIF), <meta>-kuvakkeet	ilman
OG-tiedot toteutettu	Open Graph -tiedot sosiaalisille medioille	Open Graph Checker
Rakenne-aineisto (Markup-Schema)	Schema-Markup / strukturoitujen tietojen	Schema.org
PageSpeed Etusivu	PageSpeed mobiili/desktopille	PageSpeed Insights
PageSpeed Landing-sivu	PageSpeed mobiili/desktopille	PageSpeed Insights
PageSpeed Kategoria-sivu	PageSpeed mobiili/desktopille	PageSpeed Insights
PageSpeed Tuotesivu	PageSpeed mobiili/desktopille	PageSpeed Insights
PageSpeed Blogisivu	PageSpeed mobiili/desktopille	PageSpeed Insights
Esteettömyys eri sivutyypeissä	Esteettömät palvelut vammaisryhmille	Accessibility Checker ja/tai wave.webaim.org
Hreflang-tarkistus	Monikielisille verkkosivuille	Hreflang Validator
Turvallisuusotsikot	Luottamus & Turvallisuus	SecurityHeaders.com
Health-Check	Luottamus & Turvallisuus	Security Audit (Astra)
Selain & Laite-testaus	Edge, Firefox, Safari, Chrome desktop & mobiili, iOs & Android	Dev-työkalut / Lambdatest
Evästekäytäntö & GDPR	Suostumuksellinen evästekäytäntö & GDPR-yhteensopivuus	Cookie Metrix
Kävijälaskenta: Isäntätila	Hakurobotin nouto, DNS-tiedustelu, palvelinyhteys	Google Search Console
Kävijälaskenta-tilasto	Pyyntömäärät, latauskoko, keskimääräinen reaktioaika	Google Search Console
Klikkaukset SERP-tuloksissa	aikaedellytys (kuukausittain/90 päivää, ...)	Google Search Console
Impressiot SERP-tuloksissa	aikaedellytys (kuukausittain/90 päivää, ...)	Google Search Console
Keskimääräinen CTR SERP-tuloksissa	aikaedellytys (kuukausittain/90 päivää, ...)	Google Search Console
Keskimääräinen SERP-sijainti	aikaedellytys (kuukausittain/90 päivää, ...)	Google Search Console
Core Web Vitals -testin läpäiseminen	Näyttökerroin käyttäjäkokemuksesta (PageSpeed, mobiilioptimointi, ...)	Google Search Console
GA4-tietojen tarkistus	oleskeluaika, sivut/kävijä, ...	Google Analytics 4
Konversioprosentti	Varausverkkosivustoille tai verkkokaupoille	Omat suoritusindikaattorit
Keskimääräinen ostoskorin arvo	Verkkokaupoille	Omat suoritusindikaattorit
Ostot/liikevaihto päivässä	Verkkokaupoille	Omat suoritusindikaattorit
Uutiskirjautumisten määrä	Tarpeelle sopivasti tarvittaessa	Uutiskirjeen palvelu
Yhteydenottopyynnöt	Tarpeen mukaan	Omat suoritusindikaattorit