WordPress Vedlikehold & Support i Praha

WordPress-vedlikehold i Praha handler sjelden om å bygge noe nytt. Det handler om å holde et nettsted som allerede selger, rekrutterer, booker rom eller leverer B2B-tjenester til hele Sentral-Europa oppe, raskt og i tråd med tsjekkisk og EU-regelverk, måned etter måned, mens betalingsvaner, språkkrav og hostingforventninger endrer seg rundt det. Denne siden beskriver hvordan løpende drift og støtte ser ut for en virksomhet som driver fra Tsjekkias hovedstad.

Utgangspunktet er alltid det eksisterende nettstedet, ikke et idealisert ett. Plugin-inventaret, hosting-oppsettet med datalagring i EU, backup-historikken, GoPay- og Comgate-integrasjonene og CZ/EN/DE-strukturen kartlegges først, deretter låses en månedlig rytme som er forutsigbar nok til at du kan glemme at den finnes.

#WordPress-vedlikehold og støtte i Praha

Et nettsted i Praha møter en sammensetning av krav som speiler hovedstadens rolle: fintech og SaaS som selger til DACH, hoteller og opplevelsesleverandører som må tåle sesongtopper, offentlige og halvoffentlige aktører med dokumentasjonskrav, og et marked der tsjekkisk, engelsk og tysk ofte må fungere parallelt på samme plattform. Vedlikeholdsarbeidet handler om å holde alle disse delene i drift når WordPress-kjernen, WooCommerce, betalingspluginene og flerspråklige utvidelser oppdateres ut av takt med hverandre.

#Hva som inngår i den løpende driften

• Oppetidsovervåking med korte kontrollintervaller og varsling til en skriftlig kanal, slik at en nede kasse, bookingmotor eller B2B-portal oppdages før brukerne rapporterer den, ikke etterpå
• Testede oppdateringer av WordPress-kjerne, plugins og temaer i et testmiljø før produksjon, med dokumentert tilbakeføring per syklus, fordi en GoPay- eller WooCommerce-oppdatering som bryter CZK-kassen koster omsetning per time
• Daglige sikkerhetskopier med 30 dagers oppbevaring og prøvd gjenoppretting, lagret utenfor produksjonsserveren, helst i tråd med avtalt EU-datalagring hos leverandører som Wedos eller Forpsi
• Sikkerhetsovervåking: malware-skanning, filintegritetskontroll, overvåking av innloggingsforsøk og en Web Application Firewall tilpasset WordPress-spesifikke angrepsmønstre
• Kontroll av at flerspråklig ruting (CZ/EN/DE) og hreflang ikke forfaller mellom oppdateringer, siden hovedstadsbedrifter ofte retter seg mot både det lokale markedet, internasjonale partnere og tyskspråklige kunder
• Noen utviklertimer i måneden satt av til mindre endringer, tekstrettelser og småfeil uten at det må settes opp et eget prosjekt

#Markedet og det tekniske miljøet i Praha

Praha er Tsjekkias hovedstad og det største tech- og forretningsmiljøet i landet. CzechInvest, Prague Startup Summit og miljøer som HUB Praha og StartupYard samler gründere, investorer og produktteam som forventer at nettstedet tåler rask vekst uten at noen må sette opp et nytt prosjekt for hver plugin-oppdatering. Karlin og Holešovice har blitt tette klynger for software, fintech og shared services, og mange nettsteder i disse miljøene ble satt opp raskt i en vekstfase, ofte av et byrå eller en frilanser som siden har gått videre, og som nå trenger noen til å ta over driften uten å bygge alt på nytt.

Parallelt med tech-scenen dominerer turisme, hotell, konferanse og opplevelsesbransjen. Et nettsted som booker rom, selger turer eller håndterer flerspråklig innhold for gjester fra Tyskland, Storbritannia og Norden må tåle sesongvariasjon: roligere vintermåneder og topper rundt julemarked, påske og sommer. WordPress-vedlikehold her handler like mye om at booking og betaling fungerer når trafikken kommer, som om plugin-versjoner, fordi nedetid i høysesong treffer omsetningen direkte.

Eksport til Tyskland, Østerrike og Slovakia gjør flerspråklighet til en forretningskritisk funksjon, ikke et tillegg. Mange Praha-bedrifter publiserer på tsjekkisk mot det lokale markedet, engelsk mot internasjonale partnere og investorer, og tysk mot DACH-kunder. WPML, Polylang eller tilsvarende må testes i hver oppdateringssyklus sammen med kasse og skjemaer, ellers ender du med tyske produktsider som peker på tsjekke URL-er etter en rutinemessig plugin-oppdatering.

Lokale betalingsvaner avgjør hvilke deler av siden som er mest forretningskritiske. I Tsjekkia dominerer GoPay og Comgate for lokale betalingsmetoder, Stripe brukes ofte for internasjonale kort og abonnementer (Stripe CZ), og mange nettbutikker tar imot CZK som primærvaluta med EUR som sekundær. Det styrer hva vi overvåker tettest: kasseflyt i CZK, tilbakekall fra betalingsgateway, og at MVA-visning følger tsjekkisk regelverk uten at en cache serverer utdaterte priser.

WordPress Praha Community møtes jevnlig, og mange team i hovedstaden har hørt om testmiljø, WP-CLI og sikkerhetsoppdateringer. Problemet er sjelden mangel på teori, men at ingen eier driften når gründeren har flyttet videre, sesongansatt redaktør har sluttet, eller byrået har avsluttet avtalen rett før en kampanje.

#Verktøyene vi drifter med

Overvåking settes opp med oppetidskontroll og PageSpeed-måling, sikkerhetsskanning kjøres med Wordfence eller tilsvarende, og oppdateringer på tvers av flere nettsteder orkestreres fra ett kontrollpanel. Sikkerhetskopier lagres adskilt fra produksjonsserveren med versjonering. Hosting hos tsjekkiske EU-leverandører (Wedos, Forpsi, Stable.cz og tilsvarende) avtales eksplisitt etter datalagringskrav; vi bytter ikke ut en fungerende stack uten dokumentert grunn.

For bedrifter som selger til Tyskland, har kontrakter med offentlige aktører eller driver fintech er det ofte et eksplisitt krav at primærdata og backup ligger i EU. Revisjonen kartlegger faktisk datasenterlokasjon, ikke bare markedsføringstekst på leverandørens nettsted, og om CDN eller tredjepartsplugins sender data utenfor avtalt jurisdiksjon. Wedos og Forpsi er vanlige valg blant Praha-SMB-er som vil ha tsjekkisk support og EU-datasenter; større aktører bruker ofte OVH, Hetzner eller AWS EU med standardklausler. Valget dokumenteres i onboarding, ikke antas.

#Slik foregår overtakelsen

Overtakelse av et eksisterende nettsted følger en fast rekkefølge som holder risikoen lav:

1. Onboarding-revisjon, en gjennomgang av WordPress-installasjonen: plugin-inventar, hosting og datalagringsland, PHP-versjon, backup-status, sikkerhetsposisjon, GoPay-, Comgate- og Stripe CZ-integrasjon, CZ/EN/DE-struktur og en Lighthouse-referanse å måle mot senere.
2. Overvåking og sikkerhetskopier på plass, oppetid, ytelse og sikkerhet settes under overvåking, daglige backups med prøvd gjenoppretting etableres, og et testmiljø klargjøres for oppdateringstesting.
3. Første testede oppdateringssyklus, kjerne, plugins og temaer oppdateres i testmiljø, kasse, skjemaer og språkbytte testes, og endringene flyttes til produksjon med en tilbakeføringsplan klar.
4. Månedlig rytme, testede oppdateringer, backups, sikkerhetsskanning, ytelseskontroller og en månedsrapport med målinger, beslutninger og gjenværende risiko.
5. Hendelsesrespons, ved nedetid eller en bekreftet sikkerhetshendelse utløses SLA-arbeidsflyten: respons, avgrensning, dokumentert tidslinje og rotårsak, vurdering av meldeplikt under GDPR der relevant, oppretting og oppdatert rapport.

#Problemene vi oftest tar over

Henvendelsene fra Praha-bedrifter handler stort sett om de samme tingene:

• En oppdatering brøt GoPay-kassen, Comgate-flyten eller CZK-prisvisningen og ingen oppdaget det før salgstallene falt. Når oppdateringer testes i testmiljø mot kasseflyten først, fanges denne typen feil før den når kundene.
• Flerspråklig plugin oppdatert og tysk eller engelsk innhold peker plutselig på tsjekke URL-er. Vi tester språkbytte og hreflang i hver syklus, ikke bare forsiden.
• Nettstedet klappet sammen under en konferanse, julemarked eller sommerkampanje fordi ingen hadde testet cache og serverkapasitet på forhånd. En årlig kalender over kjente topper og forberedelse før disse datoene unngår det meste.
• Hosting utenfor EU uten at avtalen tillater det, oppdaget først i leverandørrevisjon eller av en DACH-kunde. Da kartlegger vi migrering til Wedos, Forpsi eller tilsvarende og oppdaterer databehandlerdokumentasjon.
• Et skjema som samler personopplysninger uten oppdatert personvernerklæring, oppdaget i forbindelse med GDPR-gjennomgang. Da stopper vi nye sporingspunkter til eier har godkjent.
• En side som har stått uten oppdateringer lenge og nå har sårbare plugins, malware eller en backup som ikke virker. Da starter vi med en oppretting-liste før den jevne driften begynner.

#Hva du kan vente deg

Resultatet av løpende, testet vedlikehold er udramatisk, og det er poenget. Færre supporthenvendelser fordi feil fanges i testmiljø i stedet for i produksjon. Stødigere lastetider når caching, bildeoptimalisering og databaseopprydding er på plass og holdes ved like. Kortere nedetid ved hendelser fordi backupene faktisk lar seg gjenopprette og responsrutinen er øvd inn. Vi måler før og etter og legger tallene i månedsrapporten i stedet for å love en bestemt prosent på forhånd.

#Hvorfor Praha-bedrifter velger WPPoland

Vi har drevet med WordPress siden 2007 og har sett plattformen gå fra bloggverktøy til forretningskritisk infrastruktur for nettbutikker, B2B-portaler, booking og rekrutteringssider. Vi vet hva som ryker når et nettsted skaleres eller når en utvikler slutter uten at noen har overtatt driften, og hva en kunde faktisk trenger sammenlignet med det de tror de trenger.

Vi er ikke et hostingselskap som selger vedlikehold som tillegg. Vi er utviklere som drifter nettsteder, både de vi har bygget selv og de andre har bygget. Vi leser koden fordi vi skriver den, og du snakker direkte med personen som gjør arbeidet, ikke med et ledd imellom. Kommunikasjonen kan foregå på norsk selv om nettstedet betjener det tsjekkiske og tyskspråklige markedet.

#Sikkerhet og samsvar i en tsjekkisk kontekst

Sikkerhet i drift handler mer om disiplin enn om enkeltgrep. Herdet serveroppsett, WAF-regler tilpasset WordPress, parametriserte databasespørringer mot SQL-injeksjon, output-escaping mot cross-site scripting og hastighetsbegrensning på innlogging er grunnlinjen. Det som gjør det forretningskritisk i Praha, er kombinasjonen av GDPR, tsjekkisk håndheving via Úřad pro ochranu osobních údajů (ÚOOÚ), og kundekrav fra fintech, turisme og eksportbedrifter som krever sporbarhet.

GDPR gjelder direkte i Tsjekkia som EU-medlem, og ÚOOÚ er det nasjonale tilsynet som håndhever personvernloven. Et WordPress-nettsted som samler jobbsøknader, bookingdata, nyhetsbrev, leverandørregistreringer eller bestillingsdata må ha oppdatert personvernerklæring, dokumentert behandlingsgrunnlag, og rutiner for innsyn og sletting. Vedlikeholdet inkluderer å stoppe nye sporingspunkter eller skjemaer som ikke er gjennomgått, og å logge hendelser som kan utløse meldeplikt til ÚOOÚ innen 72 timer etter at bruddet ble oppdaget.

For fintech, offentlige leverandører og softwarehus med ISO-sertifisering er det ofte krav om at IT-drift kan dokumenteres: hvem deployet hva, når ble backup sist testet, hvor ligger data. Månedsrapporten og hendelsesloggen er derfor en del av leveransen, ikke et tillegg. NIS2 og sektorspesifikke krav kan også påvirke nettsteder som er inngangsport til kritiske systemer; revisjonen kartlegger om nettstedet er en ren markedsføringsflate eller en integrert del av en større leveransekjede.

Cookie-samtykke og informasjonsplikt er særlig synlig i hovedstaden der mange nettsteder retter seg mot både tsjekkiske og utenlandske besøkende. En oppdatering som introduserer ny analytics, chat-widget eller betalingsplugin uten gjennomgang av personvernerklæring og samtykkelogikk er en typisk feil vi stopper i testmiljø, ikke i produksjon.

#Ytelse som forretningssignal

Lastetid betyr noe i et marked der GoPay og mobil kjøp gjør at beslutningen tas på sekunder, og der hotell- og turismeaktører konkurrerer om synlighet i søk og direktebookinger. En treg kasse på mobil mister salg på samme måte som en nede kasse gjør det, og en treg booking-side øker frafall før skjemaet er sendt. Ytelsesarbeidet i driften dekker:

• Ressurser, bilder levert som responsive WebP og AVIF, CSS renset og delt per rute, JavaScript redusert og lastet etter behov.
• Caching, flere lag: nettlesercache, CDN, applikasjonscache og databasecache med fornuftig invalidering, slik at en cachelagring ikke serverer utdatert CZK-pris eller feil publiseringsstatus.
• Nettverk, HTTP/3, Brotli-komprimering og ressurshint der det faktisk flytter målingen, med server lokalisert nær tsjekkisk og sentraleuropeisk publikum når hosting tillater det.
• Rendering, kritisk CSS innlinjet, ikke-kritiske stilark lastet asynkront, og lazy loading av bilder under folden.

Hver endring måles mot en referanse fra onboardingen, slik at effekten er etterprøvbar i månedsrapporten.

#Spørsmål Praha-bedrifter stiller

Kan dere overta et nettsted dere ikke har bygget selv? Ja, det er det vanligste tilfellet. Revisjonen kartlegger hva som finnes, og den første måneden går ofte mer til opprydding enn til jevn drift.

Hva skjer hvis en oppdatering bryter CZK-kassen eller GoPay? Oppdateringer kjøres i testmiljø og testes mot kasse og betaling før produksjon, og hver syklus har en tilbakeføringsplan. Skulle noe likevel slippe gjennom, ruller vi tilbake først og finner årsaken etterpå.

Må nettstedet ligge på tsjekkisk hosting? Avhenger av avtalen din og hva personverndokumentasjonen sier. Mange Praha-kunder velger Wedos, Forpsi eller tilsvarende EU-hosting for primærdata; andre bruker større EU-leverandører med standardklausler. Revisjonen avklarer gap og anbefaler tiltak, ikke ideologi.

Hvordan håndterer dere tsjekkisk, engelsk og tysk parallelt? Vi tester WPML, Polylang eller tilsvarende i hver oppdateringssyklus: språkbytte, hreflang, kanoniske URL-er og at skjemaer sender riktig språkversjon. Redaksjonelle arbeidsflyter med riktige roller reduserer at noen publiserer halvferdig oversettelse.

Jobber dere bare med bedrifter i Praha? Vi har kunder i hele Tsjekkia og utenfor. Driften er uansett ekstern, med rapportering og SLA avtalt skriftlig.

Hvordan faktureres løpende vedlikehold? Vedlikehold faktureres månedlig etter en avtalt pakke. Omfang settes individuelt etter antall nettsteder, språkversjoner og responskrav, og avtales skriftlig før arbeidet starter.

Hvordan foregår kommunikasjonen? Via en skriftlig billettkanal med en månedlig statusrapport. Telefon brukes når en beslutning må avblokkeres eller en hendelse skal gjennomgås.

#Teknisk omfang

Denne siden holder seg til WordPress-vedlikehold og støtte. Arbeidet tar utgangspunkt i tjenesten i tittelen: gjennomgang av nåsituasjonen, et risikokart, prioriterte tiltak, akseptkriterier og verifisering etter hver endring for en virksomhet i Praha. Dukker en annen plattform eller et annet system opp underveis, behandles det som kontekst for driften, ikke som en grunn til å bytte tema.

#Sikkerhetskopier og gjenoppretting som er testet

En sikkerhetskopi uten testet gjenoppretting er en antakelse, ikke en beredskap. Den vanligste svakheten vi finner i revisjonsfasen i Praha er ikke at backup mangler. Det er at backupen kjører, rapporterer grønt og aldri har blitt rullet tilbake til et fungerende nettsted. Et arkiv kan være ubrukelig på måter loggen ikke fanger opp: databasedumpen ble tatt uten --single-transaction mens en CZK-bestilling ble skrevet, tegnsettet ble eksportert feil slik at tsjekke tegn kommer tilbake ødelagt, wp-content/uploads ble hoppet over fordi katalogen passerte en størrelsesgrense hos Wedos eller Forpsi, eller arkivet ligger på samme disk som den serveren du nettopp mistet. Forskjellen mellom en sikkerhetskopi og et gjenopprettingspunkt er én konkret handling: at noen har lagt arkivet inn i et rent miljø og bekreftet at nettstedet kommer opp, at innlogging virker, at kassen tar imot en testbestilling i CZK og at alle tre språkversjoner vises.

3-2-1-prinsippet er minstekravet, ikke en ambisjon. Tre kopier av dataene, lagret på to ulike medier eller lagringstyper, og minst én kopi utenfor lokasjonen til produksjonsserveren. For et WordPress-nettsted i drift i Praha betyr det i praksis den daglige kopien hos hostingleverandøren, en uavhengig kopi i objektlagring hos en annen leverandør (gjerne innen EU dersom avtalen krever det), og en versjonert kopi med lengre oppbevaring som produksjonsmiljøet ikke har skriverettigheter til. Begrunnelsen for den tredje kopien er ikke diskhavari, det er løsepengevirus og utilsiktet sletting. Et angrep som får skrivetilgang på serveren rammer også de sikkerhetskopiene serveren selv kan skrive til. Derfor skal minst én kopi være uforanderlig, med object lock eller tilsvarende, eller ligge bak påloggingsinformasjon som verken webserveren eller WordPress-installasjonen har.

Et komplett øyeblikksbilde består av fire deler, og de tas sjelden samtidig. En backuprutine som bare dekker to av dem gir en falsk trygghet som først viser seg under press:

• Filene. Hele installasjonen, inkludert wp-content/plugins, wp-content/themes, wp-content/mu-plugins og egen kode som ligger utenfor wp-content. Kjernefilene kan hentes tilbake fra WordPress og verifiseres med wp core verify-checksums, men et spesialtilpasset tema eller en integrasjon skrevet for kunden finnes bare i arkivet ditt.
• Databasen. En konsistent dump laget med wp db export eller mysqldump med --single-transaction og riktig tegnsett, slik at bestillinger som skrives mens eksporten pågår ikke havner halvveis i filen. Serialiserte verdier i wp_options og wp_postmeta er grunnen til at en domene- eller URL-endring etter gjenoppretting må gjøres med wp search-replace, aldri med søk og erstatt i SQL-filen.
• Opplastingene. wp-content/uploads er nesten alltid den største delen og den som først utelates for å holde arkivet lite. Mediebiblioteket kan sikkerhetskopieres med et annet intervall enn databasen, men det skal være en dokumentert beslutning i vedlikeholdsavtalen.
• Serverkonfigurasjonen. wp-config.php med nøkler og salt, .htaccess eller nginx-konfigurasjonen, PHP-innstillinger, cron-oppsettet, sertifikater, DNS-oppføringer og hvilke API-nøkler som peker mot GoPay, Comgate, Stripe og fraktleverandører. Denne delen mangler i de fleste plugin-baserte backupløsninger, og det er nettopp den som avgjør om en gjenoppretting tar minutter eller en arbeidsdag.

Hvor ofte gjenopprettingen bør testes. En gjenopprettingstest er en øvelse, ikke en kontroll av at filen finnes. Intervallet vi anbefaler, og som settes skriftlig i vedlikeholdsavtalen, er en full gjenoppretting til et rent testmiljø hvert kvartal, og i tillegg etter hver strukturelle endring: bytte av hostingleverandør, migrering til ny server, ny PHP-versjon, ny betalingsintegrasjon eller en større WooCommerce-oppgradering. Mellom kvartalstestene holder det med en lettere kontroll der arkivet pakkes ut, databasedumpen importeres, og fem punkter sjekkes: forsiden på alle språk, innlogging, en produktside, en testbestilling i CZK og et bilde fra mediebiblioteket. Prosedyren skal være skrevet ned og kunne følges av en annen person enn den som satte opp backupen, og tiden testen faktisk tok skal noteres, fordi det tallet er det eneste realistiske grunnlaget for RTO-en du oppgir internt.

RPO og RTO, forklart i klartekst. RPO, Recovery Point Objective, svarer på hvor mye data virksomheten tåler å miste, målt i tid. Kjører backupen én gang i døgnet, er RPO i verste fall et helt døgn. RTO, Recovery Time Objective, svarer på hvor lenge nettstedet kan være nede før tapet ikke lenger er akseptabelt. For en nettbutikk i Praha som tar CZK-bestillinger gjennom dagen betyr et RPO på ett døgn at bestillinger i verste fall bare eksisterer hos GoPay, Comgate eller Stripe og må avstemmes manuelt etterpå. For en hotell- eller konferanse-side er det samme tapet billigere, men fortsatt dokumenterbart i en hendelsesrapport. De konkrete verdiene settes i vedlikeholdsavtalen, fordi de bestemmer arkitekturen: hyppige inkrementelle kopier ligger i en annen kategori enn en nattlig dump.

Den første timen etter et datatap. Rekkefølgen betyr mer enn hastigheten:

1. Stopp skrivingen. Sett nettstedet i vedlikeholdsmodus, deaktiver planlagte importer og WP-Cron. En gjenoppretting som kjører mens nye data fortsatt skrives, gir to ufullstendige versjoner i stedet for én komplett.
2. Bevar bevisene før du rydder. Ta en kopi av dagens tilstand som den er, både filsystem, database og logger. Ved mistanke om innbrudd er den kompromitterte tilstanden det eneste grunnlaget for å finne inngangspunktet.
3. Fastslå tidspunktet, ikke symptomet. Finn siste kjente gode tilstand ved hjelp av logger, bestillingsnumre og publiseringstidspunkter.
4. Velg den siste verifiserte kopien før det tidspunktet. Ikke den nyeste. En kopi tatt etter at malwaren ble skrevet inn, gjenoppretter malwaren sammen med innholdet.
5. Gjenopprett til et separat miljø først. Verifiser der: innlogging, kasse i CZK, GoPay, Comgate, Stripe, skjemaer, CZ/EN/DE-sider, integrasjoner. Først når miljøet er godkjent, settes det i produksjon.
6. Avstem tidsrommet du mistet. Alt som skjedde mellom gjenopprettingspunktet og hendelsen må hentes fra kilder utenfor nettstedet: transaksjoner hos GoPay, Comgate eller Stripe, skjemainnsendinger som også gikk på e-post, og eventuell CRM-synkronisering.
7. Bytt alle passord og nøkler hvis kompromittering ikke kan utelukkes. Databasepassord, SSH-tilgang, API-nøkler mot betaling, og saltene i wp-config.php.
8. Skriv tidslinjen mens den er fersk. Hva som ble oppdaget, når, hvilket gjenopprettingspunkt som ble valgt og hva som ble avstemt manuelt. Under GDPR kan personopplysningsbrudd kreve melding til ÚOOÚ uten ugrunnet opphold.

Responstider og eskaleringsvei følger av vedlikeholdsavtalen og settes sammen med RPO og RTO. Det som avgjør utfallet er arbeidet som ble gjort før hendelsen: at kopien var komplett, at den lå utenfor rekkevidde for det som gikk galt, og at noen hadde gjenopprettet den minst én gang mens det ikke hastet.

For selve nettbutikken er inngangen WooCommerce-utvikler i Praha. Huber i Tsjekkia sammenligner SLA med vedlikehold i Brno og vedlikehold i Wien.

#Vedlikehold i andre tsjekkiske byer

Trenger du løpende WordPress-vedlikehold utenfor Praha, er oppgavene de samme - oppdateringer, sikkerhetskopier, overvåking og støtte - men med lokal kontekst for drift og responstid. Se også vedlikehold og support i Brno for hvordan avtalen tilpasses Tsjekkias andre tech-hub.

#Andre byer i regionen

Samme vedlikeholdsavtale finnes i flere europeiske byer utenfor Tsjekkia, med samme SLA og rapporteringsform:

• Wien - WordPress-vedlikehold i Wien for det østerrikske DACH-markedet
• Budapest - WordPress-vedlikehold i Budapest for sentral-europeisk eksport
• Kraków - polsk nabo med lignende eksportorienterte softwaremiljøer

For nordiske markeder, se WordPress-vedlikehold i Oslo og WordPress-vedlikehold i Stockholm.

#Start en samtale

Hvis virksomheten din i Praha trenger noen til å overta drift og støtte av et WordPress-nettsted, ta kontakt for en uforpliktende gjennomgang. Vi ser på dagens situasjon, peker på den mest presserende risikoen og gir en ærlig vurdering av hva som bør gjøres først. Omfang og avtale settes individuelt etter den gjennomgangen.