# websitedevelopment.biz — tam metin

> Bu dildeki her rehberin tam metni; bir cevap motoru katalogu tek istekte okuyabilsin diye. Burada görünür sayfalarda olmayan hiçbir şey yok.

## Website’nizi Ne Zaman Yenilemelisiniz (ve Ne Zaman Yenilememelisiniz)
https://websitedevelopment.biz/tr/guides/website-ne-zaman-yenilenmeli
Güncelleme 2026-08-07 · Bakım

Yenilemeler sıklıkla yanlış sebeple başlatılır — siteyi her gün gören insanlara eski göründüğü için — ve gerçek risk taşır: tam bir yeniden yapım birikmiş arama sinyallerini sıfırlar, dönüşüm bilgisini çöpe atar ve çoğu zaman bilinen bir sorunu bilinmeyen bir sorunla değiştirir.

Bu rehber bir yenilemeyi gerçekten neyin haklı çıkardığını, neyin çıkarmadığını ve çoğu sitede daha iyi sonuç veren kademeli yolu ele alıyor.

### Yenilemeyi haklı çıkaran sebepler
Bunlar sayfaları değiştirerek çözülemeyen yapısal sorunlardır; onları iyileştirme sebebi değil yenileme sebebi yapan da budur.
- Platformun ömrü doldu ya da artık güvenlik güncellemesi almıyor.
- Site responsive değil ve yeniden yapmadan öyle yapılamıyor.
- Yapı artık işi karşılamıyor — bilgi mimarisinin ifade edemediği bir şey satıyorsunuz.
- Düzenleme geliştiricisiz imkânsız, dolayısıyla içerik varsayılan olarak bayat.
- Performans birkaç büyük görsel yüzünden değil kuruluş biçimi yüzünden yapısal olarak zayıf.
- Erişilebilirlik arızaları bileşenlerin kendisinde ve yamanamıyor.
- Bir birleşme ya da marka değişikliği yalnız renkleri değil adı da değiştiriyor.
Listede olmayana dikkat edin: "eski görünüyor". Bu genelde bir yeniden biçimlendirme projesidir ve yeniden biçimlendirme maliyetin küçük bir kısmıdır, riskin neredeyse hiçbirini taşımaz.

### Haklı çıkarmayan sebepler
Bunların her birinin, asıl soruna yönelen daha ucuz ve daha düşük riskli bir çözümü var.
| "Eski görünüyor" | Görsel stil | Yeniden biçimlendirme: tipografi, renk, boşluk |
| "Trafik düşüyor" | İçerik ya da teknik sorun | Önce teşhis — yenileme genelde daha kötü yapar |
| "Dönüşüm düşük" | Belirli sayfalar ya da bir form | O sayfalarda değişiklikleri test edin |
| "Rakip yeniledi" | Ölçülebilir hiçbir şey | Bir sebep değil |
| "Yeni pazarlama direktörü" | Sahiplik, website değil | Önce veriyi birlikte inceleyin |
| "Üç yaşında" | Yaş bir kusur değil | Ölçülebilir biçimde yanlış olanı düzeltin |

### Tam yenilemeler neden sık sık trafik kaybettirir
Tam bir yenileme yapıyı, içeriği, URL’leri ve şablonları aynı anda değiştirir. Performans düşerse hangi değişikliğin sebep olduğunu söyleyemezsiniz — yükselirse de söyleyemezsiniz.
- URL değişiklikleri, her yönlendirme doğru eşlenmedikçe birikmiş sinyalleri kaybettirir.
- "Daha derli toplu olsun" diye yeniden yazılan içerik, sık sık tam da sıralanan metni siliyor.
- Yeni şablonlar eskilerin taşıdığı iç bağlantıları, yapısal veriyi ya da meta veriyi düşürebilir.
- Tasarım değişiklikleri dönüşümü ancak haftalar sonra görünen biçimlerde azaltabilir.
- Her şey aynı anda değiştiği için sonradan atıfta bulunmak tahmin işidir.
Yenileme gerçekten gerekliyse URL yapısını ve sıralanan içeriği mümkün olduğunca koruyun. Görünümü ve kodu değiştirin, adresleri değil.

### Kademeli alternatif
Çoğu site için hedefli değişiklikler dizisi bir yeniden yapımdan iyi sonuç verir — daha ucuzdur, ölçülebilir ve her adım geri alınabilir.
- Önce ölçün: analitik, Core Web Vitals, Search Console ve birkaç kullanıcı oturumu.
- Mevcut şablonlarda performansı ve erişilebilirliği düzeltin. Bunlar genelde kendini amorti eder.
- Trafik alıp dönüşmeyen sayfaları birer birer yeniden yazın.
- Yeniden biçimlendirin: tipografi, renk, boşluk. Bu, maliyetin küçük bir kısmıyla "eski görünüyor"u çözer.
- Şablonları URL’lerini koruyarak birer birer değiştirin.
- İçeriğin bayatlamayı bırakması için düzenleme deneyimini iyileştirin.
- Her adımdan sonra yeniden ölçün ki hangi değişikliğin neyi yaptığını bilesiniz.

Q: Bir website ne sıklıkla yenilenmeli?
A: Doğru bir aralık yok. Bakımı yapılan ve kademeli iyileştirilen bir site yıllarca yeniden yapılmadan çalışabilir. Tetikleyici, takvimdeki bir tarih değil mevcut yapı içinde çözemediğiniz yapısal bir sorun olmalı. Politika gereği her üç yılda bir yenilenen siteler genelde her seferinde zemin kaybediyor.

Q: Yenileme SEO’mu iyileştirir mi?
A: Kendi başına hayır ve rahatlıkla zarar verebilir. Yardım eden şey, bir yenilemenin bazen içerdiği unsurlardır: daha hızlı sayfalar, daha iyi yapı, daha iyi içerik. Bunlar yenileme olmadan, daha az riskle de yapılabilir. Hedef arama performansıysa yeniden yapıma karar vermeden önce asıl sebebi teşhis edin.

Q: Yenilemede URL’lerimi korumalı mıyım?
A: Mümkün olan her yerde. URL’leri korumak bir yeniden yayında en büyük tek riski ortadan kaldırır. Değişmek zorundalarsa — gerçekten bozuk bir yapı ya da alan adı değişikliği — her eski URL’yi belirli bir yenisine 301 ile eşleyin ve o yönlendirmeleri süresiz tutun.

Q: Yenileme ne kadar sürer?
A: Yeni bir yapıma benzer ve veri taşıma yüzünden çoğu zaman daha uzun: orta ölçekli bir site için iki ile beş ay. İçerik taşıma, URL eşleme ve mevcut davranışı tutturma sayıldığında sıfırdan başlamaktan nadiren ucuzdur; bu, zaten bir sitesi olduğu için indirim bekleyen çoğu kişiyi şaşırtıyor.

## Website İzleme: Müşterilerinizden Önce Öğrenmek
https://websitedevelopment.biz/tr/guides/website-izleme
Güncelleme 2026-08-07 · Bakım

Erişilebilirlik izleme tek bir soruyu cevaplar: ana sayfa yanıt veriyor mu? Gerçek arızaların çoğu bundan daha sessizdir. Site ayaktadır ve iletişim formu üç haftadır çalışmıyordur ya da ödeme, tek bir ödeme yöntemini kullananlar dışında herkes için çalışıyordur.

Bu rehber neyi izleyeceğinizi, anlamlı eşiklerin nasıl kurulacağını ve uyarıların güvenilir kalmasını ele alıyor.

### "Ayakta mı" sorusunun ötesi
Para kaybettiren arızalar genelde kısmidir. Yalnız sunucunun yanıt vermesini değil, önemsediğiniz sonuçları izleyin.
| HTTP erişilebilirliği | Sunucu çöktü, DNS arızası | 1–5 dakikada bir |
| İşlem kontrolü | Bozuk form, bozuk ödeme akışı | 15–60 dakikada bir |
| Hata oranı | Bir dağıtımdan sonra artan istisnalar | Sürekli |
| Sertifika süresi | Klasik pazar sabahı kesintisi | Günlük, 30 gün önce uyarı |
| Alan adı süresi | Mümkün en kötü kesinti | Günlük, 60 gün önce uyarı |
| Core Web Vitals | Kimsenin fark etmediği yavaş bozulma | Haftalık |
| Search Console kapsamı | İndeksten düşen sayfalar | Haftalık |
| Disk ve veritabanı boyutu | Sert bir sınıra doğru sessiz büyüme | Günlük |
| Yedek başarısı | Aylar önce durmuş yedekler | Günlük |
Bir test adresine gerçek bir form gönderen sentetik bir işlem, çoğu işletme sitesi için en yüksek değerli tek izlemedir. Bozuk formlar görünmez ve pahalıdır.

### Anlamlı eşikler kurmak
Her dalgalanmada uyaran bir izleme insanlara onu yok saymayı öğretir; sonra gerçekten gerektiğinde çalışmaz. Eşikler sizi gerçekten harekete geçirecek şeyi yansıtmalı.
- Uyarmadan önce birden çok konumdan iki üç ardışık arıza isteyin.
- Tek tek hatalar yerine hata oranı üzerinden uyarın — tek bir 500 gürültü, oran değişimi sinyaldir.
- Performans uyarılarını tek bir yavaş ölçüme değil günler süren bir eğilime kurun.
- Önem derecelerini ayırın: site çöktü telefona, yavaş sayfa haftalık özete gider.
- Uyarıları kimsenin sahiplenmediği ortak bir kutuya değil bir kişiye yönlendirin.
- Tetiklenen her uyarıyı gözden geçirin: eylem gerektirmediyse ya eşiği değiştirin ya izlemeyi silin.

### Bir uyarı tetiklendiğinde ne yapmalı
Yazılı bir işlem sırası, bir olayı doğaçlamadan bir prosedüre çevirir; bu da en çok nöbetteki kişi siteyi kuran kişi olmadığında önem taşır.
- Gerçek olduğunu doğrulayın: siteyi farklı bir ağdan kendiniz açın.
- Önce bariz olanlara bakın — bir dağıtım oldu mu, bir sertifika doldu mu, hosting bir olay bildiriyor mu?
- Müşteriler etkileniyorsa bir durum güncellemesi yayımlayın. Sessizlik kötü haberden kötüdür.
- Teşhisten önce hizmeti geri getirin. Dağıtımı geri alın, sonra rahatça inceleyin.
- Ne olduğunu, neden olduğunu ve neyin daha erken yakalayabileceğini yazın.
- Onu yakalayacak izlemeyi ekleyin. Yukarıdaki liste böyle doğru biçimde büyür.
Bir olayın en faydalı çıktısı, bir yeni izleme ve sessizce tekrarlanma yolunun bir eksilmesidir.

### Küçük bir site için makul varsayılanlar
Bir gözlemlenebilirlik platformuna ihtiyacınız yok. Çoğu işletme sitesi için bu küme yeterli ve kurulumu bir öğleden sonra sürer.
- Ana sayfa ve bir derin sayfada, iki konumdan, beş dakikada bir erişilebilirlik kontrolü.
- Günlük olarak bir insanın okuduğu adrese sentetik bir form gönderimi.
- Sertifika ve alan adı süre uyarıları, epey önceden.
- Uygulamadan gelen, oran eşikli sunucu hatası uyarıları.
- Core Web Vitals ve Search Console kapsamını içeren haftalık bir e-posta.
- Yedeğin çalıştığına ve boyutunun normal göründüğüne dair günlük bir onay.

Q: Erişilebilirliği ne sıklıkla kontrol etmeliyim?
A: Bir ile beş dakikada bir standarttır; en az iki coğrafi konumdan olsun ki bir izleme düğümündeki ağ sorunu sizi gece üçte uyandırmasın. Daha sık kontrol sonucu nadiren değiştirir, çünkü fark etme süresi düzeltme süresinin yanında küçüktür.

Q: Ne kadar erişilebilirlik beklemeliyim?
A: İyi bir paylaşımlı hosting yaklaşık %99,9 verir; bu yılda kabaca dokuz saat kesinti demek. Yönetilen platformlar ve iyi bulut kurulumları %99,95 ve üstüne çıkar. Rakamdan daha önemlisi, kesintinin dağınık dakikalar mı yoksa mesai saatlerinde tek uzun bir kesinti mi olduğudur.

Q: Ücretsiz izleme araçları yeterli mi?
A: Küçük bir sitede erişilebilirlik için genelde evet — ücretsiz katmanlar beş dakikalık aralıklarla bir avuç kontrolü karşılıyor. Ücretsiz katmanlarda genelde olmayan şey sentetik işlemler ve çok adımlı kontrollerdir; değerli izlemenin tam olarak orada olması ironiktir. Özellikle bunlar için küçük bir bütçe ayırın.

Q: Uyarı yorgunluğundan nasıl kaçınırım?
A: Hiç eylem gerektirmemiş izlemeleri silin, uyarmadan önce birden çok ardışık arıza isteyin ve acil ile bilgilendirici yönlendirmeyi ayırın. Sonra tetiklenen uyarıları ayda bir gözden geçirin. İnsanların sessize aldığı bir uyarı kanalı, hiç uyarı olmamasından kötüdür, çünkü birinin izlediği inancını üretir.

## Website Yedekleme Stratejisi: Neyi, Ne Sıklıkla
https://websitedevelopment.biz/tr/guides/website-yedekleme-stratejisi
Güncelleme 2026-08-07 · Bakım

Çoğu sitenin yedeği vardır. Daha azının geri yüklenmiş yedeği vardır. İkisi arasındaki fark en kötü anda keşfedilir; genelde yedeğin veritabanını ya da yüklemeleri ya da son üç haftayı içermediğinin keşfiyle birlikte.

Bu rehber neyi yedekleyeceğinizi, ne sıklıkla, nerede saklayacağınızı ve bir geri yüklemenin gerçekten çalıştığını nasıl doğrulayacağınızı ele alıyor.

### Eksiksiz bir yedek neleri içerir
Bir site tek bir şey değildir. Bunlardan herhangi birinin eksikliği geri yüklemeyi kısmi yapar ve kısmi bir geri yükleme çoğu zaman hiç olmamasından kötüdür, çünkü işe yaramış gibi görünür.
- Veritabanı — içerik, kullanıcılar, siparişler, ayarlar. Sürekli değişen parça.
- Yüklenen dosyalar — görseller, belgeler, kullanıcıların ya da editörlerin eklediği her şey.
- Uygulama kodu — tercihen sürüm kontrolünde; bu, geçmişi olan bir yedekleme biçimidir.
- Yapılandırma — ortam değişkenleri, sunucu ayarları, zamanlanmış görevler, yönlendirme kuralları.
- Sertifikalar ve DNS kayıtları — dışa aktarması ucuz, baskı altında yeniden kurması acı.
- Üçüncü taraf ayarları — ödeme webhook adresleri, e-posta yapılandırması, API anahtarları.
En sık atlanan parça yapılandırmadır. Farklı yapılandırılmış bir sunucuda geri yüklenmiş bir veritabanı ve dosya kümesi aynı site değildir.

### Ne sıklıkla ve ne kadar saklamalı
Sıklık tek bir sorudan çıkar: ne kadar işi kaybetmeyi göze alabilirsiniz? Saklama süresi başka bir sorudan: bir sorunu fark etmeniz ne kadar sürer?
| Durağan tanıtım sitesi | Haftalık | Haftalık | 30 gün |
| Bloglu işletme sitesi | Günlük | Günlük | 30–60 gün |
| Yoğun içerik sitesi | Günlük ya da saatlik | Günlük | 60–90 gün |
| Online mağaza | Saatlik ya da sürekli | Günlük | 90+ gün, artı aylık arşivler |
| Web uygulaması | Zaman noktalı kurtarmayla sürekli | Günlük | Veri politikanıza göre |
Saklama önemlidir çünkü yavaş ilerleyen sorunlar var. Bozuk bir içe aktarma ya da sessiz bir ele geçirilme haftalarca fark edilmeyebilir; o noktada 7 günlük bir döngüde yalnız bozuk kopyalar vardır.

### Nerede saklamalı
Klasik kural hâlâ geçerli: üç kopya, iki tür ortamda, biri dışarıda. Websiteler için uyarlaması şu: yedek hem sunucunun çökmesinden hem ele geçirilmesinden sağ çıkmalı.
- Tek kopyayı asla sitenin bulunduğu sunucuda tutmayın.
- En az bir kopya için farklı bir sağlayıcı kullanın ki sağlayıcı düzeyinde bir arıza ikisini birden götürmesin.
- En az bir kopyayı değiştirilemez ya da yalnız-yazılır yapın ki siteyi çalıştıran kimlik bilgileri onu silemesin.
- Yedekleri şifreleyin — kişisel veri dahil her şeyi içeriyorlar.
- Yavaş keşfedilen sorunlar için döngünün dışında aylık bir arşiv tutun.
- Nerede olduklarını ve nasıl geri yükleneceğini yalnız sitede olmayan bir yerde belgeleyin.

### Test: yedeği gerçek yapan adım
Hiç geri yüklemediğiniz bir yedek bir varsayımdır. Test bir saat sürer ve onu bir olguya çevirir.
- Canlı sitenin üzerine değil ayrı bir staging ortamına geri yükleyin.
- Veritabanının eksiksiz geldiğini kontrol edin — önemli tablolarda satır sayın.
- Yüklenen dosyaların, yenileri dahil, orada olduğunu kontrol edin.
- Giriş yapıp gerçek bir iş yapın: bir sayfa yayımlayın, bir test siparişi verin.
- Süreyi ölçün. "Bir geri yükleme ne kadar sürer?" önceden cevaplamak isteyeceğiniz bir sorudur.
- Prosedürü yazın ki yalnız onu kuran kişide kalmasın.
- Ayda bir ve hosting kurulumundaki her değişiklikten sonra tekrarlayın.
Geri yükleme süresini ölçün. Dört saat sürdüğünü bilmek bir kesinti sırasında paydaşlara ne söz vereceğinizi değiştirir ve ihtiyaç anında kimsenin elinde olmayan sayı odur.

Q: Hosting sağlayıcımın yedeği yeterli mi?
A: İyi bir temel ve kötü bir tek strateji. Hosting yedeklerinin saklama süresi genelde kısadır, aynı altyapıda saklanır ve bir fatura anlaşmazlığı ya da sağlayıcı arızasında hesapla birlikte kaybolur. Kendi kopyanızı başka bir yerde tutun — maliyeti küçük ve hosting yedeklerinin yardım etmediği senaryoda ihtiyaç duyacağınız kopya odur.

Q: Yedekleri ne kadar saklamalıyım?
A: Yavaş keşfedilen bir sorunu kapsayacak kadar. Otuz gün makul bir asgari, doksan gün bir mağaza için daha güvenli ve bir yıl saklanan aylık bir arşivin maliyeti neredeyse sıfır. Bunu veri koruma yükümlülüklerine karşı dengeleyin — kişisel veri içeren yedekler de saklama kurallarına tabidir.

Q: Kodum sürüm kontrolündeyse yedeğe gerek var mı?
A: Evet. Sürüm kontrolü kodu ve geçmişini kapsar; veritabanını, yüklenen dosyaları ya da sunucu yapılandırmasını içermez. İçeriğin ve müşteri verisinin yaşadığı yer orasıdır ve bir dağıtımı yeniden çalıştırarak yeniden yaratılamayacak parça da odur.

Q: Zaman noktalı kurtarma nedir?
A: Veritabanını son zamanlanmış anlık görüntüye değil herhangi bir ana geri yükleyebilme yeteneği — işlem kaydının sürekli arşivlenmesiyle sağlanır. Bir saatlik siparişi bile kaybetmenin kabul edilemez olduğu durumlarda önemlidir. Bir tanıtım sitesi için gereksiz; gece boyunca sipariş alan bir mağaza için ek kuruluma değer.

## Website Güvenliği: Olayların Çoğunu Önleyen Uygulamalar
https://websitedevelopment.biz/tr/guides/website-guvenligi-uygulamalari
Güncelleme 2026-08-07 · Bakım

Website ele geçirilmelerinin çoğu hedefli değildir. Eski yazılımdaki bilinen bir açığı bulan otomatik tarayıcılar ya da bir yönetici hesabında tekrar kullanılmış bir paroladır. Sıradan saldırılara karşı savunmak gerçek riskin büyük çoğunluğunu kapsar.

Bu rehber olayların çoğunu önleyen uygulamaları kabaca etki sırasıyla ve bir site zaten ele geçirildiyse ne yapılacağını ele alıyor.

### Olayların çoğunu önleyen önlemler
Harcanan emek başına kaldırdıkları risk sırasına göre.
- Yazılımı güncel tutun. Ele geçirilmelerin ezici çoğunluğu yaması mevcut bir açığı sömürüyor. Bu tek madde altındaki her şeyden ağır basıyor.
- Benzersiz güçlü parolalar artı iki adımlı doğrulama: her yönetici hesabı, hosting paneli, alan adı kaydı ve e-posta hesabında.
- En az yetki. Editörlerin yönetici hesabına ihtiyacı yok. İnsanlar ayrıldığında hesapları kaldırın.
- Her yerde HTTPS, bütün alt kaynakların TLS üzerinden erişilebilir olduğundan emin olduktan sonra HSTS ile.
- Sunucudan uzakta test edilmiş yedekler. Ele geçirilen makinedeki bir yedek her şeyle birlikte şifrelenir.
- Yönetim alanını kısıtlayın — mümkünse IP ile ve her durumda giriş denemelerini sınırlayın.
- Kullanmadığınızı kaldırın. Her pasif eklenti, tema ve eski kurulum, karşılığı olmayan saldırı yüzeyidir.
Eski, unutulmuş kurulumlar — /eski’deki bir staging kopyası, bir alt klasördeki test blogu — tam da kimse güncellemediği için yaygın bir giriş noktasıdır.

### Girdi, çıktı ve klasik açıklar
Bunlar geliştirici sorumluluğudur ve "güncellemediniz" olmayan açıkların çoğunu oluşturur.
| SQL enjeksiyonu | Veritabanınızı okur ya da yok eder | Her zaman parametreli sorgu — asla dize birleştirme |
| Siteler arası betik (XSS) | Ziyaretçinin oturumunda saldırgan betiği çalıştırır | Bağlama göre çıktı kaçışı; katı bir Content-Security-Policy |
| Siteler arası istek sahteciliği | Oturum açmış kullanıcı adına işlem yapar | Durum değiştiren her istekte oturuma özel token |
| Dosya yükleme istismarı | Kod yükleyip çalıştırır | Türü içerikten doğrulayın, web kökü dışında saklayın, asla çalıştırmayın |
| Bozuk erişim denetimi | Kullanıcılar kendilerine ait olmayan veriye ulaşır | Yetkiyi arayüzde değil her istekte sunucuda kontrol edin |
| Hassas veri sızıntısı | Anahtarları ve kimlik bilgilerini sızdırır | Ortam değişkenleri, asla depoda değil |
| Sunucu taraflı istek sahteciliği | Sunucunuza iç sistemleri çağırtır | Giden hedefleri beyaz listeye alın |

### Yapılandırma ve başlıklar
Bütün sorun kategorilerini kapatan ucuz önlemler; çoğu dakikalar içinde uygulanır.
- Güvenlik başlıklarını gönderin: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, X-Frame-Options.
- Dizin listelemesini kapatın; /.git, /.env ve yedek dosyalarının HTTP’den erişilemediğinden emin olun.
- Canlıda ayrıntılı hata çıktısını kapatın — yığın izleri keşif bilgisidir.
- Yönetim ve yapılandırma yollarına halka açık internetten erişimi mümkün olduğunca engelleyin.
- Çerezleri HttpOnly, Secure ve uygun bir SameSite değeriyle kurun.
- Bağımlılıkları denetlenmiş tutun; derlemenizdeki açıklı bir kütüphane sizin açığınızdır.
- Kimlik doğrulama olaylarını kaydedin ve olağandışı desenlerde uyarı alın.

### Site zaten ele geçirildiyse
Sıra burada önemli. Kimlik bilgilerini değiştirmeden dosyaları temizlemek, saldırganın aynı kapıdan geri gelmesi demektir.
- Siteyi kapatın ya da bakım moduna alın. Ziyaretçilere zararlı yazılım sunmaya devam etmesin.
- Kanıtı koruyun: hiçbir şeyi değiştirmeden önce kayıtları ve dosyaların bir kopyasını alın.
- Her kimlik bilgisini değiştirin — hosting, veritabanı, yönetici kullanıcılar, API anahtarları, e-posta. Hepsinin bilindiğini varsayın.
- Ele geçirilmeden önce alındığını güvenilir biçimde belirleyebiliyorsanız o yedekten geri yükleyin.
- Belirleyemiyorsanız kaynaktan yeniden kurun ve yalnız veriyi içe aktarın, asla kaynağı belirsiz dosyaları.
- Girdikleri açığı yamalayın. Bu adım olmadan bütün süreci tekrarlarsınız.
- Kalıcılık arayın: zamanlanmış görevler, fazladan yönetici kullanıcılar, değiştirilmiş çekirdek dosyalar, enjekte edilmiş içerik.
- Site işaretlendiyse Search Console’dan inceleme isteyin ve enjekte edilmiş spam sayfalarını kontrol edin.
- Kişisel veri açığa çıktıysa etkilenen kullanıcıları bilgilendirin — pek çok yargı alanında yasal bir süre içinde.
Giriş noktasını yamalamadan yedek geri yüklemek, sitelerin iki hafta içinde ikinci kez ele geçirilmesinin en yaygın sebebidir.

Q: Bir güvenlik eklentisi yeterli mi?
A: Birkaç konuda yardımcı olur — giriş sınırlama, dosya değişikliği izleme, temel bir güvenlik duvarı — ve güncellemelerin, güçlü kimlik bilgilerinin ve en az yetkinin yerine geçmez. Güvenlik eklentisi olan ve on sekiz aydır güncellenmemiş bir site güvenli değildir. Önce temelleri düzeltin, sonra araç ekleyin.

Q: Küçük siteler gerçekten saldırıya uğrar mı?
A: Sürekli ve kim olduğunuzdan bağımsız olarak. Otomatik tarayıcılar erişilebilir her sunucuyu bilinen açıklar için deniyor; küçük siteler tam da yamalanma olasılıkları düşük olduğu için çekici. Ele geçirilen küçük siteler spam, oltalama sayfaları ve yönlendirme için kullanılıyor; sitenizin trafik seviyesinin riskle ilgisiz olmasının sebebi budur.

Q: Yedekler nerede saklanmalı?
A: Web sunucusunun yazamayacağı bir yerde, tercihen farklı bir sağlayıcıda ve en az bir kopyası siteyi çalıştıran kimlik bilgileriyle silinemeyecek biçimde. Fidye yazılımları ve yıkıcı saldırılar özellikle ele geçirilen makineden erişilebilen yedekleri hedefliyor ve tam da onlara ihtiyaç duyduğunuz an bu.

Q: En yüksek değerli tek güvenlik önlemi nedir?
A: Güncellemeleri hızla uygulamak. Gösterişsizdir ve gerçek ele geçirmelerin geri kalan her şeyin toplamından fazlasını önler, çünkü gerçekten olan saldırılar bilinen ve yamalanmış açıkların otomatik sömürüsüdür. İkinci sırada yönetici ve hosting hesaplarında iki adımlı doğrulama var.

## Website Bakımı: Gerçekte Neleri Kapsıyor
https://websitedevelopment.biz/tr/guides/website-bakim-rehberi
Güncelleme 2026-08-07 · Bakım

Website bakımı, bir siteyi yayından sonra güvenli, güncel ve çalışır tutan iştir. Yapıldığında görünmez, yapılmadığında son derece görünürdür — genelde bir kesinti, bir ele geçirilme ya da bir aydır sessizce başarısız olan bir form olarak.

Bu rehber bakımın gerçekte neleri içerdiğini, ne tuttuğunu, bir anlaşmanın neleri belirtmesi gerektiğini ve aldığınızı nasıl doğrulayacağınızı ele alıyor.

### İş nedir
Bakım, takvimli rutin iş ile bir şey olduğunda yapılan tepkisel işe ayrılır. Yalnız ikincisini kapsayan bir anlaşma bakım değil destektir.
| Güvenlik yamaları | Yayınlandıkça, günler içinde | Bilinen açıklar otomatik olarak sömürülüyor |
| Platform ve eklenti güncellemeleri | Aylık, staging’de test edilerek | Geride kalmak yükseltmeyi her ay zorlaştırıyor |
| Yedek doğrulaması | Aylık geri yükleme testi | Test edilmemiş yedek yedek değildir |
| Erişilebilirlik izleme | Sürekli | Kesintiyi müşteriden öğrenmemelisiniz |
| Hata kaydı incelemesi | Haftalık | Sessiz arızalar — bozuk formlar, başarısız ödemeler |
| Performans kontrolü | Aylık | İçerik eklendikçe sayfa ağırlığı sessizce artıyor |
| Kırık bağlantı kontrolü | Üç aylık | Dış bağlantılar düzenli bir hızla çürüyor |
| İçerik gözden geçirme | Üç aylık | Bayat fiyat ve ölü telefon numarası hatalardan pahalı |
| Bağımlılık denetimi | Üç aylık | Terk edilmiş kütüphaneler bozulmadan değiştirilmeli |

### Ne tutuyor
İşe yarayan bir planlama rakamı: CMS tabanlı bir site için yılda yapım maliyetinin %10–20’si, mağaza ya da uygulama için daha fazlası. Bunun altında genelde iş değil erişilebilirlik satın alıyorsunuz.
| Küçük tanıtım sitesi | 50 – 200 $ | Güncellemeler, yedekler, erişilebilirlik izleme, küçük düzenlemeler |
| Orta ölçekli işletme sitesi | 200 – 800 $ | Yukarıdakiler artı staging testleri, performans ve hata incelemesi |
| Online mağaza | 500 – 3.000 $ | Yukarıdakiler artı ödeme ve stok izleme, daha hızlı yanıt |
| Web uygulaması | 1.500 $+ | Yukarıdakiler artı sürüm yönetimi ve nöbet |
Raporsuz ucuz bir anlaşmayı hiç anlaşma olmamasından ayırmak zordur. Asıl satın aldığınız şey rapordur.

### Bir anlaşma neleri belirtmeli
Muğlak anlaşmalar tam da en kötü anda anlaşmazlık üretir. Bunlar imzalamadan önce yazılı olmalı.
- Hangi rutin işlerin, hangi sıklıkla yapıldığı.
- Önem derecesine göre yanıt süresi hedefleri: site çöktü, özellik bozuk, kozmetik.
- Kapsam saatleri ve dışında ne olduğu.
- Kaç saat değişikliğin dahil olduğu ve kullanılmayan saatlerin devredip devretmediği.
- Neyin değişiklik, neyin yeni proje sayıldığı — örneklerle.
- Kimin neye erişimi olduğu ve anlaşma bittiğinde bunun nasıl iptal edildiği.
- Aylık ne aldığınız: fatura değil, gerçek bir rapor.
- İhbar süresi ve sonunda verinize ve erişimlerinize ne olacağı.

### Kendiniz yapmak
Küçük bir site için bu gayet makul — yeter ki niyet değil takvim olsun. Adı belli bir sahiple takvime koyun, çünkü "aklımıza geldikçe" yapılan bakım yapılmamış bakımdır.
- Haftalık: sitenin açıldığını kontrol edin, iletişim formunu gönderin, hata kayıtlarına göz atın.
- Aylık: güncellemeleri önce staging’de, sonra canlıda uygulayın. Bir yedeğin geri yüklendiğini doğrulayın.
- Aylık: Search Console’da yeni kapsam hatalarına ve manuel işlemlere bakın.
- Üç aylık: bağlantı denetleyicisi, performans testi ve erişilebilirlik taraması çalıştırın.
- Üç aylık: içeriği fiyat, tarih, personel adı ve ölü bağlantı açısından gözden geçirin.
- Yıllık: alan adı ve sertifika yenilemelerini ve kimin hâlâ erişimi olduğunu denetleyin.
Takvim hatırlatıcılarını bir ekibe değil adı belli bir kişiye kurun. Tekrarlayan bir işin paylaşılmış sorumluluğu güvenilir biçimde hiç kimsenin sorumluluğuna dönüşüyor.

Q: Bakımı atlarsam ne olur?
A: Bir süre görünür bir şey olmaz — atlanmasının sebebi de budur. Sonra üç şeyden biri olur: bilinen bir açık otomatik bir tarayıcı tarafından sömürülür, birkaç ana sürüm geride kaldığınız için güncelleme imkânsız hâle gelir ya da haftalardır bozuk olan bir şeyi kimse fark etmemiştir. Üçü de bakımın tutacağından pahalıya gelir.

Q: Hosting sağlayıcımın bakım paketini kullanabilir miyim?
A: Yönetilen hosting genelde sunucuyu kapsar ve çoğu zaman çekirdek platform güncellemelerini ve yedekleri. Eklentilerinizi, özel kodunuzu, hata kayıtlarınızı ya da içeriğinizi nadiren kapsar. Neyin dahil olduğunu okuyun; olayların çoğu "yönetilen hosting" ile "site bakımı" arasındaki boşlukta yaşanıyor.

Q: Bakımın yapıldığını nasıl bilirim?
A: Aylık bir rapor isteyin: ne güncellendi, ne yamalandı, erişilebilirlik, bulunan ve düzeltilen hatalar ve en son başarılı geri yükleme tarihi. Bir anlaşma hiç rapor üretmiyorsa iyi bakımı hiç bakımdan ayıramazsınız — ve bunu genelde bir olay sırasında öğrenirsiniz.

Q: Güncellemeler otomatik uygulanmalı mı?
A: Çekirdek platformun güvenlik yamaları için genelde evet — gecikme riski bozulma riskini aşar. Eklenti ve ana sürüm güncellemeleri önce staging’de test edilmeli, çünkü düzenleri ve özel kodu bozanlar onlardır. Doğru ayrım, sitenin kesinti saati başına ne kadar değerli olduğuna bağlıdır.

## E-ticaret SEO: Gerçekten Önemli Olan Uygulamalar
https://websitedevelopment.biz/tr/guides/e-ticaret-seo-uygulamalari
Güncelleme 2026-08-07 · E-ticaret

Mağaza SEO’su içerik SEO’sundan önemli bir noktada ayrılır: site URL’leri kendi başına üretir. Filtreler, sıralama, varyantlar ve sayfalama, 500 ürünlük bir katalogu 50.000 indekslenebilir sayfaya çevirebilir ve mağaza SEO sorunlarının çoğu orada başlar.

Bu rehber doğru sayfaların sıralanması ve makine üretimi olanların indeksin dışında kalması için bir mağazanın nasıl yapılandırılacağını ele alıyor.

### Kategoriler en değerli sayfalarınızdır
Ticari arama talebinin çoğu belirli bir ürün için değil bir kategori içindir: insanlar belirli bir modelden çok "su geçirmez yürüyüş botu" arıyor. Dolayısıyla yatırım yapmaya değen sayfalar kategori sayfalarıdır ve genelde en ince olanlar da onlardır.
- Her kategoriye gerçek metin verin — ızgaranın üstünde kısa bir giriş, altında faydalı ayrıntı.
- Kategoriyi deponuzun düzenine göre değil insanların nasıl aradığına göre eşleyin.
- İlgili kategorileri birbirine bağlayın; editoryal bağlantısı olmayan bir ürün ızgarası çıkmaz sokaktır.
- Ürün gamı değişse bile kategori URL’lerini kalıcı tutun. URL, içindeki ürünlerden uzun yaşar.
- Katlamanın üstünde yeterince ürün gösterin ki sayfa sorguyu hemen cevaplasın.
Metni olmayan bir kategori sayfası yalnız ürün başlıklarıyla yarışıyor demektir. Kategori sayfalarının aynı ürünleri inceleyen içerik sitelerine bu kadar sık kaybetmesinin sebebi budur.

### Filtreli gezinme: sorunların ana kaynağı
Filtreler URL’leri kombinatoryal olarak çoğaltır. Açık bırakılırsa tarama bütçesini yer, sinyalleri seyreltir ve indeksi kaldırması yavaş neredeyse-kopyalarla doldurur.
| Temel kategori | İndeks, kendine kanonik |
| Talebi yüksek tek filtre (ör. marka) | Gerçek arama talebi ve yeterli ürün varsa indeks |
| Birden çok filtre birleşimi | noindex, follow |
| Sıralama düzeni | noindex ya da hiç ayrı URL üretmeyin |
| Sayfalama | İndeks, her sayfa kendine kanonik, gerçek taranabilir bağlantılar |
| Boş filtre sonucu | noindex ve 404 döndürmeyi değerlendirin |
| İzleme parametreleri | Temizleyin ya da temiz URL’ye kanonikleştirin |

### Ürün sayfaları: URL’ler, varyantlar ve stok
Ürün sayfası sorunlarının çoğunu buradaki üç karar üretir ve üçü de yayından önce karara bağlanınca daha ucuza gelir.
- Ürün başına tek URL, kategori yolu başına bir tane değil. Üç kategoride bulunan bir ürün üç URL’de var olmamalı.
- Varyantlar: varyant seçimli tek indekslenebilir ürün sayfası — bir varyantın gerçekten ayrı talebi yoksa; renk nadiren, beden asla.
- Stokta yok: sayfayı stok durumu işaretlenmiş ve alternatifler gösterilmiş hâlde yayında tutun. Silmek, gelecek ay dönebilecek bir ürünün birikmiş sıralama sinyallerini çöpe atar.
- Kalıcı olarak üretimden kalktıysa: ana sayfaya değil en yakın muadile ya da kategoriye 301.
- Benzersiz açıklamalar. Üretici metni her rakibin sitesindedir; kopya içeriğin tanımı budur.
- Yapısal veride fiyat ve stok durumu görünen sayfayla birebir aynı olmalı.

### Mağazalara özgü teknik kalemler
Bunlar neredeyse her mağazada karşınıza çıkar ve bir tanıtım sitesinde nadiren.
| Site içi arama sonuçları | noindex — sonsuz ve ince |
| Sepet ve ödeme | noindex ve taramaya kapatın |
| Müşteri hesapları | noindex; sipariş sayfalarının indekslenmesine asla izin vermeyin |
| Birden çok para birimi | Tek kanonik URL; para birimi başına URL üretmeyin |
| Birden çok pazar | Önekli URL’ler artı karşılıklı hreflang |
| Yorumlar | HTML’de çizin; işaretlemeyi yalnız gerçek sayfa yorumları için kullanın |
| Liste performansı | Katalog büyüdükçe izleyin — önce o bozulur |
| Site haritaları | Türe göre bölün ve stok değiştikçe güncel tutun |
Alışveriş reklamları için ürün beslemeleri, indekslenebilir ürün sayfalarının yerine geçmez. Ayrı sistemlerdir ve biri diğerini sıralamaz.

Q: Stokta olmayan ürünler kaldırılmalı mı?
A: Ürün geri gelecekse hayır. Sayfayı tutun, stok durumunu hem görünen sayfada hem yapısal veride doğru işaretleyin ve alternatifler sunun. Silmek, parasını ödediğiniz bağlantıları ve sıralama geçmişini atmaktır. Yalnız ürün gerçekten üretimden kalktığında 301 yapın ve ana sayfaya değil en yakın muadile.

Q: Birden çok kategorideki ürünleri nasıl ele alırım?
A: Her ürüne kategori yolunu içermeyen tek bir kanonik URL verin — /urunler/yuruyus-botu-x gibi, /botlar/yuruyus/yuruyus-botu-x değil. Ona ilgili her kategoriden bağlantı verin. Kategori tabanlı ürün URL’leri kopya üretir ve katalogu yeniden düzenlediğiniz an kırılır.

Q: Her ürün için benzersiz açıklama şart mı?
A: Sıralanmasını istediğiniz ürünler için evet. Üretici metni aynı ürünü satan her rakipte görünür, dolayısıyla sayfanızı ayıran hiçbir şey kalmaz. 4.000 ürünü baştan yazmak gerçekçi değilse, geliri gerçekten getiren ürünlerle başlayın ve gerisini kategori sayfalarına bırakın.

Q: Filtre sayfaları hiç indekslenmeli mi?
A: Bilinçli seçilmiş az sayıda: gerçek arama talebine karşılık gelen ve makul sayıda ürün döndüren tek filtreler, örneğin bir kategori içindeki marka. Onlara kendi başlık ve açıklamalarını verin. Diğer her şey — kombinasyonlar, sıralamalar, fiyat kaydırıcıları — noindex, follow olmalı.

## Ödeme Altyapısı Entegrasyonu: Geliştiricilerin Doğru Yapması Gerekenler
https://websitedevelopment.biz/tr/guides/odeme-altyapisi-entegrasyonu
Güncelleme 2026-08-07 · E-ticaret

Ödeme entegrasyonu bir eğitimde basit görünür ve canlıda affetmez, çünkü her arıza durumu ya ödeyip hiçbir şey alamayan bir müşteri ya da bir şey alıp ödemeyen bir müşteri demektir.

Bu rehber akışın nasıl işlediğini, sorunların çoğunu önleyen tasarım kararını ve yayından önce bilerek test edilmesi gereken durumları ele alıyor.

### Akış gerçekte nasıl işler
Sağlayıcı ne olursa olsun şekil aynıdır: sunucunuz bir tahsilat niyeti oluşturur, müşteri ödeme sağlayıcısında kimlik doğrular ve sağlayıcı size sonucu söyler — iki kez, iki farklı yoldan.
- Sunucunuz tutar, para birimi ve siparişinize bir referansla bir ödeme niyeti oluşturur.
- Müşteri kart bilgilerini barındırılan bir alana ya da sayfaya girer, böylece veri sunucunuza hiç dokunmaz.
- Güçlü kimlik doğrulama gerekebilir; bu, müşterinin tamamlaması gereken bir adım ekler.
- Sağlayıcı müşteriyi bir sonuçla sitenize geri yönlendirir.
- Ayrıca sunucudan sunucuya, yetkili sonucu içeren bir webhook gönderir.
- Sisteminiz siparişi günceller — yönlendirmeden değil webhook’tan.
- Sevkiyat yalnız ödeme doğrulandıktan sonra tetiklenir.
Bütün tasarım 4. ve 5. adımdır. Yönlendirme ne olduğuna dair bir ipucu, webhook ise olgudur.

### Webhook neden tek doğruluk kaynağı olmalı
Müşterinin tarayıcısı güvenilmez bir anlatıcıdır. Yönlendirme sırasında kapanabilir, bağlantısı kopabilir ya da manipüle edilebilir. Sipariş durumunuz müşterinin başarı sayfanıza dönmesine bağlıysa, hiç kaydedilmemiş ödenmiş siparişleriniz olacaktır.
- Sipariş durumunu yalnız doğrulanmış webhook’lardan güncelleyin; yönlendirmeyi yalnız kullanıcıya gösterilen bir mesaj sayın.
- Webhook imzalarını doğrulayın. Siparişleri ödenmiş işaretleyen kimliksiz bir uç nokta tam olarak kulağa geldiği kadar kötüdür.
- Webhook işlemeyi idempotent yapın — sağlayıcılar yeniden dener ve kopyalar gelecektir.
- Hızlı yanıt verip işlemi asenkron yapın; yavaş uç noktalar yeniden denenir ve sonunda devre dışı bırakılır.
- Her webhook yükünü kaydedin. Ödeme itirazları kayıtlarla çözülür.
- Olayları sırasız gelebilecek şekilde ele alın, çünkü öyle gelebilir ve gelecektir.

### Test edilmeye değer arıza durumları
Bunların her biri canlıda oluyor. Yayından önce sağlayıcının test kartlarıyla bilerek test edin.
| Müşteri ödedikten sonra sekmeyi kapatıyor | Webhook siparişi yine tamamlıyor; onay e-postası gidiyor |
| Kart reddedildi | Net mesaj, sepet korunuyor, tekrar denenebiliyor |
| Güçlü kimlik doğrulama başarısız | Sipariş onaylanmıyor; müşteriye ne yapacağı söyleniyor |
| Kopya webhook | Sipariş bir kez güncelleniyor, iki kez değil; ikinci sevkiyat yok |
| Webhook yönlendirmeden önce geliyor | Başarı sayfası zaten tamamlanmış siparişi yansıtıyor |
| Kısmi iade | Sipariş toplamları ve muhasebe aktarımı tutarlı kalıyor |
| Ödeme ile sevkiyat arasında stok bitti | Tanımlı süreç: iade, ön sipariş ya da muadil |
| Para birimi yuvarlama | Tahsil edilen tutar gösterilen toplamla birebir aynı |

### Kapsam, uyum ve para
Birkaç karar, ne kadar mevzuat yükü üstleneceğinizi ve işlemin ne kadarını elde tutacağınızı belirler.
- Kart numaralarını asla saklamayın. Barındırılan alanlar ya da barındırılan bir sayfa kullanın ki kart verisi sunucunuza hiç ulaşmasın; PCI kapsamı böylece asgaride kalır.
- Ücret yapısını anlayın. Yüzde artı sabit ücret, artı para birimi çevrimi, artı ters ibraz ücreti. Manşet yüzdesi maliyet değildir.
- Ödeme zamanlamasını kontrol edin. Hesabınıza geçiş süresi, küçük bir oran farkından çok nakit akışını etkiler.
- İade yolunun kısmi iadeler dahil uçtan uca çalıştığını yayından önce doğrulayın.
- Pazarınızın gerçekten kullandığı yerel yöntemleri destekleyin — kart her yerde varsayılan değildir ve baskın yerel yöntemi atlamak dönüşüm kaybettirir.
- Ödeme kritikse ikinci bir sağlayıcı hazır tutun. Kesintiler oluyor ve geliri tamamen durduruyorlar.

Q: Barındırılan ödeme sayfası mı gömülü form mu?
A: Barındırılan ödeme daha basittir, PCI kapsamını en küçük tutar ve bakımını sağlayıcı yapar — çoğu mağaza için doğru varsayılan budur. Gömülü alanlar müşteriyi sizin alan adınızda tutar ve deneyim üzerinde daha çok kontrol verir; bedeli daha fazla kod ve daha fazla sorumluluktur. İkisi de kart verisini sunucunuzdan uzak tutar ki asıl önemli olan odur.

Q: Webhook uç noktam çökerse ne olur?
A: Sağlayıcılar geri çekilmeli olarak yeniden dener, genelde saatler ya da günler boyunca, dolayısıyla kısa bir kesinti kendiliğinden toparlanır. Uzun bir kesinti, siparişlerin onaysız beklemesi demektir, o yüzden uç noktayı izleyin ve arızalarda uyarı alın. Ayrıca sağlayıcı işlemlerini siparişlerinizle günlük karşılaştıran bir mutabakat işi kurun — yeniden denemelerin kaçırdığı her şeyi o yakalar.

Q: Güçlü müşteri kimlik doğrulamasını ele almam gerekir mi?
A: Bunu gerektiren bölgelerdeki müşterilere satıyorsanız evet ve modern sağlayıcı SDK’ları akışın çoğunu üstlenir. Sizin üstlenmeniz gereken şey sonuçtur: kimlik doğrulaması bekleyen bir sipariş ödenmiş değildir ve onu ödenmiş saymak, karşılığını hiç almadığınız malı göndermek demektir.

Q: Ödemeleri güvenli biçimde nasıl test ederim?
A: Her sağlayıcının belirli sonuçları tetikleyen kartları olan bir test modu vardır — ret, kimlik doğrulama gerekli, dolandırıcılık. Yukarıdaki tablodaki zor durumlar dahil listenin tamamını çalıştırın. Sonra yayından önce canlıda küçük bir gerçek işlem yapıp iade edin, çünkü test modu canlı anahtarlarınızı ve canlı webhook adresinizi denemez.

## WooCommerce, Shopify ve Magento: Uygulamalı Karşılaştırma
https://websitedevelopment.biz/tr/guides/woocommerce-shopify-magento-karsilastirma
Güncelleme 2026-08-07 · E-ticaret

Bu üçü mağaza projelerinin çoğunu kapsıyor ve gerçekten farklı durumlara uyuyorlar. Seçim özelliklerden çok — üçü de ürün satabiliyor — mağazayı kimin bakacağı ve gereksinimler büyüdüğünde ne olacağıyla ilgili.

Bu karşılaştırma özellik listesine göre değil işletme modeline göre yapılıyor, çünkü bir platformun işe yarayıp yaramayacağını belirleyen odur.

### Hangisi kime uyar
Ayrıntıdan önce, açıkça.
| Shopify | Barındırılan SaaS | Altyapıyla değil satışla uğraşmak isteyen ekipler |
| WooCommerce | WordPress eklentisi, kendi sunucunuzda | Mütevazı kataloglu, WordPress becerisi olan içerik odaklı siteler |
| Magento / Adobe Commerce | Kendi sunucunuzda kurumsal | Karmaşık kataloglar, B2B kuralları, iç ya da ajans kapasitesi |

### Pratik farklar
Kararı değiştiren karşılaştırmalar, pazarlama sayfalarında görünenler değil.
| Kurulum eforu | Düşük | Orta | Yüksek |
| Güvenliği kim yamalıyor | Satıcı | Siz | Siz |
| Ödeme özelleştirmesi | Tasarım gereği sınırlı | Tam | Tam |
| Ölçekte katalog | İyi | Çalışmadan bozuluyor | Bunun için kurulmuş |
| B2B fiyat kuralları | Ek uygulama | Eklenti, kalitesi değişken | Yerleşik |
| Çoklu mağaza / pazar | Ek maliyet | Zahmetli | Yerleşik |
| İşletme maliyeti | Abonelik + ücret + uygulamalar | Hosting + eklenti + geliştirici zamanı | Ciddi hosting ve geliştirici zamanı |
| Gereken beceri | Operatör | WordPress geliştiricisi | Uzman geliştirici |

### Her biri nerede kırılır
Her platformun değerlendirme sırasında değil yayından sonra ortaya çıkan bir arıza biçimi var. En sık karşılaşılanlar bunlar.
- Shopify: platformun izin vermediği ödeme kuralları ve sonunda platform ücretini aşan uygulama abonelikleri. Ayrıca kendi ödeme ürününü kullanmıyorsanız işlem ücretleri.
- WooCommerce: katalog büyüdükçe liste sayfası performansı, güncellemelerden sonra eklenti çakışmaları ve yamayı kimsenin sahiplenmediği durumdaki güvenlik açığı.
- Magento: toplam sahip olma maliyeti. Güçlüdür ve gerçek altyapı ile gerçek uzmanlık ister; yeterince kaynak ayrılmamış Magento mağazaları yavaştır ve güncellemelerde geride kalır.
- Üçü de: bilinçli yapılandırılmadıkça binlerce indekslenebilir URL üreten filtreli gezinme.
En yaygın pahalı hata, WooCommerce’in kaldıracağı bir katalog için Magento seçmek ya da Magento gereken bir katalog için WooCommerce seçmektir. İki hata da yaklaşık bir yıl sonra ortaya çıkıyor.

### Çıkış maliyetleri
Taahhüt vermeden önce bilmeye değer, çünkü seçimin geri alınabilir olup olmadığına karar veren parça budur.
| Shopify | CSV dışa aktarma, düz | Şifresiz dışa aktarma | Dışa aktarma, sınırlı geçmiş | Sabit URL önekleri eşlemeyi zahmetli yapıyor |
| WooCommerce | Tam veritabanı erişimi | Tam erişim | Tam erişim | Tamamen sizin kontrolünüzde |
| Magento | Tam veritabanı erişimi | Tam erişim | Tam erişim | Tamamen sizin kontrolünüzde |
Kendi sunucunuzdaki platformlardan ayrılmak daha kolaydır, çünkü veritabanı sizdedir. Bu, açık kaynağın gerçek bir avantajıdır ve seçim anında nadiren tartılır.

Q: Hangisi en ucuz?
A: Küçük bir mağaza için hosting, yama ve geliştirici zamanı sayıldığında toplamda genelde Shopify — abonelik görünür, alternatif maliyetler değildir. Zaten WordPress kullanıyorsanız ve yetkin biri bakıyorsa WooCommerce en ucuzudur. Magento hiçbir senaryoda ucuz seçenek değildir.

Q: WooCommerce büyük kataloglar için iyi mi?
A: Düzgün hosting, önbellekleme ve sorgu çalışmasıyla binlerce ürünü kaldırabilir ama bu çalışmaya ihtiyacı vardır — liste ve filtre sayfalarındaki performans, ürün sayısı etkileyici görünmeden önce bozulur. Katalog ilk günden büyük ve karmaşıksa bu şekle göre kurulmuş platformlarla karşılaştırmaya değer.

Q: B2B için Magento şart mı?
A: Zorunlu değil, ama B2B gereksinimleri — müşteriye özel fiyat, teklifler, satın alma emirleri, hesap hiyerarşileri — orada yerleşiktir, başka yerde ek uygulamadır. Bunlardan birkaçına ihtiyacınız varsa karşılaştırma adildir. Bir tanesine ihtiyacınız varsa, daha basit bir platformdaki bir ek uygulama genelde sahiplenmesi daha ucuzdur.

Q: İçerik ve ticareti aynı platformda çalıştırabilir miyim?
A: WooCommerce bunu doğal olarak yapıyor, çünkü WordPress önce bir içerik sistemidir. Shopify’ın içerik araçları daha zayıftır, o yüzden içerik ağırlıklı Shopify mağazaları genelde ayrı bir CMS ile eşleştirilir. Kazanım stratejiniz içerik odaklıysa bunu ciddiye alın — çoğu özellik karşılaştırmasının ima ettiğinden daha büyük pratik bir farktır.

## E-ticaret Platformları Karşılaştırması: Nasıl Seçilir
https://websitedevelopment.biz/tr/guides/e-ticaret-platformlari-karsilastirma
Güncelleme 2026-08-07 · E-ticaret

Platform karşılaştırmaları hızla eskir, çünkü özellikler her çeyrek değişiyor. Değişmeyen şey hangi platform kategorisinin uyduğuna karar veren soru kümesi ve her kategorinin yaptığı takaslardır.

Bu rehber markaları değil kategorileri karşılaştırıyor ve seçimi hızla daraltan soruları veriyor.

### Dört kategori
Neredeyse her seçenek bunlardan birine düşer ve kategori, içindeki markadan daha çok şeye karar verir.
| Barındırılan SaaS | Yalnız içerik ve operasyon | Çoğu küçük ve orta ölçekli mağaza |
| Kendi sunucunuzda açık kaynak | Her şey: hosting, güncelleme, güvenlik | Sıra dışı gereksinimler, iç kapasite |
| CMS eklentisi (ör. bir mağaza eklentisi) | Bütün yığın, hafifçe | Mütevazı kataloglu içerik odaklı siteler |
| Headless ticaret | Front-end ve entegrasyon katmanı | Çok kanal, özel deneyim, büyük ekipler |

### Seçimi gerçekten daraltan sorular
Herhangi bir özellik listesine bakmadan önce bunları cevaplayın. Çoğu, tekil ürünleri değil bütün kategorileri eler.
- Tek bir ürün ne kadar karmaşık? Varyantlar, yapılandırılabilir seçenekler ve müşteriye özel fiyat en basit araçları eler.
- Kaç pazar? Birden çok vergi rejimi ve para birimi, ucuz platformların pahalıya geldiği yerdir.
- Neyle entegre olmalı? Mevcut bir ERP ya da muhasebe sistemi genelde belirleyici kısıttır.
- Günlük olarak kim yönetecek? Rutin değişiklik için geliştirici gerektiren bir platform iki kişilik bir işletmeye uymaz.
- İki yıl içinde gerçekçi sipariş hacmi ne? İşlem ücretleri aylık ücretlerin ölçeklenmediği biçimde ölçekleniyor.
- Ayrılırsanız ne olur? Bir şey imzalamadan önce ürünleri, müşterileri ve siparişleri nasıl dışa aktardığınızı sorun.
Kimsenin sormadığı ve sonradan en çok canını yakan soru çıkış sorusudur. Dışa aktarma araçları zayıf olan bir platform, ucuza geri dönemeyeceğiniz bir karardır.

### Lisans maliyeti değil toplam maliyet
Barındırılan platformlar abonelik satırında pahalı görünür ve hosting, güvenlik ve bakım sayıldığında çoğu zaman toplamda daha ucuzdur. Kendi sunucunuz bedava görünür ve değildir.
| Abonelik | Aylık, hacme göre kademeli | Yok |
| İşlem ücreti | Genelde ödeme ücretinin üstüne bir yüzde | Yalnız ödeme ücretleri |
| Hosting | Dahil | Sizde ve bir mağaza gerçek kaynak ister |
| Güvenlik ve PCI | Büyük ölçüde üstlenilmiş | Sizde, kapsam dahil |
| Güncellemeler | Otomatik | Sizde ve özelleştirmeleri bozabilir |
| Uygulama ve eklentiler | Uygulama başına aylık, hızla birikiyor | Genelde tek seferlik ya da ücretsiz, artı sizin zamanınız |
| Geliştirici zamanı | Rutin iş için daha düşük | Daha yüksek ve sürekli |

### Her kategori nerede kırılır
Arıza biçimini bilmek özellik listesini bilmekten daha faydalıdır, çünkü onunla demoda değil ikinci yılda karşılaşırsınız.
- Barındırılan SaaS: platformun izin vermediği bir ödeme gereksinimi ya da platform ücretini sessizce aşan uygulama abonelikleri.
- Kendi sunucunuzda: güvenlik güncellemelerini kimse uygulamaz ve mağaza ele geçirilir ya da ciddi biçimde geride kalır.
- CMS eklentisi: katalog büyümesi performansı bozar ve site ticaret ölçeğindeki sorgular için hiç kurulmamıştır.
- Headless: pazarlama ekibinin eskiden kendi yaptığı değişiklikler için front-end ekibi darboğaza dönüşür.
Bunların neredeyse hepsi teknik değil operasyonel arızadır. En yetenekli platformu değil, kurumunuzun gerçekten işletebileceğini seçin.

Q: Açık kaynak barındırılan bir platformdan ucuz mu?
A: Hosting, güvenlik yamaları, geliştirici zamanı ve bir olayın maliyeti sayıldığında nadiren. Aksi hâlde boşta duracak iç kapasiteniz varsa ya da barındırılan platformların reddettiği gereksinimleriniz varsa ucuzdur. Abonelik satırını sıfırla karşılaştırmak, onu bariz gösteren hatadır.

Q: Sonradan platform değiştirebilir miyim?
A: Evet ve bu tam bir projedir — katalog taşıma, URL eşleme ve entegrasyonların yeniden yazımı sayıldığında genelde yeni bir yapımın %30–50’si. Dışa aktarma sorusunun seçim sürecine ait olmasının sebebi budur. Ürünler genelde temiz çıkar; zor olan müşteriler ve sipariş geçmişidir.

Q: Headless ticaret ne olacak?
A: Birkaç kanaldan satış yapıyorsanız ya da platformun üretemeyeceği bir front-end gerekiyorsa gerçekten faydalıdır; aksi hâlde ciddi bir ek karmaşıklıktır: front-end, entegrasyon katmanı ve bunların dağıtımı sizde olur. Normal kataloglu tek kanallı bir mağaza için genelde harcamayacağınız bir esneklik satın alırsınız.

Q: SEO için hangi platform en iyisi?
A: Artık büyük ölçüde denkler — farklar URL’ler, kanonikler ve meta veri üzerinde ne kadar kontrolünüz olduğunda ve front-end performansındadır. Daha önemlisi, uygulamanızın filtreli gezinmeyi, sayfalamayı ve ürün URL kalıcılığını düzgün ele alıp almadığıdır; bu her platformda bir yapım kararıdır.

## E-ticaret Sitesi Geliştirme: Kapsamlı Rehber
https://websitedevelopment.biz/tr/guides/e-ticaret-sitesi-gelistirme-rehberi
Güncelleme 2026-08-07 · E-ticaret

Online mağaza, üzerine para, stok ve hukuki yükümlülük eklenmiş bir website’tir. E-ticaret sitesi geliştirmeyi bir tanıtım sitesinden farklı bir proje yapan da budur: en pahalı parçalar genelde müşterinin gördüğü parçalar değildir.

Bu rehber bir mağaza projesinin gerçekte neleri içerdiğini, maliyeti neyin belirlediğini, yayında başlayan operasyon işini ve geri alması pahalı hataları ele alıyor.

### Vitrinin ötesinde bir mağaza neleri içerir
Katalog ve ödeme görünen kısımdır. Altında işletmenin gerçekten çalışıp çalışamayacağına karar veren sistemler durur ve en küçüğü dışındaki her mağazada bütçenin çoğu oraya gider.
- Katalog yapısı: kategoriler, varyantlar, nitelikler, paketler, stok kuralları.
- Fiyatlandırma: pazara göre KDV dahil ya da hariç, indirimler, müşteri grupları, para birimi.
- Ödemeler: en az bir sağlayıcı, artı iade, kısmi iade ve başarısız ödeme yönetimi.
- Kargo: bölgeler, ağırlıklar, ölçüler, taşıyıcı kuralları, ücretsiz kargo eşikleri.
- Vergi: varış yerine göre KDV, yargı alanınızın istediği alanlarla fatura.
- Stok: müsaitlik, ön sipariş ve ödeme sırasında rezervasyon, böylece fazla satmazsınız.
- Sipariş yönetimi: personelin siparişleri işlediği yer — çoğu zaman tamamen ayrı bir sistem.
- E-postalar: onay, kargo, iade, terk edilmiş sepet ve bunların hukuki içeriği.
- İadeler: politika ve onu uygulayan iş akışı.
Personelin siparişleri gerçekte nerede işleyeceğini erken sorun. Cevap mevcut ERP’nizse entegrasyon projenin ciddi bir parçasıdır ve ilk tahmine girmelidir.

### Maliyeti ne belirler
Ürün sayısı, ürün karmaşıklığından ve mağazanın konuşması gereken sistem sayısından daha az önemlidir.
| Katalog | Basit ürünler, tek fiyat | Varyantlar, yapılandırılabilir seçenekler, müşteriye özel fiyat |
| Pazarlar | Tek ülke, tek para birimi | Birden çok vergi rejimi, para birimi, dil |
| Entegrasyonlar | Ödemenin ötesinde yok | ERP, PIM, WMS, muhasebe, pazar yeri beslemeleri |
| Veri taşıma | Yeni mağaza, geçmiş yok | Mevcut katalog, müşteriler, siparişler ve URL’ler |
| Sevkiyat | Tek depo, sabit kargo | Birden çok konum, taşıyıcı kuralları, dropshipping |
| Mevzuat | Standart tüketici satışı | Yaş sınırı, lisans, düzenlenmiş ürünler |

### Veri taşıma başlı başına bir projedir
Mevcut bir mağazayı platform değiştirmek genelde yenisini kurmaktan zordur ve zorluk tasarımda değil veri ile URL’lerdedir.
- Her şeyden önce katalogu dışa aktarıp temizleyin. Mevcut veri her zaman hatırlandığından kötüdür.
- Neyin taşınmayacağına karar verin. Trafiği olmayan üretimden kalkmış ürünlerin taşınmasına gerek yok.
- Her eski ürün ve kategori URL’sini yenisine eşleyin; 301 yapın ve bu listenin uzun olmasını bekleyin.
- Müşteri hesaplarını şifresiz taşıyın — sistemler arasında hash taşımak yerine sıfırlama zorunlu kılın.
- Sipariş geçmişinin ne kadarının taşınacağına karar verin. Cevap genelde "hiçbiri, eski sistemi bir yıl salt okunur tutun" oluyor.
- Stok izin veriyorsa iki sistemi kısa bir süre paralel çalıştırın ve günlük mutabakat yapın.
- Kategori başına arama trafiğini altı hafta izleyin; düşen bir kategori genelde atlanmış bir yönlendirmedir.
Katalog verisini temizlemeye mağazayı kurmak kadar zaman ayırın. Çoğu taşımada bu daha büyük görevdir ve kimsenin planlamadığıdır.

### Yayında başlayan iş
Mağaza biten bir proje değil, bir işletmenin işletim sistemidir. Bu maliyetler süreklidir ve ilk bütçeden sık sık eksiktir.
| Ürün içeriği | Yeni seriler, yeni fotoğraflar, yeni açıklamalar |
| Stok doğruluğu | Fazla satmak her geliştirme hatasından pahalıya geliyor |
| Ödeme ve platform güncellemeleri | Sağlayıcılar API’lerini kendi takvimlerinde emekliye ayırıyor |
| Güvenlik yamaları | Mağazalar ödeme verisi hedefi; yamalar isteğe bağlı değil |
| Dolandırıcılık ve ters ibraz | Sipariş karması değiştikçe kuralların ayarlanması gerekiyor |
| Vergi kuralı değişiklikleri | Oranlar ve eşikler ülkeye göre, bazen yılda bir değişiyor |
| Performans | Katalog büyüdükçe önce liste sayfaları bozuluyor |

Q: Bir online mağaza kurmak ne kadara mal olur?
A: Hafif bir temayla barındırılan bir platformdaki küçük mağaza 5.000 $ civarında başlayabilir. Özel tasarımlı ve bir iki entegrasyonlu orta ölçekli bir mağaza genelde 20.000–60.000 $ arasıdır. ERP entegrasyonlu ve çok pazarlı büyük kataloglar bunun epey üstüne çıkar. Veri taşıma genelde eşdeğer bir yeni yapıma %30–50 ekler.

Q: Barındırılan platform mu kendi sunucumda mı?
A: Barındırılan platformlar güvenliği, PCI kapsamını ve ölçeklemeyi aylık bir ücret ve çoğu zaman bir işlem yüzdesi karşılığında üstlenir; bedeli özelleştirme sınırlarıdır. Kendi sunucunuz tam kontrol verir ve bakım ile uyum yükü sizde olur. Çoğu küçük ve orta ölçekli mağaza için barındırılan seçenek daha düşük risklidir; kendi sunucu argümanı sıra dışı gereksinimler ve ciroyla birlikte güçlenir.

Q: Ayrı bir sipariş yönetim sistemine ihtiyacım var mı?
A: Günde birkaç düzine siparişin altında platform yönetim paneli genelde yeter. Üstünde ya da birden çok satış kanalında, özel bir sistem kendini hızla amorti eder. Yapımdan önce cevaplanacak soru, yetkili stok sayısının nerede yaşadığıdır; hangi sistemin hangisine söyleyeceğine o karar verir.

Q: En yaygın e-ticaret yapım hatası nedir?
A: Vergiyi ve kargoyu gereksinim değil ayar saymak. Bunlar sınır durumları olan iş kurallarıdır — eşikler, bölgeler, karışık sepetler, dijital ürünler — ve sekizinci haftada keşfedilmeleri ödeme akışını yeniden yazdırır. Keşif aşamasında, zor örneklerle birlikte yazılı hâle getirin.

## SEO Uyumlu URL Yapısı: Hâlâ Önemli Olan Kurallar
https://websitedevelopment.biz/tr/guides/seo-uyumlu-url-yapisi
Güncelleme 2026-08-07 · SEO

URL’ler küçük bir sıralama faktörü, büyük bir kullanılabilirlik ve bakım faktörüdür. Asıl değerleri kalıcılıktır: hiç değiştirmediğiniz bir URL, bağlantılarını, sıralamalarını ve yer imlerini koruyan bir URL’dir.

Bu rehber hâlâ önemli olan kuralları, artık olmayanları ve gerçekten zorunlu olduğunda bir URL’yi nasıl değiştireceğinizi ele alıyor.

### Uyulmaya değer kurallar
Bunlar arama motorları arasında ve daha önemlisi yıllar boyunca tutarlıdır — sıralama kadar bakımla da ilgilidirler.
- Yalnız küçük harf. Bazı sunucular /Sayfa ile /sayfa’yı farklı URL sayar ve bu kazara kopya üretir.
- Kelimeler arasında tire, alt çizgi ya da camelCase değil.
- Kısa ve açıklayıcı. Biri URL’yi sesli okuduğunda sayfayı tahmin edebilmeli.
- Bağlaçlara gerek yok: /guides/website-planlama, /guides/isletmeniz-icin-website-nasil-planlanir’dan iyidir.
- İçerik sayfalarında dosya uzantısı olmasın. /hakkimizda, /hakkimizda.php değil — uygulamayı gizler ve bir taşımada ayakta kalır.
- Sondaki eğik çizgi için tek bir kanonik karar, yönlendirmeyle uygulanmış.
- Mümkünse ASCII; ASCII olmayan URL’ler çalışır ama kopyalandığında yüzdeyle kodlanır, bu da çirkin ve hataya açıktır.
En değerli özellik kalıcılıktır. Hiç değişmeyen biraz kusurlu bir URL, iki kez değişen optimize bir URL’den değerlidir.

### Artık pek önemli olmayanlar
URL’lerle ilgili birkaç köklü inanışın bugün etkisi sınırlı ve uymak bazen zarar veriyor.
| Tam eşleşen anahtar kelime URL’leri daha iyi sıralanır | En iyi ihtimalle marjinal; doldurmak spam görünüyor |
| Derin klasör yapısı hiyerarşi sinyali verir | Tık derinliği önemli, yol derinliği neredeyse değil |
| URL’deki tarihler tazeliğe yardım eder | Kalıcı içeriği bayat gösteriyorlar |
| Kısa her zaman daha iyidir | Açıklayıcı, kısadan iyidir; /p/4821 kimseye yardım etmiyor |
| Alt alan adı mı alt klasör mü belirleyici | Alt klasörler yönetmesi daha basit; ikisi de çalışabilir |
| Sorgu dizeleri indekslenemez | İndekslenebilir ama kopyaları çoğaltır — temiz yolları tercih edin |

### Çok dilli URL kalıpları
Birkaç dilli bir sitede URL kalıbı sonradan değiştirmesi en zor şeylerden biridir, çünkü hreflang, kanonikler ve yazacağınız her yönlendirmeyle etkileşir.
| Alt klasör | site.com/de/guides | En basiti; tek alan adı bütün otoriteyi biriktirir |
| Alt alan adı | de.site.com/guides | Daha net ayrım; daha çok kurulum, bölünmüş sinyal |
| Ülke alan adı | site.de/guides | En güçlü yerel sinyal; yönetilecek ayrı bir site |
| Parametre | site.com/guides?lang=de | Kaçının — zayıf sinyal ve kopya riski |
Hangisini seçerseniz seçin, slug’ın kendisinin çevrilip çevrilmeyeceğine ayrıca karar verin. Çevrilmiş slug yerel alakayı artırır; aynı kalması bakımı kolaylaştırır. İkisi de savunulabilir — fikir değiştirmek değil.

### Trafik kaybetmeden bir URL’yi değiştirmek
Bazen değişiklik gerçekten gerekli. Prosedür mekaniktir ve atlanan her adım trafiğin gittiği yerdir.
- Buna değdiğinden emin olun. URL değişikliği her zaman bir bedel öder; küçük bir ifade iyileştirmesi bunu nadiren geri kazandırır.
- Eskiden yeniye bire bir eşleyin. Her eski URL bir kategori sayfası değil belirli bir hedef alır.
- 302 değil 301 kullanın ve her birinin tek adımda döndüğünü doğrulayın.
- İç bağlantıları doğrudan yeni URL’ye çevirin. Kendi yönlendirmelerinize dayanmayın.
- Site haritasını güncelleyin ve yönlendirmeleri süresiz bırakın — dış bağlantılar hiçbir zaman güncellenmez.
- Search Console kapsamını ve öne çıkan sayfa raporunuzu dört ile altı hafta izleyin.
- Bir düşüş bekleyin ve yalnız bir ay sonra hâlâ derinleşiyorsa inceleyin.

Q: URL’lere anahtar kelime koymalı mıyım?
A: Sayfayı tarif eden kelimeleri koyun; bunlar genelde zaten anahtar kelimelerdir. Yapmamanız gereken şey varyant doldurmaktır: /website-gelistirme-hizmetleri-ucuz-website-gelistirme, /website-gelistirme-hizmetleri’nden her açıdan kötüdür — arama sonucunda onu gören insanlar için de.

Q: Blog için alt alan adı mı alt klasör mü?
A: Çoğu durumda alt klasör. site.com/blog yönetmesi daha basit, alan adının birikmiş sinyallerini paylaşır ve ayrı bir teknik kuruluma ihtiyaç duymaz. Alt alan adı, bölüm gerçekten ayrı bir uygulamaysa, ayrı bir ekibi varsa ya da farklı altyapıda çalışması gerekiyorsa anlamlıdır.

Q: Eski yönlendirmeleri ne kadar tutmalıyım?
A: Süresiz. Tutmanın maliyeti neredeyse sıfır ve eski URL’lerinize verilen dış bağlantılar asla güncellenmeyecek. Yapmanız gereken şey, art arda taşımaların ürettiği zincirleri düzenli olarak kısaltmak; böylece her eski URL tek adımda mevcut hedefe gider.

Q: URL parametreleri SEO’ya zarar verir mi?
A: Kendi başlarına zararlı değiller ama neredeyse-kopya URL’leri hızla çoğaltırlar — sıralama, filtreleme ve izleme parametreleri tek bir sayfanın binlerce varyantını üretebilir. İndekslenmesini istediğiniz her şey için temiz yollar kullanın ve parametre varyantlarını kanonikleştirin ya da noindex yapın.

## Çok Dilli Website Geliştirme: Yapı, URL’ler ve İş Akışı
https://websitedevelopment.biz/tr/guides/cok-dilli-website-gelistirme
Güncelleme 2026-08-07 · CMS

Bir website’e dil eklemek nadiren yalnız çeviridir. URL yapısını değiştirir, sessizce bozulan karşılıklı bir etiket kümesi ekler ve tek bir sayfanın birbirinden ayrışabilen on iki sayfaya dönüştüğü bir içerik akışı getirir.

Bu rehber yapısal kararları, teknik gereksinimleri ve çevirilerin bayatlamasını önleyen iş akışını ele alıyor.

### Önce URL kalıbına karar verin
Bu, geri alması pahalı olan karardır; çünkü sitedeki her URL’ye, her yönlendirmeye ve her hreflang etiketine dokunur.
| Alt klasör | site.com/de/guides | Çoğu site — en basiti, tek alan adı otoriteyi biriktirir |
| Alt alan adı | de.site.com/guides | Ayrı altyapı ya da ayrı ekipler |
| Ülke alan adı | site.de/guides | Güçlü yerel taahhüt ve yönetilecek ayrı bir site |
| Parametre | site.com/guides?lang=de | Kaçının — zayıf sinyal, kopya riski |
Slug’ın çevrilip çevrilmeyeceğine ayrıca karar verin. Çevrilmiş slug yerel alakayı artırır; aynı slug bakımı kolaylaştırır. İkisi de savunulabilir — sonradan fikir değiştirmek değil.

### Teknik gereksinimler
Bunların her biri sessizce başarısız olur; çok dilli sitelerin etiketleri olduğu hâlde neden çalışan hreflang’i olmadığının sebebi budur.
- Karşılıklı hreflang. Bir dil kümesindeki her sayfa, kendisi dahil diğer hepsini listeler. Eksik tek bir geri referans kümeyi düşürür.
- Tutarlı kodlar. HTML’de ve site haritasında aynı kod. Bir sayfa için iki kod kümeyi kırar.
- x-default, dil seçiciyi ya da varsayılan sürümü gösterir.
- Her sürümde doğru lang ve dir nitelikleri html öğesinde.
- Dil başına kendine referans veren kanonik — çevirileri asla orijinale kanonikleştirmeyin.
- IP ya da tarayıcı diline göre otomatik yönlendirme YOK. Taramayı bozar ve bilinçli bir seçimi ezer; onun yerine öneri sunun.
- Çevrilmiş meta veri. Başlıklar ve açıklamalar hedef dilde, kaynak dilde değil.

### Ayakta kalan bir çeviri akışı
Arıza biçimi ilk çeviri değil, İngilizce sayfaya yapılan ve diğer on bire hiç ulaşmayan beşinci düzenlemedir.
- Çevirileri tek bir içerik öğesinin bağlı sürümleri olarak modelleyin ki sistem birbirine ait olduklarını bilsin.
- Hangi çevirilerin kaynağa göre geride kaldığını takip edin ve bunu düzenleme arayüzünde gösterin.
- Bir çeviri eksikse ne olacağına karar verin: varsayılana düşmek mi, o URL’yi hiç yayımlamamak mı.
- Çevirisi olmayan bir URL’yi asla yayımlamayın — başka bir dilde yarım çizilen bir sayfa, hiç olmamasından kötüdür.
- İçerik öğesi başına değil dil başına bir gözden geçirme tarihi tutun.
- Çevirmenlere bağlam verin: bir ekran görüntüsü ya da önizleme, bir dize tablosundan iyidir.
- Her dilin sahibini belirleyin. Sahipsiz diller önce bayatlar.
Başlangıç noktası olarak makine çevirisi sorun değil; gözden geçirilmeden yayımlamak sorundur. Gözden geçirilmemiş çıktı gözden geçirilmemiş okunur ve arama motorlarının giderek daha açık konuştuğu düşük değerli içerik tam olarak budur.

### Metnin ötesinde
Çeviri, herkesin bütçelediği kısımdır. Bunlar atlanan ve görünür hatalara yol açan kısımlardır.
| Tarih ve sayılar | Biçim ve ayraçlar yerel ayara göre farklı |
| Para birimi | Sembol, konum ve yuvarlama alışkanlıkları |
| Adres ve telefon | Alan sırası ve doğrulama kuralları |
| İsimler | Ad ve soyad sırası evrensel değil |
| Metin uzunluğu | Almanca ve Fince uzuyor; düzenler esnemeli |
| Yazı yönü | Arapça ve İbranice mantıksal CSS özellikleri ister |
| Metin içeren görseller | Dil başına bir sürüm ya da görselde hiç metin olmaması |
| Hukuki sayfalar | Gereksinimler yalnız dile göre değil yargı alanına göre değişir |

Q: Ziyaretçileri diline otomatik yönlendirmeli miyim?
A: Hayır. IP ya da tarayıcı diline göre otomatik yönlendirme taramaya karışır — bir ülkeden gelen tarayıcı diğer sürümleri hiç görmeyebilir — ve bilinçli seçimleri ezer ki bu, ikinci bir dilde okuyan herkes için sinir bozucudur. Kapatılabilir bir öneri gösterin ve kararı ziyaretçiye bırakın.

Q: Makine çevirisi kabul edilebilir mi?
A: İlk taslak olarak evet ve gerçek para tasarrufu sağlar. İnsan gözden geçirmesi olmadan yayımlandığında makine üretimi gibi okunan içerik üretir ve bu hem kullanıcıları hem arama kalitesi değerlendirmesini etkiler. Pragmatik yaklaşım makine çevirisi artı ana dili konuşan bir gözden geçirmedir; özellikle bir şey satan ya da açıklayan sayfalarda.

Q: hreflang’i en çok ne bozar?
A: Karşılıklı olmayan etiketler: A sayfası B’yi listeliyor, B A’yı listelemiyor ve bütün küme yok sayılıyor. İkincisi HTML ile site haritası arasındaki kod uyuşmazlığı. İkisi de hreflang’i iki liste bakmak yerine tek bir doğruluk kaynağından üreterek önlenir.

Q: Sitenin tamamını çevirmem gerekir mi?
A: Hayır ve kısmi çeviri normaldir. O pazarda talebi olanı çevirin ve gerisi yalnız kaynak dilde var olsun. Yapmamanız gereken şey boş ya da yarı çevrilmiş bir URL yayımlamaktır — sayfa ya o dilde düzgün vardır ya hiç yoktur.

## Site Hızı Optimizasyonu: Uygulamalı Bir İş Sırası
https://websitedevelopment.biz/tr/guides/site-hizi-optimizasyonu
Güncelleme 2026-08-07 · SEO

Site hızı çalışmasının güçlü bir Pareto şekli var: çoğu sitede iyileşmenin çoğunu az sayıda düzeltme sağlıyor ve bunlar neredeyse her zaman görseller, sunucu yanıtı ve üçüncü taraf betikleri oluyor.

Bu rehber hangi sırayla çalışacağınızı, bir değişikliğin işe yarayıp yaramadığını nasıl ölçeceğinizi ve genelde emeğe değmeyen optimizasyonları ele alıyor.

### Bir şeyi değiştirmeden önce ölçün
Ölçmeden optimize etmek, yavaş olanı değil kolay olanı düzeltmek demektir. İki ölçüm, sonra iş.
- Gerçek ziyaretçiler için saha verisi alın — Search Console’daki Core Web Vitals raporu ya da kendi izlemeniz.
- En önemli üç şablonda 4G’de orta seviye bir telefona kısıtlanmış bir laboratuvar testi çalıştırın.
- Başlamadan önce rakamları kaydedin. Referans olmadan bir değişikliğin işe yarayıp yaramadığını bilemezsiniz.
- Her şablonda en büyük tek varlığı ve en büyük tek engelleyici isteği belirleyin.
- Time to First Byte’ı ayrıca not edin: 800 ms üzerindeyse hiçbir front-end işi sizi kurtarmaz.

### Kazandıran sıra
Tipik bir içerik ya da tanıtım sitesi için, kabaca harcanan saat başına iyileşmeye göre.
| Görselleri optimize edip doğru boyutlamak | Büyük | Düşük |
| Kullanılmayan üçüncü taraf betiklerini kaldırmak | Büyük | Düşük — çoğunlukla siyasi bir iş |
| Önbellek ve CDN açmak | Büyük | Düşük |
| Çizimi engelleyen CSS ve JS’i düzeltmek | Orta–büyük | Orta |
| JavaScript paketini küçültmek | Orta–büyük | Orta–yüksek |
| Yavaş veritabanı sorgularını düzeltmek | Geçerli olduğu yerde büyük | Orta |
| Yazı tipi yüklemeyi optimize etmek | Orta | Düşük |
| Metin varlıklarını küçültüp sıkıştırmak | Küçük | Düşük — genelde zaten açık |
| CSS seçicilerini mikro-optimize etmek | İhmal edilebilir | Yapmaya değmez |

### Görseller: genelde en büyük kazanç
Çoğu sitede görseller sayfa ağırlığının çoğunluğudur ve çoğu gösterildiği boyutun birkaç katında sunulur. Bu, mevcut en ucuz büyük iyileştirmedir.
- WebP ya da AVIF sunun; ikisi de geniş desteklidir ve eşdeğer kalitede JPEG’den genelde %25–50 küçüktür.
- Birden çok boyut üretin ve srcset ile sizes kullanın ki telefonlar telefon boyutunda dosya indirsin.
- 400px’lik bir alana asla 2000px’lik görsel sunmayın — bu tek hata son derece yaygın.
- Katlamanın altındaki her şeyi geç yükleyin, üstündeki hiçbir şeyi yüklemeyin.
- Derlemede ya da CMS’te otomatikleştirin. Elle optimize edilen görseller, başkası bir tane yüklediği an optimize olmaktan çıkar.
- Meta veriyi temizleyin; kamera EXIF verisi dosya başına onlarca kilobayt olabilir.
Asıl mesele otomasyon. Tek seferlik bir optimizasyon geçişi yeni içerik eklendikçe aylar içinde bozulur ve sayfa ağırlığı ikiye katlanana kadar kimse fark etmez.

### Üçüncü taraf betikleri ve sunucu
Sorunun genelde teknik değil kurumsal olduğu iki alan: etiket yöneticisinin sahibi yok ve hosting kararının sahibi yok.
| Bilinmeyen etiketlerle dolu etiket yöneticisi | Her etiketi denetleyin; kimsenin gerekçelendiremediğini silin |
| Her sayfada yüklenen sohbet widget’ı | Etkileşimde yükleyin ya da yalnız destek gereken sayfalarda |
| Birden çok analitik aracı | Bir tane tutun; her biri tam bir betik ve bir bağlantı |
| Çizimi engelleyen A/B test betiği | Sunucu tarafına taşıyın ya da bir titremeyi kabul edip async yükleyin |
| Paylaşımlı hostingde yavaş TTFB | Tam sayfa önbelleği ekleyin; sürerse paketi yükseltin |
| Önbelleklenmemiş veritabanı sorguları | Pahalı olanları önbellekleyin; yaygın olanlara indeks ekleyin |
| CDN yok | Ekleyin — mevcut en ucuz küresel gecikme düzeltmesi |
Üçüncü taraf betikleri açıklanamayan yavaşlamaların en güvenilir kaynağıdır, çünkü size haber vermeden değişirler ve dağıtım sürecinizin dışındadırlar.

Q: İyi bir sayfa yüklenme süresi nedir?
A: İşe yarayan hedefler tek bir yüklenme sayısı değil Core Web Vitals eşikleridir: LCP 2,5 saniyenin altında ve Time to First Byte 800 ms’nin altında. Toplam yüklenme süresi kötü bir ölçüdür, çünkü bir sayfa her varlık bitmeden çok önce kullanılabilir ve yavaş bir cihazda ondan çok önce kullanılamaz olabilir.

Q: Daha hızlı bir site dönüşümü artırır mı?
A: Genelde evet ve etki, sayfaların hâlihazırda yavaş olduğu ve ziyaretçilerin mobil ağda olduğu yerde en büyüktür. Üç saniyeden ikiye inmenin kazancı, bir buçuktan bire inmekten çok daha büyüktür. Siteniz zaten hızlıysa emeği içeriğe ve netliğe harcayın — getirisi daha iyidir.

Q: Önbellek eklentileri her şeyi çözer mi?
A: Gerçek bir şeyi iyi çözerler — aynı sayfa için tekrarlanan sunucu işini — ve özellikle oturum açmış kullanıcılar, sepetler ve formlarla yeni sorunlar yaratabilirler. Ayrıca genelde daha büyük sorunlar olan büyük görseller ve üçüncü taraf betikleri konusunda hiçbir şey yapmazlar. Faydalı, ama yeterli değil.

Q: Sunucu tarafında çizim hız için değer mi?
A: Sayfalarınız şu an yalnız tarayıcıda üretiliyorsa evet: sunucuda çizim ya da statik üretim, içerik görünmeden önceki bir tam gidiş dönüşü ortadan kaldırır ve aynı anda indekslemeye de yardım eder. Sayfalarınız zaten sunucuda üretilmiş HTML ise soru geçerli değil — faydayı zaten alıyorsunuz.

## Geliştiriciler İçin Core Web Vitals: Rakamları Ne Hareket Ettirir
https://websitedevelopment.biz/tr/guides/gelistiriciler-icin-core-web-vitals
Güncelleme 2026-08-07 · SEO

Core Web Vitals, bir sayfanın nasıl hissettirdiğine dair üç saha ölçümüdür: ana içerik ne kadar sonra görünüyor, yüklenirken ne kadar oynuyor ve girdiye ne kadar hızlı yanıt veriyor. Bir sıralama sinyalidir ve daha önemlisi insanların kalıp kalmamasıyla ilişkilidir.

Bu rehber her metriğin ne ölçtüğünü, zayıf puanların ardındaki somut sebepleri ve yalnız laboratuvar puanını değil saha verisini hareket ettiren düzeltmeleri ele alıyor.

### Üç metrik neyi ölçüyor
Her birinin "iyi" için bir eşiği ve az sayıda alışılmış sebebi var. Sıralama için sayılan sayının, dizüstünüzdeki laboratuvar puanı değil gerçek ziyaretçilerden gelen saha verisi olduğunu unutmayın.
| LCP | 2,5 sn altı | En büyük görünür öğenin çizildiği an | Optimize edilmemiş hero, yavaş sunucu, çizimi engelleyen CSS |
| CLS | 0,1 altı | Yükleme sırasında düzenin ne kadar oynadığı | Boyutsuz görseller, sonradan eklenen bantlar, geç gelen yazı tipleri |
| INP | 200 ms altı | Kullanıcı girdisine yanıt verme hızı | Ana iş parçacığını bloke eden uzun JavaScript görevleri |
Laboratuvar araçları tek bir makinede tek bir yüklemeyi ölçer. Saha verisi gerçek ziyaretlerin 75. yüzdelik dilimidir; buna eski telefonlar ve kötü ağlar da dahildir — yani ayrılma olasılığı en yüksek ziyaretçiler.

### LCP’yi düzeltmek
LCP neredeyse her zaman bir görsel ya da bir başlığın başka bir şeyin arkasında bloke olmasıdır. Sırayla ilerleyin; ilk ikisi çoğu siteyi düzeltir.
- Saha verisinde gerçek LCP öğesini belirleyin. Yanlış görseli optimize etmek en yaygın boşa emektir.
- LCP görselini asla geç yüklemeyin. Onun yerine fetchpriority="high" verin.
- Gösterildiği boyutta ve modern formatta sunun, küçük ekranlar için srcset ile.
- LCP metninin kullandığı yazı tipini preload edin ve font-display: swap kullanın ki metin beklerken görünmez kalmasın.
- Head’den çizimi engelleyen CSS ve JavaScript’i çıkarın; sayfa yeterince küçükse kritik CSS’i satır içi koyun.
- Önbellek ve CDN ile Time to First Byte’ı düşürün — yavaş bir sunucuyu hiçbir front-end işi telafi edemez.
- Kritik yoldaki üçüncü taraf betikleri azaltın. Her biri bir DNS sorgusu, bir bağlantı ve öngörülemeyen bir dosyadır.

### CLS’yi düzeltmek
Düzen kayması neredeyse tamamen önlenebilir ve düzeltmeler ucuzdur. Ayrıca ziyaretçilerin en içgüdüsel fark ettiği metriktir — insanların yanlış şeye basmasına o yol açar.
- Her görsele ve videoya width ve height verin ki tarayıcı yeri ayırsın.
- Reklamlara, gömülü içeriğe ve iframe’lere sabit en boy oranlı bir kapla yer ayırın.
- Yüklemeden sonra mevcut içeriğin ÜSTÜNE asla içerik eklemeyin — çerez bantları alta ait ya da üstte katman olarak.
- Yedek yazı tipi ölçülerini web fontuyla eşleştirin ya da size-adjust kullanın ki değişim sayfayı yeniden akıtmasın.
- Düzen özelliklerini animasyonlamayın. Yeniden akış tetiklemeyen transform ve opacity kullanın.
- Dinamik yüklenen bölümlere min-height verin ki sıfırdan açılmasınlar.

### INP’yi düzeltmek
INP, First Input Delay’in yerini aldı ve daha zordur; çünkü yalnız ilk etkileşimi değil ziyaret boyunca her etkileşimi ölçer. Zayıf INP neredeyse her zaman ana iş parçacığında çalışan fazla JavaScript demektir.
| Yüklemede ayrıştırılan büyük paket | Kodu bölün; yalnız sayfanın ihtiyacını yükleyin |
| 50 ms üzeri uzun görevler | İşi parçalara bölün ve ana iş parçacığına yol verin |
| Pahalı olay işleyicileri | Debounce uygulayın ve ağır işi etkileşim yolundan çıkarın |
| Ağır üçüncü taraf etiketleri | Etkileşimden sonra yükleyin ya da kaldırın — her birinin kazancını denetleyin |
| Büyük DOM (10.000+ düğüm) | Uzun listeleri sanallaştırın; derin iç içe işaretlemeyi sadeleştirin |
| İşleyicilerde düzen çırpınması | Okuma ve yazmaları iç içe geçirmek yerine gruplayın |
İçerik sitelerinde en yüksek değerli INP düzeltmesi genelde JavaScript’i optimize etmek değil silmektir. Her betiğin ne kazandırdığını sorun; etiket yöneticileri kimsenin eklediğini hatırlamadığı betikler biriktiriyor.

Q: Core Web Vitals sıralamayı ne kadar etkiler?
A: Gerçek ama ölçülü bir sinyaldir ve alaka düzeyinin yerine geçmez, eşitlik bozucu olarak çalışır. Yanlış konu hakkındaki hızlı bir sayfa, sorguyu cevaplayan daha yavaş bir sayfayı geçmez. Düzeltmek için daha güçlü gerekçe davranışsaldır: yavaş ve oynayan sayfalar sıralama devreye girmeden ziyaretçi kaybettirir.

Q: Lighthouse puanım iyi ama saha verim neden kötü?
A: Çünkü Lighthouse sizin makinenizde sizin bağlantınızla tek bir yüklemeyi taklit ediyor, saha verisi ise gerçek ziyaretlerin 75. yüzdeliği — üç yaşındaki telefonlar ve tıkalı mobil ağlar dahil. İkisi çeliştiğinde sayılan saha verisidir. Laboratuvar araçlarını puanlamak için değil teşhis için kullanın.

Q: Üç metriği de düzeltmem gerekir mi?
A: Başarısız olanları, ziyaretçilerinizin deneyimlediği sıraya göre düzeltin. CLS genelde düzeltmesi en ucuz ve kullanıcıyı en çok rahatsız edendir, o yüzden başlamak için iyi bir yerdir. LCP insanların bekleyip beklememesinde en büyük etkiye sahiptir. INP etkileşimli sitelerde en çok, durağan makalelerde en az önem taşır.

Q: İyileştirmeler ne zaman görünür?
A: Saha verisi 28 günlük kayan bir penceredir, dolayısıyla bir düzeltme tüm ziyaretçilere dağıtıldıktan yaklaşık dört hafta sonra anlamlı hareket görülür. Üç gün sonra karar vermeyin. Ama laboratuvar metriklerini hemen kontrol edin ki düzeltmenin beklediğiniz şeyi yaptığını doğrulayın.

## CMS Taşıma: Trafik Kaybetmeden Nasıl Taşınır
https://websitedevelopment.biz/tr/guides/cms-tasima-rehberi
Güncelleme 2026-08-07 · CMS

CMS taşıma, içeriği bir sistemden diğerine taşır. Risk teknik değildir — dışa ve içe aktarma çözülmüş sorunlardır — risk, yol boyunca yapının, URL’lerin ve meta verinin değişmesi ve arama motorlarının üçünü de fark etmesidir.

Bu rehber trafiği koruyan sırayı, önce yapılması gereken denetimi ve sonrasında neye bakacağınızı ele alıyor.

### Bir şeyi taşımadan önce denetleyin
Her şeyi taşımak varsayılan ve genelde yanlış seçimdir. Çoğu sitede hiç trafik almayan, hiç bağlantısı olmayan ve hiçbir işe yaramayan ciddi bir kuyruk vardır; bunları taşımak sorunu yeni sisteme ithal etmektir.
- Gerçekte var olan her URL’yi almak için mevcut siteyi tarayın.
- URL başına on iki aylık trafiği ve gelen bağlantıları çekin.
- Her sayfayı sınıflandırın: olduğu gibi taşı, yeniden yaz, başka bir sayfayla birleştir ya da at.
- Trafiği ya da bağlantısı olan her şeyin bir hedefi olmalı. Diğer her şey gidebilir.
- Hangi sayfaların yapısal veri, özel alanlar ya da sıra dışı şablonlar taşıdığını not edin.
- Meta veriyi — başlıklar ve açıklamalar — ayrıca dışa aktarın. Bir taşımada en sık kaybedilen varlık odur.
Taşıma sırasında ince sayfaları güçlü olanlarla birleştirmek, bütün işlemin güvenilir biçimde olumlu birkaç SEO sonucundan biridir. Birleştirilenleri hayatta kalana yönlendirin.

### İçe aktarmadan önce içeriği modelleyin
Cazibe eski yapıyı birebir yeniden kurmaktır. Bu, eski tavizleri de ithal eder. İçeriği olması gerektiği gibi modelleyin, sonra eski veriyi ona eşleyin.
| İçerik türleri | Gerçekten farklı olan ne — sayfa, makale, ürün, kişi, etkinlik |
| Alanlar | Mümkün olan her yerde tek bir HTML yığını yerine yapılandırılmış alanlar |
| Taksonomiler | Hangi kategori ve etiketler hayatta kalıyor; çoğu sitede fazlası var |
| Medya | Dosyaların nerede yaşadığı ve yolların değişip değişmediği |
| Yazarlar ve tarihler | Gerçek yayın tarihlerini koruyun; hepsini bugüne sıfırlamayın |
| Meta veri | Başlıklar, açıklamalar ve kanonikler açıkça eşlenmiş |
| Yönlendirme haritası | Eski URL’den yeni URL’ye, bire bir, yol boyunca kurulmuş |
İçe aktarmada yayın tarihlerini sıfırlamak yaygın bir kazadır ve bütün arşivinizdeki tazelik sinyalini tek seferde yok eder.

### URL’leri koruyun, koruyamadığınızı yönlendirin
Bir taşımanın trafiğe mal olup olmayacağını belirleyen tek en büyük etken.
- Gerçekten bozuk değilse mevcut URL yapısını koruyun. "Yeni CMS farklı bir kalıp tercih ediyor" yeterli bir sebep değildir.
- URL’lerin değişmesi gereken yerde bire bir eşleyin — asla bir kategori sayfasına ya da ana sayfaya değil.
- 301 yönlendirme kullanın ve her birinin tek adım olduğunu doğrulayın.
- Medya dosyalarını da yönlendirin. Görseller bağlantı biriktirir ve görsel aramada görünür.
- Yönlendirmeleri süresiz tutun; dış bağlantılar asla güncellenmez.
- Yönlendirme haritasını yayından önce staging’de bir örnekle değil tam listeyle test edin.

### Yayın ve sonraki altı hafta
Taşıma geçiş anında bitmez. Sorunların çoğu takip eden ayda görünür hâle gelir.
- İzleyebileceğiniz bir zamanda yayına alın. Cuma değil, tatilden hemen önce değil.
- Canlıda robots.txt’i, meta robots’u, kanonikleri ve site haritasını hemen doğrulayın.
- Tam yönlendirme listesini canlıya karşı çalıştırın ve 404’leri ve zincirleri kontrol edin.
- Yeni site haritasını Search Console’a gönderin ve bir hafta boyunca kapsamı günlük izleyin.
- Öne çıkan sayfaları önceki dönemle karşılaştırın; sert düşen bir sayfanın genelde belirli bir sebebi vardır.
- Tarayıcı 404’leri için sunucu kayıtlarını izleyin — atlanmış URL’leri analitikten hızlı bulurlar.
- İki ile altı hafta dalgalanma bekleyin; bir ay sonra hâlâ derinleşen bir düşüşü inceleyin.
- Eski sistemi bir süre salt okunur tutun ki bir sayfanın eskiden ne içerdiğini kontrol edebilesiniz.

Q: Taşırken arama trafiği kaybeder miyim?
A: Her şey doğru yapılsa bile birkaç haftalık bir düşüş bekleyin — arama motorlarının yeniden tarayıp yeniden değerlendirmesi gerekiyor. Temiz yönlendirme ve korunmuş içerikle trafik normalde iki ile altı hafta içinde eski seviyesine döner. Kalıcı kayıp neredeyse her zaman atlanmış yönlendirmelere, değişmiş içeriğe ya da sessizce düşürülmüş sayfalara dayanır.

Q: Aynı anda yenileme de yapmalı mıyım?
A: Cazip ve teşhisi çok zorlaştırıyor: trafik hareket ettiğinde bunun taşımadan mı yenilemeden mi olduğunu söyleyemezsiniz. Ayırabiliyorsanız önce mevcut şablonlarla taşıyın, kararlılığı doğrulayın, sonra yenileyin. Birlikte olmak zorundaysa URL’leri ve içeriği korumakta daha titiz olun.

Q: Temiz eşlenmeyen içeriği nasıl taşırım?
A: Bazı içerikler her zaman otomasyona direnir — özel düzenler, gömülü widget’lar, elle kurulmuş tablolar. Bunları denetim sırasında belirleyin ve elle çalışmaya zaman ayırın. Son %5’i otomatikleştirmeye çalışmak genelde elle yapmaktan pahalıya gelir ve daha kötü sonuç verir.

Q: Eski CMS’i çalışır tutmalı mıyım?
A: Birkaç ay erişilebilir ama halka açık olmayacak biçimde tutun: salt okunur, arama motorlarına kapalı, iç bir adreste. Bir şey yanlış göründüğünde bir sayfanın eskiden ne dediğini kontrol etmek için paha biçilmezdir. Sonra düzgün biçimde kapatın — terk edilmiş halka açık bir kurulum güvenlik yüküdür.

## Website Geliştiricileri İçin Teknik SEO Kontrol Listesi
https://websitedevelopment.biz/tr/guides/teknik-seo-kontrol-listesi
Güncelleme 2026-08-07 · SEO

Teknik SEO, arama işinin içerik takviminde değil kod tabanında yaşayan kısmıdır. Büyük ölçüde bir kontrol listesidir ve çoğu görüş meselesi değil doğrulanabilir bir şeydir.

Bu rehber o kontrol listesidir; her kalemin önlediği soruna göre gruplanmış ve adlandırılmaya değecek kadar yaygın hatalarla birlikte.

### İndeksleme denetimleri
Buradaki amaç tam olarak indekslenmesini istediğiniz sayfaların indekslenmesi ve başka hiçbir şeyin — staging kopyası yok, filtre kombinasyonu yok, yazdırma kopyası yok.
- Tek bir kanonik host; diğer her varyant ona 301 ile gidiyor — HTTP ve www/www’suz ikizi dahil.
- İndekslenebilir her sayfada kendine referans veren kanonik.
- İnce ya da kopya sayfalarda noindex, follow: site içi arama sonuçları, filtre kombinasyonları, teşekkür sayfaları.
- noindex taşıyan bir sayfayı robots.txt’te ASLA engellemeyin — etiket o zaman hiç okunamaz ve URL indekste kalır.
- Staging yalnız robots.txt ile değil HTTP kimlik doğrulamasıyla engelli.
- Parametre yönetimi kararlaştırılmış: hangi sorgu dizeleri ayrı bir sayfa üretir, hangileri üretmez.
noindex ile robots.txt engeli zıt işler yapar ve birbirini iptal eder. Bir sayfanın gitmesini istiyorsanız taramaya izin verin ki noindex görülebilsin.

### Yönlendirmeler ve durum kodları
Yenilemelerin sessizce trafik kaybettiği yer yönlendirmelerdir. Hatalar mekaniktir ve yayından önce test edilmesi kolaydır.
| Sayfa kalıcı taşındı | Eşdeğer sayfaya 301 | 302 ya da ana sayfaya yönlendirme |
| Sayfa silindi, karşılığı yok | 410 ya da 404 | Yumuşak 404: 200 dönen bir "bulunamadı" sayfası |
| Geçici erişilemez | Retry-After ile 503 | Hata mesajıyla 200 döndürmek |
| Sondaki eğik çizgi varyantları | Tek kanonik biçim, diğeri 301 | İkisi de 200 ile aynı içeriği sunuyor |
| Eski alan adı | Sayfa sayfa eşlenmiş 301 | Her şeyi yeni ana sayfaya |
| Yönlendirme zincirleri | Tek adıma indirgeyin | A → B → C → D, her adımda sinyal kaybı |

### Sayfalama, filtreler ve kopya içerik
En büyük indeks sorunlarını liste sayfaları üretir, çünkü birkaç filtre tek bir sayfanın binlerce neredeyse-kopya varyantını doğurabilir.
- Sayfalanmış sayfalar: gerçek taranabilir bağlantılar, her sayfa kendine kanonik — 2. sayfayı 1. sayfaya kanonikleştirmeyin.
- Filtre kombinasyonları: varsayılan olarak noindex, follow; yalnız gerçek arama talebine karşılık gelen az sayıdakini indeksleyin.
- Sıralama düzenleri: asla yeni indekslenebilir URL üretmesin. Aynı içerik, farklı sıra.
- Oturum kimlikleri ve izleme parametreleri: temizleyin ya da temiz URL’ye kanonikleştirin.
- Yazdırma dostu kopyalar: ana sürüme kanonik.
- Birden çok kategorideki ürünler: tek kanonik URL, hepsinden bağlantılı.
Açık bırakılmış filtreli gezinme indeks şişmesinin en yaygın sebebidir ve yavaş temizlenir. Yapım anında önlemek sonradan çözmekten çok daha ucuzdur.

### Yapısal veri ve uluslararası kurulum
Mekanik bir hatanın bütün özelliği sessizce devre dışı bıraktığı iki alan.
| Article işaretlemesi | Yalnız gerçek makalelerde, gerçek tarihlerle | Sahte tazelik tarihleri özelliği tamamen görmezden getirtiyor |
| Product işaretlemesi | Fiyat ve stok sayfayla birebir aynı olmalı | Uyuşmazlık manuel işlem tetikliyor |
| FAQ işaretlemesi | Yalnız sayfada görünen sorular için | Gizli içerik bir politika ihlalidir |
| Sayfa yolu | Görünen yolla aynı olmalı | Ayrışan yollar basitçe yok sayılıyor |
| hreflang | Kümedeki her sayfada karşılıklı | Tek yönlü etiketler bütün kümeyi düşürüyor |
| hreflang kodları | HTML ve site haritasında aynı kod | Aynı sayfa için iki farklı kod kümeyi kırıyor |
| x-default | Dil seçiciyi ya da varsayılan sürümü gösterir | Eksikliği geri düşüş davranışını kaybettiriyor |

Q: Mevcut bir sitedeki teknik SEO sorunlarını nasıl bulurum?
A: Bir masaüstü tarayıcıyla siteyi tarayın ve çıkanı site haritanızla ve Search Console kapsamıyla karşılaştırın. Sorunlar bu üç listenin uyuşmadığı yerdedir: taramada olup site haritasında olmayan URL’ler, indekslenmiş ama taramada olmayanlar ve sizin istemediğiniz gerekçelerle hariç tutulan sayfalar.

Q: Yönlendirme zincirleri gerçekten önemli mi?
A: Evet, iki sebeple. Her adım gerçek kullanıcılar için gecikme ekler ve tarayıcılar birkaç adımdan sonra takip etmeyi bırakır. Birkaç taşımadan sonra kimsenin planlamadığı dört beş adımlık zincirler bulmak yaygındır. Zincirleri kısaltın ki her eski URL doğrudan son hedefi göstersin.

Q: Etiket ve kategori sayfalarını noindex yapmalı mıyım?
A: Yalnız gerçekten inceyse. Gerçek bir açıklaması, seçilmiş bir listesi ve iç bağlantıları olan bir kategori sayfası meşru ve çoğu zaman güçlü bir iniş sayfasıdır. İki yazısı ve hiç metni olmayan bir etiket sayfası indeks şişmesidir. Her şablonu, birinin gerçekten sorduğu bir soruyu cevaplayıp cevaplamadığına göre değerlendirin.

Q: hreflang’i en çok ne bozar?
A: Karşılıklı olmayan etiketler. İngilizce sayfa Almanca alternatifi listeliyor ama Almanca sayfa İngilizceyi listelemiyorsa küme atılır. İkinci en yaygın hata, aynı sayfa için HTML’de bir kod ve site haritasında başka bir kod ilan etmektir. İkisini de tek bir kaynaktan üretin ki ayrışamasınlar.

## WordPress, Webflow ve Özel Geliştirme
https://websitedevelopment.biz/tr/guides/wordpress-webflow-ozel-gelistirme
Güncelleme 2026-08-07 · CMS

Bir işletme sitesi için kararların çoğu bu üçüne iniyor. Basit anlamda rakip değiller — farklı ekiplere, farklı bütçelere ve bakıma karşı farklı iştaha uyuyorlar.

Bu rehber onları işletme modeline, üç yıllık maliyete ve çıkış zorluğuna göre karşılaştırıyor; çünkü seçimin işe yarayıp yaramayacağını gerçekten belirleyen faktörler bunlar.

### Üçü tek tabloda
Ayrıntıdan önce özet.
| Model | Kendi sunucunuzda açık kaynak | Barındırılan görsel kurucu | Sizin kodunuz, sizin hostinginiz |
| Düzenleme | İyi, çoğu kişiye tanıdık | Mükemmel görsel kontrol | Ne kadar kurarsanız o kadar iyi |
| Bakımı kim yapar | Siz | Satıcı | Siz |
| Genişletilebilirlik | Çok büyük eklenti ekosistemi | Sınırlı, gelişiyor | Sınırsız |
| Performans | Büyük ölçüde yapıma bağlı | Genelde iyi | Ödediğiniz kadar iyi |
| İşletme maliyeti | Hosting + eklenti + geliştirici zamanı | Site başına abonelik | Hosting + geliştirici zamanı |
| Ayrılmak | Tam veritabanı erişimi | Dışa aktarma sınırlı ve kayıplı | Kod sizin |

### Her biri nerede gerçekten güçlü
Durumunuza uyan güce göre seçmek, korktuğunuz zayıflığa göre seçmekten daha güvenilirdir.
- WordPress: içerik odaklı siteler, bloglar, belirli bir eklentiye ihtiyaç duyan siteler, WordPress becerisi olan ekipler ve büyük bir ekosistemin özel işten tasarruf ettirdiği her durum.
- Webflow: görsel kontrolün önemli olduğu ve altyapıyı sürdürecek geliştiricinin bulunmadığı tasarım odaklı pazarlama siteleri. Ayrıca hızlı iniş sayfası çıkarması gereken ekipler için iyi.
- Özel geliştirme: uygulamalar, sıra dışı entegrasyonlar, katı performans ya da erişilebilirlik hedefleri ya da sitenin kendisinin ürün olduğu durumlar.
En yaygın uyumsuzluk, küçük bir ekibin bir tanıtım sitesi için özel geliştirme seçmesi. Teknik olarak yanlış değil; yalnız içeriğe harcansa daha çok getiri sağlayacak bir para.

### Dürüstçe üç yıllık maliyet
Orta ölçekli bir işletme sitesi için kesin rakamlar değil kaba şekil.
| Yapım | Düşük–orta | Düşük–orta | Yüksek |
| Hosting | Düşük–orta | Abonelikte dahil | Düşük–orta |
| Lisans ve eklentiler | Sürekli, zamanla artıyor | Dahil, kullanıma göre kademeli | Asgari |
| Bakım | Orta, sürekli | Düşük | Orta |
| Değişiklik için geliştirici zamanı | İçerikte düşük, özellikte orta | Düşük | Orta |
| Risk maliyeti | Yamalanmazsa ele geçirilme | Satıcının fiyat ve politika değişiklikleri | Kilit kişiye bağımlılık |

### Çıkış zorluğu
Terk etmenin ne kadar zor olduğu kararın parçası olmalı, çünkü seçimin geri alınabilir olup olmadığını o belirler.
- Özel: ilkece en kolayı — kod, veritabanı ve hosting sizde. Risk, dokümantasyon ve başka birinin bu kodla çalışıp çalışamayacağıdır.
- WordPress: düz. İçerik temiz dışa aktarılır; iş, eklentilerin yaptığını yeniden kurmaktır.
- Webflow: en zoru. Statik HTML ve CSS dışa aktarabilirsiniz ama CMS içeriği, formlar ve etkileşimler onunla gelmez; yani ayrılmak bir yeniden yapımdır.
Çıkış sorusunu bir anlaşmazlık sırasında değil seçim sırasında sorun. Sorulması en ucuz, atlanması en pahalı sorudur.

Q: SEO için hangisi en iyisi?
A: Üçü de mükemmel olabilir ve üçü de kötü olabilir. Önemli olan sunucuda çizilmiş HTML, başlık ve kanonik kontrolü, temiz URL’ler, site haritaları, yapısal veri ve hız. WordPress bunun için eklenti verir, Webflow bazı sınırlarla yerleşik sunar, özel geliştirme tam kontrol ve tam sorumluluk verir. Yapım kalitesi platform seçimine baskın gelir.

Q: WordPress güvensiz mi?
A: WordPress çekirdeği aktif bakılıyor ve makul ölçüde güvenli. Ele geçirmelerin çoğu güncellenmemiş eklentilerden, terk edilmiş temalardan ve zayıf yönetici parolalarından geliyor. Yamalanmış, az eklentili ve iki adımlı doğrulamalı bir WordPress gayet iyidir; kimsenin güncellemediği kırk eklentili bir site değildir ve bu bir platform özelliği değil bakım tercihidir.

Q: Webflow büyük bir siteyi kaldırır mı?
A: Orta ölçekli içerik sitelerini iyi kaldırır ve CMS öğe sayıları ile koleksiyon yapısında, taahhüt vermeden önce kendi içerik modelinize karşı kontrol etmeye değer sınırları vardır. Büyük ve karmaşık bir katalog ya da ağır özel mantık için genelde yanlış araçtır — zayıf olduğu için değil, bunu hedeflemediği için.

Q: Özel geliştirme ne zaman değer?
A: Site, hazır araçların direndiği ve işinize özgü bir şey yaptığında: bir konfigüratör, sıra dışı bir rezervasyon akışı, operasyonel sistemlerinizle derin entegrasyon ya da katı performans ve erişilebilirlik gereksinimleri. Yalnız ayırt edici tasarım nadiren yeterli bir sebeptir, çünkü bir CMS üzerindeki özel tema bunu çok daha ucuza sağlar.

## Website Geliştirmede SEO Temelleri: Neyi Baştan Kurmalı
https://websitedevelopment.biz/tr/guides/website-gelistirmede-seo-temelleri
Güncelleme 2026-08-07 · SEO

SEO’nun büyük bir kısmı aslında pazarlama değildir — website geliştirme sırasında alınan, yapım anında ucuz ve sonradan pahalı kararlardır. URL yapısı, çizim stratejisi, iç bağlantı ve düzenlenebilir meta veri bu kategoriye girer.

Bu rehber baştan neyin kurulması gerektiğini, kabaca sonradan eklemenin ne kadar acı verdiği sırayla ele alıyor.

### Sitenin taranabildiğinden ve indekslenebildiğinden emin olun
Arama motorları sayfalarınıza ulaşamıyor ya da okuyamıyorsa diğer her şey anlamsızdır. Yayın günü hataları da burada toplanıyor.
- Canlıdaki robots.txt taramaya izin veriyor. Staging kopyası oraya dağıtılmamalı.
- Staging’den taşınmış başıboş noindex meta etiketi yok.
- Her sayfanın kendine referans veren bir kanonik URL’si var ve tek bir kanonik host var.
- İçerik HTML’in içinde ya da sunucuda üretiliyor. Yalnız JavaScript çalıştıktan sonra beliriyorsa indeksleme yavaşlar ve güvenilirliğini kaybeder.
- Yalnız indekslenebilir kanonik URL’leri listeleyen bir XML site haritası — filtreli ya da sayfalanmış varyantları değil.
- İndekslenebilir her sayfanın en az bir iç bağlantısı var. Öksüz sayfalar neredeyse hiç taranmaz.
- Tutarlı durum kodları: gerçek sayfalar için 200, olmayanlar için 404, taşınanlar için 301.
Bu listedeki en yaygın yayın hatası, staging robots.txt’inin canlıya ulaşmasıdır. Yayın günü kendi ağınızın dışından kontrol edin.

### Arama motorlarının okuyabileceği yapı
Yapısal kararlar sonradan değiştirmesi acı olanlardır, çünkü değiştirmek yönlendirme ve birikmiş sinyal kaybı demektir.
| URL kalıbı | Kısa, küçük harf, tireli, kalıcı | Yüksek — yönlendirme ve kaybolan sinyal |
| Başlık hiyerarşisi | Tek H1, atlanmış seviye yok | Düşük |
| İç bağlantı | Hublar detay sayfalarına ve geri bağlanıyor | Orta |
| Sayfalama | Taranabilir bağlantılar, yalnız JavaScript değil | Orta |
| Filtreli gezinme | Filtre kombinasyonlarında noindex | Yüksek — indeks şişmesi yavaş temizlenir |
| Dil sürümleri | Önekli URL’ler artı karşılıklı hreflang | Çok yüksek |

### Ekibinizin gerçekten düzenleyebileceği meta veri
Yaygın bir yapım hatası, başlıkları ve açıklamaları bir şablondan üretip geçersiz kılma imkânı bırakmamaktır. Altı ay sonra pazarlama tek bir sayfanın başlığını değiştirmek ister ve cevap bir geliştirici talebidir.
- Sayfa başına düzenlenebilir başlık etiketi, makul bir varsayılanla.
- Düzenlenebilir meta açıklama, CMS’te görünür bir karakter sayacıyla.
- Paylaşılan bağlantılar için düzenlenebilir Open Graph başlığı, açıklaması ve görseli.
- Destekleyen şablonlarda yapısal veri: Article, Product, FAQ, Breadcrumb, Organization.
- Var olması gereken ama sıralanmaması gereken sayfalar için sayfa başına noindex anahtarı.
- Otomatik kanonik, nadir durumlar için elle geçersiz kılma imkânıyla.
Yalnız sayfada gerçekten görünen şeyi işaretleyin. Ziyaretçinin göremediği içeriği tarif eden yapısal veri bir kısayol değil, bir politika ihlalidir.

### Yapım gereksinimi olarak hız ve kararlılık
Sayfa deneyimi yapımın parçasıdır, sonraki bir optimizasyon projesi değil. Bitmiş bir siteye hızı sonradan eklemek genelde kod eklemek değil kararları geri almak demektir.
| Largest Contentful Paint | 2,5 sn altı | Hero görselini önceliklendirmek, çizimi engelleyen varlıklardan kaçınmak |
| Cumulative Layout Shift | 0,1 altı | Görsellerde width/height, gömülü içerik için ayrılmış yer |
| Interaction to Next Paint | 200 ms altı | Daha az JavaScript ve ana iş parçacığını bloke etmemek |
| Sayfa ağırlığı | Tasarımın izin verdiği kadar düşük | Modern görsel formatları, kullanılmayan kütüphane yok |
| Time to First Byte | 800 ms altı | Önbellek, CDN ve makul veritabanı sorguları |

Q: SEO geliştirme brief’inde yer almalı mı?
A: Teknik kısımları evet — taranabilirlik, URL yapısı, düzenlenebilir meta veri, yapısal veri, performans hedefleri ve yönlendirme haritası. İçerik stratejisi ve bağlantı çalışması farklı becerilerle yapılan ayrı işlerdir. Teknik gereksinimleri brief’e koymak, onların yayından sonra — birkaç kat pahalıya — keşfedilmek yerine fiyatlanması demektir.

Q: JavaScript çatısı SEO’ya zarar verir mi?
A: Sayfalar yalnız tarayıcıda üretiliyorsa verebilir. Arama motorları JavaScript çalıştırabiliyor ama gecikmeli ve her zaman eksiksiz değil, dolayısıyla yalnız istemcide çizim indekslemeyi yavaşlatır ve güvenilirliğini düşürür. Sunucu tarafında çizim ya da statik üretim sorunu ortadan kaldırır. İçerik sitesi için en basit cevap içeriği HTML’e koymaktır.

Q: Yayından sonra arama trafiğini ne zaman görürüm?
A: Yepyeni bir alan adında indeksleme için genelde haftalar, anlamlı sıralamalar için aylar — yeni siteler teknik kalite ne olursa olsun hızlı sıralanmıyor. Mevcut bir sitenin temiz yönlendirmelerle yeniden yayınında ise işler oturmadan önce iki ile altı hafta dalgalanma bekleyin.

Q: SEO eklentisine ihtiyacım var mı?
A: Bir CMS’te eklenti, editörlere başlık, açıklama, kanonik ve site haritası kontrolü vermenin pratik yoludur. Bir strateji değildir ve varsayılan çıktısı, her sayfanın ne hakkında olacağına birinin karar vermesinin yerini tutmaz. Özel bir yapımda aynı işlevsellik genelde doğrudan yazılır ve bu yüzden daha hafiftir.

## Headless CMS mi Geleneksel CMS mi? Sitenize Hangisi Uyar
https://websitedevelopment.biz/tr/guides/headless-cms-mi-geleneksel-cms-mi
Güncelleme 2026-08-07 · CMS

Geleneksel bir CMS içeriği saklar ve sayfaları çizer. Headless bir CMS içeriği saklar ve onu bir API üzerinden devreder, çizimi tamamen size bırakır. Bu tek fark her şeye yansır: önizleme, maliyet, ekip yapısı ve bir pazarlamacının bir sayfayı ne kadar hızlı değiştirebildiği.

Bu rehber ne kazandığınızı, ne kaybettiğinizi ve orta yolun nerede olduğunu ele alıyor.

### Gerçek fark
Diğer her şey çizimin nerede yapıldığından çıkar.
| Çizim | HTML’i CMS üretir | Sizin front-end’iniz üretir |
| Şablonlar | CMS’in içinde | Sizin kod tabanınızda |
| Önizleme | Yerleşik ve doğru | Sizin kurmanız gerekir |
| Kanallar | Bir website | Site, uygulama, kiosk, API çağırabilen her şey |
| Front-end özgürlüğü | CMS ile sınırlı | Tam |
| İlk sayfaya kadar süre | Hızlı | Yavaş — siz kurana kadar hiçbir şey çizilmez |
| Düzen değişikliği için kim gerekli | Çoğu zaman bir editör | Bir geliştirici |

### Headless’a geçerken neyden vazgeçersiniz
Geleneksel bir CMS’in bedava verdiği özellikler, insanların özlediği özelliklerdir ve genelde karar verildikten sonra keşfedilirler.
- Önizleme. Editörler yayımlamadan önce sayfayı görmeyi bekler. Headless’ta bu, sizin kurup baktığınız bir özelliktir.
- Sayfa kurgusu. Bir sayfada blokları düzenlemek geleneksel sistemlerde çözülmüş bir sorun, headless’ta bir yapımdır.
- Menüler ve gezinme. Bunları da artık siz modelleyip kuruyorsunuz.
- Formlar. API ile birlikte bir form kurucu gelmiyor.
- Yönlendirmeler ve URL yönetimi. Uygulaması size ait.
- Eklenti ekosistemi. SEO alanları, site haritaları, yönlendirmeler — hepsi özel iş hâline geliyor.
- Küçük değişikliklerin hızı. "Şu bölümü yukarı al" artık bir editör işi olmaktan çıkıyor.
Hayal kırıklığı yaratan headless projelerindeki tekrarlayan desen, eskiden bir sayfayı kendi değiştirebilen ve şimdi talep açan bir pazarlama ekibidir.

### Headless ne zaman doğru karar
Belirli bir sorun şekline uyar ve o şeklin dışında pahalı bir esnekliktir.
| İçerik hem sitede hem mobil uygulamada gösteriliyor | Güçlü — asıl senaryo bu |
| Tek içerik kaynağını paylaşan birkaç site | Güçlü |
| CMS’in karşılayamadığı front-end gereksinimleri | Güçlü |
| Zaten var olan özel bir front-end ekibi | İyi |
| Küçük ekipli pazarlama sitesi | Zayıf — hız kaybedip talep kazanırsınız |
| Sık düzen değişikliği olan içerik odaklı site | Zayıf |
| "Modern yaklaşım bu" | Bir sebep değil |

### Orta yol
Çoğu siteye, iki uç arasındaki bir şey daha iyi hizmet eder.
- Özel temalı geleneksel CMS. Tam front-end kontrolü, önizleme ve sayfa kurgusu hâlâ çalışıyor.
- Tek bir yüzey için headless kullanılan geleneksel CMS. Website’i CMS çizmeye devam eder; uygulama bir API tüketir.
- Statik site üreteciyle headless CMS. Editörler iyi bir arayüz alır, site statik ve hızlıdır; önizleme çalışma ister.
- Hibrit CMS. Hem çizilmiş sayfa hem API sunan sistemler — çoğu zaman pragmatik cevap.
- Git tabanlı editörlü statik üreteç. Çoğunlukla belge olan içerik için çok düşük maliyet ve çok düşük risk.
Geleneksel bir CMS üzerindeki özel bir tema, insanların headless’a geçme sebebi olan front-end özgürlüğünün çoğunu, önizlemeden, sayfa kurgusundan ve ekosistemden vazgeçmeden verir.

Q: Headless performans için daha mı iyi?
A: Olabilir, çünkü tam olarak neyin gönderildiğini siz kontrol edersiniz — ama kazanç API’den değil statik üretimden ve yalın bir front-end’ten gelir. Düzgün önbelleklenmiş ve özel temalı geleneksel bir CMS de hızlıdır. Performans, içeriğin nerede saklandığının değil nasıl kurduğunuzun sonucudur.

Q: Headless SEO için daha mı iyi?
A: En iyi ihtimalle nötr ve sayfalar yalnız tarayıcıda çiziliyorsa daha kötü. Teknik SEO’nun ihtiyaç duyduğu her şey — sunucuda çizilmiş HTML, kanonikler, site haritaları, yapısal veri, yönlendirmeler — headless’ta kendiniz uygulamak zorundasınız; geleneksel sistemlerin bunun için olgun eklentileri var. Headless disiplinle SEO için sorun değil, disiplinsiz hayal kırıklığı.

Q: Headless kurulumda editörler önizleme yapabilir mi?
A: Evet ama siz kurarsınız: front-end’te taslak içeriği çeken ve çizen bir önizleme modu. Bunu açıkça bütçeleyin. Önizlemeyi atlayan projeler, editörlerin bir şeyin nasıl göründüğünü görmek için canlıya yayımlamasıyla bitiyor — ki bir CMS’in tam olarak önlemesi gereken şey budur.

Q: Headless geleneksele göre ne tutar?
A: İlk yapım genelde daha yüksektir, çünkü front-end’i artı geleneksel bir CMS’in içerdiği özellikleri kuruyorsunuz. İşletme maliyeti, özellikle statik üretimle, daha düşük olabilir. Uzun vadede daha büyük fark, daha çok rutin değişikliğin geliştirici zamanı gerektirmesidir; bu, yapım teklifinde görünmeyen süregelen bir maliyettir.

## Website’niz İçin Tasarım Sistemi Gerekli mi?
https://websitedevelopment.biz/tr/guides/website-icin-tasarim-sistemi
Güncelleme 2026-08-07 · Web tasarım

Tasarım sistemi, yeniden kullanılabilir bileşenler ve onların kullanım kurallarıdır. Birkaç kişinin değişiklik yaptığı büyük bir sitede aynı kararın tekrar tekrar verilmesini ortadan kaldırır. Beş sayfalık bir tanıtım sitesinde ise karşılığı olmayan bir maliyettir.

Bu rehber sınırın nerede olduğunu, asgari işe yarar bir sistemin gerçekten neleri içerdiğini ve tam bir sistem haklı çıkmadığında ne yapılacağını ele alıyor.

### Ne zaman değer, ne zaman değmez
Değer tekrardan gelir: aynı kararın kırk kez yerine bir kez ve tutarlı biçimde verilmesi. Tekrar yoksa değer de yoktur.
| Beş sayfalık tanıtım sitesi, tek tasarımcı, nadir değişiklik | Hayır — bir stil kılavuzu sayfası yeter |
| Tek site, birkaç şablon, ara sıra içerik değişikliği | Hafif: token’lar ve bir bileşen listesi |
| Markayı paylaşan site ve uygulama | Evet — kaymanın olduğu yer paylaşılan yüzeydir |
| Tek kurumda birkaç site | Evet — en güçlü gerekçe budur |
| Sık A/B testi ve kampanya sayfaları | Evet — kazanç hızlı kurabilmektir |
| Bir yıl içinde yeniden yapım planlı | Henüz değil — sistemi yeni yapımla birlikte kurun |

### Asgari işe yarar sistem
Faydanın çoğu küçük bir çekirdekten gelir. Bunu aylarla değil günlerle kurabilirsiniz ve bir sisteme ihtiyaç duyan çoğu website için yeterlidir.
- Token’lar: renk, tipografi ölçeği, boşluk ölçeği, köşe yarıçapları, gölgeler, kırılma noktaları — adlandırılmış, sabit sayı değil.
- Tipografi: başlık seviyeleri ve gövde stilleri, duyarlı davranışlarıyla.
- Düğmeler ve bağlantılar: her durum — varsayılan, üzerinde, odak, basılı, pasif, yükleniyor.
- Form denetimleri: input, select, textarea, onay kutusu, radyo, artı hata ve ipucu stilleri.
- Kartlar ve listeler: sitenizin gerçekten kullandığı iki üç tekrarlayan içerik kabı.
- Gezinme: başlık, footer, sayfa yolu, sayfalama.
- Geri bildirim: boş durum, hata durumu, yükleniyor durumu, başarı mesajı.
Durumlar atlanan ve en çok önem taşıyan parçadır. Yalnız varsayılan hâliyle tanımlanmış bir bileşen, her sınır durumunu uygulayan kişiye geri devreder.

### Kimsenin bütçelemediği bakım maliyeti
Tasarım sistemi, kullanıcıları olan bir üründür ve bir sahibi olmalıdır. Sahipsizken kayar: site sistemde olmayan bileşenler kazanır, sistem hiçbir şeyin kullanmadığı bileşenleri taşır ve bir yıl sonra insanlar onunla değil onun etrafından çalışır.
- Bir kişi sahiplenir ve neyin gireceğine karar verir. Komiteye ait bir sistem değişmeyi bırakır.
- Yeni bileşen önermek için belgelenmiş bir yol olsun ki insanlar sistemi atlamak yerine genişletsin.
- Sürümleme olsun ki bir değişiklik bir anda bütün sayfaları sessizce değiştirmesin.
- Canlı sitede olup sistemde olmayanların düzenli denetimi — o boşluk sağlık ölçüsüdür.
- Silme. Kullanılmayan bileşenler değer değil maliyettir.

### Daha hafif alternatifler
Tam bir sistem için gerekçe yoksa, tutarlılık faydasının çoğunu yakalayan daha ucuz adımlar var.
| Renk, tipografi ve boşluk için CSS özel özellikleri | Saatler | Her siteye — bu asgari zemin |
| Sitenin içinde tek bir canlı stil kılavuzu sayfası | Bir gün | Ara sıra katkı alan küçük siteler |
| CMS ya da şablon katmanında bileşen kütüphanesi | Günler | Sayfa kuran içerik ekipleri |
| Hafifçe temalandırılmış hazır bir CSS çerçevesi | Günler | İç araçlar ve yönetim ekranları |
| Tam belgelenmiş tasarım sistemi | Haftalar–aylar | Birden çok ürün ya da birden çok ekip |
Gerçek sitenin içindeki canlı bir stil kılavuzu sayfası bir belgeden iyidir: aynı CSS’i kullandığı için gerçeklikten görünür şekilde bozulmadan sapamaz.

Q: Hazır bir tasarım sistemi kullanabilir miyim?
A: Evet ve iç araçlarda genelde doğru seçim — markanın önemi azdır ve anında erişilebilir, test edilmiş bileşenler elde edersiniz. Halka açık bir pazarlama sitesinde takas şudur: siteniz aynı sistemi kullanan diğer sitelere benzer, o yüzden çoğu kurum onu ağır biçimde temalandırır ve o noktada bakım kazancının bir kısmı kaybolur.

Q: Tasarım sisteminin sahibi kim olmalı?
A: Tasarımcı ve geliştiricilerin katkısıyla, adı belli tek bir kişi. Tasarım ve mühendislik arasında paylaşılan sahiplik işbirlikçi görünür ve pratikte kimsenin karar vermemesi demektir; sistem gelişmeyi bırakır ve insanlar etrafından dolaşır. Sahibin her şeyi kurması gerekmez; evet ve hayır demesi gerekir.

Q: Stil kılavuzu ile tasarım sistemi arasındaki fark ne?
A: Stil kılavuzu görünümü belgeler: renkler, yazı tipleri, logo kullanımı. Tasarım sistemi bunu artı çalışan bileşenleri, durumlarını, birleştirme kurallarını ve genelde kodu içerir. Stil kılavuzu size nasıl göründüğünü söyler; tasarım sistemi parçaları verir ve hangisini ne zaman kullanacağınızı söyler.

Q: Bayatlamasını nasıl engellerim?
A: En az direnç gösteren yol yapın ve boşluğu denetleyin. Sistemi kullanmak tek seferlik CSS yazmaktan yavaşsa insanlar tek seferlik CSS yazar. Canlı sitede olup sistemde olmayan bileşenleri düzenli listeleyin: büyüyen bir liste, sistemin sayfa kuran insanlara hizmet etmediği anlamına gelir ve bu, sistemin kendi tasarım sorunudur.

## Website Geliştiricisi Nasıl Olunur: Gerçekçi Bir Yol
https://websitedevelopment.biz/tr/guides/website-gelistiricisi-nasil-olunur
Güncelleme 2026-08-07 · Geliştirici bulma

Website geliştiricisi olmak, belirli ve sonlu bir şeyler kümesini öğrenip ardından işi bitirebildiğinizi kanıtlama meselesidir. Öğrenilecek şeyler iyi belgelenmiş ve ücretsizdir; zor olan kısım birinin size para ödemesi gerektiğine dair kanıt üretmektir.

Bu rehber gerçekçi bir öğrenme sırasını, dürüst süreleri, bir portfolyonun gerçekte neye ihtiyacı olduğunu ve ilk müşterilerin nasıl bulunduğunu ele alıyor.

### Ne öğrenmeli, hangi sırayla
Sıra hızdan önemlidir. Her katman bir sonrakini anlaşılır kılar ve atlamak, çözümleri kopyalayabilen ama sorunları teşhis edemeyen geliştiriciler üretir.
- HTML’i düzgün. Anlamsal işaretleme, formlar, erişilebilirlik. Çalışan geliştiricilerin çoğunda burada boşluk var ve işlerinde görünüyor.
- CSS’i düzgün. Kutu modeli, flexbox, grid, özel özellikler, duyarlı düzen. Yeni başlayan birinin en hızlı gerçekten faydalı hâle gelebileceği yer burası.
- JavaScript temelleri. Herhangi bir çatıdan önce dilin kendisi ve DOM.
- Sürüm kontrolü. Git, dallar, pull request. Herhangi biriyle çalışmak için tartışmaya kapalı.
- Web’in nasıl çalıştığı. HTTP, durum kodları, önbellek, DNS, TLS. Teşhisi tahminden ayıran şey budur.
- Bir back-end dili ve SQL. Yaygın seçeneklerden herhangi biri; kavramlar aktarılabilir.
- Bir CMS ya da çatı, yakınınızda hangi iş varsa ona göre seçilmiş.
- Dağıtım. Bir siteyi alan adı ve sertifikayla gerçek bir hostinge almak.
HTML ve CSS’teki derinlik hafife alınıyor ve anında pazarlanabilir. Hızlı, erişilebilir ve duyarlı arayüzler kurabilen bir geliştirici, üç çatıyı yüzeysel bilen birinden daha kolay iş buluyor.

### Gerçekte ne kadar sürüyor
Haftada 15–20 saatlik düzenli çalışmayla. Tam zamanlı bunu sıkıştırır ve hiçbir şey son satırı sıkıştırmaz.
| HTML ve CSS temelleri | 1–2 ay | Bir tasarımdan durağan bir sayfa kurmak |
| Duyarlı düzen ve JavaScript temeli | 3–5 ay | Etkileşimli küçük bir site kurmak |
| İlk gerçek proje | 5–8 ay | Başkası için bir şey yayına almak |
| İşe alınabilir junior | 8–14 ay | Gözetim altında bir kod tabanına katkı vermek |
| Bağımsız çalışmak | 2–3 yıl | Küçük bir projeyi uçtan uca yürütmek |
| Kıdemli | 5+ yıl | Mimari kararlar almak ve sık sık haklı çıkmak |
İnsanların hafife aldığı adım "başkası için bir şey yayına almak"tır. Kendiniz için kurmak sözdizimi öğretir; bir müşteri için kurmak kapsamı, geri bildirimi, teslim tarihini ve gereksinimlerin değiştiği gerçeğini öğretir.

### Bir portfolyonun neyi göstermesi gerekir
Üç dört tane bitmiş, yayında ve iyi açıklanmış proje, yirmi eğitim kopyasını yener. Değerlendirilen şey işleri bitirip bitirmediğiniz ve kurduğunuz şeyi anlayıp anlamadığınızdır.
- Ekran görüntüsü değil yayında adresler. Biri tıkladığında çalışmalı.
- Proje başına kısa bir yazı: sorun, kararlarınız, neyi farklı yapardınız.
- Ücretsiz de olsa gerçek kullanıcısı olan en az bir gerçek proje — yerel bir işletme, bir dernek, bir vakıf.
- Kalite kanıtı: hızlı, erişilebilir, telefonda çalışıyor. İnsanlar kontrol edecek.
- Kendi siteniz, düzgün yapılmış. İlk bakılan şey ve düzgün yapması en kolay olan şey.
- Okunabilir commit’leri ve nasıl çalıştırılacağını anlatan bir README’si olan açık bir depoda kod.

### İlk müşterileri bulmak
İlk iki üç tanesi zor olanlardır. Ondan sonra işlerin çoğu referansla gelir; yani iyi bitirmek pazarlamadan önemlidir.
- Zaten tanıdığınız insanlarla başlayın. Neredeyse her geliştiricinin ilk ücretli işi böyle geldi.
- Genel olmak yerine bir niş seçin. "Diş kliniklerine website" satması "website"ten çok daha kolaydır.
- Her şeyi sunmak yerine belirli ve pahalı bir sorunu çözün — site hızı, bir erişilebilirlik denetimi, bir taşıma.
- Küçük bir tutar da olsa ilk projeden itibaren ücret alın. Ücretsiz iş ona göre değerlenir ve sınırsız kapsam çeker.
- İş ne kadar küçük olursa olsun başlamadan önce kapsamı ve ödeme koşullarını yazın.
- Düzgün bitirin: devir, dokümantasyon, bakım teklifi. İkinci müşteriyi üreten şey budur.
- Referansı müşterinin en memnun olduğu anda isteyin, ki bu yayından hemen sonrasıdır.

Q: Bilgisayar mühendisliği diploması şart mı?
A: Hayır ve çalışan web geliştiricilerinin büyük bir kısmında yok. Diploma bazı büyük kurumlarda ve web geliştirmeden çok bilgisayar bilimine yakın rollerde yardımcı olur. Website işlerinin çoğu için bitmiş projelerin kanıtı diplomadan önemlidir — ama bir diplomanın vereceği temellere, başka bir yoldan öğrenilmiş olarak, ihtiyacınız var.

Q: Önce front-end mi back-end mi?
A: Neredeyse her durumda front-end. Sonuçları hemen görürsünüz, bu motivasyonu ayakta tutar ve birine faydalı olmanın en kısa yoludur. Arayüzleri düzgün kurabildiğinizde back-end kavramları daha kolay öğrenilir, çünkü verinin ne işe yaradığını zaten anlıyorsunuzdur.

Q: Başlamak için geç mi kaldım?
A: Hayır ve kariyer değiştirenler sıkça iyi iş çıkarıyor, çünkü başkasında olmayan bir alan bilgisi getiriyorlar — muhasebeciler için kuran muhasebeciler, okullar için kuran öğretmenler. Junior genelciler pazarı rekabetçidir; belirli bir sektörü anlayan ve kurabilen birinin pazarı çok daha az rekabetçidir.

Q: Erken bir çatı öğrenmeli miyim?
A: Önce temelleri öğrenin. Çatılar birkaç yılda bir değişiyor ve neyi soyutladıklarını anladığınızda öğrenmesi çok daha kolay. Altındaki dili öğrenmeden çatı öğrenen geliştiriciler o çatının kalıpları içinde etkili, dışında sıkışmış oluyor ve o tavan hızla geliyor.

## CMS Nedir ve Gerçekten İhtiyacınız Var mı?
https://websitedevelopment.biz/tr/guides/cms-nedir
Güncelleme 2026-08-07 · CMS

İçerik yönetim sistemi, kod yazmayan insanların sayfa oluşturup değiştirmesini sağlar. Bütün değer önerisi budur ve gerçek bir değerdir — ama bedava değildir, çünkü bir CMS site var oldukça barındırılması, güncellenmesi ve güvenliği sağlanması gereken bir yazılımdır.

Bu rehber bir CMS’in size gerçekte ne verdiğini, ne zaman bu yüke değdiğini ve değmediğinde ne kullanacağınızı ele alıyor.

### Bir CMS neyi sağlar
"Sayfa düzenlemek"in ötesinde, satın aldığınız yetenekler bunlar — ve listelemeye değer, çünkü CMS kararlarının çoğu hangilerine ihtiyacınız olduğuna bakılmadan veriliyor.
- Dağıtım olmadan düzenleme. Metni değiştirip anında yayımlamak.
- Yapılandırılmış içerik. Bir HTML yığını yerine alanlar, böylece içerik yeniden kullanılabilir ve tutarlı çizilir.
- Medya yönetimi. Bir kez yükleyin, her yerde kullanın, otomatik yeniden boyutlandırmayla.
- Kullanıcılar ve yetkiler. Farklı haklarla yazarlar, editörler, onaycılar.
- İş akışı. Taslak, önizleme, zamanlama, sürüm geçmişi.
- Arama ve gezinme içerikten otomatik üretiliyor.
- Genişletilebilirlik. Bir ekosistem üzerinden formlar, ticaret, çeviriler.
Bu listeden yalnız ilk maddeye ihtiyacınız varsa ve yılda iki kez tek bir kişi değişiklik yapıyorsa, CMS küçük bir iş için büyük bir makinedir.

### Başta kimsenin söz etmediği yük
CMS çalışan bir uygulamadır; yani kimse siteyi düzenlemese bile süregelen bir maliyet profili vardır.
| Güvenlik yaması | Yaygın sistemler sürekli yoklanıyor; güncellemeler isteğe bağlı değil |
| Eklenti bakımı | Her eklenti başka bir güncelleme ve olası bir açıktır |
| Hosting | Veritabanı destekli bir uygulama statik dosyalardan fazlasını ister |
| Performans işi | Dinamik sayfaların hızlı olması için önbellek gerekir |
| Sürüm yükseltmeleri | Ana sürümler tema ve özelleştirmeleri bozabilir |
| Eğitim | Editörlerin düzeni bozmadan kullanmayı bilmesi gerekir |

### Ne zaman gerekir, ne zaman gerekmez
Belirleyici faktör, değişiklik sıklığı ile değişiklik yapması gereken kişi sayısının çarpımıdır.
| Haftalık yayın yapan pazarlama ekibi | Evet — CMS tam olarak bunun içindir |
| Yılda iki kez değişen beş sayfalık site | Hayır — statik site daha ucuz ve daha güvenli |
| Geliştiricilerin baktığı dokümantasyon | Hayır — sürüm kontrolündeki dosyalar daha iyi çalışıyor |
| Online mağaza | Evet ve genel bir CMS değil bir ticaret platformu |
| Kampanya iniş sayfaları | Evet — yayınlama hızı bütün mesele |
| Birkaç içerik türü ve çeviri olan site | Evet — yapı, CMS’in iyi olduğu şeydir |

### Alternatifler
Nadiren değişen siteler için çok daha düşük işletme maliyeti ve neredeyse hiç saldırı yüzeyi olmayan seçenekler var.
- Statik site üreteci. İçerik dosyalarda, HTML’e derlenir, bir CDN’e dağıtılır. Hızlı, ucuz ve saldıracak neredeyse hiçbir şey yok — ama bir düzenleme katmanı eklemedikçe düzenleme teknik bir akış ister.
- Statik üreteç artı git tabanlı editör. Dosyaların üstünde teknik olmayan düzenleme, statik çıktıyı koruyarak.
- Headless CMS artı statik üretim. Editörler dostane bir arayüz alır; halka açık site yine statiktir.
- Elle yazılmış HTML. Gerçekten hiç değişmeyen küçük bir tanıtım sitesi için gayet makul.
- Site kurucu. Ürün zaten düzenlemenin kendisidir; takas taşınabilirlik ve performanstır.
Statik yol bütün bir risk kategorisini kaldırır: enjekte edilecek bir veritabanı ve kaba kuvvet denenecek bir yönetici girişi yoktur. Ayda bir değişen bir site için bu anlamlı bir tasarruftur.

Q: WordPress varsayılan seçim mi?
A: En yaygını ve yaygınlık büyük bir ekosistem, onu bilen çok sayıda insan ve buna karşılık saldırganlardan gelen orantılı miktarda otomatik ilgi getiriyor. İçerik odaklı sitelere iyi uyar. Uygulamalar, karmaşık ticaret ya da içeriği sayfalardan çok yapılandırılmış veri olan siteler için otomatik olarak doğru değildir.

Q: CMS ile site kurucu arasındaki fark ne?
A: CMS içeriği yönetir ve sunumu genelde sizin ya da bir geliştiricinin kontrol ettiği şablonlara bırakır. Kurucu, içeriği ve düzeni tek bir görsel düzenleme aracında birleştirir. Kurucular teknik olmayan kullanıcılar için daha hızlı ve terk etmesi daha zordur, çünkü düzen kararları sahip olduğunuz kodda değil ürünün içinde yaşar.

Q: Mevcut bir statik siteye CMS ekleyebilir miyim?
A: Evet ve bu yaygın bir yükseltme yolu — ya mevcut şablonlara içerik sağlayan bir headless CMS ya da mevcut dosyaların üstünde git tabanlı bir düzenleme katmanı. Genelde tam bir taşımadan daha az iştir, çünkü şablonlar ve URL’ler yerinde kalır.

Q: Kaç eklenti fazla sayılır?
A: Sabit bir sayı yok, ama her eklenti uygulanacak bir güncelleme, olası bir çakışma ve olası bir açıktır. İşe yarar bir disiplin: her birini kazandırdığı şeye karşı gerekçelendirin. Yılda bir saat kazandırıyor ve üç ayda bir ilgi istiyorsa size maliyet çıkarıyordur. Kırk eklentili siteler neredeyse her zaman kimsenin açıklayamadığı birkaç tanesini taşıyor.

## İşe Almadan Önce Bir Web Geliştiriciye Sorulacak Sorular
https://websitedevelopment.biz/tr/guides/web-gelistiriciye-sorulacak-sorular
Güncelleme 2026-08-07 · Geliştirici bulma

İlk görüşmede sorulan soruların çoğu teknolojiyle ilgili ve teknoloji, projenin başarılı olup olmayacağı açısından en az önemli parçadır. Sonuçları öngören sorular süreç, mülkiyet ve bir şey ters gittiğinde ne olduğuyla ilgilidir.

Bu rehber o soruları, neyi ortaya çıkardıklarına göre gruplanmış hâlde ve iyi bir cevabın neye benzediğine dair bir notla veriyor.

### İşin kendisi hakkında
Bunlar, projenizi anlayıp anlamadıklarını ya da standart tekliflerini mi anlattıklarını ortaya çıkarır.
| İşimizle ilgili ne sormak istersiniz? | Herhangi bir şey. Buradaki sessizlik en güçlü olumsuz sinyaldir |
| Bizim ölçeğimizde yayında bir site gösterin | Görsel değil bir adres; tercihen vitrin işleri değil |
| Mevcut sitemizde neyi farklı yapardınız? | Somut gözlemler, yani gerçekten bakmışlar |
| Bu projenin en riskli parçası ne? | Dürüst bir cevap — genelde içerik ya da entegrasyonlar |
| Bu teklife neler dahil değil? | Kolayca sunulan somut bir liste |
| Ne kadar sürer ve bunu ne belirliyor? | Tek bir sayı değil, bağımlılıkları olan bir takvim |

### Süreç hakkında
Bunlar, tekrarlanabilir bir çalışma biçimi olan geliştiricileri doğaçlama yapanlardan ayırır.
- Kod nerede saklanıyor ve ilk günden erişimimiz olacak mı?
- Bir değişiklik sizin makinenizden yayındaki siteye nasıl gidiyor?
- İşi yayına girmeden nerede inceliyoruz?
- İlerlemeyi ne sıklıkla ve hangi biçimde göreceğiz?
- İşi tam olarak kim yapacak ve o kişi müsait olmazsa ne olur?
- Nasıl test ediyorsunuz — tarayıcılar, cihazlar, erişilebilirlik, performans?
- Bizden neye ve ne zamana kadar ihtiyacınız var?
Dağıtım sorusu en açıklayıcı olanıdır. Dosyaları bir FTP istemcisine sürüklemeyi içeren bir cevap, sürüm kontrolü, staging ve geri alma olmadığını söyler.

### Sonrasında ne olacağı hakkında
Sunum sırasında kimsenin sormadığı ve altı ay sonra herkesin önemsediği dönem.
- Yayından sonra kodun, alan adının ve hosting hesaplarının sahibi kim?
- Yayından sonra hangi destek dahil, ne kadar süreyle ve neye kusur deniyor?
- Sonrasında küçük bir değişiklik ne tutuyor ve ne kadar sürüyor?
- Bakım sunuyor musunuz, içinde ne var ve bir rapor alıyor muyuz?
- Birlikte çalışmayı bırakırsak neyi ve ne kadar sürede alırız?
- Başka bir geliştirici bunu devralabilir mi? Hangi dokümantasyon var?
- Site hangi üçüncü taraf hizmetlere bağımlı olacak ve ücretlerini kim ödüyor?

### Konuşmayı bitirmesi gereken cevaplar
Nadir ama hemen tanınmaya değer.
| "İlk sayfa sıralaması garanti ederiz" | Kimse edemez; ya bilgisizlik ya dürüstlük eksikliği |
| "Alan adını biz kendi hesabımızda tutuyoruz" | Sizi rehin alır |
| "Staging’e gerek yok, biz dikkatliyiz" | Herkes dikkatlidir; bu bir süreç değildir |
| "Küçük sitelerde sürüm kontrolü kullanmıyoruz" | Geçmiş yok, geri alma yok, ikinci geliştirici yok |
| "Fiyat yalnız bugün imzalarsanız geçerli" | Baskı taktikleri çalışma ilişkisini öngörür |
| Ayrıntısız "SEO dahil" | Ya anlamsız ya ima edilen ayrı bir hizmet |
| "Ayrıntıları yol boyunca çözeriz" | Sabit fiyatta bu sizin sorununuza dönüşür |

Q: En faydalı tek soru hangisi?
A: "Bir değişiklik sizin makinenizden yayındaki siteye nasıl gidiyor?" Yetkin herkes bunu tek cümleyle cevaplar ve cevap, sürüm kontrolünün, staging’in, incelemenin ve geri almanın var olup olmadığını ortaya çıkarır. Süreç listesindeki diğer her şey genelde bir yönde ya da diğerinde bunu takip eder.

Q: Belirli teknolojileri sormalı mıyım?
A: Yalnız gerçek bir kısıtınız varsa — mevcut bir sistem, ekibinizin zaten kullandığı bir platform. Aksi hâlde teknoloji onların kararıdır ve sormak, etkileyici olmak için tasarlanmış bir cevap davet eder. Hangi sonuçları ürettiğini sorun: ne kadar hızlı, ne kadar bakılabilir, başka kim üzerinde çalışabilir.

Q: Bir referansı düzgün nasıl kontrol ederim?
A: Memnuniyeti değil bir sorunu sorun: "ne ters gitti ve bunu nasıl yönettiler?" Her projede bir şey olur. Hiçbir şey söyleyemeyen bir referans ya çok küçük bir proje yaşamıştır ya açık davranmıyordur. Ayrıca daha büyük bir proje için onları tekrar kullanıp kullanmayacaklarını sorun; bu, memnun olup olmadıklarından daha keskin bir sorudur.

Q: Mülkiyet ve fesih sormak kabalık mı?
A: Hayır ve profesyonel bir tedarikçi bunu bekler. İki taraf da nerede durduğunu bilmekten kazanır ve cevaplar kısadır. Bu sorulardan rahatsızlık kendi başına bir bilgidir — genelde standart düzenlemenin size olması gerekenden daha az elverişli olduğu anlamına gelir.

## Website Erişilebilirliği: Önce Neyi Düzeltmeli
https://websitedevelopment.biz/tr/guides/website-erisilebilirlik-rehberi
Güncelleme 2026-08-07 · Web tasarım

Erişilebilirlik çalışmasının uzun bir kontrol listesi ve gerçek engellerin çoğunu oluşturan kısa bir listesi vardır. Kısa listeden başlamak gerçek kullanıcıları hızla sitenize alır; tam denetimle başlamak genelde kimsenin uygulamadığı bir belge üretir.

Bu rehber önce neyi düzelteceğinizi, bir öğleden sonrada kendinizin nasıl test edebileceğinizi ve overlay eklentilerinin neden satıldıkları kısayol olmadığını ele alıyor.

### En büyük etkiyi yaratan düzeltmeler
Bunlar insanların işlerini biraz zorlaştıran değil tamamen engelleyen bariyerlerdir. Daha uzun bir listedeki hiçbir şeyden önce bunları düzeltin.
- Klavye erişimi. Her etkileşimli öğeye Tab ile ulaşılabilsin, Enter ya da Space ile çalıştırılabilsin, mantıklı bir sırayla ve görünür bir odak halkasıyla. Siteyi yalnız fareyle kullanabiliyorsanız bu listedeki hiçbir şeyin önemi yok.
- Metin alternatifleri. Bilgi taşıyan görsellerde anlamlı alt metin; dekoratif olanlarda boş alt. Eksik alt ile boş alt aynı şey değildir.
- Form etiketleri. Her alana bağlı gerçek bir <label>. Yer tutucu metin etiket değildir — yazmaya başlayınca kaybolur ve güvenilir biçimde okunmaz.
- Kontrast. Gövde metni 4,5:1, büyük metin ve denetimler 3:1, gerçek arka plana karşı ölçülmüş.
- Başlıklar. Tek H1, atlanmış seviye yok. Ekran okuyucu kullanıcıları en çok başlıkla geziyor.
- Bağlantı metni. On dört kez tekrarlanan "devamını oku", ekran okuyucu kullanıcısına on dört özdeş hedef verir. Nereye gittiğini söyleyin.
- Hata mesajları. Alanın yanında, metin olarak, ne yapılacağını anlatarak — yalnız renkle değil, yalnız kırmızı çerçeveyle değil.

### Bir öğleden sonrada kendiniz test edin
Sorunların çoğunu bulmak için özel yazılım gerekmiyor. Bu beş geçiş orta ölçekli bir sitede bir iki saat sürer ve gerçek engellerin çoğunu bulur.
| Yalnız klavye | Fareyi çıkarın, her sayfada Tab ile gezin | Tuzaklar, görünmez odak, erişilemeyen denetimler |
| %200 yakınlaştırma | Sayfa zoom’u değil tarayıcı yazı boyutu | Kırpılan metin, yatay kaydırma, bozulan düzen |
| Ekran okuyucu | Ana şablonlarda VoiceOver ya da NVDA | Eksik etiketler, anlamsız bağlantılar, duyurulmayan değişiklikler |
| Otomatik tarama | Tarayıcıda axe ya da Lighthouse | Kontrast, eksik alt, ARIA hataları — sorunların yaklaşık %30’u |
| Gri tonlama | Tarayıcı filtresi ya da işletim sistemi ayarı | Yalnız renkle aktarılan her şey |
Otomatik araçlar erişilebilirlik sorunlarının kabaca üçte birini bulur. Başlangıç noktasıdır, geçme notu değil — Lighthouse’ta 100 alan bir site klavyeyle hâlâ kullanılamaz olabilir.

### En çok soruna yol açan kalıplar
Erişilebilirlik genelde özel bileşenlerde kırılır, çünkü yerleşik öğeler hazır davranışla gelir ve özel olanların bunu yeniden yazması gerekir.
- Div’lerden kurulmuş özel açılır listeler, klavye desteği ve rol olmadan. Yerleşik <select> bedava ve her yerde çalışıyor.
- Odağı hapsetmeyen, Escape ile kapanmayan ve arka planı kaydırılabilir bırakan modaller.
- Duraklatma denetimi olmadan otomatik ilerleyen karuseller — yalnız engelli kullanıcılara değil neredeyse herkese düşmanca.
- Erişilebilir adı olmayan yalnız ikonlu düğmeler. Etiketsiz bir X "düğme" olarak okunur.
- Footer’a ulaşmanın yolu olmayan sonsuz kaydırma.
- Div çorbası: düğme ve bağlantı yerine tıklanabilir div’ler — tek hamlede hem klavye desteğini hem anlamı kaldırıyor.
- prefers-reduced-motion’u yok sayan hareket.
En ucuz erişilebilirlik stratejisi, iş için doğru yerleşik HTML öğesini kullanmaktır. Her özel yedek, bedava gelen davranışı yeniden yazma sözüdür.

### Overlay eklentileri neden çözüm değil
Erişilebilirlik overlay’leri tek bir betikten uyumluluk vaat eder. Bunu veremezler, çünkü alttaki sorunlar yapısaldır: bir betik bir görselin ne gösterdiğini bilemez, alanın amacına uyan bir form etiketi yazamaz ve özel bir bileşendeki klavye tuzağını onaramaz.

Ayrıca insanların zaten kullandığı ve ayarladığı yardımcı teknolojiye karışırlar; bir dizi engelli örgütünün bunlara karşı uyarmasının sebebi budur. Onları bilmeye değer, çünkü savunulabilir bir gerekçeyle reddedebilesiniz.
- Doğru alt metin üretemezler, çünkü görselin bağlamdaki anlamını bilmezler.
- Kendi yazmadıkları bileşenlerdeki klavye tuzaklarını düzeltemezler.
- Kullanıcının kendi ekran okuyucu ayarlarıyla sık sık çakışırlar.
- Hukuki riski kaldırmazlar — alttaki engeller hâlâ oradadır.
- O para bu sayfanın başındaki yedi düzeltmeye harcansa daha iyi olur.

Q: Erişilebilirlik hukuken zorunlu mu?
A: Pek çok yargı alanında kamu kurumları için evet ve giderek özel işletmeler için de — Avrupa Erişilebilirlik Yasası, ABD’de web sitelerine uygulandığı biçimiyle ADA ve başka ülkelerdeki karşılıkları. Yükümlülükler ülkeye ve sektöre göre değişir, o yüzden yerel duruma bakın. Pratik durum şu: neredeyse her düzenleme WCAG 2.2 AA’yı işaret ediyor.

Q: Erişilebilirlik yapıma ne kadar ekler?
A: Baştan tasarlanınca çok az — çoğunlukla anlam, kontrast ve odak durumları konusunda disiplin. Bitmiş özel bir siteye sonradan eklendiğinde ciddi bir proje olabilir, çünkü düzeltmeler kozmetik değil yapısaldır. Bu fark, konuyu yayından sonra değil brief’te gündeme getirmenin bütün gerekçesidir.

Q: WCAG A, AA ve AAA arasındaki fark ne?
A: Bunlar uygunluk seviyeleridir. A asgaridir ve gerçek engelleri yerinde bırakır; AA düzenlemelerin genelde istediği ve çoğu kurumun hedeflediğidir; AAA ise her içerik için ulaşılabilir olmayan ölçütler içerir — örneğin bazı marka paletlerinin karşılayamayacağı 7:1 kontrast şartı. AA’yı hedefleyin ve AAA’yı hedef değil ölçüt bazında bir iyileştirme olarak görün.

Q: Erişilebilirlik SEO’ya yardım eder mi?
A: Dolaylı ve gerçekten eder. Düzgün başlık yapısı, açıklayıcı bağlantı metni, alt nitelikleri, gerçek anlamsal işaretleme ve hızlı, sabit sayfalar ikisine de yarıyor. Ama örtüşme kısmi: bir site iyi sıralanıp klavyeyle hâlâ kullanılamaz olabilir. Erişilebilirlik çalışmasını insanlar siteyi başka türlü kullanamadığı için yapın ve SEO faydasını yan etki olarak alın.

## Website Geliştirme Sözleşmesi: İmzalamadan Önce Neye Bakmalı
https://websitedevelopment.biz/tr/guides/website-gelistirme-sozlesmesi
Güncelleme 2026-08-07 · Geliştirici bulma

Bir website geliştirme sözleşmesi tam olarak iki durumda önem taşır: proje kötü gittiğinde ve ilişki bittiğinde. İkisi de öngörülebilir ve az sayıda madde bunların size ne kadara mal olacağını belirler.

Bu rehber imzalamadan önce neye bakacağınızı, her maddenin sizi neye karşı koruduğunu ve pazarlığa değen koşulları ele alıyor.

### Mülkiyet: sonradan düzeltilemeyen madde
Bir sözleşmedeki diğer her şey yeniden pazarlık edilebilir. İlişki kötü bittikten sonra mülkiyet edilemez.
- Son ödemeyle birlikte kaynak kodun sahibi siz olursunuz, süregelen bir lisans koşulu olmadan.
- Alan adı, geliştiricinin değil kurumunuzun adına ve sizin fatura bilgilerinizle kayıtlıdır.
- Hosting ve üçüncü taraf hesaplar sizin adınıza, geliştirici kullanıcı olarak eklenmiş biçimde.
- Sağladığınız içerik, görsel ve metin sizde kalır; onların ürettiklerini ayrıca sorun.
- Üçüncü taraf lisansları — yazı tipleri, eklentiler, stok görseller — devredilir ya da kendinizinkini alabilmeniz için listelenir.
- Herhangi bir kod sahip olunan değil lisanslanan bir koda dayanıyorsa, koşullarıyla birlikte açıkça yazılır.
- Fesihte kodu, veritabanını ve kimlik bilgilerini belirtilen bir süre içinde alırsınız.
Aranacak cümle şu: "son fatura ödendiğinde kodun sahibi sizsiniz." "Siteyi kullanmanız için size bir lisans veriyoruz" farklı bir düzenlemedir ve bunu seçtiğinizi bilmelisiniz.

### Kapsam, değişiklikler ve revizyonlar
Anlaşmazlıkların çoğu başka bir ad takmış kapsam anlaşmazlıklarıdır. Bu maddeler anlaşmazlığın bedelini kimin ödeyeceğine karar verir.
| İş kapsamı | Bir paragraf değil, ek olarak konmuş somut bir liste |
| Kapsam dışı | Açık bir hariç tutma listesi — içerik, fotoğraf, giriş, SEO |
| Değişiklik süreci | Kim talep eder, kim fiyatlar, nasıl onaylanır, tarihe etkisi |
| Revizyon turları | Bir sayı ve ek bir turun maliyeti |
| Kabul | Neyin onay sayıldığı ve incelemek için ne kadar süreniz olduğu |
| Müşteri yükümlülükleri | Neyi ne zaman sağlamanız gerektiği ve geç kalırsa etkisi |
| Gecikme | Her iki tarafta da ne olduğu — bu tek yönlü olmamalı |

### Ödeme, yayın ve destek
Görebileceğiniz şeylere bağlı ödeme iki tarafı da korur; düşmanca bir talep değildir.
- Yalnız tarihlere değil, inceleyebileceğiniz teslimatlara bağlı kilometre taşı ödemeleri.
- %30–50 kapora normaldir; iş başlamadan tamamını ödemek değildir.
- Son ödeme, doğrulayamayacağınız bir iç onaya değil yayına bağlı olsun.
- Kusurların düzeltilmesi için tanımlı bir yayın sonrası dönem — genelde 30 ile 90 gün — ve kusurun ne demek olduğu.
- Kusur (onlar düzeltir) ile yeni talep (siz ödersiniz) arasındaki fark örneklerle yazılmış olsun.
- Sitenin çökmesi işinizi etkiliyorsa önem derecesine göre yanıt süreleri.
- Bakımın dahil mi, isteğe bağlı mı yoksa hiç olmadığı — ve sonradan alırsanız fiyatı.

### Fesih ve unutulan şeyler
Yalnız bir kez önem taşıyan ve o zaman çok önem taşıyan maddeler.
| İhbar süresi | İki taraf da makul bir bildirimle çıkabilmeli |
| Fesihte ödeme | Tamamlanmış ama teslim edilmemiş iş için ne borçlu olduğunuz |
| Devir | Kod, veritabanı, kimlik bilgileri ve dokümantasyon, belirtilen sürede |
| Sorumluluk sınırı | Genelde sözleşme bedeli; ne olduğunu bilin |
| Veri koruma | Sizin adınıza kişisel veri işliyorlarsa gerekli |
| Gizlilik | Karşılıklı ve fesihten sonra da sürmeli |
| Portfolyo hakkı | İşi göstermek isteyecekler; koşulları şimdi anlaşın |
| Uygulanacak hukuk | Yurt dışı bir tedarikçide çok önem taşıyor |
| Uyuşmazlık süreci | Davadan önce arabuluculuk iki tarafa da para kazandırıyor |
Net bir fesih maddesinden rahatsız olmayan bir tedarikçi, genelde ilişkinin iyi gitmesini bekleyen bir tedarikçidir. Buna direnç sorulmaya değer.

Q: Website sözleşmesi için avukat gerekir mi?
A: Küçük bir proje için yukarıdaki noktaları kapsayan net bir yazılı anlaşma genelde orantılıdır. Ciddi bir iş için — bir mağaza, bir uygulama ya da kaybı gerçekten canınızı yakacak bir yapım — birkaç saatlik hukuki inceleme risk altındaki değere göre ucuzdur. En azından, proje konusunda hevesli olmayan birine okutun.

Q: Alan adını geliştiricinin tutması normal mi?
A: Yaygın ve sizin yararınıza değil. Alan adı, sizin fatura bilgilerinizle kurumunuz adına kayıtlı olmalı; erişim gerekiyorsa geliştiriciyi teknik iletişim olarak ekleyin. Eski bir tedarikçinin elindeki alan adları bu sektörün en güvenilir biçimde acı veren durumlarından biridir.

Q: Makul bir kapora nedir?
A: Yüzde otuz ile elli, kalanı kilometre taşları ve yayına yayılmış olarak. Kapora meşrudur — tedarikçinin sizin ortadan kaybolma riskini karşılar. Tamamını peşin ödemek riskin tamamını size taşır ve iş %80’de takıldığında elinizde hiçbir koz bırakmaz.

Q: Proje gecikirse ne olur?
A: Sözleşme gecikmeyi iki taraf için de ele almalı, çünkü gecikme çok sık müşteri tarafındaki içerik ve kararlardan kaynaklanıyor. Bunları ayıran ve sonucunu yazan bir madde arayın. Ceza maddeleri güven verici gelir ve genelde yalnız fiyatı yükseltir, çünkü tedarikçi riski fiyatlar.

## Website Yayına Alma Kontrol Listesi: Canlıya Geçmeden Önce
https://websitedevelopment.biz/tr/guides/website-yayina-alma-kontrol-listesi
Güncelleme 2026-08-07 · Website planlama

Yayın günü sorunları neredeyse hiç egzotik olmaz. Arama motorlarına açık bırakılmış bir staging kopyası, kimsenin okumadığı bir adrese giden bir iletişim formu ve yönlendirmesi olmayan eski bir URL yapısıdır.

Bu kontrol listesi canlıya geçmeden önce neyi doğrulayacağınızı — bir yayının gerçekte olduğu sırayla — ve ilk saatte ve ilk haftada neye bakacağınızı ele alıyor.

### Yayından önce: teknik
Bunlar dışarıdan fark edilmesi zor ve geç keşfedilmesi pahalı kontrollerdir.
- HTTPS her sayfada çalışıyor ve HTTP ona 301 ile yönleniyor.
- Tek kanonik host: www ya da www’suz, diğeri yönleniyor. İkisi birden içerik sunmuyor.
- Staging şifreli ya da engelli ve oradaki noindex canlıya KOPYALANMAMIŞ.
- Canlıdaki robots.txt taramaya izin veriyor. Bu, en yaygın yayın hatasıdır.
- Bir 404 sayfası var, gerçekten 404 durum kodu döndürüyor ve bir çıkış yolu sunuyor.
- Formlar gönderiliyor, kaydı saklıyor ve bildirimi birinin okuduğu bir adrese yolluyor.
- Yedekler kurulu ve bir geri yükleme test edilmiş. Test edilmemiş yedek yedek değildir.
- Hata kaydı açık ve uyarıları alan biri var.
Yalnız sayfalara değil durum kodlarına bakın. HTTP 200 döndüren bir "404 sayfası", arama motorlarına her yanlış yazılmış adresin gerçek bir sayfa olduğunu söyler.

### Yayından önce: içerik ve SEO
İçerik kontrolleri hızlıdır ama ziyaretçilerin ilk fark ettikleri onlardır; SEO kontrolleri ise sonradan düzeltmesi acı olanlardır.
- Her sayfanın üzerinde ne olduğunu yansıtan benzersiz bir başlığı ve açıklaması var.
- Hiçbir yerde yer tutucu metin, "Lorem ipsum" ya da "[müşteri adı]" kalmamış.
- Her görselin anlamlı bir alt metni var — dekoratif görsellerde eksik değil boş alt.
- Başlık yapısı düzgün: sayfa başına bir H1, H1’den H4’e atlama yok.
- Tüm iç bağlantılar çalışıyor; staging alan adına bağlantı yok.
- XML site haritası üretiliyor, yalnız indekslenebilir URL’leri listeliyor ve robots.txt’te belirtiliyor.
- Trafiği ya da bağlantısı olan her eski URL için yönlendirme çıkarılmış ve test edilmiş.
- Yapısal veri taşıyan şablonlarda doğrulanıyor.
- Open Graph etiketleri, adres bir sohbet uygulamasına yapıştırıldığında düzgün bir önizleme veriyor.

### Yayından önce: hukuk, analitik ve erişilebilirlik
"Yayından sonra" bırakılan ve sonra hiç yapılmayan kısımlar.
| Gizlilik politikası | Var, gerçekten topladığınız veriyi doğru anlatıyor, her sayfadan bağlantılı |
| Çerez onayı | Zorunlu olmayan çerez kuruyorsanız gerekli; onaya kadar engelliyor |
| Koşullar ve künye | Yargı alanınızın gerektirdiği yerde mevcut |
| Analitik | Bir kez kurulmuş, tüm sayfalarda tetikleniyor, birincil eylem için hedef tanımlı |
| Search Console | Mülk doğrulanmış ve yayın günü site haritası gönderilmiş |
| Klavye erişimi | Her etkileşimli öğeye Tab ve Enter ile ulaşılıyor ve çalıştırılıyor |
| Kontrast | Gövde metni ve denetimler arka planlarına karşı WCAG AA’yı geçiyor |
| Yakınlaştırma | Sayfa %200 yazı boyutunda yatay kaydırmasız kullanılabiliyor |

### İlk saat ve ilk hafta
Yayın bir an değil bir penceredir. Kontrol listesini geçen sorunların çoğu ilk saatte, SEO sorunları ise sonraki günlerde ortaya çıkar.
- Ana sayfayı ofis ağından değil, mobil veriyle bir telefondan açın.
- Ana formu kendiniz gönderin ve bildirimin ulaştığını doğrulayın.
- Biri derin olmak üzere beş eski URL’nin doğru yönlendiğini kontrol edin.
- Analitiğin kendi ziyaretinizi kaydettiğini doğrulayın, sonra kendi trafiğinizi hariç tutun.
- Search Console’a site haritasını gönderin ve öne çıkan sayfalar için indeksleme isteyin.
- İlk saat sunucu hata kayıtlarını izleyin — yeni trafik yeni hatalar ortaya çıkarır.
- Bir hafta sonra: Search Console kapsamında beklenmeyen dışlamalara ve tarama hatalarına bakın.
- Bir hafta sonra: trafiği eski siteyle karşılaştırın ve ağır kayıp veren sayfaları inceleyin.
Cuma öğleden sonra yayına almayın. Bir şey bozulursa düzeltebilecek kişiler iki gün yok ve sorun katlanarak büyür.

Q: En yaygın yayın hatası nedir?
A: Staging’den canlıya taşınan bir robots.txt ya da noindex meta etiketi. Site ziyaret eden herkese kusursuz görünür ve arama motorlarına görünmezdir; genelde haftalar sonra biri "trafik neden hiç gelmedi" diye sorduğunda fark edilir. Yayın günü, kendi ağınızın dışından, canlıdaki robots.txt ve meta robots etiketini kontrol edin.

Q: Eski URL’leri yönlendirmem gerekir mi?
A: Eski sitenin herhangi bir trafiği ya da gelen bağlantısı olduysa evet. Her eski URL’yi en yakın karşılığına 301 ile eşleyin. Hepsini ana sayfaya yönlendirmek, birikmiş sıralama sinyalleri açısından sayfaları silmekle aynı şeydir ve eski bir bağlantıyı takip eden herkes için kötü bir deneyimdir.

Q: Yenilemeden sonra arama trafiği ne zaman toparlanır?
A: Temiz yönlendirme ve eşdeğer içerikle, işler oturmadan önce genelde iki ile altı hafta dalgalanma olur. İlk iki haftadaki düşüş normaldir. Bir ay sonra hâlâ derinleşen bir düşüş genelde teknik bir sorunu gösterir — eksik yönlendirme, engellenmiş tarama ya da kimsenin fark etmeden çıkardığı içerik.

Q: Her şeyi birden mi yoksa aşamalı mı yayına almalıyım?
A: Site değişimi için hepsi birden genelde daha basittir: iki siteyi paralel çalıştırmak bağlantılarınızı böler ve kopya içerik sorunu yaratır. Mevcut bir sitedeki yeni bölümler için aşamalı olmasında sakınca yok. Yapmamanız gereken şey, yapının yarısını yayına alıp gelecek olanın URL’lerini planlamadan geri kalanını sonra eklemektir.

## Freelance, Ajans mı İç Ekip mi? Projenize Hangisi Uyar
https://websitedevelopment.biz/tr/guides/freelance-ajans-mi-ic-ekip-mi
Güncelleme 2026-08-07 · Geliştirici bulma

Aynı website’i tek bir freelancer, bir ajans ekibi ya da istihdam ettiğiniz biri kurabilir. Çıktı benzer olabilir; risk profili, maliyet ve ikinci yılda olanlar olmaz.

Bu rehber üçünü gerçekten farklılaşan etkenlere göre karşılaştırıyor ve çoğu kurumun sonunda kullandığı melez düzenlemeleri ele alıyor.

### Önemli olan karşılaştırma
Maliyet bariz eksendir ve nadiren belirleyicidir. Süreklilik genelde belirleyicidir.
| Tek proje maliyeti | En düşük | En yüksek | Tek projeyse yüksek |
| Yıllar içindeki maliyet | Düşük | Orta–yüksek | Sürekli iş varsa en düşük |
| Başlama hızı | Hızlı | Daha yavaş — sıraya giriyor | En yavaş — işe alım |
| Beceri genişliği | Dar–orta | Geniş | Kimi işe aldıysanız |
| Süreklilik riski | Yüksek — tek kişi | Düşük | Orta — ayrılabilirler |
| Süreç ve kalite kontrol | Çok değişken | Genelde kurumsallaşmış | Ne kurarsanız o |
| İş bilgisi | Zamanla artıyor | Ekip içinde paylaşılıyor | En derini |
| Kime uyar | Tanımlı projeler, süregelen küçük işler | Büyük projeler, çoklu beceri | Sürekli ürün işi |

### Freelancer durumu, dürüstçe
İyi bir freelancer, iyi tanımlanmış bir proje için mevcut en iyi değerdir ve düzenlemenin görmezden gelmek yerine etrafında planlanacak belirli bir arıza biçimi vardır.
- Avantaj: işi yapan kişiyle konuşuyorsunuz; bir hesap yönetimi katmanı ve onun üzerine binen kâr marjı yok.
- Risk: hastalık, başka bir müşteri ya da yoluna devam etme. Tek kişilik bir tedarikçinin yedeği yoktur.
- İşe yarayan önlemler: ilk günden sizin deponuzda kod, belgelenmiş dağıtım, sizin adınıza hesaplar ve projeyi en azından görmüş ikinci bir geliştirici.
- Nerede başarısız olur: aynı anda birkaç disiplin — tasarım, back-end, entegrasyon, test — ve sabit bir teslim tarihi gereken projelerde.
- Nerede parlar: sitenizi tanıyan bir kişinin, tanımayan bir ekipten çok daha değerli olduğu süregelen küçük iyileştirmelerde.
Freelancer riski yetkinlik değil erişilebilirliktir. Yukarıdaki önlemlerin hepsi projeyi o kişi olmadan da ayakta tutmakla ilgili ve hepsini baştan ayarlamak ucuzdur.

### Ajans durumu, dürüstçe
Kapasite, genişlik ve süreklilik satın alıyorsunuz ve bunları sağlayan yapının maliyetini ödüyorsunuz.
- Avantaj: aynı anda birkaç beceri, bir süreç ve biri ayrılsa da devam eden bir proje.
- Maliyet: hesap yönetimi, proje yönetimi ve kâr marjı; aynı çıktı için genelde bir freelancerın %40–60 üstü.
- Risk: sunumu yapan kişiler işi yapan kişiler değildir. İşi gerçekte kimin yapacağını sorun ve isim alın.
- Nerede başarısız olur: ajans maliyet yapısına göre verimsiz olan ve daha büyük müşterilerin arkasına düşen küçük süregelen değişikliklerde.
- Nerede parlar: gerçek bir teslim tarihi ve birkaç disiplinin dahil olduğu ciddi bir yapımda.

### İç ekip ve melezler
Geliştirici istihdam etmek yalnız sürekli iş varsa anlamlıdır — aksi hâlde boş kapasiteye ve daha kötüsü, kararlarını gözden geçirecek bir akranı olmayan tek bir kişiye para ödüyorsunuz.
- Yalnız iç ekip, website’in biten bir proje değil yol haritası olan bir ürün olduğu kurumlara uyar.
- Ajans kurar, freelancer bakar yaygın ve mantıklı bir kalıptır: yapım için kapasite, sonraki yıllar için süreklilik satın alırsınız.
- İç ekip artı uzmanlar, içeride yetkin biri varken belirli sorunlar için dışarıdan uzmanlık getirdiğinizde işe yarar.
- Freelancer artı adı belli bir yedek, herhangi bir yedekliliği olan en ucuz düzenlemedir.
- Sabit aylık tahsisli ajans anlaşması, tahsis gerçekten kullanılıyorsa işe yarar; kullanılmayan saatler saf maliyettir.

Q: Freelancer ajanstan daha mı riskli?
A: Süreklilik açısından evet — bir kişi iki yerde olamaz ve projeyi etkilemeden hastalanamaz. Kalite açısından doğası gereği değil; freelancerlar arasındaki değişkenlik iki yönde de geniştir ve ajanslar arasındaki de öyle. Doğru karşılaştırma yetkinlik değil, tedarikçiniz önümüzdeki ay ulaşılamaz olursa ne olacağıdır.

Q: Freelancer ne kadar ucuz?
A: Karşılaştırılabilir çıktı için genelde %30–50; çünkü proje yönetimi katmanı, hesap yönetimi ve ajans marjı yoktur. Kaybedebileceğiniz şey sorunları yakalayan süreçtir — test, kod incelemesi, ikinci bir görüş — ve bu tam da eksik olana kadar görünmeyen şeydir.

Q: Ne zaman geliştirici istihdam etmeye değer?
A: Gerçekten sürekli iş olduğunda — yol haritası olan, ürün niteliğinde bir site — ve tercihen birden fazla kişi olacağı zaman. Akranı olmayan tek bir iç geliştirici bir bilgi silosu ve tek hata noktasıdır; bu, freelancer durumuna benzer bir risktir ama sabit maliyeti daha yüksektir.

Q: Yaklaşımları karıştırabilir miyim?
A: Çoğu kurum tam olarak bunu yapıyor ve iyi işliyor: yapım için ajans, süregelen değişiklikler için bir freelancer ya da küçük bir anlaşma. Koşul, devrin gerçek olması — sizin deponuzda kod, belgelenmiş dağıtım, sizin adınıza hesaplar — aksi hâlde ikinci taraf haftalarca birincinin işini geri mühendislik yapar.

## Website Geliştiricisi Nasıl Seçilir: Uygulanabilir Bir Süreç
https://websitedevelopment.biz/tr/guides/website-gelistiricisi-nasil-secilir
Güncelleme 2026-08-07 · Geliştirici bulma

Website geliştiricisi seçmek çoğunlukla kanıt toplama işidir ve çoğu kişi yanlış kanıtı topluyor: tipik işi değil en iyi işi gösteren portfolyolar ve karşılaştırılamayan şeyleri karşılaştıran fiyat.

Bu rehber daha iyi sonuç veren bir süreci ele alıyor — ne göndereceğinizi, ne soracağınızı, neyi kontrol edeceğinizi ve ne zaman duracağınızı.

### Aynı brief’i herkese gönderin
Teklifler ancak aynı soruyu cevaplıyorsa karşılaştırılabilir. Tek sayfalık bir brief artı bir sayfa yapısı yeterlidir ve teklifleri bu kadar farklı gösteren değişkenliğin çoğunu ortadan kaldırır.
- Sitenin neyi başarması gerektiği ve en önemli tek eylem.
- Yayın-kritik ya da sonra diye işaretlenmiş bir sayfa listesi.
- İşlevsel gereksinimler: formlar, arama, hesaplar, ödeme, entegrasyonlar.
- Kapsam dışı olan — metin yazımı, fotoğraf, süregelen SEO.
- Bütçe aralığınız. Saklamak herkesin zamanını boşa harcar ve kullanamayacağınız teklifler üretir.
- Teslim tarihiniz ve onu ne belirlediği.
- Nasıl ve ne zamana kadar karar vereceğiniz.
Bütçe aralığı vermek, üst sınırından ücretlendirileceğiniz anlamına gelmez. Alacağınız tekliflerin gerçekten satın alabileceğiniz projeler için olması anlamına gelir.

### Ne sormalı ve cevaplar ne anlama geliyor
Bu sorular, proje bitirmiş geliştiricileri proje başlatmış olanlardan ayırır.
| Benim ölçeğimde benzer bir site gösterin | Portfolyo görseli değil, bağlamıyla birlikte yayında bir adres |
| Kodun ve hesapların sahibi kim olacak? | "Siz" — anında, çekincesiz |
| Bir değişiklik canlıya nasıl gidiyor? | FTP değil, sürüm kontrolü ve bir dağıtım süreci |
| Yayından sonra bir şey bozulursa ne olur? | Tanımlı bir destek penceresi ve sonrasında ne olduğu |
| Neler dahil değil? | Zorlanmadan sunulan somut bir liste |
| Bu projede ne ters gidebilir? | Dürüst riskler — genelde içerik, entegrasyon, kararlar |
| İşi gerçekte kim yapacak? | "Ekibimiz" değil, isimler |
| Bizden ne lazım? | Tarihleriyle birlikte net bir liste |

### Kanıtı kendiniz kontrol edin
Yirmi dakikalık bağımsız kontrol, bir saatlik konuşmadan değerlidir; çünkü sunumu değil işi sınar.
- Yayındaki iki sitesini mobil veriyle telefondan açın.
- Birini bir performans testinden geçirin ve sonuca dürüstçe bakın.
- Bir sayfada klavyeyle Tab’layın ve odağın görünür olup olmadığına bakın.
- Kaynağı görüntüleyin: başlık, meta açıklama, düzgün başlık yapısı var mı?
- Bir eski müşteriyle konuşun — ve özellikle bir şeyin ters gittiği anı sorun.
- Kendi sitelerinin bakımlı olup olmadığına bakın. Belirleyici değil ama bir sinyal.
En faydalı referans sorusu "memnun kaldınız mı" değil, "bir şey ters gittiğinde ne oldu ve bunu nasıl yönettiler?" Her projede öyle bir an vardır.

### Kırmızı bayraklar ve yeşil bayraklar
İki yönde de ağır tartılmaya değer desenler.
| Soru sormadan bir saat içinde gelen teklif | Teklif vermeden önce işiniz hakkında sorular |
| Garantili ilk sayfa sıralaması | Kimsenin sıralama garanti edemeyeceğini açıklamak |
| Muğlak kapsamla sabit fiyat | Açık bir kapsam dışı listesi |
| Alan adını ya da hostingi onlar tutuyor | Her şey sizin adınıza kayıtlı |
| Staging ortamı yok | İlk şablondan itibaren staging’de inceliyorsunuz |
| Referans vermek istememek | Siz sormadan sunuyor |
| Bu hafta imzalama baskısı | Karşılaştırmanız için beklemeye razı |
| Tamamı peşin ödeme | Teslimatlara bağlı kilometre taşı ödemeleri |

Q: En ucuz teklifi seçmeli miyim?
A: Yalnız diğerleriyle aynı soruyu cevaplıyorsa. Gerisinin çok altındaki bir teklif genelde bir şeyi dışarıda bırakıyordur — içerik girişi, test, yayın sonrası düzeltmeler — ya da brief’i okumamıştır. Neyin hariç olduğunu yazılı sorun, sonra bakım dahil ilk yılın toplam maliyetini ve sonunda neye sahip olacağınızı karşılaştırın.

Q: Teknik değilsem bir geliştiriciyi nasıl değerlendiririm?
A: Teknolojiyi değil süreci ve kanıtı değerlendirin. Sizin ölçeğinizde yayında bir site gösterebiliyorlar mı? Sürüm kontrolü ve staging kullanıyorlar mı? "Kodun sahibi kim?" sorusunu duraksamadan cevaplıyorlar mı? İşiniz hakkında soru soruyorlar mı? Bunların hiçbiri teknik bilgi gerektirmiyor ve sonuçları teknoloji yığınından daha iyi öngörüyor.

Q: Sözleşmede ne olmalı?
A: Açık bir hariç tutma listesiyle kapsam, kilometre taşları ve ödemeler, kodun/alan adının/hesapların mülkiyeti, revizyon turları, yayından sonra ne olduğu, sorunlar için yanıt süreleri ve ihbar süreleri. Israr edilecek tek bir madde varsa o mülkiyettir — diğer her şey sonradan yeniden pazarlık edilebilir, o edilemez.

Q: Kaç geliştiriciye başvurmalıyım?
A: Üç ile beş işe yarar aralıktır. Daha azı karşılaştıracak bir şey bırakmaz; daha fazlası değerlendirme emeğini ek seçeneklerin değerinin üstüne çıkarır ve herkesi bekletirsiniz. Aynı brief’i hepsine gönderin ve süreç bitsin diye bir karar tarihi belirleyin.

## Responsive Web Tasarım: Uygulamalı Rehber
https://websitedevelopment.biz/tr/guides/responsive-web-tasarim-rehberi
Güncelleme 2026-08-07 · Web tasarım

Responsive tasarım, ayrı bir mobil sürüm değil, her genişlikte çalışan tek bir sitedir. Pratikte çoğu site kâğıt üzerinde responsive ve belirli yerlerde bozuktur — yatay kaydırmaya zorlayan bir tablo, ekranın üçte birini yiyen bir gezinme, iOS’ta beklenmedik şekilde yakınlaşan bir form.

Bu rehber konuya nasıl yaklaşacağınızı, gerçek hataların nerede olduğunu ve nasıl test edeceğinizi ele alıyor.

### Dar uçtan tasarlayın
Dardan başlamak önceliklendirmeyi zorunlu kılar. 320 pikselde aynı anda tek bir şeye yer vardır, dolayısıyla o şeyin ne olduğuna karar vermek zorundasınız; bir tasarımı sonradan genişletmek çoğunlukla öğelere daha fazla yer vermek meselesidir.

Ters yönde gitmek — 1440’ta tasarlayıp sonra parça çıkarmak — masaüstünün parçaları gizlenmiş mobil düzenler üretir; önemli içeriğin ziyaretçilerin çoğunun kullandığı cihazda display:none olarak bitmesinin yolu budur.
- Düzenlere yaygın olarak kullanılan en dar cihazlar olan 320–360px’te başlayın.
- Mobil ziyaretçinin ihtiyaç duyduğu içeriği mobilde asla gizlemeyin; taşıyın ya da katlayın.
- Kırılma noktalarını içerik belirlesin — cihaz adlarında değil, düzenin bozulduğu yerde.
- Tarayıcı yazı boyutunu %200’e alarak test edin: bu yaygın bir erişilebilirlik ayarıdır ve düzenleri her telefondan çok bozar.
Cihaz adlı kırılma noktaları hızla eskir. "Tablet" on yılda altı farklı genişlik demekti; "kart ızgarasının çirkinleştiği nokta" değişmiyor.

### Gerçekten bozulan öğeler
Responsive hatalarının çoğunu az sayıda bileşen üretir ve bunlar bilerek kontrol edilecek kadar öngörülebilir.
| Tablolar | Bütün sayfa yatay kayıyor | Kaydırma kabı ya da kart yığınına dönüştürme |
| Uzun kelime / URL | Sayfa yana kayıyor | overflow-wrap ve esnek/ızgara çocuklarında min-width:0 |
| Görseller | Taşma ya da düzen kayması | max-width:100%, açık width ve height nitelikleri |
| Gezinme | Ekranın üçte birini alıyor | Katlayın ya da ana hedefleri alt çubuğa taşıyın |
| Formlar | iOS yakınlaştırıyor ve geri çıkmıyor | Alanlarda yazı boyutu en az 16px |
| Sabit öğeler | Bağlandıkları içeriği örtüyor | scroll-padding ve gövde boşluğunda hesaba katın |
| Modaller | Küçük ekranda kapatılamıyor | Mobilde tam ekran ve görünür bir kapatma denetimi |

### Görseller ve medya
Görseller genelde sayfadaki en büyük şey ve düzen kaymasının en yaygın kaynağıdır. Üç nitelik bunun çoğunu düzeltir ve hiçbir maliyeti yoktur.
- width ve height niteliklerini her zaman verin ki tarayıcı dosya gelmeden yeri ayırsın.
- Modern formatları sunun — WebP ya da AVIF — hâlâ gerekliyse bir yedekle.
- srcset ve sizes kullanın ki telefon 2000px’lik bir hero değil telefon boyutunda bir dosya indirsin.
- Katlamanın altındaki görselleri geç yükleyin, ama görünen en büyük görseli asla: o sizin LCP öğeniz.
- Ana görsele fetchpriority="high" verin ki dekoratif varlıkların arkasında kuyruğa girmesin.
- Arka plan görsellerine en boy oranı verin ki kap yüklenmeden çökmesin.

### Yalnız genişlik değil, dokunma
Responsive yalnız düzenle ilgili değildir. Dar bir görünüm genelde fare değil parmak demektir ve parmak girdisinin, yalnız genişliğe bakan medya sorgularının karşılamadığı farklı gereksinimleri vardır.
- Dokunma hedefleri en az 44×44px ve aralarında boşluk olsun; yan yana duran 30px’lik bağlantılara sürekli yanlış basılıyor.
- Önemli hiçbir şey hover’ın arkasında olmasın — yalnız hover ile açılan bir menü dokunmatikte erişilemez.
- Dokunuştan sonra takılı kalan hover etkilerini kaldırmak için pointer:coarse medya sorgusu kullanın.
- Birincil eylemleri uzun telefonlarda başparmağın ulaştığı alanda tutun; sağ üst köşe tek elle basılması en zor yerdir.
- prefers-reduced-motion’a saygı gösterin: paralaks ve büyük geçişler bazı kullanıcılarda gerçek rahatsızlık yaratıyor.

Q: Kaç kırılma noktası gerekir?
A: Genelde üç ile beş ve bunlar cihaz listesinden değil içeriğinizden çıkmalı. Pencereyi genişletirken düzenin yanlış görünmeye başladığı yere bir tane ekleyin, belirli bir telefon var diye değil. Bir düzine kırılma noktası olan siteler neredeyse her zaman baştan akışkan olmayan bir düzeni telafi ediyordur.

Q: Ayrı bir mobil site hiç doğru olur mu?
A: Nadiren. İki kod tabanı, iki URL kümesi, iki dağıtım ve bakılacak bir kanonik ilişki demek ve genelde ikisinden biri sessizce geride kalarak biter. Hâlâ görüldüğü durumlar responsive yapılamayan eski sistemler ve orada bile bu bir plan değil geçici çözümdür.

Q: Responsive tasarımı düzgün nasıl test ederim?
A: Tarayıcı cihaz taklidi düzen sorunlarını yakalar ama dokunuşu, ağı ve platform davranışını yakalamaz. En az bir gerçek orta seviye Android ve bir iPhone’da, ofis wifi’si yerine mobil veriyle test edin. Sonra önemli sayfaları tarayıcı yazı boyutu %200’de tekrarlayın; düzenlerin asıl çöktüğü yer orasıdır.

Q: Telefonda veri tabloları ne olacak?
A: İki çalışan seçenek: tabloyu görünür bir ipucu ve yapışkan bir ilk sütunla yatay kaydırılan bir kaba koymak ya da her satırı, her hücrenin kendi sütun adını taşıdığı bir karta dönüştürmek. Kaydırma kabı karşılaştırmayı mümkün tutar; kart yığını okumayı kolaylaştırır. Ziyaretçilerin satırları karşılaştırmasına mı yoksa tek tek okumasına mı göre seçin.

## Site Yapısı ve Site Haritası: Sayfalarınızı Nasıl Planlarsınız
https://websitedevelopment.biz/tr/guides/site-yapisi-ve-site-haritasi
Güncelleme 2026-08-07 · Website planlama

Site yapısı, sayfalarınızın düzeni ve aralarındaki yollardır. Ziyaretçinin aradığını bir tıkta mı yoksa üç tıkta mı bulacağına karar verir ve arama motorunun sitenizin ne hakkında olduğuna ve hangi sayfaların önemli olduğuna dair en güçlü sinyallerinden biridir.

Bu rehber bir yapının nasıl planlanacağını, ne kadar derinliğin fazla olduğunu, URL’lerin nasıl adlandırılacağını ve şimdi ucuz, yayından sonra pahalı olan hataları ele alıyor.

### Organizasyon şemasına göre değil işe göre gruplayın
En yaygın yapısal hata, ziyaretçinin yapmaya geldiği işi değil kurumun nasıl düzenlendiğini yansıtan bir gezinmedir. Kimse "Çözümler Direktörlüğü"nü aramaya gelmiyor.

Ziyaretçilerin gerçekten sorduğu sorulardan başlayın, her birini cevaplayan sayfaları gruplayın ve grubu onların kullanacağı kelimelerle adlandırın — ki bunlar neredeyse hiçbir zaman sizin iç kelimeleriniz değildir.
- Her sayfayı kendi satırına yazın, sonra aynı soruyu cevaplayan satırları gruplayın.
- Her grubu ziyaretçinin dilinde adlandırın: "Ticari Çerçeve" değil "Fiyatlar".
- Beş ile yedi üst bölüm hedefleyin; fazlası gezinmeyi taranabilir olmaktan çıkarır.
- Bir sayfa hiçbir gruba uymuyorsa ya gereksizdir ya da tek kişilik yeni bir gruptur — hangisi olduğuna karar verin.

### Önemli sayfaları yüzeyde tutun
Derinlik, ana sayfadan kaç tık uzakta olduğudur. Önemli sayfalara iki üç tıkta ulaşılmalı; beşinci derinlikteki bir sayfa ziyaretçiler tarafından nadiren bulunur ve arama motorları tarafından daha seyrek taranır.

Derinlik URL uzunluğuyla aynı şey değildir. /guides/seo/technical-seo adresindeki bir sayfa, ona doğrudan bağlantı veren bir şey varsa ana sayfadan tek tık uzakta olabilir. Önemli olan eğik çizgi sayısı değil bağlantı yoludur.
| 0 | Ana sayfa | Her üst bölüme ve birincil eyleme bağlantı verir |
| 1 | Bölüm hubları, önemli iniş sayfaları | Ana gezinmede |
| 2 | Tekil makaleler, ürünler, hizmetler | Hublardan ve ilgili içerikten bağlantılı |
| 3 | Varyantlar, derin referans sayfaları | Üst sayfasından ve aramadan bağlantılı |
| 4+ | Arşivler, eski kampanyalar | İndekslenmeli mi diye sorgulayın |
Çoğu site için ana sayfa asıl giriş kapısı değildir. Arama trafiği derine düşer, o yüzden her sayfa nerede olduğunu söylemeli ve bir sonraki adımı sunmalı.

### Bir kez karar verilecek URL kalıpları
URL’leri baştan doğru kurmak ucuz, sonradan değiştirmek acıdır; çünkü değiştirmek yönlendirme, kaybolan sinyal ve kırık dış bağlantı demektir. İlk sayfa var olmadan kalıba karar verin.
- Küçük harf, kelimeler tire ile ayrılmış, alt çizgi ya da boşluk yok.
- Kısa ve açıklayıcı: /guides/website-planlama-rehberi, /p?id=4821 değil.
- Sondaki eğik çizgi için tek bir karar, kanonik biçime yönlendirmeyle uygulanmış.
- Bölüm anlam katıyorsa yola girsin; her üst kategoriyi yola yığmayın.
- İçerik gerçekten tarihe bağlı değilse URL’de tarih olmasın — kalıcı sayfaları bayat gösterir.
- Çok dilli sitede dil kalıbına şimdi karar verin: /de/… önekleri üzerine düşünmesi en kolay olanıdır.

### İki site haritası, iki farklı okuyucu
Bu terim iki farklı şeyi kapsıyor. Planlama site haritası, yapımdan önce çizdiğiniz diyagramdır — sayfalar ve ilişkileri. XML site haritası ise /sitemap.xml adresindeki, indekslenebilir URL’lerinizi arama motorlarına listeleyen bir dosyadır.

İkisi de gerekli ve farklı okuyuculara hitap ediyorlar.
| Okuyucu | Ekibiniz ve geliştirici | Arama motorları |
| Ne zaman | Tasarım başlamadan önce | Yayından sonra otomatik üretilir |
| İçerik | Planlanan her sayfa ve üst sayfası | Her kanonik, indekslenebilir URL |
| Biçim | Bir diyagram ya da iç içe liste | XML, büyük sitelerde bölüme göre bölünmüş |
| Bakım | Kapsam değişince güncellenir | İçerik değişince yeniden üretilir |
XML site haritası yalnız indekslenmesini istediğiniz sayfaları listelemeli. Filtreli, sayfalanmış ya da noindex URL’leri eklemek tarama bütçesini harcar ve çelişkili sinyal gönderir.

Q: Üst gezinmede kaç öğe olmalı?
A: Çoğu site için beş ile yedi. Fazlası şeridi göz atılan bir şey olmaktan çıkarıp okunan bir listeye çevirir — telefonda ise kimsenin açmadığı bir menüye. Gerçekten daha fazlasına ihtiyacınız varsa, çözüm genelde iki bölümünüzün aslında tek bir bölüm olmasıdır.

Q: URL’ler gezinmeyle aynı olmalı mı?
A: Tutarlı olmalı ama birebir aynısını yansıtmak zorunda değil. Önemli olan URL’nin tahmin edilebilir ve kalıcı olmasıdır. Her üst kategoriyi yola yığan derin yapılar kırılgandır: bir bölümü taşırsınız, altındaki her URL değişir ve sonsuza dek bakmanız gereken bir yönlendirme haritası devralırsınız.

Q: Yenilemede eski URL’lerime ne olur?
A: Trafiği ya da bağlantısı olan her eski URL en yakın karşılığına 301 ile yönlendirilmeli. Ana sayfaya değil — bu, arama motoruna sayfanın gittiğini söyler ve birikmiş sinyalleri kaybettirir. Yönlendirmeleri yayın öncesi eski sitenin taramasından ve analitiğinizden çıkarın ve yayına aldığınız gün test edin.

Q: Her sayfa gezinmede olmalı mı?
A: Hayır. Gezinme çoğu ziyaretçinin ihtiyaç duyduğu sayfalar içindir; geri kalanına hublar, ilgili bağlantılar, arama ve footer üzerinden ulaşılır. Ancak hiçbir gezinmede olmayan ve hiçbir yerden bağlantı almayan bir sayfa öksüzdür — neredeyse hiç taranmaz ve nadiren bulunur. İndekslenebilir her sayfanın en az bir iç bağlantısı olmalı.

## Sonuçları Gerçekten Değiştiren Website Tasarım İlkeleri
https://websitedevelopment.biz/tr/guides/website-tasarim-ilkeleri
Güncelleme 2026-08-07 · Web tasarım

Website tasarımı tavsiyelerinin çoğu ilke kılığına girmiş tercihtir. Daha küçük bir grup karar ise ziyaretçilerin davranışını güvenilir biçimde değiştirir ve bunlar çoğunlukla gösterişsizdir: önce ne göründüğü, metnin okunup okunmadığı ve birinin geldiği şeyle arasında kaç adım olduğu.

Bu rehber arkasında kanıt olanları ele alıyor ve gerçekten zevk meselesi olanları da açıkça adlandırıyor.

### Her ekranda tek bir net hiyerarşi
Her ekran tek bir şeyi açıkça en önemli kılmalı. Üç öğe aynı ağırlıkla dikkat için yarıştığında ziyaretçiler bu belirsizliği ayrılarak çözer.

Hiyerarşi boyut, kalınlık, renk, boşluk ve konumdan kurulur — kabaca bu güç sırasıyla. En az kullanılan araç boşluktur: etrafında yer olan bir öğe bağırmadan önemli okunur.
- Ekran başına tek bir birincil eylem, diğer her şeyden farklı biçimlendirilmiş.
- İkincil eylemler görünür ama görsel olarak daha sakin — dolgu yerine çerçeve.
- İçeriği anlatan başlıklar, hiçbir şey anlatmayan zekice başlıklar değil.
- Bilinçli kullanılan boşluk: kalabalık bir sayfanın hiyerarşisi yoktur, yalnız yoğunluğu vardır.

### Süslemeden önce okunabilirlik
Okunması zor metin, yazı ne kadar iyi olursa olsun size okuyucu kaybettirir. Bunlar görüş değil ölçülebilir eşiklerdir.
| Gövde yazı boyutu | Mobilde 16–18px | 16px altında iOS form odağında yakınlaştırıyor, küçük metin okuyucu kaybettiriyor |
| Satır uzunluğu | 55–75 karakter | Uzun satırlarda göz dönüşte yerini kaybediyor |
| Satır yüksekliği | Gövde metninde 1,5–1,7 | Sıkışık satır aralığı okuma hızını ölçülebilir biçimde düşürüyor |
| Metin kontrastı | En az 4,5:1, 7:1 daha iyi | WCAG AA; gri üstüne gri telefonda güneşte okunmuyor |
| Denetim kontrastı | Arka plana karşı 3:1 | Kullanıcı bir alanın nerede bittiğini görebilmeli |
| Paragraf uzunluğu | Üç dört satır | Uzun bloklar mobilde atlanıyor |
Kontrastı gradyanlar ve görseller dahil gerçek arka plana karşı ölçün. Beyaz üstünde geçen bir değer, üzerine konduğu hero görselinde kalabilir.

### Formları simetri için değil tamamlanma için tasarlayın
Website hedeflerinin çoğu formlarda tamamlanır ve tasarım dikkatinin çoğu oraya harcanmaz. Eklediğiniz her alan size tamamlanma kaybettirir; ihtiyacınız olmayan her alanı kaldırmak bedava kazançtır.
- Cevap verebilmek için gereken en azı isteyin. Gerisini yanıtta sorabilirsiniz.
- Tek sütun. İki sütunlu formlarda alanlar atlanıyor ve mobilde daha kötü çalışıyor.
- Etiketler alanların üstünde ve her zaman görünür — yalnız yer tutucuya dayanan etiket yazmaya başlar başlamaz kayboluyor.
- Doğru input türleri ve autocomplete nitelikleri, böylece telefon doğru klavyeyi açar ve doldurmayı önerir.
- Her tuş vuruşunda değil alandan çıkışta doğrulayın ve hatayı alanın yanına koyun.
- Hata durumunda formu asla temizlemeyin. Yazılan cevapları kaybetmek en yaygın vazgeçme sebebidir.
- Gönderimden sonra ne olacağını ve ne kadar süreceğini söyleyin.

### Neyi zevk, neyi değil
Farkı net koymak inceleme toplantılarında çok zaman kazandırır. Sol sütun tartışılır; sağ sütun tartışılmaz.
| Renk paleti | Gerçek arka plana karşı kontrast oranları |
| Yazı tipi seçimi | Gövde yazı boyutu ve satır uzunluğu |
| İllüstrasyon stili | Görsellerin anlamlı alt metni olup olmadığı |
| Hero görseli olsun ya da olmasın | Birincil eylemin kaydırmadan görünüp görünmediği |
| Yuvarlak ya da köşeli kenarlar | Klavye kullanıcısı için odak durumlarının görünürlüğü |
| Animasyon stili | Animasyonun prefers-reduced-motion’a saygı gösterip göstermediği |
| Yerleşim yoğunluğu | Dokunma hedeflerinin en az 44px olup olmadığı |

Q: "Katlamanın üstü" hâlâ önemli mi?
A: Her önemli şeyin oraya sığması gereken bir kural olarak değil — insanlar kaydırıyor ve yirmi yıldır kaydırıyorlar. Önemli olan, sayfanın üstünün birkaç saniye içinde "bu nedir ve bana uygun mu" sorusunu cevaplaması. Cevaplıyorsa ziyaretçiler ayrıntı için kaydırır. Cevaplamıyorsa aşağıdaki hiçbir şey okunmaz.

Q: Bir website kaç yazı tipi kullanmalı?
A: Genelde bir ya da iki aile, ek ailelerin yapacağı işi kalınlıklar üstlenerek. Pratik sebep zevk değil performans: her ek aile ve kalınlık, metin doğru görünmeden önce indirilecek başka bir dosya. Üç kalınlığı olan tek bir iyi seçilmiş aile neredeyse her siteyi karşılar.

Q: Koyu tema yapmaya değer mi?
A: Baştan tasarım token’larıyla yapabiliyorsanız değer, çünkü o zaman maliyeti çok düşük. Bitmiş bir siteye sonradan eklemek her rengi, her görseli ve her gölgeyi denetlemek demek ki bu gerçek bir projedir. Destekliyorsanız varsayılan olarak sistem tercihine saygı gösterin ve kullanıcının değiştirmesine izin verin.

Q: Tasarım rakiplere benzemeli mi?
A: Alışkanlıklar benzemeli — gezinme üstte, sepet sağ üstte, logo ana sayfaya bağlı — çünkü bunları bozmak karşılığında hiçbir şey vermeden anlaşılırlık kaybettirir. Alışkanlıkların üstündeki her şey farklılaştığınız yerdir. Hata, bir rakibin düzenini olduğu gibi kopyalamaktır; bu genelde onların içeriğine uyan, sizinkine uymayan kararları da ithal eder.

## Website Gereksinim Dokümanı Nasıl Yazılır
https://websitedevelopment.biz/tr/guides/website-gereksinim-dokumani
Güncelleme 2026-08-07 · Website planlama

Gereksinim dokümanı, sizin ve geliştiricinin aynı website’i tarif ettiğinizden emin olmak içindir. Uzun olmak zorunda değildir. İki tarafın da gerçekten okuduğu dört sayfalık bir brief, ikisinin de bitirmediği elli sayfalık bir şartnameden daha çok anlaşmazlığı önler.

Bu rehber içine ne gireceğini, neyi dışarıda bırakacağınızı ve en önemli bölümü — projenin ne OLMADIĞINI — nasıl yazacağınızı ele alıyor.

### Gereksinim dokümanı ne işe yarar
Üç işi vardır: birkaç geliştiricinin aynı şeyi fiyatlamasını sağlamak (böylece teklifler karşılaştırılabilir olur), kapsam tartışmasında bir başvuru noktası olmak ve kararları hâlâ ucuzken almanızı zorlamak.

Bir tasarım briefi değildir ve teknik bir şartname değildir. "Site hızlı yüklenmeli" bir gereksinimdir; "nesne önbelleği için Redis kullanın" bir çözümdür ve kimseyi işe almadan önce seçmek, parasını ödediğiniz uzmanlığı devre dışı bırakır.
- Uygulamayı değil sonucu ve kısıtları yazın.
- Kurumunuzun dışındaki biri telefona ihtiyaç duymadan anlayabilsin.
- Tek oturumda okunacak kadar kısa tutun — çoğu site için dört ile sekiz sayfa fazlasıyla yeter.
- Tarih ve sürüm koyun, çünkü değişecek.

### İçermeye değer bölümler
Bu yapı çoğu website geliştirme projesini kapsar. Geçerli olmayan bölümleri doldurmak yerine atlayın.
| Arka plan | Kurumun ne yaptığı ve sitenin neden yapıldığı ya da değiştirildiği |
| Hedefler | Birincil hedef, ikincil hedefler ve başarının nasıl ölçüleceği |
| Kitle | İki üç ziyaretçi grubu ve her birinin geldiği soru |
| Sayfa yapısı | Bölümlere ayrılmış, yayın-kritik ya da sonra diye işaretlenmiş her sayfa |
| İşlevsel gereksinimler | Formlar, arama, hesaplar, filtreleme, rezervasyon, ödeme — her birinin ne yapacağı |
| Entegrasyonlar | Her dış sistem, bir kişi adı ve API belgesi bağlantısıyla |
| İçerik | Her sayfayı kim yazacak, kim onaylayacak, ne zaman teslim |
| İşlevsel olmayan | Performans, erişilebilirlik, tarayıcı ve cihaz desteği, diller, güvenlik |
| Kapsam dışı | Açıkça hariç tutulan işler — en değerli bölüm |
| Kısıtlar | Bütçe aralığı, teslim tarihi ve sabit kararlar (mevcut hosting, zorunlu CMS) |

### Sınanabilir gereksinimler yazın
Bir gereksinim, iki tarafın da sonradan karşılanıp karşılanmadığında anlaşabildiğinde işe yarar. "Site hızlı olmalı" sınanamaz; "ürün liste sayfası 4G üzerinde orta seviye bir Android’de 2,5 saniyenin altında Largest Contentful Paint’e ulaşmalı" sınanabilir.

Aynısı işlevsellik için de geçerli. "Bir iletişim formu" önemli olan her soruyu dışarıda bırakır.
| Bir iletişim formu | Altı alan, spam koruması, veritabanına kayıt, iki adrese e-posta, KVKK onay satırı |
| Mobil uyumlu | 320px’te kullanılabilir, tüm dokunma hedefleri en az 44px, yatay kaydırma yok |
| Hızlı | Dört ana şablonda 4G’de LCP 2,5 sn altı ve CLS 0,1 altı |
| Erişilebilir | Şablonlarda WCAG 2.2 AA, klavye ve ekran okuyucu geçişleriyle doğrulanmış |
| SEO uyumlu | Düzenlenebilir başlık ve açıklama, temiz URL, site haritası, makalelerde yapısal veri |
| Çok dilli | Üç dil, çevrilmiş URL’ler, hreflang etiketleri, her sayfada dil değiştirici |

### Kapsam dışı listesi
İnsanların atladığı ve projeyi kurtaran bölüm budur. Aklı başında birinin dahil sanabileceği şeyleri yazın ve açıkça dahil olmadıklarını söyleyin — ya da olmaları gerekiyorsa içeri alın.

Bunu teklifler gelmeden yapmak teklifleri karşılaştırılabilir kılar. Sonra yapmak bir tartışma demektir.
- Metin yazımı ve düzelti — teklif aksini söylemedikçe sizde sayın.
- Fotoğraf, illüstrasyon ve stok lisansları.
- İçerik girişi: 200 ürünü CMS’e kim yazacak?
- E-posta kurulumu, DNS taşıma ve hosting hesabı devri.
- Yayında teknik SEO kurulumundan ayrı olarak süregiden SEO çalışması.
- Eğitim, dokümantasyon ve devir.
- Yayın sonrası destek: ne kapsamda, ne kadar süreyle ve neyi faturalıyorsunuz.
İyi bir geliştirici bu listeye siz sormadan ekleme yapar. Soru sormadan her şeye evet diyen biri genelde belgeyi okumamıştır ve anlaşmazlık sadece ertelenmiştir.

Q: Gereksinim dokümanı ne kadar uzun olmalı?
A: Çoğu işletme sitesi için dört ile sekiz sayfa yeter. Mağaza ve uygulamalarda işlevsel bölüm büyüdüğü için daha uzun olur, ama yirmi sayfayı aşıyorsa bir konuşmanın çözemeyeceği neyin anlatıldığını sorun. Ölçüt kapsamlı olması değil, iki tarafın da okumuş olmasıdır.

Q: Teknolojiyi belirtmeli miyim?
A: Yalnız gerçek bir kısıtınız varsa: ekibinizin bildiği mevcut bir CMS, kalmak zorunda olduğunuz bir hosting, entegre edilmesi gereken bir sistem. Aksi hâlde sonucu yazın ve uygulamayı işe aldığınız kişilere bırakın. Anlamadığınız bir teknolojiyi şart koşmak seçeneklerinizi daraltır ve size daha kötü bir cevap verir.

Q: Tel çerçeve de gerekli mi?
A: En önemli üç dört şablon için düşük çözünürlüklü tel çerçeveler çok az emekle çok fazla belirsizliği kaldırır ve bir tasarımdan çok daha ucuza değişir. Yazılı gereksinimin yerine geçmezler — düzeni gösterirler, davranışı değil — ama ikisi birlikte her birinin tek başına yapabileceğinden çok daha doğru fiyatlanır.

Q: Bazı cevapları bilmiyorsam?
A: "Karara bağlanacak" yazın ve kimin, ne zamana kadar karar vereceğini belirtin. Sahibi olan dürüst bir boşluk sorun değil; uydurulmuş bir cevap sorundur, çünkü teklif onun üzerine kurulur. Geliştiriciler belirsizliği zaten fiyatlıyor, o yüzden belirsizliği görünür kılmak genelde saklamaktan daha iyi bir rakam getirir.

## Web Tasarım Süreci, Adım Adım
https://websitedevelopment.biz/tr/guides/web-tasarim-sureci
Güncelleme 2026-08-07 · Web tasarım

Web tasarım, birinin renk seçtiği aşama değildir. "Bu site ne için var" sorusundan "bu düğme, bu boyutta, bu etiketle" cümlesine kadar daralan bir kararlar dizisidir ve her adım bir sonrakinden daha ucuza değişir.

Bu rehber aşamaları sırasıyla, her birinin ne ürettiğini ve tasarım projelerinin düzenli olarak takıldığı iki noktayı ele alıyor.

### Keşif: tasarımın neyi başarması gerekiyor
Görsel hiçbir şeyden önce tasarımcının da geliştiricinin ihtiyaç duyduğu şeylere ihtiyacı var: birincil hedef, kitle, sayfa yapısı ve kısıtlar. Bunlar olmadan başlanırsa portfolyoda iyi duran ve gerçek içerik geldiğinde çöken bir tasarım çıkar.

Bu aşama belge değil mutabakat üretir. İki tarafın da kabul ettiği tek sayfalık bir özet yeterlidir.
- Sitenin sürüklemesi gereken tek eylem ve nasıl ölçüleceği.
- İki üç ziyaretçi grubu ve her birinin geldiği soru.
- Gerçekten var olan marka kısıtları: logo, renkler, yazı tipleri, üslup.
- Teknik kısıtlar: CMS, platform, gerçekten önemli olan cihazlar.
- Müşterinin beğendiği site örnekleri — ve daha da faydalısı, nedenleri.

### Yapı ve tel çerçeveler
Tel çerçeveler, renk tartışması olmadan düzeni ve hiyerarşiyi karara bağlar. Her şablonda ne olduğunu, hangi sırayla ve ziyaretçinin ne yapmasının beklendiğini — değişiklikler hâlâ dakikalarla ölçülürken — cevaplar.

Her sayfayı değil şablonları tel çerçeveleyin. Çoğu sitede dört ile sekiz farklı şablon ve onlarca sayfa vardır.
| Ana sayfa | Bu ne ve bana uygun mu? | Doğru bölüme gitmek |
| Bölüm hubu | Burada ne var? | Bir öğe seçmek |
| Makale / detay | Asıl cevap | Okumak, sonra bir sonraki adım |
| Ürün | Doğru ürün mü ve ne kadar? | Sepete eklemek |
| İletişim / form | Nasıl başlarım? | Göndermek |
| Arama sonucu | Aradığını buldun mu? | Bir sonucu açmak ya da daraltmak |
Tel çerçeveleri gerçekçi içerik uzunluklarıyla yapın. Altı kelimelik bir başlığa göre tasarlanmış bir düzen, gerçek başlık on dört kelime olduğunda kırılır.

### Görsel tasarım ve tasarım sistemi
Görsel tasarım markayı tel çerçevelere uygular: tipografi ölçeği, renk, boşluk, durumlar ve bileşenler. Tanıtım sitesinden büyük her işte, birbiriyle ilgisiz sayfa resimleri yerine küçük bir sistem — durumları tanımlı bir bileşen kümesi — üretmeye değer.

Sebebi düzenlilik değil. Sebebi, sistemin geliştiriciye maketlerin göstermediği durumlarda ne olacağını söylemesi; ve o durumlar sitenin çoğunu oluşturuyor.
- Bir tipografi ve boşluk ölçeği, böylece hiçbir sayı tek seferlik olmaz.
- Gerçek arka planlarına karşı kontrastı ölçülmüş renk token’ları.
- Bileşen durumları: varsayılan, üzerinde, odak, basılı, pasif, yükleniyor, hata, boş.
- Her bileşen için duyarlı davranış, yalnız ana sayfanın mobil hâli değil.
- Çok fazla içerik olduğunda ve hiç içerik olmadığında ne olacağı.

### Tasarım projeleri nerede takılır
Gecikmenin çoğunu iki aksaklık üretir ve ikisi de zevk değil süreç sorunudur.
- Sahipsiz geri bildirim. Altı kişi yorum yapar, ikisi birbiriyle çelişir ve hakemlik tasarımcıya kalır. Geri bildirimi birleştirecek ve son kararı verecek tek bir kişi belirleyin.
- Var olmayan içerik. Tasarımlar yer tutucu metne göre onaylanır, sonra gerçek metin iki katı uzunlukta gelir ve düzen baştan yapılır. Kaba da olsa gerçek içerikle tasarlayın.
- Sınırsız revizyon. Sayıyı baştan anlaşın — genelde iki ya da üç — ve fazladan bir turun ne tuttuğunu. Sınır olmadan projeler bitmez, sürüklenir.
- Onay olmayan onay. Toplantıda "güzel olmuş" onay değildir. Şablon başına, tarihli ve yazılı alın.
Bir incelemedeki en faydalı soru "beğendiniz mi" değil, "bu, ziyaretçinin sitenin var olma sebebi olan işi yapmasına yardım ediyor mu"dur. Zevk tartışmalarının sonu yoktur; hedef tartışmalarının vardır.

Q: Kaç revizyon turu beklemeliyim?
A: Şablon tabanlı bir projede iki ya da üç normaldir. Sayıdan daha önemlisi, fazladan turun maliyetiyle birlikte yazılı olarak anlaşılmasıdır. Sınırsız revizyon cömert görünür ve pratikte projenin bir karara hiç varmaması demektir, çünkü kimseyi taahhüde zorlayan bir şey kalmaz.

Q: Tasarım ve geliştirme aynı kişi mi olmalı?
A: Küçük projelerde bir kişinin ikisini de yapması verimlidir ve bir devri ortadan kaldırır. Büyük projelerde bunlar gerçekten farklı beceriler ve ayırmak genelde daha iyi iş çıkarır — yeter ki tasarımcı bir dizi resim değil, durumları ve duyarlı kuralları olan bir sistem üretsin. Risk ayrımda değil devirdedir.

Q: Geliştirme başlamadan tasarımın tamamı bitmiş olmalı mı?
A: Şablonların tasarlanmış olması gerekir, her sayfanın değil. Tasarım sistemi ve en karmaşık iki üç şablon oturduktan sonra geliştirme başlayabilir; gerisi yapım sürerken bitirilir. Hiçbir şey oturmadan geliştirmeye başlamak yeniden iş demek, son sayfaya kadar bitirmeyi beklemek ise boş bekleyen bir ekibe para ödemek.

Q: Sonunda hangi teslimatları almalıyım?
A: Her şablon ve bileşen için düzenlenebilir kaynak dosyalar, tanımlı bir tipografi ve renk ölçeği, yapımın ihtiyaç duyduğu formatlarda dışa aktarılmış varlıklar ve yazılı duyarlı kurallar. Kaynak dosyaları mı yoksa yalnız çıktıları mı aldığınızı başlamadan sorun — orijinal tasarımcı olmadan küçük bir değişiklik gerektiğinde bu fark önemli olur.

## Website Maliyeti Ne Kadar? Proje Türüne Göre Gerçek Aralıklar
https://websitedevelopment.biz/tr/guides/website-maliyeti-ne-kadar
Güncelleme 2026-08-07 · Website planlama

"Bir website" için tek bir rakam yanıltıcıdır, çünkü aynı ifade beş sayfalık bir tanıtım sitesini de, 4.000 ürünlü ve üç sistem entegrasyonlu bir mağazayı da kapsıyor. İşe yarayan şey aralıkların şekli ve sizi bir aralıktan diğerine taşıyan etkenler.

Bu rehber proje türüne göre tipik maliyetleri, rakamı gerçekten belirleyen faktörleri, tekliflerde nadiren görünen işletme giderlerini ve beş kat farklı iki teklifi nasıl karşılaştıracağınızı ele alıyor.

### Proje türüne göre tipik aralıklar
Bunlar profesyonel iş için geniş piyasa aralıkları, teklif değil. Bölgesel ücretler çok değişir ve aynı brief, proje yöneticisi ve QA süreci olan bir ajanstan, tek başına çalışan bir freelancerdan daha pahalıya gelir — farklı miktarda kod değil, farklı miktarda risk örtüsü satın alıyorsunuz.
| Hazır tema / kurucu site | 500 – 3.000 $ | Var olan tema, sizin içeriğiniz, hafif özelleştirme |
| Küçük işletme sitesi | 3.000 – 12.000 $ | Özel tasarım, CMS, 5–15 sayfa, temel SEO kurulumu |
| Orta ölçekli özel site | 12.000 – 50.000 $ | Kendine ait tasarım sistemi, özel şablonlar, entegrasyonlar |
| Online mağaza | 5.000 – 80.000 $+ | Platform, katalog, ödeme, kargo, vergi, veri taşıma |
| Web uygulaması | 40.000 – 250.000 $+ | Özel iş mantığı, hesaplar, yetkiler, sürekli sürümler |
| Mevcut sitenin yenilenmesi | Yeni yapımın %60–90’ı | Veri taşıma sayıldığında sıfırdan yapmaktan nadiren ucuz |
Yenileme genelde indirim değildir. İçeriği taşımak, URL’leri korumak ve mevcut davranışı birebir tutturmak, yeni bir yapımda hiç olmayan bir iştir.

### Rakamı gerçekten ne belirler
Sayfa sayısı maliyetin zayıf bir göstergesidir. Üç şablondan üretilen yirmi sayfa, hepsi birbirinden farklı beş sayfadan ucuzdur. Fiyatı hareket ettiren şey özel mantık, entegrasyonlar ve içerik hacmidir.
- Farklı şablon sayısı, sayfa sayısı değil. Her benzersiz düzen ayrı tasarım, ayrı yapım, ayrı test demek.
- Entegrasyonlar. Sitenin konuşması gereken her sistem — CRM, ERP, ödeme, rezervasyon, e-posta — hem iş hem de bozulabilecek bir parça ekler.
- İçerik taşıma. 40 sayfayı elle taşımak bir öğleden sonradır; görselleri ve varyantlarıyla 4.000 ürünü taşımak başlı başına bir projedir.
- Diller. İkinci dil nadiren iki katıdır ama asla bedava değildir: yapı, URL’ler, hreflang ve bir çeviri akışı.
- Özel mantık. Fiyatlandırma kuralları, konfigüratörler, yetkiler ve iş akışları bütçenin asıl gittiği yerdir.
- Erişilebilirlik ve performans hedefleri. Baştan tasarlanınca sonradan eklemekten ucuz, ama iki durumda da sıfır değil.

### Teklifte olmayan maliyetler
Yapım teklifi harcamanın sonu değil başıdır. İşletme giderleri tek tek küçük, toplamda önemlidir ve kimse söz etmese de gelir.
| Alan adı | 10 – 50 $ | Ajansın değil sizin adınıza kayıtlı olduğundan emin olun |
| Hosting | 60 – 3.000 $+ | Paylaşımlıdan yönetilen buluta; mağaza tanıtım sitesinden fazlasını ister |
| SSL sertifikası | 0 – 200 $ | Çoğu site için ücretsizi yeterli |
| CMS / platform ücreti | 0 – 30.000 $+ | E-ticaret platformları çoğu zaman ciroya oran da alır |
| Eklenti ve lisanslar | 100 – 2.000 $ | Yenilemeler bir şey bozulana kadar unutuluyor |
| Bakım ve güncelleme | Yapım maliyetinin %10–20’si | Güvenlik yamaları, yedekler, küçük düzeltmeler |
| İçerik ve fotoğraf | Çok değişken | Sıklıkla bütçelenmemiş en büyük kalem |

### Fazla ucuz görünen bir teklif nasıl okunur
Diğerlerinin çok altında bir teklif otomatik olarak kötü değildir ama her zaman farklı bir soruyu cevaplıyordur. Fiyata bakmadan önce hangisini cevapladığını öğrenin.
- Neyin hariç olduğunu yazılı sorun. İçerik girişi, SEO kurulumu, eğitim ve yayın sonrası düzeltmeler klasik eksiklerdir.
- Yayından sonra kodun, alan adının ve hosting hesabının sahibinin kim olduğunu sorun. Cevap "siz" değilse fiyat, fiyat değildir.
- Kaç revizyon turu dahil ve dördüncü tur ne tutuyor, sorun.
- İkinci hafta bir şey bozulursa ne olacağını sorun: kapsamda mı, saatlik mi, yeni proje mi?
- Sizin ölçeğinizde yaptıkları yayında bir siteyi görmek isteyin — en güzel işlerini değil, en benzer işlerini.
- Yapım rakamını değil ilk yılın toplamını karşılaştırın. Ucuz tekliflerin ucuz olmaktan çıktığı yer orasıdır.
Endişe verici iki teklif vardır: diğerlerinin üçte biri olan ve brief gönderildikten bir saat sonra gelen. İkisi de genelde briefin okunmadığı anlamına gelir.

Q: Aynı brief için teklifler neden bu kadar farklı?
A: Çünkü farklı miktarda risk ve farklı miktarda süreç fiyatlıyorlar. Tek başına çalışan bir geliştirici kendi saatlerini fiyatlar. Bir ajans bir tasarımcıyı, bir geliştiriciyi, bir proje yöneticisini, testi ve işi yapan kişi ayrılırsa düzeltmenin maliyetini fiyatlar. İkisi de yanlış değil; farklı projelere ve işlerin ters gitmesine karşı farklı toleranslara uyuyorlar.

Q: Aylık abonelikli website iyi bir anlaşma mı?
A: Ödemeyi kestiğinizde ne olduğuna bağlı. Bazı abonelikler yapım, hosting ve bakımı birleştirir ve ayrıldığınızda elinizde hiçbir şey kalmaz — üç dört yılda bu genelde siteye sahip olmaktan pahalıya gelir. Bazıları çıkış yolu olan gerçek yönetilen hizmetlerdir. Aylık rakamı bir şeyle karşılaştırmadan önce neyin sizin olduğunu ve iptalde ne olacağını sorun.

Q: Kapora ödemeli miyim?
A: Kapora normaldir — genelde %30–50 peşin, kalanı kilometre taşlarında ya da yayında. Normal olmayan, hiçbir şey ortada yokken tamamını ödemektir. Ödemeleri görebileceğiniz teslimatlara bağlayın ve son ödemeyi doğrulayamayacağınız bir iç onaya değil yayına bağlayın.

Q: Bakım için ne kadar ayırmalıyım?
A: CMS tabanlı bir site için yılda yapım maliyetinin %10–20’sini planlayın: güvenlik güncellemeleri, eklenti yenilemeleri, yedekler, küçük içerik değişiklikleri ve ara sıra bozulmalar. Mağaza ya da uygulama daha fazlasını ister, çünkü hareketli parçası daha çoktur. Bakımı atlayan siteler o parayı biriktirmiyor; sonra bir acil durumda harcıyor.

## Website Nasıl Planlanır: Eksiksiz Planlama Rehberi
https://websitedevelopment.biz/tr/guides/website-planlama-rehberi
Güncelleme 2026-08-07 · Website planlama

Website geliştirme projeleri genelde kod zor olduğu için gecikmez. Planlama zayıf olduğu için gecikir: sitenin neyi başarması gerektiği, metni kimin yazacağı ya da "bitti"nin ne demek olduğu üzerinde kimse anlaşmamıştır.

Bu rehber, tasarım ve geliştirmeden önce yapılan planlama işini gerçekten işe yaradığı sırayla ve sonradan değiştirmesi pahalı olan kararlarla birlikte ele alıyor.

### Sitenin yapması gereken tek işten başlayın
Her şeyi yapmak zorunda olan bir website genelde ölçülebilir hiçbir şey yapmaz. Her şeyden önce en önemli tek eylemi yazın: bir form gönderimi, bir telefon, bir satın alma, bir rezervasyon, bir indirme.

Sonraki her şey — sayfa yapısı, gezinme, katlamanın üstünde ne duracağı, ne kadar harcamanız gerektiği — bu cevaptan çıkar. Asıl işi talep toplamak olan bir site, asıl işi 4.000 ürün satmak olan bir siteden bambaşka bir yapımdır.
- Birincil hedef: yalnız birini tutabilecek olsaydınız tutacağınız eylem.
- İkincil hedefler: faydalı ama birincil hedeften ödün verdirmeye değmeyen şeyler.
- Nasıl ölçeceğiniz: gelecek çeyrek bakabileceğiniz bir sayı, "daha çok trafik" değil.
- Sitenin yapmasına gerek olmayanlar: yazılı olarak, kapsamın dışında kalsın diye.
Kurumunuzdaki iki kişi birincil hedefi farklı söylüyorsa, bu anlaşmazlık yapımın altıncı haftasında ortaya çıkar. Sıfırıncı haftada çözün; orada bedeli bir toplantı, sonra bir yeniden yapım.

### Kimin geldiğini ve ne aradığını bilin
Kitle araştırması resmî bir çalışma olmak zorunda değil. Gereken şey, gerçekten ziyaret eden iki üç grubun dürüst bir tarifi, her birinin hangi soruyla geldiği ve onları ne uzaklaştırdığı.
| İlk kez alacak kişi | Bu ekip benim ihtiyacımı karşılar mı? | Kanıt yok, fiyat yok, netlik yok |
| Geri dönen müşteri | Şu an ihtiyacım olan şey nerede? | İşlem üç tık derinde gömülü |
| Karşılaştıran kişi | Bunun diğerlerinden farkı ne? | Herhangi bir rakibe de uyan genel metin |
| İş başvurusu yapan | Burada çalışmak nasıl bir şey? | Kariyer sayfası yok ya da bayat |

### Tasarımdan önce sayfalara karar verin
Sayfa yapısı kâğıt üzerinde değiştirmesi en ucuz, tasarım onaylandıktan sonra değiştirmesi en pahalı şeylerden biridir. Her sayfayı listeleyin, bölümlere ayırın ve hangilerinin yayın için gerekli, hangilerinin sonra gelebileceğini işaretleyin.

Yaygın hata, ziyaretçinin işine değil sizin organizasyon şemanıza benzeyen bir yapı. Kimse "Çözümler Direktörlüğü"nü aramaya gelmiyor; ihtiyacı olan şeyi aramaya geliyor.
- İhtiyacınız olduğunu düşündüğünüz her sayfayı gruplamadan, satır satır yazın.
- Her birini "yayın için gerekli" ya da "sonra" diye işaretleyin. Sert olun: çoğu site planlanandan az sayfayla açılır.
- Yayın için gerekli olanları en fazla beş altı üst bölümde toplayın.
- Her sayfanın vermesi gereken tek cümleyi yazın. Yazamıyorsanız o sayfa muhtemelen olmamalı.
- Birincil hedefin her üst düzey sayfadan tek tıkla erişilebilir olduğunu doğrulayın.

### İçerik kritik yoldadır — önce onu planlayın
Metin, fotoğraf ve ürün verisi hiçbir teknik sorunun geciktirmediği kadar çok yayını geciktiriyor. Yapım biter, site staging'de altı hafta bir "Hakkımızda" sayfası bekler.

Her sayfanın metnini kimin yazacağına, kimin onaylayacağına ve ne zaman teslim edileceğine şimdi karar verin — ve bu tarihleri geliştirme kilometre taşları kadar ciddiye alın. İçeride kimsenin vakti yoksa bir metin yazarına bütçe ayırın; boş bekleyen bir geliştirme ekibinden ucuza gelir.
- Her sayfa metni için "pazarlama" değil, bir kişi ve bir tarih belirleyin.
- Mevcut içeriğin kaderine karar verin: taşınacak, yeniden yazılacak ya da atılacak. Çoğu atılmalı.
- Fotoğraf çekimini erken planlayın — listedeki en uzun teslim süresi onda.
- Mağazada ürün verisini yapım sırasında değil, yapım başlamadan dışa aktarıp temizleyin.
- Son onayın kimde olduğunu netleştirin. Eşit yetkili iki onaycı bir takvim riskidir.
İşe yarar bir sınama: site yarın bitse doldurabilir miydiniz? Cevap hayırsa gerçek teslim tarihiniz içeriktir.

### Bir bütçe aralığı ve bir yapım yaklaşımı belirleyin
Planlama iki sayı ve bir seçimle biter: ne harcayabilirsiniz, ne zaman yayında olması gerekiyor ve bu bir hazır tema, bir CMS ya da özel bir yapım mı. Bu üçü kiminle konuşmanız gerektiğine karar verir.
| Site kurucu | Küçük tanıtım sitesi, sıra dışı gereksinim yok | Tavana çarpıp baştan başlarsınız |
| CMS (ör. WordPress) | İçerik odaklı site, geliştirici olmadan sık güncelleme | Eklenti yığılması ve sürekli bakım |
| E-ticaret platformu | Ürün satışı, standart ödeme ihtiyaçları | Platform ücretleri ve sınırlı özelleştirme |
| Özel geliştirme | Site ürünün kendisi, ya da entegrasyonlar diğerlerini eliyor | En yüksek maliyet, bakım da sizde |

Q: Planlama ne kadar sürmeli?
A: Küçük bir işletme sitesi için bir iki haftalık gerçek çalışma — geçen zaman değil. Mağaza ya da uygulama için üç ile altı hafta, çoğu belgelerde değil içerik envanteri ve ürün verisinde geçer. Planlama aylara yayılıyorsa bu genelde birincil hedefin kararlaştırılmadığı ve tartışmanın döndüğü anlamına gelir.

Q: Resmî bir gereksinim belgesi şart mı?
A: İki tarafın da gösterebileceği yazılı bir şey gerekli ama uzun olmak zorunda değil. Bir sayfa yapısı, kapsam içindeki özelliklerin listesi, açıkça kapsam dışı bırakılanların listesi ve sayfa başına bir içerik sahibi, kimsenin bitirmediği elli sayfalık bir şartnameden daha çok anlaşmazlığı önler. Kapsam dışı listesi atlanan ve projeyi kurtaran parçadır.

Q: Bu aşamada tasarımı da planlamalı mıyım?
A: Yapıyı planlayın, görünüşü değil. Hangi sayfaların var olacağına ve her birinin ne başaracağına karar vermek planlamadır; renk ve yazı tipi seçmek tasarımdır ve yapı belli olmadan yapılırsa gerçek içerik geldiğinde tasarım baştan dizilir. Tel çerçeveler ikisinin arasındaki işe yarar orta noktadır.

Q: Gereksinimler proje ortasında değişirse?
A: Değişecek. Önemli olan, değişikliklerin nasıl ele alınacağını önceden anlaşmış olmanız: kim talep edebilir, kim fiyatlar ve yayın tarihini değiştirir mi. Değişiklik süreci olan bir proje kontrollü biçimde gecikir; olmayan bir proje tartışarak gecikir.

## Gerçekten Önemli Olan Website Geliştirme Araçları
https://websitedevelopment.biz/tr/guides/website-gelistirme-araclari
Güncelleme 2026-08-07 · Website geliştirme

Araç listeleri hızla eskir ve bir website yaptıran kişiye nadiren yardım eder. Kalıcı olan şey, yetkin bir projenin kullandığı *kategoriler* ve bunların yokluğunun projenin nasıl gideceği hakkında size ne söylediğidir.

Bu rehber önemli olan araç kategorilerini, her birinin neyi önlediğini ve bir geliştiricinin bu şekilde çalışıp çalışmadığını ortaya çıkaran soruları ele alıyor.

### Tartışmaya açık olmayan kategoriler
Bunlar tercih değildir. Bunlar olmadan bir proje, en kötü anda — genelde bir şey bozulduğunda ve neyin değiştiğini kimse söyleyemediğinde — ortaya çıkan risk biriktirir.
| Sürüm kontrolü | Kaybolan iş, açıklanamayan değişiklik, geri alamama | "Kod hangi depoda ve erişebilir miyim?" |
| Staging ortamı | Canlıda test etmeyi | "Yayına girmeden nerede inceliyorum?" |
| Otomatik dağıtım | Cuma akşamı elle dosya kopyalayan bir insanı | "Bir değişiklik canlıya nasıl gidiyor?" |
| Yedekler | Tam kaybı | "Ne sıklıkla, nereye ve en son ne zaman geri yüklediniz?" |
| Hata izleme | Haftalarca fark edilmeyen sessiz arızaları | "Bir şeyin bozulduğunu nasıl öğreniyorsunuz?" |
| Erişilebilirlik izleme | Müşteriden öğrenmeyi | "Site çöktüğünde kim uyarılıyor?" |
| Bağımlılık güncellemesi | Bilinen açıkların yerinde kalmasını | "Güvenlik güncellemeleri nasıl uygulanıyor?" |
En güçlü tek sinyal, "bir değişiklik canlıya nasıl gidiyor?" sorusunun cevabıdır. Cevap dosyaları bir FTP istemcisine sürüklemeyi içeriyorsa, bu listedeki diğer her şey de muhtemelen eksiktir.

### Derleme ve front-end araçları
Modanın en hızlı değiştiği ve müşteri olarak sizi en az ilgilendiren yer burasıdır. Önemli olan üreten araç değil sonuçtur.
- Bir derleme adımı varlıkları küçültsün, paketlesin ve optimize etsin — sayfa ağırlığı bir saflık değil dönüşüm sorunudur.
- Görsel hattı modern formatları ve birden çok boyutu otomatik üretsin. Elle dışa aktarılan görseller hiçbir zaman güncel kalmıyor.
- Sistemi olan bir CSS yaklaşımı — değişkenler, token’lar, adı ne olursa olsun — tek seferlik kural biriktirmek yerine.
- Yalnız sayfanın ihtiyaç duyduğu JavaScript. Bir çatı, uygulama için meşru bir seçim ve tanıtım sitesi için genelde yüktür.
- Yazılı tarayıcı desteği. "Modern tarayıcılar" bir şartname değildir.

### Test ve kalite araçları
Bir pazarlama sitesinde tam otomatik test paketleri nadiren haklı çıkar. Para kazandıran yollarda az miktarda otomasyon neredeyse her zaman haklı çıkar.
- Yalnız kritik yollarda otomatik kontroller: ödeme, kayıt, ana iletişim formu.
- Otomatik kontrol edilen bir performans bütçesi — umut değil, derlemeyi düşüren bir sayı.
- Hattın içinde otomatik erişilebilirlik taraması, sorunların yaklaşık üçte birini yakaladığını bilerek.
- Her şeyin listesinde değil, analitiğinizin gerçekten gösterdiği tarayıcılarda kontrol.
- Zor olanlar dahil gerçek içerik uzunluklarını yansıtan bir staging içerik kümesi.
Bir içerik sitesi için en yüksek değerli otomasyon performans bütçesidir: onsuz sayfa ağırlığı her ay sessizce artar ve kimse sorumlu değildir.

### Neye erişiminiz olmalı
Geliştiricinin tercih ettiği araçlar ne olursa olsun, bu hesaplar ilk günden sizin adınıza olmalı. Başlangıçta ayarlamak, bir ilişki bittikten sonra ayarlamaktan çok daha kolaydır.
- Alan adı kaydı — kurumunuzun adına, sizin fatura bilgilerinizle.
- Hosting hesabı, geliştirici sahip olarak değil kullanıcı olarak eklenmiş.
- Kod deposu, sahibi kurumunuz olacak şekilde.
- Analitik ve Search Console mülkleri.
- Sitenin bağımlı olduğu her üçüncü taraf hizmet: ödeme, e-posta, CDN, hata izleme.
- Bunların ekibinizin bulabileceği bir yerde tutulan yazılı listesi.

Q: Bu araçları anlamam gerekir mi?
A: Hayır, ama var olup olmadıklarını ve erişimin kimde olduğunu sormalısınız. Yukarıdaki tablodaki sorular yetkin herhangi bir geliştirici tarafından birer cümleyle cevaplanabilir ve dağıtım ile yedek sorularındaki tereddüt bir üslup meselesi değil gerçek bir sinyaldir.

Q: JavaScript çatısı şart mı?
A: Bir web uygulaması için genelde evet. Bir pazarlama ya da içerik sitesi için genelde hayır — ve çoğu zaman karşılığında bir fayda vermeden performans kaybettirir, çünkü tarayıcı HTML’de gelebilecek bir metni göstermeden önce bir çatıyı indirip çalıştırmak zorunda kalır. Doğru soru sizin sitenizde hangi sorunu çözdüğüdür ve "biz bunu kullanıyoruz" bir cevap değildir.

Q: Performans bütçesi nedir?
A: Üzerinde anlaşılmış bir sınır — örneğin ana şablonlarda 200KB’ın altında JavaScript ve 2,5 saniyenin altında Largest Contentful Paint — otomatik kontrol edilir ve aşıldığında derlemeyi düşürür. İşe yaramasının sebebi, performansı herkesin önemli bulduğu bir şeyden bir dağıtımı engelleyen bir şeye çevirmesidir.

Q: Sitenin bakımının yapıldığını nasıl bilirim?
A: Aylık bir not isteyin: ne güncellendi, ne yamalandı, erişilebilirlik neydi ve hangi hatalar çıktı. Bir bakım anlaşması hiçbir rapor üretmiyorsa, özenli bakımla hiç bakımı ayırt etmek zordur ve bunu genelde bir olay sırasında öğrenirsiniz.

## Özel Website Geliştirme mi Hazır Tema mı?
https://websitedevelopment.biz/tr/guides/ozel-website-gelistirme-vs-hazir-tema
Güncelleme 2026-08-07 · Website geliştirme

Hazır tema, önceden yapılmış bir tasarım ve kod tabanını yapılandırmanızdır. Özel geliştirme sizin gereksinimlerinize göre yapılır. Hazır temalar, temanın yapmadığı bir şeye ihtiyaç duyduğunuz ana kadar daha ucuz ve daha hızlıdır — o noktadan sonra baştan özel başlamaktan pahalıya gelirler.

Bu rehber o noktanın genelde nerede olduğunu, birkaç yıl üzerinden gerçek maliyet farkını ve çoğu siteye uyan melez yaklaşımı ele alıyor.

### Dürüst karşılaştırma
İki yaklaşım da meşru. Soru şu: önümüzdeki üç yıl hangi kısıt kümesiyle yaşamayı tercih edersiniz?
| Ön maliyet | Düşük | Yüksek |
| Yayına çıkma süresi | Günler–haftalar | Haftalar–aylar |
| Performans | Genelde zayıf — kullanmadığınız özellikleri taşır | Ödediğiniz kadar iyi |
| Tasarımda ayırt edicilik | Tema olduğu belli | Size ait |
| Sıra dışı gereksinimler | Size direnir | Baştan tasarlanır |
| Bakım | Satıcının var olmaya devam etmesine bağlı | Sizin planınıza bağlı |
| Oradan çıkmak | Zor — mantık tema ayarlarında yaşıyor | Daha kolay — kod sizin |

### Hazır temalar nerede tavana çarpar
Tavan nadiren görseldir. Temalar genelde ikna edici biçimde yeniden biçimlendirilebilir. Direndikleri şey yapısal gereksinimlerdir ve bunlar yayından altı ay sonra ortaya çıkar.
- Temanın öngörmediği bir içerik türü. Alanları yapılandırılmış vaka çalışmaları, bir dizin, mantığı olan bir etkinlik takvimi.
- Entegrasyonlar. Tema kendi iletişim formunu varsayar; sizin veriye kendi alan eşlemenizle CRM’de ihtiyacınız var.
- Performans hedefleri. Temalar her alıcı için her özelliği taşır, yani hiç kullanmayacağınız bir sayfa kurucu, bir slider kütüphanesi ve üç ikon fontu indirirsiniz.
- Erişilebilirlik. Temanın bileşenleri erişilebilir değilse düzeltmek temayı düzenlemek demektir — bu da güncellemeleri bozar.
- Çok dilli yapı. Sonradan eklenen çeviri eklentileri, geri alması zor URL yapıları üretir.
- Editoryal iş akışı. Çoklu yazar, onay ve zamanlama genelde bir temanın verdiğinin ötesindedir.
Pahalı olan kalıp hazır tema seçmek değildir. Hazır tema seçip iki yıl boyunca onunla boğuşması için geliştiriciye para ödemektir.

### Üç yıllık toplam maliyet
Yalnız yapım fiyatlarını karşılaştırmak hazır temayı kayırır. İlgili karşılaştırma lisansları, eklentileri, sınırlamaları aşmak için harcanan geliştirici zamanını ve tema terk edildiğinde ne olduğunu içerir.
| İlk yapım | Düşük | Yüksek |
| Tema ve eklenti lisansları | Yıllık ve artıyor | Yok |
| Etrafından dolaşma geliştirmesi | Her yıl birikiyor | Düşük |
| Performans onarımı | Sık | İyi yapıldıysa nadir |
| Ana sürüm yükseltmesi | Özelleştirmeleri bozabilir | Kontrollü |
| Satıcı ürünü terk ediyor | Zorunlu yeniden yapım | Geçerli değil |
Gerçekten basit bir site için hazır tema üç yılda rahatça kazanır. Kesişme, temanın sahip olmadığı ilk yapısal gereksinimle gelir.

### Çoğu sitenin aslında ihtiyaç duyduğu melez
Yaygın orta yol, yerleşik bir platform üzerinde özel bir tema: CMS’i, ekosistemi ve güvenlik güncellemelerini alırsınız ve front-end satın alınmış bir temanın değil sizin olur.
- Yerleşik bir CMS ya da ticaret platformu kullanın — içerik yönetimini sıfırdan yazmayın.
- Tema satın almak yerine front-end şablonlarını kendiniz kurun. Performans ve ayırt edicilik burada yaşıyor.
- Eklentileri yalnız gerçekten standart işler için kullanın: ödeme, SEO meta verisi, yedekler, formlar.
- İşinize özgü her şey için özel kod yazın, böylece bir eklenti yazarına rehin kalmaz.
- Bağımlılık sayısını bilinçli olarak küçük tutun; her biri bir güncelleme, bir lisans ve olası bir açıktır.

Q: Hazır temayla başlayıp sonra özele geçebilir miyim?
A: Evet ve geçişin gerçek bir proje olduğunu bilerek girerseniz makul bir plandır. İçerik yapısını ilk günden temiz ve taşınabilir tutun — sonraki taşımanın bir hafta mı yoksa bir çeyrek mi süreceğini belirleyen parça odur. Taşımayı acı yapan şey tema ayarlarına ve eklenti yapılandırmasına gömülmüş iş mantığıdır, o yüzden orada mümkün olduğunca az şey tutun.

Q: Hazır temalar SEO için kötü mü?
A: Doğaları gereği değil ama çoğu yavaştır ve hız hem bir sıralama hem bir dönüşüm faktörüdür. Yaygın sorunlar şişkin JavaScript, optimize edilmemiş görseller ve düzgün başlık yapısı ile yapısal veriyi zorlaştıran işaretlemedir. İyi seçilmiş sade bir tema gayet iyi olabilir; kırk modüllü bir sayfa kurucu teması genelde olmaz.

Q: Bir temayı satın almadan nasıl değerlendiririm?
A: Canlı demoyu bir performans testinden geçirin ve pazarlama sayfasına değil sayfa ağırlığına ve betik sayısına bakın. Güncelleme geçmişine bakın — on sekiz aydır güncellenmemiş bir tema yüktür. Demoyu yalnız klavyeyle deneyin. Ve destek forumunda yazarın hata bildirimlerine nasıl yanıt verdiğine bakın; sonraki üç yılınızı o öngörür.

Q: Küçük bir işletme için özel geliştirme değer mi?
A: Düz bir tanıtım sitesi için genelde değmez — o para içeriğe ve fotoğrafa harcansa sonuçları daha çok hareket ettirir. Site işinize özgü bir şey yaptığında değmeye başlar: bir konfigüratör, sıra dışı bir rezervasyon akışı, operasyonu yürüttüğünüz sistemle entegrasyon. Yalnız ayırt edici görünüm bu farkı nadiren haklı çıkarır.

## Website Geliştirme Süreci Açıklandı
https://websitedevelopment.biz/tr/guides/website-gelistirme-sureci
Güncelleme 2026-08-07 · Website geliştirme

Her website geliştirme yöntemi aynı aşamaları farklı dizer. Yöntemin adından çok aşamaların kendisini — her birinin ne ürettiğini ve neyin kapattığını — anlamak işe yarar, çünkü projenin olması gereken yerde olup olmadığını size o söyler.

Bu rehber yedi aşamayı, orta ölçekli bir site için tipik süreleri ve her birinde gerçek bir onayın neye benzediğini ele alıyor.

### Yedi aşama
Buradaki süreler küçük bir ekiple orta ölçekli özel bir siteyi varsayıyor. Sayfa sayısından çok içerik hacmi ve entegrasyonlarla uzarlar.
| 1. Keşif | Hedefler, kitle, kapsam, kısıtlar | 1–2 hafta |
| 2. Yapı | Sayfa yapısı, içerik modeli, tel çerçeveler | 1–2 hafta |
| 3. Tasarım | Şablonlar, bileşen sistemi, duyarlı kurallar | 2–4 hafta |
| 4. Yapım | Çalışan şablonlar, CMS, entegrasyonlar | 4–10 hafta |
| 5. İçerik | Sistemdeki gerçek metin, görsel ve veri | Paralel yürür — çoğu zaman en uzunu |
| 6. Test | İşlevsel, tarayıcılar arası, performans, erişilebilirlik | 1–2 hafta |
| 7. Yayın | Canlı site, yönlendirmeler, izleme, devir | 2–5 gün |
Aşan aşama 5’tir. Paralel çizilmesinin sebebi küçük olması değil, 2. aşamada başlaması gerektiğidir.

### Her aşamayı ne kapatır
Bir aşama zaman geçti diye bitmez. Yetkisi olan biri belirli bir şeyi yazılı olarak onayladığında biter. Bu olmadan iş, hâlâ hareket edebilen bir zemin üzerinde sürer.
- Keşif: açık bir kapsam dışı listesiyle imzalanmış kapsam.
- Yapı: onaylanmış sayfa yapısı ve ekibinizin anladığı alan adlarıyla içerik modeli.
- Tasarım: mobil ve boş durumlar dahil her farklı düzen için onaylı şablonlar.
- Yapım: her şablonun staging’de gerçekçi içerikle gösterilmesi.
- İçerik: yayın için gerekli her sayfanın doldurulup adı belli biri tarafından okunması.
- Test: üzerinde anlaşılmış, yayını engelleyenler ve sonrası diye ayrılmış bir sorun listesi.
- Yayın: tamamlanmış yayın öncesi kontrol listesi ve doğrulanmış erişim devri.

### Şelale, çevik ya da arası
Gerçek fark kapsamın ne zaman sabitlendiğidir. Sabit kapsamlı projeler kesin fiyatlanır ve değişikliği kötü yönetir; iteratif projeler değişikliği iyi yönetir ve sabit bir toplam vaat edemez. Website işlerinin çoğu ikisinin arasındadır: yayın için sabit kapsam, sonrası iteratif.
| Fiyat | Baştan belli | Sprint ya da ay başına ücret |
| Değişiklik | Resmî talep, yeniden fiyatlanır | Öncelik değiştirilerek soğurulur |
| Kime uyar | Net ve durağan gereksinimler | Gelişen ürünler ve belirsiz gereksinimler |
| Sizin riskiniz | Artık uymayan bir şeye para ödemek | Maliyetin sert bir durak olmadan sürüklenmesi |
| Sizden istenen | Baştan kararlar | Öncelik belirlemek için sürekli erişilebilirlik |
Muğlak kapsamla sabit fiyattan kaçının. En kötü bileşim budur: geliştirici belirsizliği dar yorumlayarak kârını korur ve her açıklama bir pazarlığa dönüşür.

### Süreç genelde nerede bozulur
Aşımların çoğunu aynı dört aksaklık üretir ve hiçbiri teknik değildir.
- Yer tutucu içerikle onaylanan tasarım. Gerçek metin iki katı uzunlukta gelir ve düzen yeniden kurulur.
- Geç keşfedilen entegrasyonlar. Sekizinci haftada "bir de stok sistemimizle konuşması lazım" bir değişiklik değil yeni bir projedir.
- Tek karar verici yok. Geri bildirim beş kişiden gelir, ikisi çelişir ve kimsenin çözme yetkisi yoktur.
- Testin alışkanlık değil aşama sayılması. Üçüncü haftada girmiş bir hatayı onuncu haftada bulmak birkaç kat pahalıya düzeltilir.

Q: Tipik bir website ne kadar sürer?
A: Şablon tabanlı küçük bir site iki ile dört hafta. Orta ölçekli özel bir site uçtan uca genelde üç ile beş ay. Mağazalar ve uygulamalar daha uzun. Bunları en çok hareket ettiren değişken kodun karmaşıklığı değil, müşteri tarafında içeriğin hazır olması ve kararların hızıdır.

Q: Aşamalar üst üste binebilir mi?
A: Bazıları binmeli. İçerik yapı aşamasında başlamalı, test ise yalnız sonda değil yapım boyunca yürümeli. Binmemesi gereken şey aynı şablonun tasarımı ile yapımıdır — hâlâ hareket eden bir tasarıma göre inşa etmek yeniden işi garantiler ve "biz bunu zaten yapmıştık" tartışmalarının en yaygın kaynağıdır.

Q: Proje ortasında bir şeyi değiştirmemiz gerekirse?
A: Gerekeceğini varsayın ve mekanizmayı baştan anlaşın: kim talep edebilir, kim fiyatlar ve yayın tarihini değiştirir mi. Sessizce soğurulan küçük değişiklikler, bir projenin ne zaman olduğunu kimsenin söyleyemediği bir ay sürüklenmesinin yoludur. Yazılı bir değişiklik kaydı bunun çoğunu çözer.

Q: Aşama başına mı ödemeliyim?
A: İnceleyebileceğiniz teslimatlara bağlanmış kilometre taşı ödemeleri iki taraf için de en adil yapıdır — genelde bir kapora, sonra tasarım onayında, yapım bitiminde ve yayında ödemeler. Tamamını peşin ödemekten kaçının; tamamını bitişte ödemekten de, çünkü nakit akışı riskinin tamamını geliştiriciye yükler ve genelde size daha pahalıya gelir.

## Website Geliştirme Nasıl İşler? Sürecin Tamamı
https://websitedevelopment.biz/tr/guides/website-gelistirme-nasil-isler
Güncelleme 2026-08-07 · Website geliştirme

Dışarıdan bakınca website geliştirme, uzun bir sessizliğin ardından gelen bitmiş bir site gibi görünebilir. Pratikte ortamlar, kontrol noktaları ve kararlardan oluşan bir dizidir ve müşteri tarafının neredeyse her birinde yükümlülüğü vardır.

Bu rehber bir projenin gerçekte nasıl yürüdüğünü, sizden ne zaman ne isteneceğini ve bir sorunun hâlâ ucuz olduğu kontrol noktalarını ele alıyor.

### Ortamlar: site yayına girmeden nerede yaşar
Neredeyse her profesyonel proje sitenin üç kopyasını çalıştırır. Hangisine baktığınızı bilmek inceleme sırasındaki büyük bir karışıklığı önler.
| Yerel | Geliştirici | Günlük çalışma; siz bunu hiç görmezsiniz |
| Staging | Siz ve geliştirici | İnceleme, test ve onay — arama motorlarına kapalı |
| Canlı | Ziyaretçiler | Yayındaki site |
Staging’e eklenen içerik, proje bunun için kurulmadıysa otomatik olarak canlıya geçmez. Erken sorun; 200 ürünü iki kez yazmak gerçek bir risktir.

### Tipik bir yapımın sırası
Adlar ekipten ekibe değişir ama sıra epeyce tutarlıdır, çünkü her adım bir öncekine bağlıdır.
- Başlangıç. Gereksinimler doğrulanır, erişimler verilir, kişiler belirlenir, tarihler anlaşılır.
- Kurulum. Depo, ortamlar, CMS ya da çatı kurulumu, dağıtım hattı.
- Şablonlar. Tasarım çalışan şablonlara dönüşür, genelde en karmaşığı önce.
- İçerik modelleme. Ekibinizin düzenleri bozmadan düzenleyebilmesi için alanlar ve içerik türleri.
- Entegrasyonlar. Ödeme, CRM, e-posta, analitik — her biri sizden kimlik bilgisi ister.
- İçerik girişi. Teklifin söylediğine göre sizde ya da onlarda.
- Test. İşlevsel, tarayıcılar arası, performans, erişilebilirlik.
- Yayın öncesi kontroller. Yönlendirmeler, robots, site haritası, analitik, yedekler.
- Yayın. DNS değişikliği, doğrulama, izleme.
- Yayın sonrası. Düzeltmeler, devir, eğitim, sonra bakım.

### Sizin tarafınız ne zaman ne teslim etmeli
Geliştirici gecikmesi gibi görünen gecikmelerin çoğu müşteri bekleme gecikmesidir. Bunlar istenmeden önce hazır olması gereken kalemler, çünkü her biri geciktiğinde işi durdurur.
| Alan adı ve DNS erişimi | Kurulum | Yayın tarihi planlanamaz |
| Marka varlıkları ve logo dosyaları | Şablonlar | İncelemeler boyunca yer tutucu marka |
| Sayfa içeriği ve görseller | İçerik girişi | Kaçırılan yayın tarihinin en yaygın sebebi |
| Ürün verisi | İçerik girişi | Mağaza yapımı tamamen durur |
| Üçüncü taraf kimlik bilgileri | Entegrasyonlar | Entegrasyon işi sprint ortasında bloke olur |
| Her incelemeye geri bildirim | Her kontrol noktası | Yeniden iş, çünkü yapım ilerlemiştir |
| Hukuki sayfalar | Yayın öncesi | Bir gizlilik politikası için yayın gecikir |

### Sorunun hâlâ ucuz olduğu kontrol noktaları
Değişiklik maliyeti proje boyunca hızla yükselir. Bunlar göz gezdirmek yerine düzgün bakılacak anlar, çünkü her birinden sonra aynı değişiklik birkaç kat pahalıya gelir.
- Tel çerçevelerden sonra: yapı ve öncelik hâlâ bedavaya değişir.
- İlk şablon yapıldıktan sonra: tasarımın gerçek içerikte ayakta kalıp kalmadığını burada öğrenirsiniz.
- İçerik modellemeden sonra: bir sayfayı kendiniz düzenlemeyi deneyin. Şimdi zahmetliyse yıllarca zahmetli kalır.
- İlk entegrasyondan sonra: verinin ekibinizin gerçekten çalıştığı yere düştüğünü doğrulayın.
- Gerçek içerikle staging’de: düzen sorunlarının ucuz olduğu son nokta.
- DNS değişikliğinden önce: yönlendirmeler, analitik ve formlar doğrulanmış.
Telefonda inceleme isteğe bağlı değil. Çoğu site trafiğinin çoğunu telefondan alıyor ve yalnız masaüstünde inceleme, mobil sorunların canlıya ulaşma yoludur.

Q: Proje benim ne kadar zamanımı alacak?
A: Çoğu kişinin ayırdığından fazlasını. Haftada otuz ile altmış dakikalık bir kontrol noktası, artı saatlerle değil günlerle ölçülen içerik işi bekleyin. Bir projenin zamanında bitmesinin en güçlü göstergesi, müşteri tarafında karar verme yetkisi ve inceleme zamanı olan tek bir kişinin bulunmasıdır.

Q: Sprint nedir ve beni ilgilendirir mi?
A: Sprint, üzerinde anlaşılmış bir iş kümesinin tamamlanıp size gösterildiği sabit bir süredir — genelde bir ya da iki hafta. Sizi ilgilendirir çünkü kararların ritmini belirler: sprint sırasında verilen geri bildirim ucuzdur, üç sprint sonra verilen geri bildirim yeniden iştir. Geliştiriciniz sprintle çalışmıyorsa da aynı sebeple düzenli bir kontrol noktası istersiniz.

Q: Site bitmeden ilerlemeyi görebilir miyim?
A: Evet ve görmelisiniz. İlk şablondan itibaren staging erişimi isteyin. Yarım işi görmek rahatsız edicidir ama sonda yapılan bir "tadaa"dan çok daha iyidir, çünkü orada yapısal geri bildirim pahalıdır. Bitmemiş görünmesini bekleyin — erken bakmanın anlamı zaten bu.

Q: Yayından hemen sonra ne olur?
A: Kısa bir dönem — genelde iki ile dört hafta — küçük düzeltmelerin kapsandığı, sonra bir bakım anlaşmasına ya da hiçbir şeye geçiş. Hangisi olduğunu, neyin düzeltme neyin yeni talep sayıldığını ve site çökerse mesai dışında kimi arayacağınızı önceden anlaşın. "Sonra hallederiz" sitelerin bakımsız kalma yoludur.

## Website Geliştirme Nedir? Kapsamlı Rehber
https://websitedevelopment.biz/tr/guides/website-gelistirme-nedir
Güncelleme 2026-08-07 · Website geliştirme

Website geliştirme, bir tasarımı ve bir gereksinim kümesini çalışan bir siteye dönüştürme işidir: ziyaretçinin gördüğü işaretleme ve biçimlendirme, arkasındaki sunucu mantığı ve verisi, artı onu çalışır tutan dağıtım ve bakım.

Bu rehber terimin neleri içerdiğini, web tasarımdan nasıl ayrıldığını, front-end/back-end ayrımının pratikte ne anlama geldiğini ve belirli bir projenin hangi parçalara ihtiyaç duyduğunu ele alıyor.

### Terim neleri kapsıyor
"Website geliştirme", bir tema kurmaktan özel bir uygulama yazmaya kadar her şey için kullanılıyor. Değişmeyen şey sıradır: gereksinimler şablona, şablonlar sayfaya, sayfalar veriye dönüşür; sonra bütün bu yapı dağıtılır, ölçülür ve bakımı yapılır.

Tasarım nasıl göründüğüne ve nasıl davrandığına karar verir. Geliştirme onu var eder, hızlı çalıştırır, gerçek içerikte ayakta tutar ve yayından sonra çalışır kılar.
- Front-end: ziyaretçinin tarayıcısında çalışan HTML, CSS ve JavaScript.
- Back-end: veriyi sağlayan ve saklayan sunucu tarafı kodu, veritabanı ve API’ler.
- CMS işi: geliştirici olmayanların içeriği güvenle düzenleyebilmesi için şablonlar ve alanlar.
- Entegrasyonlar: ödeme, CRM, e-posta, analitik, kargo, rezervasyon, ERP.
- Altyapı: hosting, alan adları, sertifikalar, CDN, yedekler, dağıtım.
- Kalite: test, performans, erişilebilirlik, güvenlik, izleme.

### Website geliştirme ile web tasarım
Bu iki ifade genelde birlikte fiyatlanır ve gerçekten farklı işlerdir. Küçük projelerde tek kişi ikisini de yapar; büyüklerde ayrı kişilerdir ve hangisini satın aldığınızı bilmek yaygın bir anlaşmazlık türünü önler.
| Soru | Nasıl görünmeli ve nasıl davranmalı? | Çalışması için nasıl kurulur? |
| Çıktı | Tel çerçeveler, görsel tasarımlar, bileşen sistemi | Çalışan şablonlar, veri modelleri, dağıtılmış site |
| Ana araçlar | Tasarım yazılımı, prototipleme araçları | Kod editörü, sürüm kontrolü, derleme araçları, CMS |
| Başarısızlık biçimi | Kafa karıştıran ya da markaya uymayan site | Yavaş, bozulan ya da düzenlenemeyen site |
| Değişiklik maliyeti | Tel çerçeve aşamasında dakikalar | Yapıldıktan sonra saatler ya da günler |
Bir teklif ikisini ayırmıyorsa, elinizde zaten bir tasarım varsa ne olacağını sorun. Cevap size gerçekte hangi işin fiyatlandığını söyler.

### Pratikte front-end ve back-end
Ayrım kıdemle değil kodun nerede çalıştığıyla ilgilidir. Front-end kodu ziyaretçinin tarayıcısında çalışır, dolayısıyla çizim, etkileşim, duyarlılık ve erişilebilirlikle ilgilenir. Back-end kodu bir sunucuda çalışır, dolayısıyla veri, kimlik doğrulama, iş kuralları ve entegrasyonlarla ilgilenir.

Bir pazarlama sitesi neredeyse tamamen front-end olabilir ve içeriği bir CMS besler. Bir mağaza ya da uygulama ciddi back-end işi ister, çünkü paranın, stoğun ve hesapların tarayıcıya emanet edilemeyecek kuralları vardır.
| CMS üzerinde tanıtım sitesi | İşin çoğu | Yalnız şablonlar ve alanlar |
| Arama ve filtreli içerik sitesi | Yüksek | Orta — indeksleme ve sorgular |
| Online mağaza | Yüksek | Yüksek — katalog, ödeme, vergi, sevkiyat |
| Rezervasyon sitesi | Orta | Yüksek — müsaitlik, çakışma, bildirim |
| Web uygulaması | Yüksek | Çok yüksek — hesaplar, yetkiler, iş mantığı |

### Bir website geliştirme projesi gerçekte neyi teslim eder
"Site"nin ötesinde, sözleşmede adı geçmeye değer teslimatlar bunlar — çünkü yokluğu ancak ihtiyaç duyduğunuzda, genelde ilk geliştirici artık ulaşılabilir değilken fark edilir.
- Erişiminizin olduğu bir depoda kaynak kod.
- Hosting, alan adı ve üçüncü taraf hesaplara erişim, sizin adınıza.
- Bir değişikliği yayına almanın belgelenmiş yolu; bunu bilen tek bir kişi değil.
- Ekibinizin gerçekten düzenlediği içerik türlerini içeren bir CMS ya da yönetim alanı.
- Bir kez geri yüklenmiş yedekler, böylece çalıştığını biliyorsunuz.
- Entegrasyonların ve kimlik bilgilerinin nerede durduğunun dokümantasyonu.
- İçeriği bakacak kişi için eğitim ya da devir oturumu.
Bir website geliştirme sözleşmesindeki en değerli madde, kodun ve hesapların size ait olduğunu söyleyen maddedir. Diğer her şey yeniden pazarlık edilebilir; ilişki bittikten sonra o edilemez.

Q: Website geliştirme ile web geliştirme aynı şey mi?
A: Çoğu bağlamda birbirinin yerine kullanılıyor. "Web geliştirme" biraz daha geniştir ve genelde tam olarak website olmayan web uygulamalarını ve API’leri de kapsar; "website geliştirme" genelde sayfaları ve içeriği olan bir siteyi ima eder. Bir brief’te önemli olan ayrım ifade değil, projede özel iş mantığı olup olmadığıdır — maliyeti ve gereken beceriyi değiştiren odur.

Q: Site kurucu kullanıyorsam geliştiriciye ihtiyacım var mı?
A: Basit bir site için genelde yok ve bu meşru bir tercih. Kurucuların kötü yaptığı şeyler için yine de isteyebilirsiniz: performans, yapısal veri, mevcut sistemlerinizle entegrasyon ve ileride oradan çıkmak. Yaygın bir kalıp: siteyi kendiniz kurup belirli bir sorun için geliştirici çağırmak.

Q: Full-stack geliştirici ne demek?
A: Hem front-end hem back-end üzerinde çalışan kişi. Küçük ve orta ölçekli website projelerinde yetkin bir full-stack geliştirici genelde en verimli tercihtir, çünkü iki uzman arasındaki devir maliyeti derinlik faydasını aşar. Büyük projelerde uzmanlaşma değer, çünkü her tarafta gereken derinlik tek kişinin kapsayabileceğinden hızlı büyür.

Q: Bir website’in ne kadarı kod, ne kadarı içerik?
A: Emek olarak içerik genelde daha büyük yarıdır ve neredeyse her zaman takvim riskidir. Yapım bitmiş olabilir ve site ürün açıklamaları, fotoğraflar ve hukuki sayfalar yazılmadığı için hâlâ haftalarca yayından uzak olabilir. İçeriği geliştirme kilometre taşlarıyla aynı ciddiyetle planlayın; yayın tarihi o zaman tutulabilir hâle gelir.