WordPress

    WordPress Sertlestirme (Hardening) Kontrol Listesi

    WordPress'i sertlestirmek icin uygulanabilir guvenlik kontrol listesi

    13 dk okuma Güncellendi: 10 Temmuz 2026

    WordPress internetteki sitelerin çok büyük bir bölümünü çalıştırıyor ve tam da bu yaygınlık, onu saldırganlar için birinci sınıf bir hedef hâline getiriyor. Bir saldırganın çoğu zaman sizi özel olarak seçmesine gerek yok; otomatik botlar gün boyunca wp-login.php adreslerini, bilinen eklenti açıklarını ve zayıf parolaları tarıyor. Yıllardır barındırma tarafında yüzlerce ele geçirilmiş kurulumu temizledikten sonra söyleyebilirim ki bu sitelerin neredeyse tamamı, birbirini tekrar eden bir avuç ihmalin kurbanı oluyor: güncellenmemiş bir eklenti, admin kullanıcı adı, herkese açık bir yönetim paneli ve tek başına yeterli olmayan bir parola.

    Sertleştirme (hardening) tam da bu ihmalleri kapatma sanatıdır. Amaç kusursuz, kırılmaz bir sistem kurmak değil; saldırganın işini o kadar zorlaştırmaktır ki otomatik botlar başka bir hedefe geçsin, hedefli bir saldırgan ise birden fazla katmanı aşmak zorunda kalsın. Bu rehberde WordPress'i katman katman nasıl sertleştireceğinizi gerçek komutlar ve yapılandırma örnekleriyle anlatıyorum. Her maddeyi kısa gerekçesiyle veriyorum, çünkü neden yaptığınızı bilmeden uygulanan güvenlik önlemi ilk zorlukta geri alınır. Konuya sıfırdan giriyorsanız önce WordPress güvenliği temelleri yazısını, sunucu tarafını merak ediyorsanız sunucu güvenliği temelleri rehberini okumanızı öneririm.

    Sertleştirme (Hardening) Nedir ve Neden Gerekli#

    Sertleştirme, bir sistemin saldırı yüzeyini bilinçli olarak küçültme işidir. WordPress varsayılan hâliyle "her senaryoda çalışsın" mantığıyla gelir: dosya düzenleyici açıktır, herkes kayıt olabilir, XML-RPC etkindir, sürüm bilgisi kaynak kodunda görünür. Bu esneklik geliştiriciye kolaylık sağlar ama saldırgana da kapı aralar. Sertleştirme, ihtiyacınız olmayan her özelliği kapatıp geriye yalnızca kullandığınız işlevleri bırakma disiplinidir.

    Bunu "derinlemesine savunma" (defense in depth) mantığıyla düşünün. Tek bir önlem değil, üst üste binen katmanlar. Botun wp-login.php'ye erişememesi bir katmandır; erişse bile parolayı kıramaması ikinci katman, kırsa bile 2FA kodunu bilememesi üçüncü katmandır. Katmanlardan biri delinse dahi diğerleri saldırıyı durdurur. Aşağıdaki bölümlerin her biri bu katmanlardan birini örer; hiçbiri tek başına yeterli değildir, ama birlikte ciddi bir bariyer oluşturur.

    Dosya Düzenleyiciyi Kapatmak (DISALLOW_FILE_EDIT)#

    WordPress yönetim panelinde Görünüm > Tema Dosya Düzenleyicisi ve Eklentiler > Eklenti Dosya Düzenleyicisi ekranları vardır. Bir saldırgan yönetici hesabınızı ele geçirirse, buradan tek bir tema dosyasına PHP arka kapısı (backdoor) yazarak sunucuda kod çalıştırabilir. Yani panel erişimi, doğrudan sunucuda kod yürütme yetkisine dönüşür. Bu düzenleyiciye üretimde neredeyse hiç ihtiyacınız yoktur; dosya değişikliklerini SFTP veya sürüm kontrolüyle yapmak hem daha güvenli hem de daha izlenebilirdir.

    Düzenleyiciyi kapatmak için wp-config.php dosyanıza tek satır eklemeniz yeterli:

    // wp-config.php içine, "That's all, stop editing!" satırının üstüne ekleyin
    define( 'DISALLOW_FILE_EDIT', true );
    

    Daha ileri gitmek isterseniz, panelden eklenti/tema kurulumunu ve güncellemesini de tümüyle kapatabilirsiniz. Bu, otomatik güncellemeyi dış bir süreçle (WP-CLI veya CI/CD) yönettiğiniz kurulumlarda mantıklıdır:

    // Tüm dosya değişiklikleri panelden engellenir (kurulum + güncelleme dahil)
    define( 'DISALLOW_FILE_MODS', true );
    

    DISALLOW_FILE_MODS sertleştirme açısından güçlüdür ama otomatik güncellemeleri de durdurur; bu yüzden onu açtıysanız güncellemeleri başka bir yöntemle düzenli yaptığınızdan emin olun. Çoğu kullanıcı için doğru denge, yalnızca DISALLOW_FILE_EDIT açık tutup güncellemeleri panelden veya WP-CLI ile sürdürmektir.

    Yonetici Kullanici Adini Gizlemek#

    Kaba kuvvet (brute force) saldırısı iki bilgiyi tahmin etmeye çalışır: kullanıcı adı ve parola. Kullanıcı adı admin ise saldırganın işinin yarısını hediye etmiş olursunuz; geriye sadece parolayı kırması kalır. WordPress'in eski kurulumları varsayılan olarak admin kullanıcısı oluştururdu ve botlar bugün hâlâ ilk denemelerini bu adla yapıyor. Bu yüzden ilk kural: admin, administrator, yonetici veya alan adınızın aynısı olan bir kullanıcı adı asla kullanmayın.

    Mevcut kurulumunuzda admin varsa, WordPress panelden kullanıcı adını değiştirmenize izin vermez. Doğru yol yeni bir yönetici oluşturup eskisini silmektir. WP-CLI ile bu birkaç saniye sürer:

    # Yeni bir yonetici olustur
    wp user create ynt_ahmet [email protected] --role=administrator
    
    # Eski 'admin' kullanicisini sil, iceriklerini yeni kullaniciya devret
    wp user delete admin --reassign=ynt_ahmet
    

    Bir de görünürlük sorunu var: WordPress, yazar arşivi sayfalarında (/?author=1 veya /author/kullaniciadi/) kullanıcı adını sızdırabilir. Bir bot /?author=1 adresine gidip yönlendiği URL'den giriş adınızı öğrenebilir. Bunu engellemek için yazar sayısal sorgusunu kapatabilirsiniz. Nginx tarafında basit bir kural iş görür:

    # /?author=N tarzi kullanici adi sizmasini engelle
    if ($args ~* "author=\d+") {
        return 403;
    }
    

    Ayrıca kullanıcının görünen adını (display name) giriş adından farklı yapın. WordPress yazılarda display name gösterir; bu ikisi aynıysa yazının altındaki isim, aslında giriş kullanıcı adınızı ifşa eder. Panelden Kullanıcılar > Profil ekranında "Takma ad" alanını ayrı belirleyip "Genel isim olarak göster" seçeneğini ona çevirin.

    wp-admin ve wp-login.php'yi Korumak#

    Yönetim paneli ve giriş sayfası, saldırıların en yoğun toplandığı iki adrestir. Bu ikisini genel internetten izole edebilirseniz, kaba kuvvet denemelerinin ezici çoğunluğu daha WordPress'e ulaşamadan sunucu katmanında durur. En güçlü yöntem IP kısıtlamasıdır: sabit IP'niz varsa yalnızca kendi IP'nizden erişime izin verin.

    Nginx için örnek bir yapılandırma:

    # Yalnizca ofis/ev IP'nizden wp-admin ve giris sayfasina izin ver
    location ~ ^/(wp-admin/|wp-login\.php) {
        allow 203.0.113.45;   # sizin sabit IP'niz
        allow 198.51.100.10;  # ikinci ofis IP'si
        deny all;
    
        # Standart PHP islemeye devam et
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }
    

    Sabit IP'niz yoksa IP kısıtlaması pratik olmaz; bunun yerine giriş sayfasına ikinci bir HTTP temel kimlik doğrulaması (basic auth) katmanı ekleyin. Böylece bir bot wp-login.php'ye ulaşmadan önce sunucu düzeyinde ayrı bir parola sorar. Önce parola dosyasını oluşturun, sonra sunucuda tanımlayın:

    # .htpasswd dosyasi olustur (Apache araci htpasswd ile)
    htpasswd -c /etc/nginx/.htpasswd giris_kullanici
    
    # wp-login.php'ye sunucu duzeyinde ikinci parola katmani
    location = /wp-login.php {
        auth_basic "Yonetim Girisi";
        auth_basic_user_file /etc/nginx/.htpasswd;
    
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }
    

    Apache/.htaccess kullanıyorsanız aynı mantığı Require ip veya AuthType Basic yönergeleriyle kurabilirsiniz. Ek olarak XML-RPC'yi de kapatın; xmlrpc.php hem kaba kuvvet çoğaltma (multicall) saldırılarında hem de pingback tabanlı DDoS'ta kötüye kullanılır ve modern sitelerin çoğu ona ihtiyaç duymaz:

    # XML-RPC'yi tamamen kapat
    location = /xmlrpc.php {
        deny all;
    }
    

    Yönetim tarafını sertleştirirken çıtayı bir kademe daha yükseltmek isterseniz, giriş isteklerini önünüzdeki bir güvenlik duvarında filtrelemek en temiz çözümdür. Bu iş için bir WAF katmanı ve kaba kuvveti IP bazında sınırlayan bir DDoS koruma hizmeti, sunucuya yük binmeden trafiği kenarda temizler.

    Gereksiz Eklenti ve Temalari Silmek#

    WordPress'te her eklenti ve tema, ayrı ayrı bakımı gereken bir kod parçasıdır; yani her biri potansiyel bir açık kapıdır. Devre dışı bıraktığınız ama silmediğiniz eklentiler de risklidir, çünkü dosyaları sunucuda durmaya devam eder ve içlerindeki bir açık, eklenti pasif olsa bile doğrudan URL üzerinden istismar edilebilir. Kural nettir: kullanmadığınız her eklentiyi ve temayı devre dışı bırakmakla kalmayın, tamamen silin.

    Özellikle temalarda titiz olun. Aktif temanız dışında yalnızca bir tane varsayılan yedek tema (örneğin en güncel Twenty serisi) tutun; gerisini kaldırın. Nulled (kırılmış/korsan) premium eklenti ve temalardan mutlak surette uzak durun — bunların çok büyük bölümü içine gömülü arka kapılarla dağıtılır ve sitenizi kurulumun ilk gününde ele geçirilmeye açık hâle getirir.

    WP-CLI ile mevcut durumu hızlıca gözden geçirebilir, pasif ve güncel olmayanları görebilirsiniz:

    # Tum eklentileri, durumlarini ve guncelleme ihtiyacini listele
    wp plugin list --fields=name,status,update
    
    # Pasif bir eklentiyi tamamen kaldir
    wp plugin delete eski-galeri-eklentisi
    
    # Kullanilmayan temalari kaldir
    wp theme delete twentynineteen twentytwenty
    

    Bir eklentiyi kurmadan önce şu üç soruyu sormayı alışkanlık hâline getirin: Son ne zaman güncellendi? Kaç aktif kurulumu var? Geliştiricisi bilinen ve ulaşılabilir biri mi? Bir yıldır güncellenmemiş, terk edilmiş bir eklenti, işlevi ne kadar cazip olursa olsun bir zaman bombasıdır.

    Dosya Izinleri ve Sahiplik#

    Yanlış dosya izinleri, ele geçirilmiş bir sürecin siteyi tümüyle değiştirmesine izin veren sessiz bir risktir. WordPress dosyaları web sunucusu tarafından okunabilmeli ama gereksiz yere yazılabilir olmamalıdır. Genel kabul gören güvenli izin şeması dizinler için 755, dosyalar için 644, wp-config.php için ise daha kısıtlı 640 veya 600'dür. Hiçbir zaman 777 kullanmayın; bu, dosyayı sunucudaki herkese yazılabilir yapar ve "eklenti kuramıyorum" sorunlarının en tehlikeli ama en kolay yanlış çözümüdür.

    Aşağıdaki komutlar izinleri tek seferde doğru değerlere çeker (site kök dizinindeyken çalıştırın):

    # Tum dizinleri 755, tum dosyalari 644 yap
    find . -type d -exec chmod 755 {} \;
    find . -type f -exec chmod 644 {} \;
    
    # wp-config.php'yi ekstra kisitla
    chmod 640 wp-config.php
    

    Sahiplik (ownership) en az izinler kadar önemlidir. Dosyalar sizin kullanıcı hesabınıza ait olmalı, web sunucusu grubuna (www-data, nginx vb.) yalnızca okuma yetkisiyle üye olmalı. Dosyaların tümünün doğrudan www-data kullanıcısına ait olması, PHP üzerinden çalışan bir saldırının her dosyayı yeniden yazabilmesi demektir. Doğru sahipliği şöyle kurarsınız:

    # Dosyalar kullaniciya, grup web sunucusuna ait olsun
    chown -R kullanici_adi:www-data /var/www/siteniz
    

    Aşağıdaki tablo, sık karşılaşılan yolların önerilen izinlerini özetliyor:

    YolOnerilen IzinNeden
    Dizinler (genel)755Sunucu okur ve girer, baskalari yazamaz
    Dosyalar (genel)644Sunucu okur, sahibi duzenler
    wp-config.php640 / 600Veritabani sifresini korur
    .htaccess644Okunur ama disaridan yazilamaz
    wp-content/uploads755Yukleme calisir, PHP calismasi ayrica engellenir

    Son bir katman: yükleme klasöründe PHP çalışmasını tamamen yasaklayın. Saldırganlar açıkları çoğu zaman uploads içine bir .php dosyası yerleştirip onu çağırarak istismar eder. Bu yolu kapatmak saldırının en yaygın son adımını kırar:

    # uploads klasorunde PHP calismasini engelle
    location ~* /wp-content/uploads/.*\.php$ {
        deny all;
    }
    

    Surekli Guncelleme ve Otomatik Yamalar#

    Ele geçirilmiş sitelerin en yaygın tek nedeni, güncellenmemiş yazılımdır. Bir eklenti açığı yayımlandığı andan itibaren botlar o açığı taramaya başlar; siz yamayı günler sonra uygularsanız aradaki pencere sizin için tam bir açık kapıdır. Bu yüzden güncelleme, "vakit bulunca yapılan" bir iş değil, planlı ve mümkünse otomatik bir süreç olmalıdır.

    WordPress çekirdeğinin küçük (güvenlik) sürümleri varsayılan olarak otomatik güncellenir; bunu wp-config.php'de doğrulayın ve isterseniz eklenti/tema otomatik güncellemesini de açın:

    // Cekirdek guvenlik guncellemeleri otomatik (varsayilan davranis)
    define( 'WP_AUTO_UPDATE_CORE', 'minor' );
    
    # Eklenti ve temalar icin otomatik guncellemeyi WP-CLI ile ac
    wp plugin auto-updates enable --all
    wp theme auto-updates enable --all
    

    Otomatik güncellemeye tümüyle güvenmek yerine, güncelleme öncesi yedek alan bir düzen kurmak en sağlıklısıdır — nadir de olsa bir güncelleme siteyi bozabilir ve geri dönebilmeniz gerekir. Düzenli, otomatik yedekleme ile güvenli bir güncelleme rutini birlikte çalışır: bir sorun çıkarsa dakikalar içinde eski sürüme dönersiniz. Güncellemeleri kendiniz takip etmek istemiyorsanız, bu işi profesyonel bir WordPress bakım hizmetine devretmek, hem çekirdeği hem eklentileri hem de yedekleri sizin adınıza güncel tutar.

    Guclu Parola, 2FA ve Oturum Guvenligi#

    Tüm sunucu katmanlarını sertleştirseniz bile, sonunda giriş bir parolaya dayanır; o parola zayıfsa diğer önlemler ertelenmiş risktir. Yönetici hesapları için en az 16 karakterli, rastgele üretilmiş ve hiçbir yerde tekrar kullanılmamış parolalar şarttır. Parola yeniden kullanımı, başka bir sitede sızan bir parolanın sizin panelinizi de açması demektir; bir parola yöneticisi (password manager) kullanarak her hesaba benzersiz parola atayın.

    Ancak 2026 dünyasında yalnızca güçlü parola yeterli değildir. İki faktörlü kimlik doğrulama (2FA), parolanız çalınsa bile ikinci bir kanıt (telefonunuzdaki uygulama kodu veya bir donanım anahtarı) istediği için ele geçirmeyi neredeyse imkânsız hâle getirir. TOTP tabanlı bir 2FA eklentisi kurun ve tüm yönetici hesaplarında zorunlu yapın; tek bir yöneticiyi 2FA'sız bırakmak, kapıyı bir kişilik açık tutmaktır. Aşağıdaki tablo yaygın ikinci faktör yöntemlerini karşılaştırıyor:

    YontemGuvenlikKullanim KolayligiOnerilir mi
    SMS koduDusuk (SIM swap riski)YuksekSadece hicbir sey yoksa
    E-posta koduOrtaYuksekEk katman olarak
    TOTP uygulamasiYuksekOrtaEvet, varsayilan tercih
    Donanim anahtari (FIDO2)Cok yuksekOrtaKritik hesaplar icin

    Oturum güvenliği için birkaç ek ayar da işe yarar. Başarısız giriş denemelerini sınırlayan bir eklenti (login limiter) kaba kuvveti kökten yavaşlatır; belirli sayıda hatalı denemeden sonra IP'yi geçici bloklar. Kimlik doğrulama çerezlerinin yalnızca HTTPS üzerinden gitmesini zorunlu kılın ve tüm siteyi baştan sona TLS altına alın — bir SSL sertifikası olmadan parolalar ve oturum çerezleri açık ağda ele geçirilebilir. Son olarak wp-config.php içindeki güvenlik anahtarlarını (salts) taze değerlerle yenilerseniz, sızmış eski oturum çerezleri anında geçersizleşir:

    // Yeni salt degerlerini https://api.wordpress.org/secret-key/1.1/salt/ adresinden alin
    define( 'AUTH_KEY',         '... rastgele uzun deger ...' );
    define( 'SECURE_AUTH_KEY',  '... rastgele uzun deger ...' );
    define( 'LOGGED_IN_KEY',    '... rastgele uzun deger ...' );
    define( 'NONCE_KEY',        '... rastgele uzun deger ...' );
    

    Hizli Sertlestirme Kontrol Listesi#

    Aşağıdaki liste, yukarıdaki bölümlerin özetini tek bakışta uygulanabilir bir denetim aracına dönüştürür. Yeni bir kurulumda baştan sona, mevcut bir sitede ise haftalık bir gözden geçirme olarak kullanın:

    • wp-config.php içinde DISALLOW_FILE_EDIT etkin mi?
    • admin / administrator kullanıcı adı silinip yerine özgün bir ad kondu mu?
    • Yazar arşivi (/?author=1) kullanıcı adı sızdırmıyor mu?
    • wp-admin ve wp-login.php IP veya basic auth ile korunuyor mu?
    • xmlrpc.php kapalı mı?
    • Kullanılmayan tüm eklenti ve temalar silindi mi (sadece pasif değil)?
    • Dizinler 755, dosyalar 644, wp-config.php 640 izninde mi?
    • wp-content/uploads içinde PHP çalışması engelli mi?
    • Çekirdek, eklenti ve temalar güncel ve otomatik güncelleme açık mı?
    • Düzenli otomatik yedek alınıyor ve geri dönüş test edildi mi?
    • Tüm yöneticilerde 2FA zorunlu mu?
    • Site baştan sona HTTPS'te ve giriş denemeleri sınırlanıyor mu?

    Bu listeyi tek seferde tamamlamanız gerekmez; en yüksek etkiyi veren üç maddeyle başlayın: benzersiz yönetici adı, 2FA ve güncel eklentiler. Bu üçü tek başına, otomatik saldırıların büyük çoğunluğunu daha ilk adımda etkisiz bırakır.

    Sıkça Sorulan Sorular#

    DISALLOW_FILE_EDIT açmak eklenti güncellememi engeller mi?#

    Hayır, engellemez. DISALLOW_FILE_EDIT yalnızca panel içindeki tema ve eklenti dosya düzenleyicisini kapatır; eklenti kurulumu, güncelleme ve silme işlemleri normal şekilde çalışmaya devam eder. Güncellemeyi de kapatmak istiyorsanız ayrıca DISALLOW_FILE_MODS tanımlamanız gerekir, ancak çoğu kullanıcı için bunu açmak yerine güncellemeleri sürdürmek daha doğrudur.

    Sadece güçlü bir parola kullanmak yeterli değil mi?#

    Güçlü parola şarttır ama tek başına yeterli değildir. Bir parola üçüncü taraf bir veri sızıntısıyla ele geçirilebilir, klavye kaydediciyle çalınabilir veya oltalama (phishing) ile ele geçirilebilir. İki faktörlü kimlik doğrulama devreye girdiğinde, saldırgan parolayı bilse bile telefonunuzdaki ikinci kanıta erişemez. Bu yüzden güçlü parola ve 2FA'yı birbirinin alternatifi değil, tamamlayıcısı olarak düşünmek gerekir.

    wp-admin'i IP ile kısıtlarsam mobil veri veya seyahatte erişimimi kaybeder miyim?#

    Evet, sabit IP kısıtlaması yalnızca izin verdiğiniz adreslerden erişime izin verir; dinamik IP'niz değiştiğinde veya farklı bir ağdan bağlandığınızda kilitlenebilirsiniz. Sabit IP'niz yoksa daha esnek olan HTTP basic auth katmanını tercih edin ya da bir VPN üzerinden sabit bir çıkış IP'si kullanın. Kritik durumlarda sunucuya SSH veya barındırma panelinden erişip kuralı geçici olarak gevşetebilirsiniz.

    Eklentiyi pasif yapmak yerine neden silmem gerekiyor?#

    Pasif (devre dışı) bir eklentinin dosyaları hâlâ sunucuda durur ve içindeki bir güvenlik açığı, eklenti aktif olmasa bile doğrudan dosya URL'si çağrılarak istismar edilebilir. WordPress'in bir eklentiyi çalıştırmıyor olması, o eklentinin PHP dosyalarının erişilemez olduğu anlamına gelmez. Bu nedenle gelecekte kullanmayı düşünmüyorsanız pasif bırakmak yerine tamamen silmek tek güvenli yoldur.

    Sertleştirme bir kez yapıp bitecek bir iş mi?#

    Hayır, sertleştirme tek seferlik bir kurulum değil, süregelen bir bakım disiplinidir. Yeni açıklar sürekli keşfedilir, yeni eklentiler eklenir ve yapılandırmalar zamanla değişir. En iyi yaklaşım, yukarıdaki kontrol listesini düzenli aralıklarla (örneğin ayda bir) gözden geçirmek, güncellemeleri otomatikleştirmek ve yedeklerinizin geri dönüş testini periyodik olarak yapmaktır. Güvenlik bir durum değil, sürekli sürdürülen bir alışkanlıktır.

    Kapanış#

    WordPress sertleştirme, tek bir sihirli ayardan çok, üst üste binen küçük ve disiplinli önlemlerden oluşur: dosya düzenleyiciyi kapatmak, admin kullanıcısını tarihe gömmek, yönetim panelini genel internetten izole etmek, kullanılmayan kodu silmek, izinleri sıkılaştırmak, her şeyi güncel tutmak ve girişi 2FA ile kilitlemek. Bu maddelerin hiçbiri tek başına kaleyi kurmaz; ama birlikte uygulandıklarında otomatik saldırıların ezici çoğunluğunu daha kapıda durduran sağlam bir savunma hattı oluşturur.

    Bu katmanların bir kısmı sunucu ve altyapı tarafında en verimli çalışır. Clou.TR'de WordPress'inizi güçlü bir zeminde çalıştırmak isterseniz, güvenlik odaklı WordPress hosting ve genel web hosting paketlerimiz otomatik yedekleme, SSL ve güncel PHP sürümleriyle gelir. Daha fazla kaynak ve kök erişimi gereken projeler için sanal sunucu ve yüksek performanslı VDS seçeneklerimize, giriş trafiğini kenarda temizlemek için WAF ve DDoS koruma hizmetlerimize, güncelleme yükünü tamamen devretmek içinse WordPress bakım paketimize göz atabilirsiniz. Sertleştirmeye bugün üç maddeyle başlayın; gerisini zamanla ve rahatça tamamlarsınız.

    wordpressguvenlikhardening

    Uygulamaya geçmeye hazır mısınız?

    NVMe SSD, ücretsiz SSL ve %99.9 uptime garantisiyle Clou.TR hosting ve sunucu çözümleriyle projenizi hayata geçirin.