SEO Kaybı Olmadan URL Yapısını Değiştirmek: .htaccess ve Nginx 301 Yönlendirme Rehberi

Neden URL Yapısı Değiştirmek Riskli Ama Bazen Gerekli?

URL yapınızı değiştirmek, hem teknik hem de SEO tarafında en hassas operasyonlardan biridir. Bir yandan daha okunabilir, kısa ve anahtar kelime odaklı URL’ler SEO performansını uzun vadede güçlendirir; diğer yandan yanlış kurgulanmış bir geçiş, yıllardır biriken otoritenizi birkaç günde eritebilir. DCHost tarafında yeni projeler planlarken, mimari tasarım toplantılarında en çok konuştuğumuz başlıklardan biri de tam olarak bu: “URL yapısını nasıl iyileştiririz ve bunu yaparken hiçbir şeyi kırmayız?”

Bu yazıda SEO kaybı olmadan URL yapısı değiştirmek için baştan sona teknik bir yol haritası paylaşacağız. Hem Apache/.htaccess hem de Nginx üzerinde 301 yönlendirme örnekleri, sık yapılan hatalar, test yöntemleri ve log analizi dahil olacak. Eğer alan adı da değiştiriyorsanız, mutlaka önce alan adı değiştirirken SEO kaybetmemek için hazırladığımız rehbere de göz atmanızı öneririm; bu yazı ise özellikle aynı alan adında URL yapısını değiştirme kısmına odaklanıyor.

Ayrıca HTTP durum kodlarının SEO’ya etkisini henüz netleştirmediyseniz, arka planda nasıl çalıştığını anlamak için 301, 302, 404 ve 410 durum kodlarını anlattığımız detaylı rehber de bu makalenin iyi bir tamamlayıcısı olacaktır.

SEO Perspektifinden URL Değişikliğinin Etkileri

Google ve diğer arama motorları için URL, bir sayfanın benzersiz kimliğidir. Siz URL’yi değiştirdiğinizde, arama motorunun gözünde yeni bir sayfa oluşturmuş olursunuz. Bu yüzden, eski URL’den yeni URL’ye doğru HTTP durum kodu ile sinyal göndermek kritik önem taşır.

Burada temel prensipleri netleştirelim:

• 301 (Moved Permanently): Kalıcı taşınma sinyalidir; link otoritesinin (link juice) büyük kısmını yeni URL’ye taşır.
• 302/307 (Temporary Redirect): Geçici yönlendirmedir; uzun vadeli URL değişikliklerinde SEO için doğru tercih değildir.
• 404 (Not Found): İçerik gerçekten yoksa kullanılmalı; fazla 404, site kalitesine olumsuz sinyal verir.
• 410 (Gone): İçeriğin kalıcı olarak kaldırıldığını net şekilde bildirir; bazı durumlarda 404’ten daha uygun olabilir.

URL yapısını değiştirirken amacımız, eski tüm URL’leri tek seferde ve kalıcı olarak yeni karşılıklarına taşımak. Bu yüzden neredeyse her zaman 301 yönlendirme kullanacağız.

URL Değişikliğinde Sık Görülen SEO Problemleri

• Yanlışlıkla 302 kullanmak ve otorite transferini geciktirmek
• Eski URL’ye birden fazla “zincirli” yönlendirme (301 → 302 → 301 gibi) uygulamak
• Eski URL’yi yeni URL yerine ana sayfaya yönlendirmek (soft 404 etkisi)
• Yeni URL’leri sitemap’e eklemeyi unutmak
• İç linkleri güncellemeden bırakmak ve “gizli” redirect zincirleri oluşturmak

Bu hatalardan kaçınmak için, URL değişikliğini diğer SEO bileşenleriyle birlikte ele almak gerekir. Özellikle robots.txt ve sitemap.xml kurulum rehberimizde anlattığımız prensipleri bu sürece entegre etmek, arama motorlarının yeni yapınızı daha hızlı anlamasını sağlar.

Planlama: URL Haritası Çıkarmak ve Strateji Belirlemek

İyi planlanmamış bir URL geçişi, ne kadar düzgün 301 kuralı yazarsanız yazın mutlaka bir yerlerden sızar. DCHost’ta bu tür geçişlerde her zaman önce URL haritası çıkarıyoruz. Adım adım gidelim:

1. Mevcut Tüm URL’leri Listeleyin

Önce gerçekten hangi URL’lere sahip olduğunuzu netleştirmeniz gerekiyor:

• CMS (WordPress, Laravel admin, özel panel) içinden URL export’u
• Veritabanından yazı, ürün, kategori vb. slug/ID listeleri
• Sunucu erişiminiz varsa Apache/Nginx log’larından en çok hit alan URL’ler
• Google Search Console ve Analytics’ten organik trafik alan URL listeleri

Özellikle log analizine meraklıysanız, Apache ve Nginx loglarını okuma rehberi bu aşamada işinizi kolaylaştırır. En çok trafik alan URL’leri net görmek, önceliklendirme yapmanızı sağlar.

2. Yeni URL Tasarımını Netleştirin

URL yapısını değiştirme motivasyonlarınız genelde şunlar olur:

• Dinamik parametrelerden (id=123 gibi) SEO dostu slug’lara geçmek
• Uzun URL’leri kısaltmak (özellikle tarih içeren yapılar)
• Kategori/etiket hiyerarşisini sadeleştirmek
• Çok dilli yapıda /en/, /de/ gibi dil dizinlerine geçmek

Burada önemli nokta, yeni yapınızın en az 3–5 yıl dayanıklı olacak şekilde tasarlanması. Sık sık URL yapısı değiştirmek, arama motorlarının güvenini ciddi şekilde zedeler. Çok dilli yapılar ve blog/mağaza ayrımı gibi konularda daha geniş resme bakmak istiyorsanız, subdomain mi alt dizin mi rehberi size iyi fikir verecektir.

3. Eski → Yeni URL Eşleştirme Tablosu Oluşturun

Artık iki listemiz var: mevcut URL’ler ve tasarladığınız yeni yapı. Şimdi bir eşleştirme tablosu hazırlamalısınız. Örneğin bir elektronik ticaret sitesi için:

• /urun.php?id=123 → /urun/iphone-15-pro/
• /kategori.php?id=12 → /kategori/telefon/
• /blog_detay.php?id=45 → /blog/seo-url-yapisi-degistirme/

Eğer URL sayınız binlerce ise, tek tek eşleştirme yapmak zor olabilir. Bu durumda desen bazlı (pattern) yönlendirmeler kullanacağız. Birazdan hem .htaccess hem Nginx tarafında pratik regex örnekleriyle bunu göstereceğim.

4. Önce Staging Ortamında Test Edin

Canlı ortamda deneme yapmak, özellikle yüksek trafikli WordPress ve e-ticaret sitelerinde gereksiz risk almanız anlamına gelir. Bu yüzden mümkünse önce bir staging/test ortamı kurun. paylaşımlı hosting kullanıyorsanız, adım adım nasıl staging ortamı kurabileceğinizi WordPress staging rehberimizde ayrıntılı şekilde anlattık.

Apache Üzerinde .htaccess ile 301 Yönlendirme Örnekleri

Apache kullanan çoğu hosting hesabında, yönlendirmeleri .htaccess dosyası üzerinden yönetiyoruz. Aşağıdaki örneklerde mod_rewrite etkin olmak zorunda, çoğu paylaşımlı hosting ve DCHost Apache ortamında zaten varsayılan olarak açık gelir.

.htaccess Dosyasının Temel İskeleti

RewriteEngine On

# Gerekirse buraya kurallar gelecek

Eğer mevcut .htaccess’inizde WordPress, Laravel veya başka bir uygulamanın kuralları varsa, yeni yönlendirmelerinizi genellikle bu kuralların üzerine eklemeniz gerekir; aksi halde uygulama kuralları önce çalışıp sizin yazdığınız yönlendirmeleri boşa düşürebilir.

1. Tek Bir URL’yi Yeni URL’ye 301 ile Taşımak

En basit senaryo: Tek bir eski URL’yi yeni bir URL’ye kalıcı olarak yönlendirmek.

RewriteEngine On

RewriteRule ^eski-sayfa$ yeni-sayfa [R=301,L]

• ^eski-sayfa$ ile dizin kökündeki /eski-sayfa hedefleniyor.
• Tarayıcıya ve arama motoruna 301 sinyali gönderiliyor.

Eğer URL’niz uzantılı ise (eski-sayfa.html gibi), deseni şu şekilde güncelleyin:

RewriteRule ^eski-sayfa.html$ yeni-sayfa [R=301,L]

2. Tüm Siteyi Yeni Alan Adına Yönlendirmek

Aynı anda hem alan adını hem URL yapısını değiştiriyorsanız, öncelikle alan adı taşıma stratejisini netleştirmeniz gerekir. Bu konuda detaylı bir rehberi zaten hazırladık: alan adı değiştirirken SEO kaybını önleme kılavuzu. Burada yalnızca teknik örneği gösterelim:

RewriteEngine On

RewriteCond %{HTTP_HOST} ^eskidomain.com$ [NC]
RewriteRule ^(.*)$ https://yenidomain.com/$1 [R=301,L]

Bu kural:

• eskidomain.com altındaki tüm URL’leri
• yeni domain altındaki aynı path’e 301 ile taşır

Bundan sonra, yeni domain altında ek URL yapısı değişiklikleri yapacaksanız, kuralları yenidomain.com üzerinde ayrı .htaccess/Nginx bloklarında yönetmelisiniz.

3. Eski Klasörü Yeni Klasöre Taşımak

Örneğin /blog/ dizininizi /icerik/ dizinine taşıdınız. Eski linklerin boşa düşmemesi için:

RewriteEngine On

RewriteRule ^blog/(.*)$ icerik/$1 [R=301,L]

Bu sayede:

• /blog/seo-url-yapisi-degistirme/ → /icerik/seo-url-yapisi-degistirme/
• /blog/kategori/teknoloji/ → /icerik/kategori/teknoloji/

4. Query String’li Eski Yapıdan Temiz Permalink’e Geçmek

Dinamik parametre kullanan eski yapılar SEO açısından problemli olabilir. Örneğin:

• /urun.php?id=123 yerine /urun/iphone-15-pro/

Bu durumda, çoğu zaman ürün slug’ını veritabanından çekip .htaccess’te otomatik üretmek mümkün olmaz; genelde URL eşleştirme tablosunu kullanıp tek tek kural yazarız:

RewriteEngine On

RewriteCond %{QUERY_STRING} ^id=123$ [NC]
RewriteRule ^urun.php$ urun/iphone-15-pro/? [R=301,L]

RewriteCond %{QUERY_STRING} ^id=124$ [NC]
RewriteRule ^urun.php$ urun/samsung-galaxy-s24/? [R=301,L]

Buradaki ?, eski query string’in yeni URL’ye taşınmamasını sağlar. Yani kullanıcı /urun.php?id=123’ye geldiğinde /urun/iphone-15-pro/ adresine, parametresiz şekilde yönlendirilir.

5. www ↔ non-www veya HTTP → HTTPS Zorunlu Yönlendirme

URL yapısı değişikliğinden bağımsız olarak, site mimarinizi tek bir kanonik ana domain üzerinde toplamak zorundasınız. HTTP’den HTTPS’e geçiş rehberimizde bu konuyu detaylı işledik; burada kısa bir örnek verelim:

RewriteEngine On

# www'den non-www'ye zorunlu yönlendirme
RewriteCond %{HTTP_HOST} ^www.siteadiniz.com$ [NC]
RewriteRule ^(.*)$ https://siteadiniz.com/$1 [R=301,L]

Bu kural, URL yapısı değişikliğinden önce zaten aktif olmalı; böylece arama motorları hangi sürümün kanonik olduğunu net şekilde anlar.

Nginx ile 301 Yönlendirme Kuralları

Nginx kullanan VPS veya dedicated sunucularda yönlendirmeleri .htaccess yerine server block (site konfigürasyon dosyaları) içinde yazıyoruz. DCHost VPS hizmetlerinde Nginx konfigürasyonlarını çoğunlukla /etc/nginx/sites-available ve /etc/nginx/sites-enabled yapısıyla yönetiyoruz.

1. Tek Bir URL’yi 301 ile Yönlendirmek

Basit bir örnek:

server {
    listen 80;
    server_name siteadiniz.com;

    location = /eski-sayfa {
        return 301 /yeni-sayfa;
    }

    # Diğer location ve ayarlar
}

location = /eski-sayfa ifadesi, tam eşleşme (exact match) yapar. Daha karmaşık desenler için ~ (regex) veya ^~ (prefix) kullanabilirsiniz.

2. Tüm Siteyi Yeni Alan Adına Taşımak

Eski domain’deki tüm istekleri yeni domain’e taşımak için:

server {
    listen 80;
    server_name eskidomain.com www.eskidomain.com;

    return 301 https://yenidomain.com$request_uri;
}

$request_uri, path ve query string’i olduğu gibi korur. Böylece:

• http://eskidomain.com/blog/yazi?ref=facebook → https://yenidomain.com/blog/yazi?ref=facebook

3. Eski Klasörden Yeni Klasöre Geçiş

Apache’deki ^blog/(.*)$ → icerik/$1 örneğinin Nginx karşılığı:

server {
    listen 80;
    server_name siteadiniz.com;

    location ~ ^/blog/(.*)$ {
        return 301 /icerik/$1;
    }

    # Diğer location'lar
}

Bu kural:

• /blog/seo-url-yapisi → /icerik/seo-url-yapisi
• /blog/kategori/hosting → /icerik/kategori/hosting

4. Query String’e Göre Yönlendirme

Nginx’te query string’e göre yönlendirme yapmak için if kullanmak yaygın bir yaklaşımdır, ancak karmaşık koşullarda dikkatli kullanmak gerekir. Basit bir örnek:

server {
    listen 80;
    server_name siteadiniz.com;

    location = /urun.php {
        if ($arg_id = 123) {
            return 301 /urun/iphone-15-pro/;
        }
        if ($arg_id = 124) {
            return 301 /urun/samsung-galaxy-s24/;
        }
    }
}

Burada $arg_id, ?id= parametresinin değerini temsil eder. Yine uzun liste gerekiyorsa, map direktifi ile ayrı bir haritalama tablosu da kullanabilirsiniz.

5. www ↔ non-www ve HTTP → HTTPS Zorunlu Yönlendirme

Nginx tarafında bu yönlendirmeleri ayrı bir server block ile çözmek daha sağlıklıdır:

# HTTP'den HTTPS'e ve www'den non-www'ye yönlendirme
server {
    listen 80;
    server_name www.siteadiniz.com siteadiniz.com;

    return 301 https://siteadiniz.com$request_uri;
}

server {
    listen 443 ssl http2;
    server_name siteadiniz.com;

    # SSL ayarları, root, PHP-FPM vb.
}

HTTP/2 ve HTTP/3 desteğinin SEO ve Core Web Vitals üzerindeki etkilerini merak ediyorsanız, HTTP/2 ve HTTP/3 rehberimiz yönlendirme kurgunuzla birlikte dikkate almanız gereken performans detaylarını da anlatıyor.

WordPress, Laravel ve E-Ticaret Siteleri İçin Özel Senaryolar

Gerçek dünyada URL yapısı değişiklikleri çoğunlukla belirli uygulamalar etrafında gerçekleşiyor. DCHost üzerinde en sık karşılaştığımız üç senaryoyu kısaca ele alalım.

1. WordPress Permalink Yapısını Değiştirmek

WordPress’te Ayarlar → Kalıcı Bağlantılar menüsünden permalink yapısını değiştirmek oldukça kolay görünür; ancak bu işlemi, özellikle büyük sitelerde, doğrudan canlıda yapmak risklidir. Önerilen akış:

1. Önce staging ortamında permalink değişikliğini test edin.
2. Yeni yapıda 404 veren sayfa kalmadığından emin olun.
3. Gerekirse özel redirect eklentileriyle bazı eski URL’leri manuel eşleyin.
4. Staging’de her şey yolundaysa, canlıya aynı adımları uygulayın.
5. Sunucu seviyesinde (.htaccess/Nginx) ek kurallarla eksik yönlendirmeleri tamamlayın.

WordPress optimizasyonu ve sunucu tarafı ayarlarıyla ilgileniyorsanız, WordPress için sunucu tarafı optimizasyon rehberimiz URL geçişinden sonra performansın da yerinde kalmasını sağlamak için iyi bir referans olacaktır.

2. Laravel ve Özel PHP Uygulamalarında Route Değişiklikleri

Laravel veya özel framework’lerde URL yapısı genellikle routes/web.php gibi dosyalarda tanımlıdır. Yeni route isimleri, controller action’ları veya slug yapıları tanımladığınızda:

• Uygulama içi route isimlerini (route name) güncelleyin.
• Eski URL’lere sunucu seviyesinde 301 yönlendirme ekleyin.
• Eğer route model binding kullanıyorsanız, eski slug’lardan yeni slug’lara eşleştirme tablosu tutmayı düşünün.

Laravel dağıtımı ve hosting tarafındaki akışı henüz netleştirmediyseniz, Laravel’i VPS’te yayınlama rehberimiz ile başlayıp, ardından URL geçişini planlamak daha doğru bir sıradır.

3. E-Ticaret Sitelerinde Kategori ve Filtre Yapısını Değiştirmek

E-ticaret sitelerinde en sancılı URL değişiklikleri genelde kategori/alt kategori ve filtre URL’lerinde ortaya çıkar:

• /telefonlar/iphone/?renk=siyah → /telefon/iphone/siyah/
• /kadin-giyim/?beden=m → /kadin-giyim/beden-m/

Burada iki kritik nokta var:

1. Gerçekten indekslenmesini istediğiniz sayfalar için 301 yönlendirme yapın.
2. Eski yapıda “gereksiz” indekslenmiş (çoklu filtre kombinasyonu) sayfaları, yeni yapıda noindex veya 410 ile temizlemeyi değerlendirin.

Bu kararlar tamamen SEO stratejinizle ilgilidir; teknik olarak her şeyi yönlendirebilirsiniz, ama her şeyi yönlendirmek her zaman doğru değildir. Trafik analizi ve log incelemesiyle hangi filtre kombinasyonlarının değerli olduğunu mutlaka ayırın.

Değişiklik Sonrası Kontrol Listesi

URL yapısını değiştirdiniz, 301 kurallarını yazdınız. Şimdi işin en az teknik kısım kadar önemli olan kontrol ve izleme aşamasına geldik.

1. 404 ve 5xx Hatalarını İzleyin

Geçişten sonraki ilk 1–2 hafta, Apache/Nginx loglarını yakından takip edin:

• Hangi eski URL’ler 404 veriyor?
• Yanlış yazdığınız regex yüzünden beklenmedik 500 hataları var mı?

Bu aşamada sunucu loglarını okuma rehberimizde anlattığımız pratik komutlar ve filtreleme yöntemleri çok işinize yarar.

2. Sitemap ve robots.txt’yi Güncelleyin

Yeni URL yapınızı yansıtan güncel bir sitemap.xml oluşturun ve eski URL’leri bu dosyadan kaldırın. Ardından:

• robots.txt içinde sitemap adresinizin güncel olduğundan emin olun.
• Yeni sitemap’i Google Search Console’a yeniden gönderin.

Bu adımları atlamamak için, yeni web sitesi yayına alınırken SEO ve performans kontrol listemiz ile çapraz kontrol yapmak iyi bir pratiktir.

3. İç Linkleri ve Kanonik Etiketleri Güncelleyin

Site içi linkleriniz hala eski URL’lere işaret ediyorsa, her tıklamada gizli bir 301 zinciri çalıştırıyorsunuz demektir. Bu da hem performansı hem de arama motoru tarama bütçesini olumsuz etkiler.

• WordPress kullanıyorsanız, veritabanında toplu arama/değiştir ile eski URL’leri yeni URL’lerle değiştirin.
• Laravel ve özel uygulamalarda, blade/template dosyalarındaki sabit URL’leri güncelleyin.
• <link rel="canonical"> etiketlerinin yeni URL’leri gösterdiğinden emin olun.

4. Google Search Console ve Analitik Araçları Takibi

Geçişten sonraki ilk hafta içinde:

• Tarama hataları (Coverage/Indexing) raporlarını takip edin.
• Soft 404 uyarılarını ciddiye alın; genelde ana sayfaya yapılan toplu yönlendirmeler sebep olur.
• En çok trafik alan sayfalarınızda konum ve tıklama değişimlerini izleyin.

URL yapısı değişikliği, kısa vadede küçük dalgalanmalara neden olabilir; önemli olan, 4–8 hafta içinde trendin tekrar yukarı dönmeye başlamasıdır.

DCHost Üzerinde Bu Süreci Nasıl Yönetiyoruz?

DCHost’ta müşterilerimizle çalışırken URL yapısı değişikliğini hiçbir zaman sadece “.htaccess dosyasına birkaç kural ekleyelim” seviyesinde görmüyoruz. Bu süreci genellikle şu adımlarla yönetiyoruz:

• Mevcut URL envanterinin ve trafik verilerinin çıkarılması
• Yeni URL mimarisinin SEO ve performans açısından değerlendirilmesi
• Staging ortamında uygulama ve yönlendirme kurallarının test edilmesi
• Canlıya geçişte DNS/TTL, önbellek ve CDN davranışlarının birlikte ele alınması
• İlk 2–4 hafta log analizi, 404 takibi ve gerektiğinde ek 301 kurallarıyla iyileştirme

Altyapı tarafında paylaşımlı hosting, VPS, dedicated veya colocation kullanıyor olmanız fark etmiyor; önemli olan, geçişi kontrollü ve ölçülebilir bir şekilde yönetmek. Eğer siz de sitenizin URL yapısını yenilemeyi düşünüyor, ancak SEO kaybı yaşama riskinden çekiniyorsanız, DCHost ekibi olarak hem teknik altyapı hem de geçiş planı konusunda yanınızdayız.

Yeni bir hosting mimarisi tasarlarken veya mevcut sitenizi DCHost altyapısına taşırken, URL yapısı, SEO, performans ve güvenlik konularını birlikte ele alıyoruz. Böylece tek seferde, tekrar tekrar bozmadan uzun süre kullanabileceğiniz bir yapı kurmak mümkün oluyor.

Özet ve Son Tavsiyeler

URL yapısını değiştirmek, doğru yapıldığında uzun vadede daha temiz, anlaşılır ve SEO dostu bir site mimarisi sağlar. Ancak plansız ve testsiz gerçekleştirildiğinde, organik trafiğinizde ciddi dalgalanmalara yol açabilir. Bu yazıda:

• URL değişikliğinin SEO üzerindeki etkilerini
• Eski → yeni URL haritası çıkarmayı
• .htaccess ve Nginx üzerinde pratik 301 yönlendirme örneklerini
• WordPress, Laravel ve e-ticaret gibi yaygın senaryoları
• Geçiş sonrası kontrol ve izleme adımlarını
• Ve DCHost tarafında bu süreci nasıl yönettiğimizi

detaylı biçimde ele aldık.

Son tavsiyeler:

• Önce plan, sonra konfigürasyon: URL haritası çıkarmadan .htaccess/Nginx’e dokunmayın.
• Mutlaka staging/test ortamında deneyin, canlıya öyle alın.
• Büyük projelerde log analizi ve Search Console verilerini geçişten sonra en az 1–2 ay yakından takip edin.
• Her şeyi ana sayfaya yönlendirmek yerine, mümkün olduğunca spesifik 1:1 yönlendirmeler kurgulayın.

Eğer URL yapınızı değiştirmek, alan adınızı yenilemek veya sitenizi DCHost altyapısına taşımak istiyorsanız ve nereden başlayacağınızı netleştirmek istiyorsanız, ekibimizle birlikte somut bir geçiş planı çıkarabiliriz. Mevcut loglarınız, trafik verileriniz ve hedef yapınız üzerinden birlikte ilerleyip, SEO kaybı yaşamadan daha temiz bir URL mimarisine geçmenize yardımcı oluruz.