Migracija sajta 2026/2027: SEO checklista za očuvanje pozicija

Kako migrirati sajt bez nepotrebnog gubitka SEO pozicija, saobraćaja i leadova?

Prvo jedna važna stvar:

ne postoji ozbiljna migracija sajta za koju neko može unapred garantovati 0% promene u Google rezultatima

Google sam navodi da tokom značajnih site move promena može doći do privremenih ranking fluktuacija dok ponovo:

• crawl-uje stare URL-ove;
• otkriva nove URL-ove;
• obrađuje redirecte;
• rešava canonical signale;
• ponovo indeksira sadržaj.

Cilj zato nije:

„obećati da se ništa neće pomeriti“.

Cilj je:

ukloniti sve tehničke i sadržajne greške zbog kojih bi migracija izgubila vrednost koju postojeći sajt već ima.

Site migration može značiti:

• promenu domena;
• HTTP → HTTPS;
• www → non-www;
• promenu URL strukture;
• WordPress → Laravel;
• WordPress → Webflow;
• custom CMS → WordPress;
• promenu hostinga;
• promenu frontend arhitekture;
• spajanje više sajtova;
• veliki redesign sa promenom sadržaja i URL-ova.

Nisu sve ove migracije jednako rizične.

Promeniti hosting uz potpuno iste URL-ove je jedan projekat.

Istovremeno promeniti:

• domen;
• CMS;
• URL strukturu;
• dizajn;
• sadržaj;
• interno linkovanje

je potpuno drugi nivo rizika.

U ovom vodiču ćemo proći kroz kompletnu:

PRE-MIGRATION → LAUNCH → POST-MIGRATION

proceduru.

Ako još niste odlučili koju platformu koristite, prvo pogledajte WordPress vs Laravel vs Webflow vs custom development. Ako je migracija deo novog dizajna, povežite je sa vodičem kroz redizajn sajta.

1. Šta je SEO migracija sajta?

SEO migracija je proces promene web infrastrukture, domena, URL-ova, sadržaja ili platforme uz pokušaj da se očuvaju postojeći:

• organic visibility;
• indexed content;
• link signals;
• Search relevance;
• user journeys;
• conversion paths.

SEO nije poseban korak nakon development-a.

Kod migracije je:

deo arhitekture projekta.

2. Nisu sve migracije iste

3. Ako ne morate da promenite dobar URL — nemojte

Jedna od najjednostavnijih migration odluka je:

sačuvati postojeće URL-ove kada nema poslovnog ili tehničkog razloga da ih menjate.

Na primer:

stari URL:

/seo-optimizacija

možda nema nikakav razlog da postane:

/usluge/digitalni-marketing/search-engine-optimization-service

samo zato što je nova arhitektura drugačija.

URL promena treba da rešava problem.

Ne da označi:

„napravili smo novi sajt“.

4. Google preporučuje da ne menjate deset velikih stvari istovremeno

Google u svom aktuelnom site-move vodiču vrlo direktno savetuje:

change only one thing at a time

kada je to moguće.

Na primer:

umesto:

nov domen + novi CMS + potpuno novi content + potpuno nova URL struktura istog dana,

sigurnije može biti razdvojiti veće promene.

Naravno, business projekti ne dozvoljavaju uvek idealan scenario.

Ako morate da uradite sve zajedno:

migration QA mora biti mnogo stroži.

5. PRE-MIGRATION: prvo napravite baseline

Pre nego što menjate išta, zabeležite šta sada imate.

Minimum:

• organic clicks;
• impressions;
• top queries;
• top landing pages;
• conversions;
• revenue gde postoji;
• indexed pages;
• backlinks;
• top linked pages;
• Core Web Vitals/performance;
• ključne rankings.

Bez baseline-a posle launch-a ne znate:

šta ste izgubili, šta ste dobili i da li problem postoji.

6. Site-wide traffic nije dovoljan baseline

Zamislite:

organic traffic ostane isti.

Deluje dobro.

Ali:

• blog traffic poraste 30%;
• commercial landing traffic padne 40%.

Ukupan broj može sakriti poslovno važan problem.

Zato baseline pravite:

URL po URL-u i cluster po cluster-u.

7. Napravite kompletan URL inventory

Pre migracije treba pronaći stare URL-ove iz više izvora:

• crawl starog sajta;
• XML sitemap;
• Google Search Console;
• analytics;
• server logs gde su dostupni;
• backlink alati;
• CMS/database export.

Zašto više izvora?

Zato što crawl trenutne navigacije možda neće pronaći:

• orphan pages;
• stare kampanjske URL-ove;
• URL-ove koji imaju backlink;
• stare indeksirane stranice.

8. Ne tretirajte svaki stari URL jednako

Za svaki URL zabeležite:

• status;
• organic traffic;
• conversions;
• backlinks;
• content type;
• indexability;
• novu destinaciju;
• migration action.

Jedna stranica može biti:

SEO asset.

Druga:

mrtav URL bez vrednosti.

Ne zahtevaju isti tretman.

9. Napravite migration URL map

10. Najvažnije pravilo redirect mapiranja: relevantnost

Stara stranica treba da ide na:

najbliži stvarni novi ekvivalent.

Ako je:

/usluge/seo

postala:

/seo-optimizacija

mapping je jasan.

Ako je stari sadržaj trajno nestao i nema relevantne zamene:

404 ili 410 može biti ispravnije od izmišljenog redirecta.

11. Nemojte 3.000 starih URL-ova preusmeriti na homepage

Ovo je jedna od najčešćih migration grešaka.

Deluje kao:

„bolje nešto nego 404“.

Ali Google eksplicitno upozorava da veliki broj starih URL-ova preusmeren na jednu nerelevantnu destinaciju poput homepage-a može biti tretiran kao:

soft 404.

Redirect mora imati semantičkog smisla.

12. Koristite permanent server-side redirects

Google za trajno pomerene URL-ove preporučuje server-side permanent redirect kada je tehnički moguće.

Najčešće:

• 301 Moved Permanently;
• 308 Permanent Redirect.

To su jasni signali da je sadržaj trajno promenio lokaciju.

Izvor: Google — Redirects and Google Search.

13. Permanent redirect ne „gubi 15% link juice-a“

To je stara SEO ideja koju više ne treba ponavljati kao aktuelno pravilo.

Google u site-move dokumentaciji direktno navodi:

301 i drugi permanent redirects ne uzrokuju gubitak PageRank-a.

To ne znači:

„možete napraviti bilo kakav redirect i ranking će ostati isti“.

Content relevance i svi ostali migration faktori i dalje postoje.

14. Izbegavajte redirect chains

Loše:

Old A → Old B → Temporary C → New D

Bolje:

Old A → New D.

Googlebot može pratiti više redirect hops, ali Google preporučuje da chain bude što kraći.

Migration mapping zato treba da se redirectuje:

direktno ka konačnoj destinaciji.

15. Ne ostavljajte stare interne linkove da prolaze kroz redirect

301 rešava stari URL.

Ali novi sajt ne treba sam sebe da linkuje kroz stari URL.

Posle migracije:

ne:

New page → Old URL → 301 → New page

nego:

New page → New URL direktno.

To:

• smanjuje latency;
• smanjuje server requests;
• čisti crawl put;
• smanjuje budući technical debt.

16. Pre migracije sačuvajte i interno linkovanje

Ne gledajte samo navigation.

Mapirajte:

• menu;
• footer;
• breadcrumbs;
• contextual links;
• related articles;
• CTA cards;
• pagination;
• category links.

Stranica koja je na starom sajtu dobijala 70 internih linkova ne bi bez razloga trebalo na novom sajtu da postane orphan.

17. Content migration nije copy/paste posao

Za svaku važnu stranicu proverite:

• H1;
• main content;
• title;
• meta description;
• images;
• alt text gde je relevantan;
• structured data;
• internal links;
• FAQ;
• CTA;
• tables;
• embedded media.

18. Dizajnersko skraćivanje sadržaja je veliki migration rizik

Stara servisna stranica ima:

1.800 reči korisnog commercial sadržaja.

Novi design mockup predviđa:

220 reči + veliku fotografiju.

Možda je nova verzija bolja.

Ali to nije samo:

design refresh.

Napravili ste:

veliku content/relevance promenu.

Treba je proceniti pre launch-a, ne nakon pada.

19. Ne morate čuvati loš sadržaj samo zato što rankira

Druga krajnost je:

„ne smemo ništa da promenimo“.

Migracija je dobra prilika za:

• consolidation;
• uklanjanje zastarelog sadržaja;
• poboljšanje strukture;
• bolji UX;
• jači Search intent match.

Ali promenu radite:

svesno i sa URL mapiranjem.

20. Canonical tagovi na novom sajtu moraju pokazivati na nove URL-ove

Veoma loš post-launch scenario:

novi URL:

newsite.com/service

ali njegov canonical kaže:

oldsite.com/service.

Google preporučuje da nove URL stranice koriste odgovarajuće self-referencing canonical oznake.

Izvor: Google — Site moves with URL changes.

21. Redirect + canonical + sitemap treba da pričaju istu priču

Google canonical dokumentacija različite signale opisuje različitom snagom:

• redirect — strong signal;
• rel=canonical — strong signal;
• sitemap inclusion — weaker canonical signal.

Najgora situacija je:

redirect kaže NEW, canonical kaže OLD, sitemap kaže THIRD URL.

Migration QA mora da ukloni takve kontradikcije.

22. Hreflang mora takođe biti migriran

Na multilingual/multiregional sajtu:

stari hreflang:

oldsite.com/de/service

ne treba ostati u novom HTML-u.

Google posebno navodi da kod site move-a treba ažurirati hreflang anotacije na nove URL-ove.

23. XML sitemap treba da bude čist

Novi sitemap treba da sadrži:

• canonical;
• indexable;
• novi URL.

Ne treba da bude deponija za:

• 404;
• 301;
• noindex;
• staging URL-ove.

Posle launch-a submitujte novi sitemap kroz Search Console.

24. lastmod treba da označava stvarnu značajnu promenu

Google može koristiti sitemap lastmod kada je dosledno i dokazivo tačan.

Promena:

• main content-a;
• structured data;
• važnih linkova

može biti značajna promena.

Promena:

copyright 2025 → 2026

nije razlog da 20.000 URL-ova dobije lažni današnji lastmod.

25. Staging protection mora nestati na production launch-u

Dok razvijamo novi sajt često koristimo:

• noindex;
• robots.txt block;
• password protection.

To je normalno.

Katastrofa nastaje kada:

production sajt nasledi staging noindex.

26. Robots.txt i noindex nisu ista stvar

robots.txt prvenstveno kontroliše crawling.

noindex kontroliše da li stranica treba da bude indeksirana.

Ne treba ih mehanički kombinovati bez razumevanja posledice.

Kod migracije proverite i:

• meta robots;
• X-Robots-Tag;
• robots.txt;
• WAF/CDN bot restrictions.

27. Crawl novi sajt pre launch-a

Pre nego što promenite DNS ili uključite redirecte, crawl staging/production preview.

Tražite:

• broken internal links;
• 404;
• 5xx;
• redirect chains;
• wrong canonicals;
• missing titles;
• duplicate titles;
• noindex;
• wrong hreflang;
• orphan pages;
• HTTP assets;
• broken images.

28. Uporedite old crawl i new crawl

To je mnogo korisnije nego pregledati samo novi sajt.

Pitajte:

• koji URL je nestao;
• koji title se promenio;
• koja stranica je izgubila H1;
• gde se content drastično skratio;
• koji canonical se promenio;
• koje interne veze više ne postoje.

29. Structured data takođe migrira

Proverite:

• Organization;
• Article;
• BreadcrumbList;
• Product;
• LocalBusiness;
• druge relevantne tipove.

Posebno:

• stare URL reference;
• stari logo;
• staro ime;
• stari breadcrumbs.

Ako migracija uključuje i rebranding, pogledajte Entity SEO i Knowledge Graph.

30. Promena hostinga bez URL promene ima drugačiji proces

Ako:

• domen ostaje isti;
• URL ostaje isti;
• content ostaje isti;

nije vam potreban klasičan URL redirect mapping.

Glavni rizici su:

• DNS;
• server availability;
• crawl access;
• performance;
• Search Console verification.

31. Kod hosting migracije pripremite DNS unapred

Google preporučuje da razmotrite spuštanje DNS TTL-a na razumno nisku vrednost:

najmanje oko nedelju dana pre promene

kako bi se DNS cache brže osvežavao tokom prelaska.

Posle promene pratite:

• old server logs;
• new server logs;
• DNS propagaciju;
• Googlebot access.

Izvor: Google — Changing your hosting.

32. Ne gasite stari hosting iste sekunde

Kod DNS migracije deo korisnika i crawler-a može određeno vreme i dalje dolaziti do stare infrastrukture.

Stari server treba ugasiti tek kada ste sigurni da:

traffic više ne dolazi tamo.

33. Crawl rate može privremeno da se promeni

Google navodi da kod hosting promene crawl rate može:

• privremeno pasti odmah nakon launch-a;
• zatim ponovo rasti narednih dana.

To samo po sebi nije dokaz:

„SEO migracija je propala“.

Problem je ako Googlebot nailazi na:

• timeouts;
• 5xx;
• ozbiljna usporenja;
• blokade.

34. Promena domena zahteva dodatni nivo procedure

Ako:

oldsite.rs → newsite.rs

onda osim redirects-a i sitemap-a treba proveriti i:

• old/new Search Console properties;
• Change of Address gde odgovara;
• external links;
• profiles;
• ads;
• brand mentions;
• analytics;
• email i business sistemske reference.

35. Kada koristiti Search Console Change of Address?

Google Change of Address alat koristite kada selite:

jedan domen ili subdomain na drugi domen/subdomain.

Na primer:

example.com → example.net

Ali Google kaže da ga ne koristite za:

• HTTP → HTTPS;
• promenu pojedinačnih path-ova unutar istog sajta;
• www → non-www;
• hosting/CDN promenu bez URL promene.

Izvor: Google Search Console — Change of Address.

36. Change of Address nije zamena za 301 redirecte

Redosled je:

prvo pravilno migrirajte i redirectujte URL-ove.

Tek onda:

koristite Change of Address tamo gde je primenljiv.

Alat pomaže Google-u da razume domain move.

Ne popravlja lošu migration arhitekturu.

37. Zadržite redirecte najmanje godinu dana

Google-ov aktuelni site-move vodič preporučuje da permanentne redirecte ostavite:

najmanje godinu dana.

To omogućava sistemima dovoljno vremena da:

• ponovo crawl-uju stare URL-ove;
• obrade nove URL-ove;
• prenesu relevantne signale;
• ponovo obrade linkove ka starim URL-ovima.

Za korisnike često ima smisla ostaviti važne redirecte i duže.

38. Nemojte prestati da plaćate stari domen odmah

Kod domain migration-a Google preporučuje da zadržite kontrolu nad starim domenom najmanje dovoljno dugo da migracija sazri, a Change of Address dokumentacija posebno preporučuje da ga zadržite najmanje godinu dana kako ga ne bi preuzeo neko drugi.

U praksi, za važan bivši brand domen često ima smisla:

zadržati ga dugoročno.

39. Updateujte najvažnije eksterne linkove

301 će pomoći.

Ali gde je moguće, promenite direktno:

• najvažnije backlinkove;
• partner profile;
• Clutch/DesignRush/directory profile;
• social profiles;
• PR reference;
• Google Ads landing URLs.

Google takođe preporučuje da prioritizujete važne external links prema inbound traffic-u.

40. Updateujte oglase

Vrlo česta migration rupa:

organic redirecti rade.

Ali Google Ads i dalje šalje klik na:

old URL → redirect → new URL.

Bolje je promeniti:

• Final URL;
• tracking templates;
• UTM;
• landing references;
• conversion flows.

41. Tracking mora biti testiran PRE launch-a

Novi sajt može savršeno rankirati i ipak napraviti ozbiljan poslovni problem ako nestanu:

• GA4 events;
• Google Ads conversions;
• GTM;
• Meta Pixel;
• CRM attribution;
• call tracking;
• form integrations.

Za detaljan measurement sloj pogledajte Conversion tracking.

42. Nemojte launch raditi u petak u 17:45

Ako možete birati termin:

• birajte niži traffic period;
• obezbedite developer-a;
• SEO osobu;
• osobu za analytics;
• osobu koja može vratiti prethodnu verziju ako nastane ozbiljan problem.

Google takođe preporučuje da se site move tempira u period nižeg saobraćaja kada je to moguće.

43. Launch treba da ima rollback plan

Pre launch-a treba znati:

• ko odlučuje o rollback-u;
• šta predstavlja P0 incident;
• koliko vremena imamo za reakciju;
• kako vraćamo prethodnu infrastrukturu;
• šta se događa sa bazom/podacima ako rollback radimo nakon novih transakcija.

Posebno kod e-commerce i application projekata.

44. LAUNCH DAY checklist

45. Crawl produkciju odmah nakon launch-a

Pre-launch staging crawl nije dovoljan.

Production može imati drugačije:

• redirect rules;
• CDN;
• robots;
• environment variables;
• cache;
• domain config.

Zato ponovite crawl.

46. Testirajte reprezentativan uzorak redirecta ručno

Ne samo homepage.

Testirajte:

• top organic pages;
• top linked pages;
• service pages;
• blog;
• categories;
• products;
• PDF/assets gde su relevantni;
• old query-string URL patterns.

47. POST-MIGRATION: Search Console postaje monitoring alat

Pratite:

• Page Indexing;
• Sitemaps;
• Performance;
• URL Inspection za kritične URL-ove;
• HTTPS/Core Web Vitals gde su relevantni.

Kod domain move-a gledajte:

old property ↓

i:

new property ↑

kao proces, ne kao instant switch.

48. Stari URL u Google rezultatima nekoliko dana ili nedelja nije automatski problem

Google navodi da nakon domain migration-a stari URL može još neko vreme biti prikazan kao alternativna verzija dok se sistemi i korisničko poverenje postepeno prebacuju ka novoj adresi.

To je očekivan deo procesa.

Ne treba svakih 12 sati menjati:

• redirect;
• canonical;
• sitemap

zato što Search još nije završio obradu.

49. Koliko traje SEO migracija?

Google trenutno navodi da za:

small/medium site

može biti potrebno:

nekoliko nedelja ili više

da većina URL-ova pređe.

Za veće sajtove proces može trajati duže.

Zavisi od:

• broja URL-ova;
• server speed-a;
• crawl-a;
• kvaliteta mapping-a;
• obima promene.

50. Nemojte oceniti migraciju samo nakon 48 sati

Prvih dana možete videti:

• stare URL-ove;
• nove URL-ove;
• privremene ranking promene;
• promenu crawl pattern-a.

To ne znači da treba ignorisati P0 probleme.

Ali treba razlikovati:

normalnu tranziciju

od:

tehničke greške.

51. Šta je P0 post-migration problem?

52. Šta nije automatski P0?

Na primer:

• jedan title je drugačiji;
• jedan mali image alt nedostaje;
• Google još prikazuje stari URL;
• ranking jedne fraze oscilira nekoliko pozicija prvog dana.

Migration tim mora da prioritizuje.

Ako sve označite kao urgent:

ništa nije urgent.

53. Monitoring tabela treba da bude URL-level

Za top stranice pratite:

• old URL;
• new URL;
• status;
• Google-selected canonical;
• organic clicks;
• impressions;
• conversions;
• notes.

54. Uporedite iste dane i iste sezonske periode

Nemojte zaključiti:

„migracija je izgubila 25%“

ako ste:

• stari sajt merili tokom Black Friday nedelje;
• novi sajt tokom januarskog pada.

Kontrolišite koliko možete:

• seasonality;
• promene media budžeta;
• brand kampanje;
• market events.

55. Organic pad nije automatski tehnički SEO problem

Ako je zajedno sa migracijom promenjen:

• content;
• offer;
• brand;
• category architecture;
• navigation,

Google možda procenjuje:

novu stranicu kao suštinski drugačiji dokument.

Zato migration diagnosis mora razlikovati:

technical transfer problem

od:

content/relevance change-a.

56. Kako dijagnostikovati pad jedne važne stranice?

Proverite:

1. Da li old URL redirectuje direktno?
2. Da li new URL vraća 200?
3. Da li je indexable?
4. Da li je canonical ispravan?
5. Da li je sadržaj sačuvan ili promenjen?
6. Da li su title/H1 promenjeni?
7. Da li je izgubila interne linkove?
8. Da li je u sitemap-u?
9. Da li Search Console vidi drugi canonical?
10. Da li je intent/SERP u međuvremenu promenjen?

57. E-commerce migration traži još stroži inventory

Pored standardnih stranica:

• products;
• categories;
• brands;
• filters;
• facets;
• pagination;
• product variants;
• out-of-stock logic;
• structured data;
• merchant feeds.

Jedna pogrešna category/facet odluka može promeniti:

desetine hiljada URL-ova.

58. Ne pravite novu URL strukturu samo zato što CMS drugačije generiše slug

Stari:

/proizvod/ime

Novi CMS automatski želi:

/collections/category/products/ime

To nije dovoljan razlog.

Development convenience ne treba automatski da diktira:

public information architecture.

59. Migracija iz WordPress-a u Laravel nije SEO upgrade sama po sebi

Možete dobiti:

• custom CMS;
• bolju business logiku;
• bolju kontrolu;
• čistiji stack.

Ali ako novi sistem nema dobar:

• metadata management;
• canonical;
• sitemap;
• redirect management;
• editorial workflow;
• internal linking,

SEO operativno može biti lošiji.

60. Isto važi za Webflow, WordPress ili bilo koji drugi CMS

Tehnologija nije sama po sebi migration rezultat.

Rezultat zavisi od:

implementation-a.

Za detaljnije poređenje pročitajte WordPress vs Laravel vs Webflow.

61. Rebranding + domain migration zahteva i entity migration

Ako:

OldBrand.com → NewBrand.com

nije dovoljno promeniti redirecte.

Treba ažurirati i:

• Organization data;
• WebSite data;
• About;
• company profiles;
• Google Business Profile;
• review platforme;
• awards;
• social;
• major third-party references.

Tu se migration SEO povezuje sa rebrandingom i Entity SEO-om.

62. AEO/GEO sloj takođe treba proveriti

Ako važni citation assets promene URL, proverite:

• da redirect rade;
• da sadržaj nije oslabljen;
• da first-party factual references koriste novi domen;
• da external profile-i vode na novu lokaciju.

Ne postoji poseban „AI migration protocol“ koji zamenjuje dobru web migraciju.

Prvo mora da bude zdrav:

web/Search migration layer.

63. Naš Migration Risk framework

64. Kompletna PRE-MIGRATION checklista

65. 30 dana posle migracije

Dan 0–1

• P0 crawl;
• redirect QA;
• indexability;
• tracking;
• transactions/forms.

Dan 2–7

• Search Console;
• server errors;
• top URL indexing;
• organic landing trend;
• conversion trend.

Nedelja 2

• old vs new URL monitoring;
• 404 cleanup;
• canonical issues;
• internal-link cleanup;
• external profile updates.

Nedelja 3–4

• cluster-level Search performance;
• commercial page performance;
• conversion quality;
• remaining migration debt.

66. Najčešće migration greške

Zaključak: migracija sajta je transfer vrednosti, ne samo transfer fajlova

Najveća greška je:

prvo napraviti novi sajt, a zatim pitati SEO tim kako da prebacimo stari.

U tom trenutku veliki deo važnih odluka je već donet.

Dobar migration proces počinje pre development launch-a:

Inventory.

Šta trenutno postoji?

Mapping.

Gde svaki važan URL ide?

Preserve.

Koju postojeću Search i business vrednost moramo da sačuvamo?

Redirect.

Kako jasno signaliziramo novu lokaciju?

Validate.

Da li novi sistem zaista radi?

Launch.

Da li produkcionu promenu kontrolišemo?

Monitor.

Da li Google, korisnici i conversions prelaze na novi sistem kako očekujemo?

Ne možemo garantovati da tokom velike migracije neće biti privremenih Search fluktuacija.

Možemo mnogo konkretnije garantovati da:

nećemo svesno obrisati godine SEO vrednosti zato što niko nije napravio URL mapping spreadsheet.

Ako planirate promenu CMS-a, redesign, novi domen ili kompleksnu web migraciju, pogledajte DA web-development pristup, SEO optimizaciju ili nam pošaljite postojeći i planirani sistem preko kontakt stranice.