Kuidas muuta WP URL-i ilma seda lõhkumata
Avaldatud 12. mail 2026
Kui pead muutma WP URL-i, tee seda kontrollitud järjekorras: tee esmalt varukoopia, uuenda WordPress Address ja Site Address ning seejärel paranda ümbersuunamised, SSL ja kõik kõvakodeeritud lingid. Enamik tõrkeid ei juhtu mitte URL-i muutmise enda tõttu, vaid seetõttu, et seda ümbritsevad osad viitavad endiselt vanale asukohale. Veebisait ei ole tavaliselt vihane - ta lihtsalt järgib aegunud seadeid.
See ülesanne tuleb ette domeeni muutmisel, HTTP-lt HTTPS-ile liikumisel, WordPressi tõstmisel alamkataloogi või staging-keskkonnast production-keskkonda migreerimisel. E-poe omanike, agentuuride ja SaaS-tiimide jaoks võib halb URL-i muudatus tähendada sisselogimissilmuseid, mixed content hoiatusi, katkist admin-liidest või vorme, mis saadavad andmeid valesse kohta. Seega ei ole eesmärk ainult kahe välja muutmine. Eesmärk on hoida kogu rakendus rahulikuna.
Mida WP URL-i muutmine tegelikult mõjutab
WordPressis on kaks põhiseadet: WordPress Address ja Site Address. Need kõlavad sarnaselt, sest ausalt öeldes nad seda ka on. Kuid neil on erinev ülesanne.
WordPress Address on koht, kus asuvad WordPressi põhifailid. Site Address on avalik URL, mida külastajad kasutavad saidile jõudmiseks. Paljudes seadistustes on need identsed. Teistes võib WordPress asuda alamkataloogis, samal ajal kui sait laetakse juurdomeenist.
Kui muudate neist ühe valesti, võib WordPress suunata teid wp-admin-ist eemale, saata varad valele domeenile või tekitada lõpmatu ümbersuunamissilmuse. Pluginad, teemad, andmebaas, veebiserver ja CDN-i reeglid võivad samuti endiselt viidata eelmisele URL-ile. Seepärast on korrektne muudatus osaliselt WordPressi töö ja osaliselt infrastruktuuri hügieen.
Enne kui muudad WP URL-i
Tee nii failidest kui ka andmebaasist värske varukoopia. Kui see on e-kaubanduse sait või suure liiklusega sisusait, tee töö väikse liiklusega ajal. URL-i muutus võib mõjutada vahemällu salvestatud lehti, seansiküpsiseid ja maksete callback'e, seega ajastus on oluline.
Samuti peaksid enne muudatuste tegemist kinnitama neli asja. Esiteks, uus domeen või protokoll laheneb juba õigesse serverisse. Teiseks, SSL-sertifikaat on aktiivne, kui liigute HTTPS-ile. Kolmandaks, teie veebiserveri virtual host või Nginxi serveriblokk on uue hostinime jaoks valmis. Neljandaks, teate, kas WordPress on proxy, load balanceri või CDN-i taga, mis võib sundida ümbersuunamisi.
Kui mõni neist ei ole paigas, võib WordPress olla õigesti seadistatud ja siiski avalikult tõrkuda. Logid räägivad siis sama lugu.
Kõige turvalisemad viisid URL-i muutmiseks
Muuda seda WordPressi halduses
Kui teil on endiselt juurdepääs haldusliidesele, on see kõige puhtam meetod. Avage Settings ja seejärel General. Uuendage WordPress Address ja Site Address uue URL-iga. Salvestage muudatused.
See toimib hästi siis, kui kolimine on lihtne ja uus domeen osutab juba õigesti saidile. Kohe pärast salvestamist logige vajadusel uuesti sisse ning testige avalehte, haldusala, meediateeki ja mõnda sisemist lehte.
Risk on ilmne: kui sisestate vale URL-i või uus host ei ole täielikult valmis, võite end juhtpaneelist välja lukustada.
Muuda seda failis wp-config.php
Kui juhtpaneel ei ole ligipääsetav või soovite rohkem kontrolli, määrake väärtused otse failis wp-config.php. Lisage need read stop editing rea kohale:
define('WP_HOME','https://example.com'); define('WP_SITEURL','https://example.com');
See sunnib WordPressi kasutama konfiguratsioonifaili väärtusi. See on sageli kiireim taastemeetod sisselogimissilmuste või katkiste admin-ümbersuunamiste korral.
See on ka hea ajutine stabilisaator migreerimiste ajal. Kui kõik töötab, võite need konstandid alles jätta või need eemaldada ja hallata väärtusi taas haldusliidesest.
Muuda seda andmebaasis
Kui ei haldusliidese ega konfiguratsiooni muutmine ole võimalik, saate väärtusi uuendada andmebaasis, tavaliselt tabelis wp_options. Suvandi nimed on home ja siteurl.
See toimib, kuid on käsitsi tehtavam ja kiirustades lihtsam halvasti teha. Kohandatud tabeliprefiksitega saitidel ärge eeldage, et tabel on wp_options. Kontrollige kõigepealt.
HTTP-lt HTTPS-ile minnes tulevad üllatused
Paljud päringud wp url-i muutmiseks on tegelikult varjatud HTTPS-i migratsioonid. Nähtav muudatus paistab väike, kuid brauserid, küpsised ja varade laadimine arvavad teisiti.
Pärast WordPressi seadetes HTTP-lt HTTPS-ile lülitumist kinnitage, et SSL-sertifikaat on kehtiv ja õige hostinime jaoks paigaldatud. Seejärel uuendage serveri ümbersuunamised nii, et HTTP päringud suunatakse püsivalt HTTPS-ile. Kui teie sait asub reverse proxy või CDN-i taga, veenduge, et WordPress suudab HTTPS-i õigesti tuvastada, vastasel juhul võib ta lõputult ümber suunata.
Mixed content on järgmine tavaline külaline. Lehed laaditakse HTTPS-i kaudu, kuid pildid, skriptid, fondid või CSS kutsuvad endiselt HTTP URL-e. See võib lõhkuda paigutusi või tekitada brauseri hoiatusi. Võite vajada andmebaasis vanade absoluutsete URL-ide search-and-replace'i, eriti kui sait on ehitatud page builder'iga või kohandatud väljadega, mis salvestavad täislinke.
Otsi ja asenda vanad URL-id hoolikalt
Kahe põhiseade muutmine ei kirjuta ümber vanu linke, mis on salvestatud postitustesse, metaandmetesse, vidinate sisusse või pluginate seadetesse. Kui vana domeen ilmub andmebaasis kõvakodeeritult, jõuavad kasutajad sinna endiselt.
Siin muutub oluliseks korrektne serialized data jaoks ohutu search-and-replace. Ärge tehke eksporditud SQL-failis hooletut lihttekstiasendust ja lootke parimat. Mõned pluginate ja suvandite andmed on serialiseeritud ning halb asendus võib rikkuda pikkused ja lõhkuda seaded.
Kui kasutate professionaalset migratsioonitöövoogu, käivitage tööriist, mis mõistab WordPressi serialiseerimist. Seejärel kontrollige page builder'i paigutusi, menüüsid, piltide URL-e, canonical tag'e, Open Graph seadeid ja kõiki pluginaid, mis salvestavad callback- või API URL-e.
Levinud probleemid pärast URL-i muutmist
Sisselogimisleht suunab pidevalt ümber
See tähendab tavaliselt, et WordPress, veebiserver või proxy ei ole õige skeemi või hostinime osas ühel meelel. Kontrollige WP_HOME-i ja WP_SITEURL-i, seejärel uurige serveri ümbersuunamisreegleid. Kui SSL-i lõpetamine toimub upstreamis, võib WordPress vajada edastatud HTTPS-päise korrektset käsitlemist.
Küpsised võivad samuti olla seotud vana domeeniga. Enne kui eeldate, et sait on neetud, puhastage brauseri küpsised ja testige privaatses aknas.
wp-admin ei ole ligipääsetav
Kui admin-URL saadab teid valesse asukohta, sundige õiged väärtused faili wp-config.php. See toob juhtpaneeli sageli kohe tagasi. Vaadake üle ka .htaccess-i või Nginxi reeglid vana rewrite-käitumise osas.
Pildid või CSS on katki
See viitab k õvakodeeritud URL-idele või mixed content'ile. Otsige andmebaasist vana domeeni ja uurige brauseri arendajatööriistu, et näha, millised varad kutsuvad endiselt eelmist URL-i.
Ümbersuunamisahelad või -silmused
Need juhtuvad tavaliselt siis, kui WordPress suunab ühtmoodi ja veebiserver või CDN teistmoodi. Vähendage loogika üheks selgeks reeglistikuks. Võimaluse korral käsitlege canonical hosti ja HTTPS-i ümbersuunamisi ainult ühes kohas.
Vormid, webhook'id või checkout'i callback'id ebaõnnestuvad
Välised teenused võivad endiselt saata päringuid vanale domeenile. Kontrollige makselüüsi URL-e, SMTP return path'e, webhook endpoint'e ja kolmandate osapoolte integratsioone. Liikmesuse või e-kaubanduse saitidel tekib siin vaikne käibekahju.
Millal peaksid WordPress Address ja Site Address erinema
Enamik saite peaks hoidma need samana. Kuid on olemas põhjendatud erandid. Kui WordPress on paigaldatud alamkataloogi nagu /wordpress, samal ajal kui avalik sait laaditakse domeeni juurest, siis võib Site Address olla juur-URL ja WordPress Address alamkataloogi URL.
See seadistus võib olla kasulik failide korraldamiseks, kuid lisab keerukust. Kui te ei tee seda teadlikult, ärge leiutage seda migratsiooni keskel. Lihtsad konfiguratsioonid ebaõnnestuvad harvemini.
Praktiline järjekord, mis väldib seisakuid
Kasutage lühikest hooldusakent, kinnitage esmalt DNS, SSL ja serveri konfiguratsioon ning seejärel muutke WordPressi URL-e. Pärast seda tehke andmebaasis search-and-replace, tühjendage vahemälud ja testige võtmeradu: avaleht, haldusliides, vormid, checkout, meedia, API endpoint'id ja cron-käitumine.
Kui sait kasutab object caching'ut, full-page caching'ut või CDN-i, puhastage pärast muudatust kõik. Vanad vahemällu salvestatud ümbersuunamised võivad panna terve saidi veel 20 minuti jooksul katkisena paistma, mis ei ole just kõige kaunim DNS-i olukord, kuid see on kontrolli all.
Ärikriitiliste saitide puhul tehke muudatus esmalt staging-keskkonnas. Kodu.cloudis on see täpselt selline ülesanne, mille puhul hallatud infrastruktuuri tugi tasub end ära - mitte sellepärast, et URL-i muutmine oleks võimatu, vaid sellepärast, et just väikesed ümbritsevad kontrollid hoiavad ära inetud üllatused.
Lõplikud kontrollid pärast WP URL-i muutmist
Avage sait värskes brauseriseansis ja testige nii www-ga kui ka ilma, kui see on asjakohane. Kinnitage SSL-i tabalukk, kontrollige mõnda lähte-URL-i ning veenduge, et haldusliides, sisselogimine, meedia üleslaadimised ja kontaktvormid käituvad tavapäraselt. Kui otsingumootorid on vana domeeni juba indekseerinud, hoidke korrektsed ümbersuunamised piisavalt kaua paigas, et liiklus ja järjestussignaalid liiguksid puhtalt üle.
WP URL-i muutmine on tavaliselt lühike töö, kui keskkond on valmis. Sellest saab pikk õhtu alles siis, kui DNS-il, SSL-il, serverireeglitel, vahemälul ja andmebaasiviidetel lastakse omavahel vaielda. Hoidke need samas suunas ja teenus on jälle rahulik.
Andres Saar klienditoe insener