Kā mainīt WP URL, to nesabojājot
Publicēts 2026. gada 12. maijā
Ja jums jāmaina WP URL, dariet to kontrolētā secībā: vispirms izveidojiet dublējumu, atjauniniet WordPress Address un Site Address, pēc tam izlabojiet novirzīšanas, SSL un visas stingri kodētās saites. Lielākā daļa problēmu rodas nevis pašas URL maiņas dēļ, bet gan tāpēc, ka ar to saistītās daļas joprojām norāda uz veco atrašanās vietu. Vietne parasti nav dusmīga — tā tikai seko novecojušiem iestatījumiem.
Šis uzdevums parādās domēna maiņas laikā, pārejot no HTTP uz HTTPS, pārvietojot WordPress uz apakšdirektoriju vai migrējot no staging uz production vidi. Veikalu īpašniekiem, aģentūrām un SaaS komandām neveiksmīga URL maiņa var nozīmēt pieteikšanās cilpas, mixed content brīdinājumus, salauztu admin piekļuvi vai formas, kas sūta datus uz nepareizo vietu. Tāpēc mērķis nav tikai rediģēt divus laukus. Mērķis ir saglabāt mierīgu visu lietotni.
Ko patiesībā ietekmē WP URL maiņa
WordPress ir divi galvenie iestatījumi: WordPress Address un Site Address. Tie izklausās līdzīgi, jo, atklāti sakot, tādi arī ir. Taču tie pilda atšķirīgus uzdevumus.
WordPress Address ir vieta, kur atrodas WordPress pamata faili. Site Address ir publiskais URL, ko apmeklētāji izmanto, lai piekļūtu vietnei. Daudzās konfigurācijās tie ir identiski. Citās WordPress var atrasties apakšdirektorijā, kam ēr vietne tiek ielādēta no saknes domēna.
Ja vienu no tiem nomaināt nepareizi, WordPress var jūs novirzīt prom no wp-admin, sūtīt resursus uz nepareizo domēnu vai izveidot bezgalīgu novirzīšanas cilpu. Spraudņi, motīvi, datubāze, tīmekļa serveris un CDN noteikumi arī joprojām var atsaukties uz iepriekšējo URL. Tāpēc pareiza maiņa daļēji ir WordPress darbs un daļēji infrastruktūras higiēna.
Pirms maināt WP URL
Izveidojiet svaigu dublējumu gan failiem, gan datubāzei. Ja tā ir e-komercijas vietne vai aizņemta satura vietne, veiciet darbu zemas datplūsmas laikā. URL maiņa var ietekmēt kešotās lapas, sesijas sīkdatnes un maksājumu callback adreses, tāpēc laikam ir nozīme.
Pirms veicat izmaiņas, jums arī jāpārbauda četras lietas. Pirmkārt, jaunais domēns vai protokols jau tiek atrisināts uz pareizo serveri. Otrkārt, SSL sertifikāts ir aktīvs, ja pārejat uz HTTPS. Treškārt, jūsu tīmekļa servera virtual host vai Nginx server block ir gatavs jaunajam resursdatora nosaukumam. Ceturtkārt, jūs zināt, vai WordPress atrodas aiz proxy, load balancer vai CDN, kas var piespiest novirzīšanas.
Ja kaut kas no tā nav sagatavots, WordPress var būt konfigurēts pareizi un tomēr publiski nedarboties. Arī žurnāli tad stāsta to pašu stāstu.
Drošākie veidi, kā mainīt URL
Mainiet to WordPress administratora panelī
Ja jums joprojām ir admin piekļuve, šī ir tīrākā metode. Dodieties uz Settings, pēc tam uz General. Atjauniniet WordPress Address un Site Address uz jauno URL. Saglabājiet izmaiņas.
Tas darbojas labi, ja pārvietošana ir vienkārša un jaunais domēns jau pareizi norāda uz vietni. Tūlīt pēc saglabāšanas, ja nepieciešams, piesakieties vēlreiz un pārbaudiet sākumlapu, administratora zonu, multivides bibliotēku un dažas iekšējās lapas.
Risks ir acīmredzams: ja ievadāt nepareizu URL vai jaunais resursdators vēl nav pilnībā gatavs, varat sev liegt piekļuvi panelim.
Mainiet to failā wp-config.php
Ja panelis nav pieejams vai vēlaties lielāku kontroli, definējiet vērtības tieši failā wp-config.php. Pievienojiet šīs rindas virs stop editing rindas:
define('WP_HOME','https://example.com'); define('WP_SITEURL','https://example.com');
Tas piespiež WordPress izmantot vērtības no konfigurācijas faila. Bieži vien tā ir ātrākā atkopšanas metode pieteikšanās cilpām vai salauztām admin novirzīšanām.
Tas ir arī labs pagaidu stabilizators migrāciju laikā. Kad viss darbojas, varat šīs konstantes atstāt vietā vai noņemt un atkal pārvaldīt vērtības no admin paneļa.
Mainiet to datubāzē
Ja nav pieejama ne admin vide, ne konfigurācijas rediģēšana, varat atjaunināt vērtības datubāzē, parasti tabulā wp_options. Opciju nosaukumi ir home un siteurl.
Tas darbojas, taču tas ir manuālāks process un to ir vieglāk izdarīt slikti, ja steidzaties. Vietnēs ar pielāgotiem tabulu prefiksiem nepieņemiet, ka tabula ir wp_options. Vispirms pārbaudiet.
HTTP uz HTTPS ir vieta, kur cilvēki mēdz pārsteigties
Daudzi pieprasījumi mainīt wp url patiesībā ir HTTPS migrācijas maskētā veidā. Redzamā izmaiņa šķiet neliela, bet pārlūkprogrammas, sīkdatnes un resursu ielāde tam nepiekrīt.
Pēc pārslēgšanās no HTTP uz HTTPS WordPress iestatījumos pārliecinieties, ka SSL sertifikāts ir derīgs un instalēts pareizajam resursdatora nosaukumam. Pēc tam atjauniniet servera novirzīšanas tā, lai HTTP pieprasījumi tiktu pastāvīgi novirzīti uz HTTPS. Ja jūsu vietne atrodas aiz reverse proxy vai CDN, pārliecinieties, ka WordPress var pareizi noteikt HTTPS, pretējā gadījumā tas var turpināt novirzīt bezgalīgi.
Mixed content ir nākamais ierastais viesis. Lapas tiek ielādētas caur HTTPS, bet attēli, skripti, fonti vai CSS joprojām izsauc HTTP URL. Tas var sabojāt izkārtojumu vai izraisīt pārlūkprogrammas brīdinājumus. Jums var būt nepieciešama datubāzes search-and-replace vecajiem absolūtajiem URL, īpaši, ja vietne ir veidota ar lapu būvētāju vai pielāgotiem laukiem, kuros tiek glabātas pilnas saites.
Rūpīgi meklējiet un aizstājiet vecos URL
Mainot divus galvenos iestatījumus, vecās saites, kas glabājas rakstos, metadatos, logdaļu saturā vai spraudņu iestatījumos, netiek pārrakstītas. Ja vecais domēns datubāzē parādās kā stingri kodēts, lietotāji joprojām nonāks pie tā.
Tieši šeit ir svarīga pareiza serialized data droša search-and-replace. Nedarbiniet neuzmanīgu vienkārša teksta aizstāšanu eksportētā SQL failā un neceriet uz labāko. Daļa spraudņu un opciju datu ir serializēti, un slikta aizstāšana var sabojāt garumus un salauzt iestatījumus.
Ja izmantojat profesionālu migrācijas darbplūsmu, palaidiet rīku, kas saprot WordPress serializāciju. Pēc tam pārbaudiet lapu būvētāja izkārtojumus, izvēlnes, attēlu URL, canonical tags, Open Graph iestatījumus un visus spraudņus, kas glabā callback vai API URL.
Biežākās problēmas pēc URL maiņas
Pieteikšanās lapa turpina novirzīt
Tas parasti nozīmē, ka WordPress, tīmekļa serveris vai proxy nav vienisprātis par pareizo shēmu vai resursdatora nosaukumu. Pārbaudiet WP_HOME un WP_SITEURL, pēc tam apskatiet servera novirzīšanas noteikumus. Ja SSL terminēšana notiek augšpusē, WordPress var būt nepieciešams korekti apstrādāt pārsūtīto HTTPS galveni.
Sīkdatnes var būt piesaistītas arī vecajam domēnam. Notīriet pārlūkprogrammas sīkdatnes un pārbaudiet privātā logā, pirms pieņemat, ka vietne ir nolādēta.
wp-admin nav pieejams
Ja admin URL sūta jūs uz nepareizo vietu, piespiediet pareizās vērtības failā wp-config.php. Tas bieži vien nekavējoties atjauno paneli. Pārskatiet arī .htaccess vai Nginx noteikumus attiecībā uz veco pārrakstīšanas uzvedību.
Attēli vai CSS ir salauzti
Tas norāda uz stingri kodētiem URL vai mixed content. Meklējiet datubāzē veco domēnu un pārbaudiet pārlūkprogrammas izstrādātāju rīkus, lai redzētu, kuri resursi joprojām izsauc iepriekšējo URL.
Novirzīšanas ķēdes vai cilpas
Tās parasti rodas, kad WordPress novirza vienā virzienā, bet tīmekļa serveris vai CDN novirza citā. Samaziniet loģiku līdz vienam skaidram noteikumu kopumam. Ja iespējams, apstrādājiet canonical host un HTTPS novirzīšanas tikai vienā vietā.
Formas, webhook vai checkout callback neizdodas
Ārējie pakalpojumi joprojām var sūtīt pieprasījumus uz veco domēnu. Pārbaudiet maksājumu vārtejas URL, SMTP atgriešanās ceļus, webhook galapunktus un trešo pušu integrācijas. Dalības vai e-komercijas vietnēs šeit rodas klusie ieņēmumu zaudējumi.
Kad WordPress Address un Site Address vajadzētu būt atšķirīgiem
Lielākajai daļai vietņu tiem vajadzētu būt vienādiem. Taču ir pamatoti izņēmumi. Ja WordPress ir instalēts apakšdirektorijā, piemēram, /wordpress, bet publiskā vietne tiek ielādēta no domēna saknes, tad Site Address var būt saknes URL, bet WordPress Address — apakšdirektorijas URL.
Šī konfigurācija var būt noderīga failu organizēšanai, taču tā palielina sarežģītību. Ja to nedarāt apzināti, neizdomājiet to migrācijas vidū. Vienkāršas konfigurācijas izgāžas retāk.
Praktiska secība, kas palīdz izvairīties no dīkstāves
Izmantojiet īsu uzturēšanas logu, vispirms apstipriniet DNS, SSL un servera konfigurāciju, pēc tam mainiet WordPress URL. Pēc tam veiciet datubāzes search-and-replace, iztukšojiet kešatmiņas un pārbaudiet galvenos ceļus: sākumlapu, admin, formas, checkout, multividi, API galapunktus un cron darbību.
Ja vietne izmanto object caching, full-page caching vai CDN, pēc izmaiņām iztīriet visu. Vecas kešotas novirzīšanas var likt veselai vietnei vēl 20 minūtes izskatīties salauztai, un tā nav pati skaistākā DNS situācija, bet tā ir kontrolējama.
Biznesam kritiskām vietnēm vispirms izmēģiniet izmaiņas staging vidē. Kodu.cloud tieši šāda veida uzdevumos pārvaldītas infrastruktūras atbalsts atmaksājas pats par sevi — nevis tāpēc, ka URL maiņa būtu neiespējama, bet gan tāpēc, ka tieši mazās apkārtējās pārbaudes novērš nepatīkamus pārsteigumus.
Pēdējās pārbaudes pēc WP URL maiņas
Atveriet vietni jaunā pārlūkprogrammas sesijā un, ja attiecināms, pārbaudiet gan ar, gan bez www. Apstipriniet SSL piekaramo atslēgu, pārbaudiet dažus avota URL un pārliecinieties, ka admin, pieteikšanās, multivides augšupielādes un kontaktformas darbojas normāli. Ja meklētājprogrammas jau ir indeksējušas veco domēnu, saglabājiet pareizās novirzīšanas pietiekami ilgi, lai datplūsma un rangu signāli pārvietotos korekti.
WP URL maiņa parasti ir īss darbs, ja vide ir gatava. Tas kļūst par garu vakaru tikai tad, kad DNS, SSL, servera noteikumiem, kešatmiņai un datubāzes atsaucēm ļauj strīdēties savā starpā. Turiet tos vienā virzienā, un pakalpojums atkal būs mierīgs.
Andres Saar klientu apkalpošanas inženieris