URL Yapısı Değiştirme: Apache ve Nginx 301 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. Daha okunabilir URL’ler kullanıcıların içeriği anlamasını kolaylaştırabilir; ancak yalnızca URL’leri kısaltmak veya anahtar kelime eklemek SEO artışı garantilemez. Yanlış planlanmış bir geçiş ise organik görünürlüğü ve mevcut bağlantılardan gelen trafiği etkileyebilir.

Bu yazıda SEO kaybı riskini azaltarak URL yapısı değiştirmek için baştan sona teknik bir yol haritası paylaşacağız. Geçiş sırasında geçici sıralama dalgalanmaları olabilir; kayıpsız sonuç garanti edilemez. 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

URL, bir sayfanın adresidir. URL değiştiğinde arama motorlarının yeni adresi keşfetmesi ve eski adresle ilişkisini anlaması gerekir. 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 ve 308: Kalıcı taşınma sinyalidir. Google bunları hedef URL’nin kanonik olması için bir sinyal olarak kullanır; yönlendirme tek başına sıralama garantisi değildir.
• 302 ve 307: Geçici taşınmayı belirtir. Kalıcı URL değişikliği için uygun kalıcı kodu seçin.
• 404 ve 410: Kaldırılmış ve ilgili yeni karşılığı olmayan içerik için uygundur; tek başına 404 sayısı genel bir site kalitesi cezası anlamına gelmez.

URL yapısını değiştirirken amacımız, taşınan içeriklerin eski URL’lerini tek adımda ve kalıcı olarak ilgili yeni karşılıklarına yönlendirmek. Bu örneklerde 301 yönlendirme kullanacağız; 308 de kalıcı yönlendirme için uygundur. Yeni karşılığı olmayan kaldırılmış içerikler ise 404 veya 410 döndürmelidir.

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

• Kalıcı bir taşınmada yanlışlıkla 302 kullanarak geçici taşınma sinyali vermek
• 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 gereksiz yönlendirme adımları 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

Doğru yazılmış 301 kuralları, eksik URL eşleştirmelerini telafi etmez. Bu nedenle geçişten önce bir URL haritası hazırlayın. 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ıyı uzun süre korunabilecek şekilde tasarlamaktır. Sık değişiklikler yeniden tarama, indeksleme ve yönlendirme yönetimi yükünü artırır. Mevcut URL’ler açık ve anlaşılırsa sırf kısaltmak için değiştirmek gerekmez. Ç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, eski ve yeni adresler arasında ortak bir dönüşüm kuralı varsa desen bazlı (pattern) yönlendirmeler kullanılabilir. Ancak sayısal ID’den ürün adına geçiş gibi dönüşümler için bir eşleştirme tablosu veya uygulama/veritabanı mantığı gerekir; regex tek başına yeni slug’ı belirleyemez. 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’de yönlendirmeler, sunucu yapılandırması izin veriyorsa .htaccess dosyası üzerinden yönetilebilir. Örnekler Apache 2.4 ve belge kökündeki .htaccess içindir; mod_rewrite, uygun AllowOverride izni ve yönetici tarafından etkinleştirilmiş FollowSymLinks veya SymLinksIfOwnerMatch gerekir. Birbirine alternatif tarifleri tek dosyaya toplamayın. Örnekler web sayfalarının GET/HEAD isteklerine odaklanır: 301 sonrasında bazı istemciler POST’u GET’e çevirebilir; yöntem ve gövdenin korunması gereken uçları ayrıca değerlendirin. Apache mod_rewrite belgesi bağlam ve önkoşulları açıklar.

.htaccess Dosyasının Temel İskeleti

RewriteEngine On

# Gerekirse buraya kurallar gelecek

Özel taşıma kurallarını uygulamanın genel front-controller kurallarından önce değerlendirin; WordPress’in otomatik ürettiği işaretli bölümü değiştirmeyin. Aynı mod_rewrite bağlamında sıra önemlidir, ancak farklı modüllerin yürütme sırası dosyadaki satır sırasıyla belirlenmez. Mevcut sanal sunucu, .htaccess, CDN ve uygulama kurallarını birlikte inceleyin.

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$ https://example.com/yeni-sayfa [R=301,L]

• Bu .htaccess deseni yalnızca /eski-sayfa yoluyla eşleşir; /eski-sayfa/ veya alt yollar ayrıca eşlenmelidir.
• Sabit hedef örnekteki kanonik HTTPS alan adıdır. Yeni hedefte sorgu tanımlanmadığı için mevcut sorgu varsayılan olarak korunur; parametre politikasını URL haritanızda belirtin.

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

RewriteRule ^eski-sayfa\.html$ https://example.com/yeni-sayfa [R=301,L]

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

Alan adı ve yol aynı geçişte değişiyorsa önce alan adı taşıma rehberini inceleyin. Aşağıdaki örnek yalnızca old.example adlı eski alan adının aynı yollarını new.example alan adına taşır; www.old.example dahil değildir. Bu örnek alan adları kendi doğrulanmış adlarınızla değiştirilmelidir.

RewriteEngine On

RewriteCond %{HTTP_HOST} ^old\.example$ [NC]
RewriteCond %{THE_REQUEST} "\s(/[^?\s]*)(?:\?|\s)"
RewriteRule ^ https://new.example%1 [R=301,L,NE]

Bu kural:

• Hedef alan adı sabittir; istemciden gelen host hedefe kopyalanmaz.
• THE_REQUEST özgün, henüz çözülmemiş istek satırıdır. Son RewriteCond yol bölümünü yakalar; NE bu yakalamadaki mevcut yüzde kodlamasının yeniden kodlanmasını önler. Sorgu, RewriteRule varsayılanıyla taşınır.
• Bu tarif normal origin-form HTTP istekleri içindir. Kodlanmış slash, Unicode, boşluk ve ayrılmış karakterleri gerçek sunucu politikanızla ayrıca test edin; decoded REQUEST_URI veya rastgele başka bir yakalamaya NE eklemek eşdeğer değildir. Eski HTTPS adında da geçerli sertifika ve erişilebilir hizmet gerekir.

Alan adı ve URL yolları aynı geçişte değişiyorsa, eski alan adındaki URL’leri doğrudan nihai yeni adreslere yönlendirin. Genel alan adı kuralı yerine veya ondan önce bu eşleştirmeleri uygulayın; önce yeni alan adındaki eski yola, ardından yeni yola yönlendirmek gereksiz bir zincir oluşturur.

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
RewriteCond %{THE_REQUEST} "\s/blog/([^?\s]*)(?:\?|\s)"
RewriteRule ^blog/ https://example.com/icerik/%1 [R=301,L,NE]

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

Parametreli URL’leri sırf parametre içerdiği için değiştirmek gerekmez. Aynı içeriğe ulaşan çok sayıda URL oluşuyorsa, URL ve kanonikleştirme stratejisini gözden geçirin. Parametreli yapıdan okunabilir bir yola geçiş örneği:

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

Regex bir ürün ID’sinden ürün adını keşfedemez. Veritabanından doğrulanmış bir eski → yeni eşleştirme çıkarın. Aşağıdaki Apache 2.4 örneği yalnızca tam olarak id=123 veya id=124 sorgusunu kabul eder; fazladan, tekrarlı ya da farklı kodlanmış parametreler bu kurallarla eşleşmez.

RewriteEngine On
RewriteCond %{QUERY_STRING} ^id=123$
RewriteRule ^urun\.php$ https://example.com/urun/iphone-15-pro/ [R=301,L,QSD]

RewriteCond %{QUERY_STRING} ^id=124$
RewriteRule ^urun\.php$ https://example.com/urun/samsung-galaxy-s24/ [R=301,L,QSD]

QSD, eşleşen isteğin tüm sorgusunu kaldırır. Örneğin /urun.php?id=123 doğrudan /urun/iphone-15-pro/ adresine gider. Eşleşmeyen istek bu iki kuralın ardından mevcut uygulama işleyişine devam eder; hâlâ geçerli ürünleri veya izleme parametrelerini nasıl ele alacağınızı ayrıca eşleyin. Eski betik kapatılacaksa karşılıksız adresler gerçek 404/410 döndürmelidir.

5. www Sürümünü HTTPS non-www Adresine Yönlendirmek

URL yapısı değişikliğinden bağımsız olarak, aynı içeriği sunan www/non-www ve HTTP/HTTPS sürümleri için tercih edilen kanonik adresi belirleyin. HTTP’den HTTPS’e geçiş rehberimizde bu konuyu detaylı işledik; burada kısa bir örnek verelim:

RewriteEngine On

RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteCond %{THE_REQUEST} "\s(/[^?\s]*)(?:\?|\s)"
RewriteRule ^ https://example.com%1 [R=301,L,NE]

Bu örnek yalnızca www.example.com sürümünü hedefler; http://example.com/ isteği için HTTPS yönlendirmesi ayrıca gerekir. HTTPS www isteği de önce www adında geçerli TLS sertifikasıyla bağlantı kurmalıdır. THE_REQUEST/NE kullanımı yukarıdaki ham yol koruma açıklamasına bağlıdır. TLS bir proxy’de sonlanıyorsa HTTPS kararını o güvenilir katmanda verin; Apache’nin yerel HTTPS değişkenini dış bağlantıyla aynı sanmayın.

Nginx ile 301 Yönlendirme Kuralları

Nginx kullanan VPS veya dedicated sunucularda yönlendirmeler .htaccess yerine server block (site konfigürasyon dosyaları) içinde tanımlanır. /etc/nginx/sites-available ve /etc/nginx/sites-enabled dizin yapısı bir düzenleme seçeneğidir; kullanılacak dosyaları mevcut Nginx yapılandırmanızdaki include yollarına göre belirleyin.

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

Aşağıdaki location parçasını mevcut kanonik HTTPS server bloğunuza ekleyin. location tam normalize edilmiş yolla eşleşir; sorgu eşleştirmenin parçası değildir.

location = /eski-sayfa {
    return 301 https://example.com/yeni-sayfa$is_args$args;
}

= tam yol eşleşmesini belirtir. $is_args$args sorguyu açıkça taşır; return bunu kendiliğinden eklemez. ~ büyük/küçük harfe duyarlı regex, ~* duyarsız regex, ^~ ise seçilen en uzun prefix için regex aramasını atlama talimatıdır. Yeni location eklemeden önce mevcut PHP ve uygulama konumlarının önceliğini kontrol edin. Nginx location belgesi seçim sırasını tanımlar.

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

Aşağıdaki port 80 örneği, eski domain’e gelen HTTP isteklerini yeni domain’e taşımak içindir; eski HTTPS adreslerini kapsayan bir yapılandırma göstermez:

server {
    listen 80;
    listen [::]:80;
    server_name old.example www.old.example;
    return 301 https://new.example$request_uri;
}

$request_uri özgün yolu ve sorguyu birlikte içerir. Bu port 80 örneğine ek olarak her eski HTTPS adı için geçerli sertifika/anahtar içeren bir TLS yönlendirme bloğu gerekir; yönlendirme sertifika hatasını gideremez. Alan adıyla birlikte yollar değişiyorsa genel kuraldan önce doğrudan nihai hedefleri eşleyin.

• http://old.example/blog/yazi?ref=facebook → https://new.example/blog/yazi?ref=facebook
• Bu eşleşme yalnızca taşınan içeriğin aynı yolda bulunduğu durumda uygundur.

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

Eski /blog/ önekini değiştirirken sorgu ve mevcut yüzde kodlamasını korumak için $request_uri üzerinden harita oluşturabilirsiniz. İlk map bölümü http bağlamına, if/return bölümü mevcut kanonik server bloğuna yerleştirilir; bunlar iki ayrı yerleştirme parçasıdır.

# http context, outside server blocks
map $request_uri $legacy_blog_target {
    default "";
    ~^/blog/(?<legacy_blog_suffix>.*)$ https://example.com/icerik/$legacy_blog_suffix;
}

# Inside the existing canonical server block
if ($legacy_blog_target != "") {
    return 301 $legacy_blog_target;
}

Bu kural:

• /blog/seo-url-yapisi?ref=mail → https://example.com/icerik/seo-url-yapisi?ref=mail
• /blog/kategori/hosting → https://example.com/icerik/kategori/hosting
• Yakalanan kuyruk sorguyu zaten içerir; ayrıca $is_args$args eklemeyin. Ham /blog/ önekiyle eşleşmeyen kodlanmış alternatifleri ayrı değerlendirin. Genel alan adı/HTTPS dönüşümü bu kuraldan önce dönüyorsa hâlâ zincir oluşabilir; ilgili giriş bloklarında nihai eşlemeyi önceliklendirin.

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

Aşağıdaki emekliye ayrılmış uç örneği yalnızca iki tam sorguyu yeni ürünlere taşır. if blokları sadece return kullanır; eşleşmeyen her istek 404 ile biter. Mevcut kanonik server bloğuna eklenir.

location = /urun.php {
    if ($args = "id=123") {
        return 301 https://example.com/urun/iphone-15-pro/;
    }
    if ($args = "id=124") {
        return 301 https://example.com/urun/samsung-galaxy-s24/;
    }
    return 404;
}

$arg_id yalnızca id parametresinin değerine bakar; başka parametrelerin veya tekrarlı id değerlerinin anlamını kendiliğinden doğrulamaz. Burada Apache örneğiyle aynı katı eşleşme için $args kullanıldı ve yönlenen sorgu tamamen kaldırıldı. Hâlâ geçerli başka ürünler varsa 404 yerine mevcut uygulamanın açıkça tanımlanmış FastCGI/proxy işleyicisi gerekir. Exact location eşleşince genel PHP regex location’ı sonradan devralmaz; boş fallback bırakmak PHP kaynağının statik sunulmasına yol açabilir. Büyük listeler için http bağlamında map veya uygulama içi veri tablosu kullanın.

5. HTTP ve HTTPS www Sürümlerini Tek Hedefte Toplamak

Bu üç server bloğu example.com’u kanonik kabul eder: iki HTTP adı ve HTTPS www adı doğrudan HTTPS example.com’a gider. Önceden alınmış sertifikanın SAN alanı hem example.com hem www.example.com’u kapsamalı; fullchain dosyasında sunucu sertifikası ara sertifikalardan önce gelmelidir. Gerçek dosya yollarını ve kök dizini uyarlayın. Son blok yalnızca statik dosyalar içindir; PHP/framework hizmetinde doğrulanmış uygulama işleyicisini kullanın. Örnek doğrudan Nginx’te TLS sonlandırır; proxy arkasına değişmeden aktarılmaz.

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.example.com;
    ssl_certificate /etc/nginx/tls/example/fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/example/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;
    ssl_certificate /etc/nginx/tls/example/fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/example/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    root /var/www/example/public;
    location / {
        try_files $uri $uri/ =404;
    }
}

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

URL değişikliklerini uygulamanın bağlantı üretimi ve yönlendirme mekanizmalarıyla birlikte planlamak gerekir. WordPress, Laravel ve e-ticaret siteleri için üç senaryoyu 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. Staging’de permalink değişikliğini ve tüm eski → yeni eşleşmelerini deneyin. WordPress’in olası otomatik yönlendirmelerine güvenerek harita kontrolünü atlamayın.
2. Yeni hedeflerin doğru içeriği 200 ile verdiğini; canonical, hreflang, sitemap ve iç bağlantıların yeni adresleri kullandığını doğrulayın.
3. Gereken eklenti veya sunucu kurallarını staging’de tamamlayın; birbirinin tersine çalışan kurallar bırakmayın.
4. Doğrulanan permalink, yönlendirme ve bağlantı değişikliklerini birlikte yayımlayın; ardından canlı adresleri ölçü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:

• Route isimlerini değiştiriyorsanız, bu isimlere yapılan uygulama içi referansları da güncelleyin.
• Eski URL’lerden karşılık gelen yeni URL’lere sunucu veya uygulama 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. Karşılık gelen yeni bir URL’ye taşınan sayfalar için 301 yönlendirme yapın; kararı yalnızca indekslenme isteğine bağlamayın.
2. noindex uygulanacak sayfanın taramaya açık olması gerekir. Kullanıcılar için açık kalacak ancak arama sonuçlarında görünmesini istemediğiniz filtre sayfalarında noindex kullanımını değerlendirin. Kalıcı olarak kaldırılan ve eşdeğer bir hedefi olmayan eski URL’ler ise 404 veya 410 döndürmelidir; 410, erişilebilir bir sayfayı yalnızca indeksten çıkarma yöntemi değildir.

Bu kararlar SEO stratejisinin yanı sıra içeriğin varlığına, yeni hedefle eşdeğerliğine ve kullanıcı ihtiyacına bağlıdır. Her eski URL’yi ilgisiz bir hedefe yönlendirmeyin. 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şin hemen ardından ve yeniden tarama sürerken Apache/Nginx loglarını izleyin; takvimi sitenin boyutuna ve trafiğine göre sürdürün.

• Önemli eski adresler doğru hedefe tek kalıcı adımda gidiyor mu; hedef gerçekten 200 ve ilgili içerik mi?
• Bilinmeyen veya kaldırılmış adresler uygun 404/410 döndürüyor mu?
• Yönlendirme döngüleri, beklenmeyen host’lar, 5xx yanıtları ve sorgu kaybı var mı?
• HEAD kontrolüne ek olarak GET isteğini test edin. Tarayıcı ve CDN’nin önbelleğe aldığı 301’leri hesaba katın; yapılandırmayı geri almak istemci önbelleğini hemen geri almaz.

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

Eski adreslere işaret eden iç bağlantılar gereksiz bir yönlendirme adımı ekler; birden fazla yönlendirme varsa zincir oluşur. İç bağlantıları doğrudan nihai adreslere geçirmek hem kullanıcı gecikmesini hem gereksiz taramayı azaltır.

• WordPress veritabanında güncelleme gerekiyorsa yedek ve önce dry-run alın; serileştirilmiş veriyi anlayan bir araç kullanın. Her yerde kör SQL REPLACE uygulamayın; GUID ve ilgisiz tabloları değiştirmeyin. WP-CLI search-replace belgesi bu kapsamı açıklar.
• Laravel ve özel uygulamalarda bağlantı üreten route yardımcılarını ve sabit şablon URL’lerini güncelleyin.
• Yeni sayfaların canonical etiketleri kendilerini göstermeli; dil alternatifi hreflang hedefleri ve sitemap’ler de yeni adresleri kullanmalıdır. Adres Değişikliği aracı yalnızca uygun alan adı/alt alan adı geçişi içindir; aynı alan adında yol, www veya HTTP→HTTPS değişimi için gerekmez.

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

Search Console ve analitikte geçiş öncesi verilerle karşılaştırma yapın:

• Sayfa dizine ekleme raporlarını, URL Denetimi sonuçlarını ve örnek eski/yeni adresleri izleyin. Yönlendirilen eski bir URL’nin dizinde olmaması tek başına hata değildir.
• Soft 404 uyarısında ilgisiz hedef, boş içerik ve yanlış durum kodunu inceleyin; bütün uyarıları tek bir nedene bağlamayın.
• Önemli sayfaların tıklama, gösterim ve konum eğilimlerini; dönüşümleri ve logları birlikte değerlendirin.

Google, URL’leri tek tek yeniden ziyaret edip işler. Küçük ve orta sitelerde çoğu adresin işlenmesi birkaç hafta alabilir; büyük sitelerde daha uzun sürebilir. Sabit bir 4–8 hafta toparlanma takvimi veya kayıpsız sonuç yoktur. Hatalı yönlendirme ya da erişim sorunu görürseniz takvim dolmasını beklemeden düzeltin. Google’ın URL taşıma rehberi süre ve yönlendirme ilkelerinin kaynağıdır.

Hosting Ortamına Göre Uygulama Planı

URL geçişi yalnızca yönlendirme dosyasından oluşmaz. Kullanılacak kontrol listesi şu adımları birlikte kapsamalıdır:

• Eski adres, trafik ve içerik envanteri; doğrudan nihai hedef haritası.
• Kanonik adres, sorgu, dil alternatifi ve kaldırılmış içerik kararları.
• Staging’de yapılandırma ve gerçek HTTP testleri; yayımlamadan önce yedek ve geri dönüş planı.
• CDN/önbellek değişiklikleri; alan adı, sunucu veya HTTP/HTTPS kullanımı değişiyorsa gerekli DNS/TLS işleri.
• Yeni ve eski adreslerin log, Search Console ve hedef içerik takibi; önemli eski bağlantılar için kalıcı yönlendirmelerin korunması.

Paylaşımlı hostingde .htaccess yetkisi ve desteklenen modülleri; VPS, dedicated veya colocation ortamında yapılandırmayı kimin yönettiğini doğrulayın. DCHost hizmeti seçerken yönetim kapsamını ve erişim yetkilerini mevcut plan üzerinden netleştirin; belirli bir planda yönlendirme veya uygulama geçişinin otomatik yönetildiğini varsaymayın.

Google yönlendirmeleri mümkün olduğunca uzun süre, genel olarak en az bir yıl korumayı önerir. Eski dış bağlantı ve yer imleri için daha uzun süre gerekebilir. Kural sayısının etkisini ölçün; binlerce regex’in maliyetini her ortam için önemsiz saymayın.

Ö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 sinyalleri ve yeniden tarama üzerindeki etkileri.
• Eski → yeni haritası; Apache ve Nginx’te tam eşleşme, sorgu, klasör ve HTTPS yönlendirmeleri.
• WordPress, Laravel ve e-ticaret entegrasyonu; yayın sonrası içerik ve HTTP kontrolü.

Bir yönlendirme başarılı görünse bile nihai sayfanın içeriği, canonical ve uygulama davranışı ayrıca doğrulanmalıdır.

Son tavsiyeler:

• Önce plan ve gerçek hedefler, sonra yapılandırma.
• Küçük örneklerin yanında bütün URL haritasını otomatik kontrol edin; host, sorgu, slash ve kodlama uç durumlarını ekleyin.
• Yönlendirmeler devredeyken eski adresleri robots.txt ile taramaya kapatmayın; yeni hedefte staging noindex engellerini kaldırın.
• İlgisiz ana sayfa yönlendirmeleri yerine ilgili nihai hedefi veya gerçek 404/410 yanıtını kullanın.

Sağlam bir geçiş planı, daha anlaşılır URL’lere geçerken kırık bağlantı ve yanlış indeksleme riskini azaltır. Başarıyı URL’nin kısalığıyla değil, doğru içeriğe erişim, tutarlı sinyaller ve ölçülen kullanıcı davranışıyla değerlendirin.