WordPress'ten Astro'ya Geçiş: Adım Adım Rehber (2026)

WordPress’ten Astro’ya geçmeye karar verdiniz — muhtemelen WordPress yerine ne kullanmalı sorusunu zaten cevapladınız. Bu yazı o kararın devamı: “neden” değil, “nasıl” sorusuna cevap veriyor. Adım adım, gerçek bir migration planı.

Bu rehberi masabaşı teorisinden yazmıyoruz. abdullahustun.com’un kendisi WordPress’ten Astro 5’e taşınmış canlı bir site — süreçteki her tuzağı kendi geçişimizde ve müşteri projelerinde birebir yaşadık.

Hızlı özet: WordPress’ten Astro’ya geçiş 6 aşamada yapılır: geçiş öncesi audit (URL envanteri + içerik export), içeriğin Markdown’a dönüştürülmesi, tasarımın yeniden inşası, 301 redirect haritası, form/analytics/schema kurulumu ve staging testi sonrası DNS cutover. Orta boy bir site için tipik süre 2-4 hafta; SEO’yu koruyan en kritik adım eksiksiz redirect haritasıdır.

Aşama 1: Geçiş Öncesi Audit — Neyiniz Var, Nereye Gidiyor?

Geçişin başarısı, kod yazmadan önce yapılan envanterle belirlenir. İki liste çıkarmadan tek satır Astro yazmayın: URL envanteri ve içerik envanteri.

URL envanteri nasıl çıkarılır?

Amaç: canlıda trafik alan veya indekslenmiş her URL’in tam listesi. Dört kaynağı birleştirin:

1. XML sitemap — /sitemap.xml veya Yoast/RankMath sitemap index’i. Temel liste bu.
2. Google Search Console — Performans raporundan son 12 ayın tüm sayfalarını export edin. Sitemap’te olmayan ama trafik alan URL’ler burada yakalanır (eski kategori sayfaları, ?p=123 kalıntıları).
3. Screaming Frog / benzeri crawl — iç link yapısını ve yetim sayfaları görürsünüz.
4. Sunucu erişim günlüğü (varsa) — 404’e düşen ama hâlâ istek alan eski URL’ler.

Bu birleşik liste, ileride redirect haritasının sol kolonu olacak. 90+ projede gördüğümüz en yaygın hata şu: sadece sitemap’e güvenmek. WordPress yıllar içinde tag arşivleri, attachment sayfaları, tarih arşivleri gibi onlarca “hayalet” URL üretir — bunlar indekste durur ve geçişte unutulursa 404 yağmuru başlar.

İçerik envanteri ve ayıklama

Her içeriği üç kovaya ayırın: taşınacak, birleştirilecek, emekliye ayrılacak. Trafiği sıfır, güncelliği geçmiş içerikleri taşımak zorunda değilsiniz — ama URL’lerini yönlendirmek zorundasınız. Emekli edilen yazı, en yakın ilgili sayfaya 301’lenir; asla 404’e bırakılmaz.

Bu aşamada meta verileri de dışa aktarın: her sayfanın title, meta description, canonical ve varsa schema markup’ı. Bunlar Astro tarafında birebir korunacak.

Aşama 2: İçerik Taşıma — WP Export’tan Markdown’a

Astro’da içerik, src/content/ altında frontmatter’lı Markdown/MDX dosyaları olarak yaşar. WordPress veritabanındaki HTML’i bu formata çevirmenin iki pratik yolu var:

Yol 1 — WP REST API (önerilen): https://siteniz.com/wp-json/wp/v2/posts?per_page=100 endpoint’inden tüm yazıları JSON olarak çekin. Küçük bir Node.js script’i ile turndown gibi bir HTML→Markdown dönüştürücüden geçirip her yazıyı frontmatter’lı .md dosyasına yazın. Kategori, etiket, tarih, yazar gibi alanları programatik eşlersiniz. Görselleri de aynı script’te wp-content/uploads’tan indirip Astro’nun src/assets/ klasörüne alırsınız.

Yol 2 — WXR export: WP admin’den Araçlar → Dışa Aktar ile XML alın, wordpress-export-to-markdown gibi hazır araçlarla çevirin. Hızlıdır ama çıktı daha kirlidir.

Hangi yolu seçerseniz seçin, dönüşüm sonrası temizlik turu şart:

• Shortcode kalıntıları ([contact-form-7 ...], [caption]) — Markdown’da anlamsız, elle veya regex’le silinir.
• Page builder çıktıları (Elementor/WPBakery) — bunlar Markdown’a düzgün çevrilemez, o sayfalar zaten Astro’da yeniden yazılır.
• Inline style ve <div> çorbası — temiz semantik HTML’e veya Markdown’a indirgeyin.
• Görsel alt metinleri — WP’den geliyorsa koruyun, boşsa bu fırsatta yazın.

Kendi sitemizi taşırken ölçtük: 40-50 içerikli bir blogda dönüşüm script’i 1 günde biter, ama temizlik turu 2-3 gün alır. Bütçenizi buna göre planlayın.

Aşama 3: Tasarımın Astro’da Yeniden İnşası

Kötü haber: WordPress temanız Astro’ya “aktarılamaz”. PHP template’leri, tema fonksiyonları, eklenti çıktıları — hiçbiri taşınmaz. İyi haber: bu bir yük değil, fırsat. Yıllarca eklenti eklene eklene şişmiş bir temayı kopyalamak yerine, sadece gerçekten kullandığınız bileşenleri sıfırdan, temiz kurarsınız.

Pratik sıra şöyle işler:

1. Layout iskeleti — header, footer, ana layout (BaseLayout.astro). Meta tag’ler, canonical ve Open Graph buraya merkezi girer.
2. Content collection şeması — blog/hizmet içerikleri için Zod ile frontmatter şeması. WordPress’in “her alana her şey yazılır” esnekliğinin aksine, Astro’da şema baştan disiplin getirir.
3. Sayfa şablonları — ana sayfa, hizmet detay, blog listesi, blog detay. Her WordPress template’inin Astro karşılığı.
4. Bileşenler — CTA blokları, kartlar, SSS akordiyonu. React/Vue/Svelte adası sadece gerçekten etkileşim gereken yerde; gerisi sıfır JavaScript.

Bu “sıfır JS varsayılanı” tam olarak hız farkının kaynağı. WordPress’te 1-2 MB JavaScript yükleyen bir sayfa, Astro’da çoğu zaman 0-50 KB ile çıkar; LCP 3 saniyelerden 1.5 saniyenin altına iner. Framework seçiminin SEO tarafını merak ediyorsanız Astro vs Next.js SEO karşılaştırmasına bakın.

Bir uyarı: tasarımı “birebir kopyalamak” ile “aynı hissi korumak” farklı işler. Piksel piksel kopya hem daha uzun sürer hem eski sitenin kusurlarını taşır. Markanın kimliğini koruyup düzeni modernleştirmek genelde daha iyi sonuç verir.

Aşama 4: 301 Redirect Haritası — SEO Equity’nin Sigortası

Bu bölüm rehberin en kritik kısmı. Google’ın yıllardır biriktirdiğiniz otoriteyi yeni URL’lere aktarmasının tek güvenilir yolu 301 (kalıcı) yönlendirme. Redirect haritası eksik kalırsa, sıralamalarınız haftalar içinde erir — ve geri kazanmak taşımaktan çok daha pahalıdır.

Harita nasıl kurulur?

Aşama 1’deki URL envanteri sol kolon, yeni Astro URL’leri sağ kolon. Üç senaryo çıkar:

Altın kural: mümkün olan her yerde URL yapısını koruyun. Slug’ları değiştirmek zorunda değilseniz değiştirmeyin; sıfır redirect, en risksiz redirect’tir. WordPress’in tarihli permalink yapısını (/2023/05/...) kullanıyorsanız işte o zaman toplu dönüşüm gerekir — bunu tek tek değil, kalıp bazlı kuralla çözün.

Redirect’ler nerede tanımlanır?

Barındırmaya göre değişir: Cloudflare Pages’te _redirects dosyası, Vercel’de vercel.json, Netlify’da yine _redirects, kendi Nginx sunucunuzda map bloğu. Hepsinde dikkat edilecekler aynı:

• 302 değil 301 kullanın — 302 “geçici” der, otorite aktarmaz.
• Zincir yönlendirme yapmayın — A→B→C yerine doğrudan A→C. Eski sitede zaten redirect varsa bunları da haritaya katıp tek adıma indirin.
• Sondaki eğik çizgi tutarlılığı — /sayfa ve /sayfa/ ikisi de tek canonical hedefe gitmeli.
• Lansman sonrası ilk hafta 404 raporunu günlük izleyin; kaçan URL’leri anında haritaya ekleyin.

Kendi geçişimizde bu disiplinin karşılığını gördük: eksiksiz redirect haritasıyla taşınan sitelerde Google birkaç hafta içinde yeni URL’leri devralıyor ve trafik grafiği kesintisiz devam ediyor.

Aşama 5: Form, Analytics ve Schema Kurulumu

WordPress’te eklentilerin görünmez şekilde hallettiği üç iş, Astro’da bilinçli kurulum ister.

Formlar: Astro statik çıktı üretir; form verisini işleyecek bir arka uç gerekir. Pratik seçenekler: Cloudflare Pages Functions veya Vercel serverless function (kendi endpoint’iniz), Netlify Forms, Formspree. Spam için honeypot alanı + basit oran sınırı çoğu kurumsal sitede yeterli — reCAPTCHA’yı ancak spam ölçtükten sonra ekleyin. Ad/telefon/e-posta/mesaj tipi sade bir form yarım günde taşınır.

Analytics: GA4 ölçüm kimliğini (G-XXXX) yeni siteye taşıyın; property’yi değiştirmeyin ki tarihsel veri kesilmesin. Google Tag Manager kullanıyorsanız container aynen gelir. Search Console’da site zaten doğrulanmışsa yeni bir işlem gerekmez — ama lansman sonrası yeni sitemap’i göndermeyi unutmayın.

Schema (JSON-LD): WordPress’te Yoast’ın ürettiği schema’yı Astro’da kendiniz yazarsınız — ve bu bir avantajdır, çünkü kontrol tamamen sizde olur. Merkezi bir schema bileşeni kurun: Organization + WebSite site geneline, Article/BlogPosting blog detayına, Service hizmet sayfalarına, FAQPage soru-cevap bloklarına, BreadcrumbList her sayfaya. Frontmatter’dan beslenen tek bir bileşen, 200 sayfada tutarlı schema demektir. Detaylı doğrulama adımları için teknik SEO checklist’imize bakabilirsiniz.

Ek olarak robots.txt ve llms.txt dosyalarını yeni sitede sıfırdan kurun; WordPress eklentilerinin ürettiği eski kuralları körlemesine kopyalamayın.

Aşama 6: Staging’de Test ve DNS Cutover

Yeni site bitince canlıya “atlamazsınız” — önce staging’de kanıtlarsınız. Cloudflare Pages/Vercel preview URL’i veya staging.siteniz.com alt alan adı kullanın (staging’i noindex yapmayı unutmayın).

Staging’de koşulacak kontrol listesi:

• Redirect testi: Envanterdeki her eski URL’e istek atıp 301 + doğru hedef döndüğünü script ile doğrulayın. Elle örneklem yetmez; listenin tamamı taransın.
• İçerik karşılaştırma: Rastgele 20-30 sayfada eski/yeni title, description, H1 ve gövde eşleşmesi.
• Lighthouse: Mobilde 95+ hedefleyin; LCP <1.5s, INP <200ms, CLS <0.1.
• Form testi: Her formu uçtan uca gönderin, bildirim e-postasının düştüğünü görün.
• Schema doğrulama: Rich Results Test + Schema.org validator, sayfa tipi başına en az bir örnek.
• 404 sayfası, sitemap.xml, robots.txt — üçü de yeni sitede çalışır durumda mı?

Her şey yeşilse cutover günü gelir. Sıralama şu:

1. Cutover’dan 24-48 saat önce DNS TTL’i 300 saniyeye düşürün.
2. Trafiğin düşük olduğu bir saatte DNS kaydını yeni hedefe çevirin.
3. Eski WordPress’i hemen kapatmayın — 1-2 hafta erişilebilir (ama indekslenmez) tutun; hem yedek hem acil dönüş kapısı olur.
4. Search Console’a yeni sitemap’i gönderin.

Tipik Süre ve Aşama Tablosu

Peki bütün bunlar ne kadar sürer? Site hacmine göre gerçekçi aralıklar:

Binlerce içerikli yayın siteleri ayrı bir lig: 4-8 hafta ve genelde kademeli geçiş (önce kurumsal sayfalar, sonra arşiv) mantıklıdır.

Lansman Sonrası: İlk 30 Günün Kontrol Listesi

Cutover bitiş değil, izleme döneminin başlangıcı. İlk ay şunları takip edin:

• İlk hafta her gün: Search Console 404/kapsam raporu — kaçan URL varsa anında 301 ekleyin.
• GA4 trafik karşılaştırması: Geçiş öncesi 4 hafta ile sonrası 4 haftayı kanal bazında kıyaslayın. Organikte %10’a kadar dalgalanma normaldir; kalıcı düşüş redirect kaçağı sinyalidir.
• Sıralama takibi: Ana 10-20 anahtar kelimenizi haftalık izleyin. Google’ın yeni URL’leri devralması 2-6 hafta sürer.
• Core Web Vitals: GSC’nin CWV raporu 28 günlük gerçek kullanıcı verisiyle güncellenir; yeşile dönmesini bekleyin.
• Eski sunucu: 30 gün sorunsuz geçtiyse WordPress barındırmasını iptal edin — ama önce veritabanı + uploads yedeğini alıp iki ayrı yerde saklayın.

Bu noktada aylık WordPress bakım maliyeti (güncelleme, güvenlik yaması, eklenti lisansları) da kalemden düşer; Astro sitede saldırı yüzeyi neredeyse sıfırdır çünkü çalışan bir PHP/veritabanı katmanı yoktur.

Geçişi Kendiniz mi Yapmalısınız?

Teknik ekibiniz varsa bu rehber size yol haritası olarak yeter. Yoksa, en riskli iki aşamayı — redirect haritası ve cutover — mutlaka deneyimli birine yaptırın; geri kalanı toleranslıdır ama SEO equity kaybı telafisi en pahalı hatadır.

Biz bu süreci hem kendi sitemizde hem müşteri projelerinde uçtan uca yürütüyoruz. Kapsamı ve süreci konuşmak isterseniz WordPress migration hizmet sayfamıza göz atın, ya da iletişim sayfasından ücretsiz 30 dakikalık görüşme planlayın — mevcut sitenizin URL envanterine bakıp gerçekçi bir süre ve risk değerlendirmesi çıkaralım.