Hoe om WordPress XML-RPC te deaktiveer en jou webwerf teen brute force-aanvalle te beveilig

Die deaktivering van WordPress XML-RPC behels dat jy die xmlrpc.php-lêer op jou webwerf blokkeer om afstandversoeke te voorkom, wat help om brute force-aanvalle, pingback-misbruik en oorbodige botverkeer vinnig te verminder. As jy nie Jetpack, die WordPress-mobiele app, ou afstandpublikasie-instrumente of ander spesiale integrasies gebruik wat XML-RPC benodig nie, is dit 'n veilige en praktiese sekuriteitsmaatstaf om hierdie funksie uit te skakel. Die doeltreffendste manier is om versoeke op bedienervlak te blokkeer – dit wil sê, om toegang tot xmlrpc.php via jou Apache-, LiteSpeed-, Nginx-bediener of WAF-reëls te beperk. Hierdie metode werk gewoonlik vinniger en meer betroubaar as om dit via 'n plugin te doen.

In hierdie gids sal jy leer hoekom jy WordPress XML-RPC moet afskakel, wanneer jy dit eerder moet laat aanstaan, en hoe om dit veilig te implementeer in verskillende bedieneromgewings. Of jy nou op Hostragons se infrastruktuur werk of enige ander hosting-omgewing gebruik, die doel is om die aanvalsvlak van jou webwerf te verminder sonder om funksionaliteit te verloor, onnodige hulpbronne te spaar en 'n hanteerbare sekuriteitsvlak te bou. As jy op soek is na 'n vinnige en veilige basis vir jou WordPress-webwerf, is WordPress hosting ook 'n belangrike aspek van jou sekuriteitsplan.

Wat is XML-RPC en waarvoor dien dit in WordPress?

XML-RPC is 'n ou afstandkommunikasieprotokol wat verskillende stelsels toelaat om data in XML-formaat via HTTP te stuur en te ontvang. In WordPress word hierdie funksie hoofsaaklik deur die xmlrpc.php-lêer in die wortelgids hanteer. Oorspronklik is hierdie lêer gebruik vir plasing van poste vanaf die WordPress mobiele app, afstandbeheer van kommentaar, pingbacks en sekere derdeparty-dienste se interaksie met die webwerf.

Met die opkoms van die REST API het die belangrikheid van XML-RPC egter afgeneem. Die lêer bly nogtans in baie installasies toeganklik, wat dit 'n maklik opspoorbare en standaard teiken maak vir kwaadwilliges. Bots wat lukraak IP-reekse deursoek, kan selfs 'n splinternuwe domeinnaam binne minute probeer om toegang tot xmlrpc.php te kry. Daarom is dit belangrik om veiligheid reeds by die begin van jou webwerf se lewensiklus te oorweeg, byvoorbeeld met Domein navraag wanneer jy jou nuwe domein aktiveer.

Wanneer mag XML-RPC nodig wees?

XML-RPC is nie onnodig vir alle webwerwe nie. Sekere ou Jetpack-funksies, spesifieke bedrywighede van die WordPress mobiele app, sommige outomatiseringsdienste en ou desktop-blogredigeerders kan dit benodig. Ook kan spesiale integrasies die xmlrpc.php-lêer gebruik om inhoud te publiseer of data af te haal. Dit beteken jy moet jou webwerf se werkvloei nagaan voordat jy dit afskakel.

‘n Maklike toets is: as jy net inhoud via die wp-admin-paneel publiseer, nie Jetpack gebruik nie, nie die mobiele app gebruik om te publiseer nie, en jou ontwikkelaar geen spesifieke XML-RPC-integrasie opgestel het nie, is die kans groot dat jy XML-RPC nie nodig het nie. Die meeste besigheidswebwerwe, blogs, kataloguswebwerwe, kleinondernemings en WooCommerce-winkels werk normaalweg sonder XML-RPC. As jy egter kritieke prosesse soos betaling, versending of ander integrasies het, is dit verstandig om die verandering in 'n lae verkeer tydperk te toets.

Hoekom is WordPress XML-RPC 'n risiko vir brute force-aanvalle?

Brute force-aanvalle behels dat 'n aanvaller outomaties baie gebruikersnaam en wagwoord kombinasies probeer om toegang te verkry. Gewoonlik gebeur dit via wp-login.php. XML-RPC bied egter 'n meer voordelige roete vir aanvallers omdat sommige XML-RPC metodes toelaat dat verskeie aanmeldpogings in 'n enkele HTTP-versoek gesluit word. Die system.multicall funksie kan byvoorbeeld honderde pogings minder sigbaar maak en dit makliker maak om sekuriteitsmaatreëls te omseil.

Om 500 wagwoordpogings via wp-login.php te doen, beteken 500 afsonderlike versoeke, maar via XML-RPC kan dieselfde aantal pogings in baie minder versoeke saamgevat word. Dit kan veroorsaak dat sekuriteitsplugins en logs die aanval eers later raaklees. Die gevolge sluit in hoër CPU-gebruik, besette PHP-processes, oorlaaide databasis en 'n stadiger gebruikerservaring vir werklike besoekers. Op gedeelde hosting kan dit nie net 'n sekuriteitsrisiko wees nie, maar ook 'n prestasie- en hulpbronprobleem.

‘n Ander risiko met XML-RPC is pingback-misbruik. Pingbacks is bedoel om ander webwerwe te vertel dat hulle na jou inhoud verwys het, maar dit kan misbruik word om DDoS-aanvalle te loods of derdeparty-webwerwe te teiken. Om hierdie redes help die deaktivering van XML-RPC om nie net aanmeldpogings te beperk nie, maar ook hierdie vorm van misbruik te verminder.

Vergelykingstabel van metodes om XML-RPC af te skakel

Soos die tabel wys, is die vinnigste en mees betroubare metode om XML-RPC te blokkeer op bediener- of WAF-vlak as jy dit nie nodig het nie. Plugins is maklik om te gebruik, maar versoeke bereik steeds die PHP-laag, wat hulpbronverbruik beteken. Daarom moet webwerwe met hoë verkeer, e-handel of gereelde aanvalle prioriteit gee aan bedienerreëls.

Voor jy begin: Kontrolelys

By sekuriteitsinstellings is die grondbeginsel om eers te meet en 'n terugdraai-plan te hê. XML-RPC deaktivering is gewoonlik veilig, maar moenie blindelings veranderinge maak op 'n lewende webwerf nie. Die volgende kontrolelys help om foute te verminder tydens implementering.

• Maak seker jy het 'n werkende rugsteun van lêers en databasis wat minder as 24 uur oud is. Rugsteun is noodsaaklik voor enige opdatering, sekuriteitsaanpassing of plugin-wissel.
• Kontroleer of jy Jetpack, die WordPress mobiele app, afstandpublikasie-instrumente of spesiale integrasies gebruik.
• Bestudeer jou toeganglogs vir die aantal versoeke na xmlrpc.php. As daar duisende versoeke per minuut is, kan jy onder aanval wees.
• Voer die veranderinge uit tydens lae verkeer-ure. Spesifiek vir WooCommerce, toets karretjie, betaling en lidmaatskapvloei na die verandering.
• Maak 'n plan om die verandering maklik terug te draai, soos om die reël te kommentarieer of te verwyder met toegang tot jou lêerbestuurder, FTP of SSH.

In 'n professionele hosting-omgewing maak gereelde rugsteun, opdaterings, geïsoleerde gebruikersrekeninge en firewall ondersteuning 'n groot verskil. Vir infrastruktuurkeuse kan jy meer leer by Veilige Web Hosting, en vir algehele webwerfsekuriteit by SSL sertifika.

Metode 1: XML-RPC blokkeer met .htaccess op Apache of LiteSpeed

Die mees algemene metode op Apache en LiteSpeed WordPress-webwerwe is om 'n reël aan die .htaccess-lêer in jou webwerf se wortel toe te voeg wat toegang tot xmlrpc.php blokkeer. Aangesien LiteSpeed .htaccess-reëls ondersteun wat met Apache versoenbaar is, werk hierdie metode in baie hostingomgewings direk. Die grootste voordeel is dat versoeke geblokkeer word voordat WordPress selfs laai.

Stap-vir-stap gids

• Maak jou hostingbeheer paneel oop en gebruik die lêerbestuurder, of verbind via FTP na die public_html gids.
• Soek die .htaccess-lêer en maak 'n rugsteun daarvan op jou rekenaar. As die lêer versteek is, maak seker dat jy verborge lêers kan sien.
• Voeg die XML-RPC-blokkeerreël bo-aan die lêer by sonder om bestaande WordPress-reëls te verwyder.
• Die reël moet alle toegang tot xmlrpc.php weier.
• Stoor die lêer en toets dit deur joublaad te besoek: joudomein.com/xmlrpc.php.

Vir Apache 2.4 en LiteSpeed is die algemene reël: Require all denied vir die xmlrpc.php-lêer. Ou Apache 2.2-omgewings gebruik Deny from all, maar dit word nie aanbeveel nie aangesien dit verouderd is. Indien jy nog 'n ou Apache-weergawe gebruik, is dit 'n goeie kans om jou bediener op te gradeer vir beter sekuriteit en prestasie.

As die blokkering suksesvol is, moet xmlrpc.php 'n 403 Forbidden, 404 Not Found of soortgelyke toegang geweier-antwoorde teruggee. Wat jy nie wil sien nie, is 'n boodskap soos "XML-RPC server accepts POST requests". Dit beteken die lêer is nog steeds toeganklik.

Metode 2: XML-RPC blokkeer op Nginx

Op Nginx werk .htaccess nie, aangesien Nginx nie lêergidsgebaseerde reëls ondersteun nie. Die reël moet in die serverblok-konfigurasie van jou webwerf bygevoeg word. As jy 'n bestuurde hosting gebruik, het jy dalk nie toegang tot hierdie konfigurasie nie – kontak jou hostingondersteuningspan om xmlrpc.php-toegang te blokkeer.

Die basiese benadering op Nginx is om 'n location = /xmlrpc.php-blok te skep wat versoeke weier of 'n 404 teruggee. Vir sekuriteit kan jy dit met 'n 403 (verbode) of 'n 404 (nie gevind) antwoord doen. Die 404-benadering gee minder inligting aan bots en word dikwels verkies. Na toevoeging moet jy jou Nginx-konfigurasie toets en die diens herlaai. Wees versigtig, want 'n klein tikfout kan jou hele webwerf onbereikbaar maak.

As jy Nginx op 'n VPS of toegewyde bediener gebruik, is dit nuttig om die toeganglogs na die verandering dop te hou en te bevestig dat versoeke na xmlrpc.php nou 403 of 404 teruggee. As daar steeds baie versoeke van dieselfde IP-adresse is, kan jy fail2ban, rate limiting of WAF-reëls as 'n tweede verdedigingslyn gebruik. Vir meer diepgaande bedienerbeheer kan jy VPS Bediener veiligheid raadpleeg.

Metode 3: XML-RPC deaktiveer met 'n sekuriteitsplugin

Vir gebruikers wat nie met lêers wil werk nie, is sekuriteitsplugins 'n praktiese opsie. Plugins soos Wordfence, Solid Security of All-In-One Security het dikwels opsies om XML-RPC te deaktiveer, pingback te blokkeer of aanmeldpogings via XML-RPC te beperk. Dit is veral geskik vir klein blogs en basiese besigheidswebwerwe.

Wees egter bewus van die beperkinge van plugins: as die plugin die versoek eers na WordPress deurlaat voordat dit geblokkeer word, kan die aanval steeds PHP-hulpbronne verbruik. Dit beteken dat by groot aanvalle die bediener steeds belas kan word. Plugins is dus beter as niks, maar by hoë verkeer of aanvalle word aanbeveel om bediener- of WAF-vlak blokkering te gebruik.

Wenke vir die gebruik van plugins

• Laai plugins slegs af van die amptelike WordPress plugin-biblioteek of die ontwikkelaar se webwerf.
• Vermy plugins wat al lank nie opgedateer is nie. Aktiewe onderhoud in 2026 is 'n belangrike sekuriteitsteiken.
• Gebruik nie verskeie sekuriteitsplugins vir dieselfde funksie nie, want dit kan botsings en prestasieprobleme veroorsaak.
• Toets jou webwerf na deaktivering van XML-RPC: insluitende die gesondheid van die webwerf, vorms, lidmaatskap en betaling.
• Monitor gereeld plugin logs en skep IP-blokke of WAF-reëls indien jy aanhoudende aanvalle sien.

Metode 4: Gebruik WAF, CDN en hosting firewall om XML-RPC te blokkeer

‘n Web Application Firewall (WAF) is een van die doeltreffendste lae om kwaadwillige versoeke te blokkeer voordat hulle jou toepassing bereik. Dienste soos Cloudflare kan versoeke na xmlrpc.php blokkeer voordat dit jou bediener bereik. Jou hostingverskaffer se ModSecurity of ander WAF-reëls kan ook soortgelyke beskerming bied. Hierdie laag is baie belangrik om bots versoeke te stop sonder om jou WordPress te belaas.

Die WAF-reël moet spesifiek wees: as die URI pad xmlrpc.php bevat, blokkeer of stel 'n uitdaging. As jy XML-RPC nie benodig nie, is 'n volledige blok die beste opsie. As jy dit gedeeltelik benodig, kan jy slegs versoeke van betroubare IP-adresse toelaat en ander blokkeer. Byvoorbeeld, as 'n outomatiseringsdiens 'n statiese IP het, kan jy dit witlys en ander versoeke blokkeer. Dit is 'n balans tussen sekuriteit en diensbaarheid.

Die WAF-laag werk die beste saam met HTTPS. Sonder HTTPS is jou aanmeldinligting en sessies kwesbaar vir onderskep. Daarom moet jy nie net XML-RPC blokkeer nie, maar ook jou hele webwerf oor HTTPS bedryf, HSTS koppe oorweeg en jou SSL-sertifikaat op datum hou. Vir meer daaroor kan jy na SSL sertifika en Gratis SSL Installasie kyk.

Hoe toets ek of XML-RPC reg afgeskakel is?

Na jou veranderinge is dit belangrik om nie net te kyk of die webwerf laai nie, maar ook om seker te maak dat XML-RPC effektief geblokkeer is, aanmeldings werk en werklike gebruikers nie geraak word nie. Die volgende toetsstappe is prakties en voldoende:

• Gaan na joublaan.com/xmlrpc.php in jou webblaaier. Jy moet 'n toegang geweier, 404 of 'n leë antwoord kry. Jy mag nie 'n boodskap sien soos "XML-RPC server accepts POST requests" nie.
• Meld aan by jou WordPress admin met jou gewone gebruikersnaam en wagwoord om te verseker dat die aanmeldproses los staan van XML-RPC.
• Toets jou kontakvorms, kommentaarvorms, lidmaatskap- en WooCommerce-betalingsprosesse.
• Kontroleer jou bediener toeganglogs vir versoeke na xmlrpc.php en kyk watter statuskode hulle teruggee. 403 of 404 dui op 'n werkende blok.
• As jy 'n sekuriteitsplugin gebruik, kyk na die logs om te sien of aanvalle minder word of geblokkeer word.

Vir meer tegniese toetsing kan jy 'n POST-versoek vanaf die terminale stuur, maar die meeste webwerf-eienaars kan met hul blaaier en logs voldoende bevestiging kry. As na die verandering Jetpack ophou werk, die mobiele app nie kan publiseer nie, of 'n integrasie fout gee, beteken dit dat jy XML-RPC wel benodig. In so 'n geval kan jy eerder IP-gebaseerde toegang of rate limiting oorweeg as 'n volle blokkering.

Is dit genoeg om net XML-RPC af te skakel? Ander sekuriteitsmaatreëls

Die deaktivering van XML-RPC is 'n vinnige en effektiewe manier om brute force-aanvalle te verminder, maar dit is nie 'n volledige sekuriteitsoplossing nie. Aanvallers kan steeds wp-login.php, REST API, swak plugins, ou temas of gesteelde wagwoorde gebruik om in te breek. Daarom moet jy WordPress-sekuriteit as 'n meerdere-laag proses beskou.

Belangrike sekuriteitsmaatreëls om toe te pas

• Gebruik sterk wagwoorde en unieke gebruikersname. Vermy steeds die gebruik van 'admin' as gebruikersnaam.
• Skakel twee-faktor-verifikasie (2FA) aan. Dit verminder die risiko van wagwoordlekke veral op admin-rekeninge drasties.
• Beperk aanmeldpogings. Gebruik rate limiting of sekuriteitsplugins vir wp-login.php.
• Hou jou WordPress kern, plugins en temas op datum. Verouderde plugins is 'n algemene inbraakpunt.
• Verwyder ongebruikte plugins en temas. Hulle kan steeds sekuriteitsrisiko's inhou.
• Kontroleer lêertoestemmings. Oormatige skryfregte verhoog risiko’s vir kwaadwillige lêeroplaai.
• Maak gereeld rugsteun en toets jou herstelprosedures. 'n Rugsteun is net bruikbaar as dit suksesvol herstel kan word.
• Kies 'n betroubare hosting met geïsoleerde rekeninge, moderne PHP-weergawe, WAF en rugsteunondersteuning.

As jy net XML-RPC afskakel, maar steeds swak wagwoorde soos '123456' gebruik, bly jou sekuriteitsketting swak. Met sterk wagwoorde, 2FA, gereelde opdaterings, WAF en betroubare hosting saam, word baie bots en algemene aanvalle effektief geblokkeer. Hierdie benadering is ook belangrik vir SEO in 2026, aangesien kwesbare webwerwe dikwels deur kwaadwillige omleidings, spam en indeksbesoedeling gestraf word en hul organiese sigbaarheid verloor.

Die impak van XML-RPC deaktivering op prestasie en SEO

XML-RPC-aanvalle is nie 'n direkte rangorde faktor nie, maar hul indirekte effekte is beduidend. As bots jou bediener oorlaai, neem bladsye langer om te laai, verswak jou Core Web Vitals, en die gebruikerservaring ly. Op webwerwe wat gereeld hulpbronlimiete raak, kan jy 500-foutboodskappe, tydsoverskrywings en onderbrekings sien. Googlebot kan ook huiwerig raak om stadige of foutiewe bladsye te kruip.

Neem byvoorbeeld jou tuisblad wat normaalweg binne 300 ms laai, maar as xmlrpc.php 1000 versoeke per minuut kry, kan PHP-prosesse oorlaai en die reaksietyd styg na meer as 2 sekondes. Die bladsy vertraag, omskakelings daal en jou Google Search Console kruipstatistieke kan wissel. Deur XML-RPC op bedienervlak te blokkeer, sny jy hierdie onnodige las af voordat dit jou toepassing bereik, wat help om prestasie stabiel te hou.

Vir SEO is 'n veilige en vinnige webwerf nie net inhoud nie, maar ook tegniese infrastruktuur. Dit sluit in HTTPS, moderne PHP, vinnige skyf, goeie kas, skoon tema en die verminderde aanvalsvlak. Daarom behoort WordPress-sekuriteit nie net in die domein van stelseladministrateurs te wees nie, maar ook vir SEO- en inhoudspanne belangrik te wees. Die Hostragons-blog kan jou verder help met WordPress snelheid optimalisering en Tegniese SEO kontrole lys.

As jy nie XML-RPC heeltemal kan afskakel nie: Alternatiewe strategieë

Daar is projekte waar XML-RPC nie heeltemal afgeskakel kan word nie. Byvoorbeeld, 'n spesifieke mobiele publiseringsstroom, 'n korporatiewe outomatisering of ou integrasies kan steeds op hierdie protokol staatmaak. In sulke gevalle is die doel nie om die poort heeltemal toe te maak nie, maar om beheer te hê oor wie toegang kry.

Die eerste opsie is IP-witlys: slegs vertroude dienste kry toegang tot XML-RPC, ander versoeke word geblokkeer.

Die tweede is om rate limiting toe te pas: 'n enkele IP kan nie te veel versoeke teen 'n kort tyd stuur nie. Dit is nie so definitief soos volledige blok nie, maar verminder die aanvalsgrootte betyds. Die derde opsie is om pingback-metodes te deaktiveer en slegs die noodsaaklike metodes toe te laat. Hierdie vereis meer gevorderde konfigurasie en moet deur ontwikkelaars hanteer word.

Die vierde opsie is om XML-RPC toegang agter 'n ekstra sekuriteitslaag te plaas, soos HTTP basiese verifikasie, VPN, korporatiewe IP-beperkings of WAF-uitdagings. Dit verminder die risiko van 'n oop publieke eindpunt. Op die lang termyn word dit egter aanbeveel om ou integrasies na moderne, beter beheerbare metodes soos die REST API te skuif.

Praktiese padkaart vir Hostragons-gebruikers

As jy jou WordPress-webwerf by Hostragons gehuisves het, maak eers 'n behoefte-analise vir XML-RPC en kies dan die mees eenvoudige metode. Op gedeelde hosting of WordPress hosting-pakkette sal die aanpassing van .htaccess meestal genoeg wees. As jy 'n VPS of toegewyde bediener het, kan jy 'n kombinasie van Nginx, Apache, LiteSpeed en WAF-reëls gebruik.

Die proses kan soos volg wees: maak eers 'n rugsteun, kontroleer watter dienste XML-RPC gebruik, blokkeer dit op bedienervlak, toets, kyk logs vir 24 uur, en as aanvalle voortduur, voeg WAF-reëls, IP-blokke en aanmeldpogingslimiete by. Laastens voltooi jy jou sekuriteitsinstellings met 2FA, opdaterings, gereelde rugsteun en SSL.

Hierdie aksies is nie 'n verkoopsopgradering nie, maar 'n basiese higiënemaatstaf. As jou infrastruktuur egter verouderd is, met ou PHP-weergawe, onvoldoende hulpbronne of geen firewall nie, is dit dalk tyd om 'n meer moderne hostingplan te oorweeg. 'n WordPress-geoptimaliseerde omgewing met sekuriteitslae bied nie net beter verdraagsaamheid teen aanvalle nie, maar verbeter ook dag-tot-dag prestasie. Vir meer inligting is WordPress hosting, wolkskink en SSL sertifika uitstekende bronne.

Gereelde vrae

Sal die deaktivering van WordPress XML-RPC my webwerf breek?

Vir die meeste standaard WordPress-webwerwe sal die deaktivering van XML-RPC nie jou webwerf breek nie. Die admin-paneel, temas, inhoud, vorms en besoekerfunksies word gewoonlik nie beïnvloed nie. As jy egter Jetpack, die WordPress mobiele app of spesiale XML-RPC integrasies gebruik, kan daar verbindingsprobleme wees. Daarom is dit belangrik om jou gebruik te kontroleer en basiese funksies na deaktivering te toets.

Hoe weet ek of XML-RPC afgeskakel is?

Besoek joudomein.com/xmlrpc.php in jou blaaiervenster. As jy 'n boodskap sien soos "XML-RPC server accepts POST requests", beteken dit dat die lêer steeds toeganklik is. As jy 'n 403, 404 of toegang geweier-boodskap kry, werk jou blok. Vir 'n meer definitiewe toets, kyk na die bediener toeganglogs om te sien watter statuskode versoeke na xmlrpc.php teruggee.

Stop die deaktivering van XML-RPC alle brute force-aanvalle?

Dit stop die meeste brute force-aanvalle via XML-RPC, maar nie alle nie. Aanvallers kan steeds wp-login.php, REST API, of ander weë probeer. Daarom is dit belangrik om XML-RPC deaktivering te kombineer met sterk wagwoorde, 2FA, aanmeldpogingsbeperking, WAF en gereelde opdaterings.

Gebruik ek Jetpack, moet ek dan XML-RPC afskakel?

Jetpack gebruik sekere funksies wat XML-RPC vereis. As jy Jetpack gebruik, moet jy eers ondersoek watter modules jy aktiveer voordat jy XML-RPC heeltemal afskakel. Dit kan ook 'n beter opsie wees om slegs Jetpack se IP-adresse toe te laat en ander versoeke te blokkeer, of om toegang met WAF-kontroles te beperk.

Is dit beter om XML-RPC met 'n plugin of op die bediener af te skakel?

Vir optimale prestasie en sekuriteit is dit beter om op bedienervlak of WAF af te skakel, want versoeke word geblokkeer voordat WordPress en PHP dit hanteer. Plugins is makliker vir minder tegniese gebruikers, maar kan nie die hulpbronverbruik by groot aanvalle heeltemal stop nie. Indien moontlik, gebruik bedienerreëls, anders 'n betroubare plugin met WAF-samewerking.

Opsomming en volgende stappe

Die afskakeling van WordPress XML-RPC is een van die vinnigste maniere om brute force-aanvalle, pingback-misbruik en oorbodige botverkeer te verminder op webwerwe wat dit nie benodig nie. Die beste praktyk is om xmlrpc.php-toegang op bediener- of WAF-vlak te blokkeer, en dit te kombineer met aanmeldsekuriteit, 2FA, opdaterings, SSL en gereelde rugsteun vir 'n gelaagde beskerming. As jy jou webwerf se infrastruktuur wil evalueer, kan jy Hostragons se WordPress-gespesialiseerde hosting en sekuriteitsdienste ondersoek, en vandag met 'n eenvoudige kontrolelys jou eerste stap neem.