Danışmanlık yaptığım projelerde en sık gördüğüm tablo şu: site yavaş, herkes bunu biliyor. Ama hangi sorun öncelikli, nereden başlanacağı belirsiz. Görseller sıkıştırılıyor, cache eklentisi kuruluyor, belki bir CDN deneniyor. Sonuç: bazı şeyler biraz iyileşiyor, bazıları değişmiyor, neden değişmediği de bilinmiyor.
Hız optimizasyonunun getirisi önceliklendirmeyle belirleniyor. En büyük kaybı hangi sorunun yarattığını görmeden yapılan her müdahale tahminden ibarettir. Google'ın bu amaçla tanımladığı standart metrikler, başlangıç noktanızı belirlemek için gereken haritayı sunuyor.
Web Sitesi Hızı Neden Önemlidir?
Bir web sitesinin yükleme süresi, yalnızca kullanıcı deneyimini değil, arama motoru sıralamalarını ve dönüşüm oranlarını da etkiliyor. İkisi birbirinden bağımsız değil; organik trafiği çekemezseniz dönüşüm için kimse gelmiyor, kullanıcıyı hızla karşılamazsanız gelen dönüşmüyor.
Hız ve SEO Sıralaması: Core Web Vitals Ranking Factor
Core Web Vitals, 2021'den itibaren Google'ın resmi sıralama sinyali olarak uygulamada. Üç metriği kapsıyor: LCP (sayfanın en büyük içerik elementinin yükleme süresi), INP (etkileşim gecikmesi) ve CLS (görsel kararlılık). Google, ziyaretçilerin en az %75'inin her üç metrikte "iyi" deneyim yaşamasını esas alıyor.
Bu sinyallerin sıralama üzerindeki ağırlığı tartışmalı; ancak gözlemlediğim şu: Core Web Vitals, tek başına ilk sayfaya taşımıyor. Eşit içerik kalitesinde belirleyici bir fark yaratıyor. Önce eşikleri sağlayın; sıralama çalışmasını diğer değişkenlerle sürdürün.
Hız ve Dönüşüm Oranı: 1 Saniyelik Gecikmenin Gelir Etkisi
Sıralama verisini bir kenara bırakın. Hızın en somut etkisi dönüşüm oranında görünüyor. 1 saniyelik yükleme gecikmesi %7 dönüşüm kaybı anlamına geliyor. 1 saniyede yüklenen bir sayfa, 5 saniyede yüklenene kıyasla 2,5 kat daha yüksek dönüşüm oranı gösteriyor. Ziyaretçilerin %53'ü ise 3 saniyeyi aşan yükleme süresinde sayfayı terk ediyor.
Bu rakamlar soyut değil. Günde 1.000 ziyaretçi alan ve %2 dönüşüm oranına sahip bir sitede 1 saniyelik gecikme, günde yaklaşık 14 dönüşüm kaybı demek. Aylık bazda bu kayıp, hangi sektörde olduğunuza göre ciddi bir gelir farkına dönüşüyor.
Sayfa Hızı SEO Sıralamalarını Gerçekten Etkiler mi?
Evet, doğrudan etkiler. Core Web Vitals metrikleri Google'ın sıralama algoritmalarına dahil edilmiş durumda. Ancak hız tek başına yetmez: içerik kalitesi ve otorite sinyalleri daha belirleyici rol oynuyor. "Hızı iyi olan ama içeriği zayıf site üst sıraya çıkmaz" demek daha doğru. İyi performans bir ön koşul; sıralama garantisi değil.
Web Sitesi Hızı Dönüşüm Oranını Nasıl Etkiler?
Doğrudan ve ölçülebilir biçimde etkiler. 1 saniyelik gecikme %7 dönüşüm kaybı, %53 kullanıcı terk oranı (3 saniye üzeri yükleme süresinde). E-ticaret sitelerinde bu oranlar doğrudan sepet terk oranına yansır; hizmet sitelerinde form doldurma ve iletişim oranını etkiler. "Trafik var ama istek yok" tablosunun ilk incelenmesi gereken yeri hız performansıdır.
Core Web Vitals: 2024 Sonrası Güncel Metrikler
Core Web Vitals, Mart 2024 itibarıyla üç metrikten oluşuyor: LCP (yükleme hızı), INP (etkileşim gecikmesi) ve CLS (görsel kararlılık). INP bu tarihte FID metriğinin yerini aldı. Eski FID verisine dayanan performans değerlendirmeleri artık geçersiz; çoğu analizde FID "iyi" çıkarken INP kritik sorun gösterebiliyor.
Core Web Vitals, Google'ın 2020'de tanımladığı ve düzenli güncellediği bir performans çerçevesi. Bu değişikliği atlayan içerikler, araçlar ve danışmanlar eski bir haritayla çalışıyor demektir. Google bu metrikleri 75. yüzdelik dilimden değerlendiriyor: ziyaretçilerinizin en az %75'inin her metrikte "iyi" deneyim yaşaması gerekiyor.
| Metrik | Açılımı | İyi | Geliştirme Gerekli | Kötü |
|---|---|---|---|---|
| LCP | Largest Contentful Paint — en büyük elementin yüklenme süresi | ≤ 2,5s | 2,5s – 4s | > 4s |
| INP | Interaction to Next Paint — etkileşim gecikmesi | ≤ 200ms | 200ms – 500ms | > 500ms |
| CLS | Cumulative Layout Shift — görsel kayma puanı | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Teknik SEO denetimi bağlamında bu metriklerin nasıl iyileştirileceğini ayrıntılı olarak ele aldığım kaynak için Teknik SEO sayfasına bakabilirsiniz.
LCP (Largest Contentful Paint): Hedef 2,5 Saniye
LCP, sayfanın görüntü alanındaki en büyük görsel veya metin bloğunun boyandığı anı ölçüyor. Çoğunlukla bu element hero görseli, büyük bir başlık ya da ana banner oluyor. 2,5 saniyelik eşiğin aşılmasının en yaygın nedenleri: optimize edilmemiş büyük görseller, yüksek TTFB ve render engelleyen CSS ya da JavaScript dosyaları. LCP'yi iyileştirmek istiyorsanız ilk adım, o elementin hangi kaynak olduğunu PageSpeed Insights ile tespit etmek.
INP (Interaction to Next Paint): FID Artık Geçersiz
Mart 2024'ten itibaren FID artık Core Web Vitals metrikleri arasında değil. Yerini INP aldı. FID, yalnızca kullanıcının sayfayla ilk etkileşimindeki gecikmeyi ölçüyordu. INP ise sayfada gerçekleşen tüm etkileşimler boyunca en uzun gecikmeyi raporluyor. Bu onu çok daha gerçekçi bir metrik yapıyor. FID'in %93'ü "iyi" aralığında çıkarken INP'nin yalnızca %75'i geçiyor.
Danışmanlık yaptığım bir projede müşteri FID'ini düzeltmişti; tüm araçlarda "iyi" yazıyordu. INP ölçtüğümüzde 780ms çıktı. Sorun hiç görülmemişti. Eğer analiz raporunuzda hâlâ FID verisi görüyorsanız, kullandığınız araç veya referans kaynak güncel değil demektir.
CLS (Cumulative Layout Shift): Görsel Kararlılık Metriği
CLS, sayfa yüklenirken elementlerin beklenmedik biçimde kayıp kaymadığını ölçüyor. Bir butona tıklamaya çalışırken butonun aşağı kayması ve başka bir şeye tıklamanıza yol açması; CLS'nin yüksek çıkmasının tipik senaryosu bu. İyi eşik ≤ 0,1. En yaygın nedenler: boyutu belirtilmemiş görseller, dinamik olarak eklenen içerik ve gecikmeli yüklenen reklamlar. Düzeltmesi genellikle görece hızlı: HTML'de görsellere width ve height değeri tanımlayın, reklam ve banner alanları için yer tutucular ayarlayın.
Core Web Vitals Skorum Nasıl İyileştirilir?
LCP için: En büyük elementi tespit edin; PageSpeed Insights gösteriyor. Görsel ise WebP formatına çevirin ve boyutunu optimize edin. Sunucu TTFB'si yüksekse önce onu çözün; diğer her şeyin tavanı TTFB tarafından belirleniyor.
INP için: JavaScript yürütme sürelerini inceleyin. Render engelleyen scriptleri erteleyin (defer). Üçüncü taraf betikler (reklamlar, chat widgetları, analytics araçları) INP'yi en çok olumsuz etkileyen kaynaklardır.
CLS için: Tüm görsellerde boyut tanımlayın. Font yükleme sırasında metin kaymasını önlemek için font-display: swap kullanın.
TTFB ve Sunucu Yanıt Süresi: Hız Sorunlarının Görünmeyen Kaynağı
TTFB (Time to First Byte), tarayıcının sunucuya istek gönderip ilk veriyi alması arasındaki süredir. Kullanıcı henüz ekranda hiçbir şey görmemişken arka planda geçen bu süre, sonraki tüm yükleme adımlarının başlangıç noktasını belirliyor.
Google'ın eşiğine göre: ≤ 800ms iyi, 800ms-1800ms arasında geliştirme gerekli, 1800ms üzeri kötü. TTFB, Core Web Vitals'ın resmi bir parçası değil; ama LCP'yi doğrudan etkileyen bir teşhis metriği. Sunucu yanıt süresi yüksekse görsel sıkıştırma, CDN kurulumu, CSS küçültme gibi diğer tüm optimizasyonların getirisini bir tavan sınırlıyor. Çatıyı boyadığınız ama temeli çöküyor olan bir binayla aynı mantık.
TTFB'yi etkileyen başlıca faktörler: Sunucu lokasyonu (hedef kitlenize coğrafi olarak uzak bir sunucu yanıt süresini artırıyor), veritabanı sorgu süreleri (WordPress gibi dinamik CMS'lerde yavaş sorgular TTFB'yi en çok etkileyen unsur) ve önbellekleme yapılandırması (sayfa önbelleğe alınmışsa sunucu her istekte veritabanını sorgulamaz; TTFB dramatik biçimde düşebilir). Teknik SEO denetimi kapsamında TTFB ölçümü standart ilk adımdır.
TTFB Nedir ve Web Sitesi Hızını Nasıl Etkiler?
TTFB, sunucunun bir kullanıcı isteğine ne kadar sürede yanıt verdiğini ölçer. Yüksek TTFB, sayfa henüz yüklenmeden önceki görünmez bir gecikme. LCP metriğinizin kötü çıkmasının önemli bir nedeni TTFB olabilir; bu nedenle hız analizine her zaman TTFB ile başlamayı öneriyorum. 800ms altında tutmak, diğer optimizasyonların etkisini maksimize ediyor.
Web Sitesi Hız Testi: Doğru Araçlar ve Doğru Okuma Yöntemi
Temel iki araç var: PageSpeed Insights (Google'ın resmi aracı, sıralama sinyali için zorunlu) ve GTmetrix (kök neden tespiti için). Ancak araç seçmekten önemli olan sonuçları doğru okumak: özellikle gerçek kullanıcı verisi (field data) ile simüle test (lab data) farkını görmezden gelmek yanlış önceliklere götürebilir.
| Araç | Güçlü Olduğu Alan | Sınırlı Olduğu Alan | Ücretsiz mi? |
|---|---|---|---|
| PageSpeed Insights | Gerçek kullanıcı verisi (field data), CWV eşik değerlendirmesi, Google sinyali | Kök neden tespiti için yüzeysel kalabiliyor | Evet |
| GTmetrix | Waterfall analizi, kaynak bazlı gecikme tespiti, detaylı zaman çizelgesi | Gerçek kullanıcı verisi yok (lab ortamı) | Ücretsiz + ücretli plan |
| WebPageTest | Farklı coğrafyadan test, TTFB analizi, bağlantı hızı simülasyonu | Kullanımı görece teknik | Evet |
PageSpeed Insights: Field Data ile Lab Data Farkı
PageSpeed Insights iki ayrı veri kaynağı sunuyor. Field data (gerçek kullanıcı verisi): sayfanızı ziyaret eden gerçek kullanıcıların Chrome tarayıcısından toplanan CrUX verisi; Google'ın sıralama kararlarında kullandığı veri bu. Lab data (simüle test ortamı): Lighthouse motoru tarafından kontrollü bir ortamda yapılan ölçüm; gerçek kullanıcı koşullarını tam yansıtmayabilir, ancak spesifik sorunları teşhis etmek için kullanışlıdır.
Yaygın hata: lab data'da 90+ puan görünce "sorunsuz" demek. Field data puanı çok daha düşük çıkabilir; Google sıralama sinyali olarak field data'yı kullanıyor. Her iki veriyi karşılaştırın: arasındaki fark büyükse gerçek ziyaretçi koşullarında tekrarlanmayan bir test sorunu var demektir.
Google PageSpeed Insights Skoru 100 Olmak Zorunda mı?
Hayır. Hedef 100 puan değil, CWV eşiklerini karşılamak. Google'ın değerlendirmesi ziyaretçilerin %75'inin LCP ≤ 2,5s, INP ≤ 200ms ve CLS ≤ 0,1 deneyimini yaşayıp yaşamadığına bakıyor. Puan 70-79 aralığında olsa bile tüm eşikler sağlandıysa sıralama sinyali açısından yeterli. 100 puanı kovalamak için harcanan süreyi içerik ve otorite inşasına ayırmak çoğu durumda daha yüksek getiri sağlıyor.
GTmetrix ve WebPageTest: Waterfall Analizi ile Kök Neden Tespiti
GTmetrix, PageSpeed Insights'ın gösteremediği şeyi gösteriyor: hangi kaynak, hangi adımda, ne kadar gecikiyor. "Waterfall" sekmesi her kaynağın ne zaman başladığını ve ne kadar sürdüğünü milisaniye kırılımında gösteriyor. "Render engelleyen script var mı? Hangi görsel LCP'yi geciktiriyor? Analytics betiği 800ms mi sürüyor?" sorularının cevabı burada.
WebPageTest ise farklı coğrafyalardan ve farklı bağlantı hızlarında test sunuyor; sunucunuzun belirli bir bölgeden nasıl yanıt verdiğini görmek için özellikle TTFB analizinde işe yarıyor. Pratik kullanım önerim: PageSpeed Insights ile başlayın, genel CWV durumunu ve "Fırsatlar" listesini görün; kök neden tespiti için GTmetrix waterfall analizine geçin.
PageSpeed Insights ile GTmetrix Arasındaki Fark Nedir?
İkisi farklı soruları yanıtlıyor; tercih değil kombinasyon. PageSpeed Insights Google'ın resmi metriklerini ve gerçek kullanıcı verisini gösteriyor; sıralama sinyali değerlendirmesi için zorunlu. GTmetrix daha ayrıntılı teknik analiz için: kaynak yükleme sırası, waterfall görünümü ve üçüncü taraf script analizi. Başlangıç noktanız her zaman PageSpeed Insights olmalı; kök neden tespitinde GTmetrix'e geçin.
Hız Optimizasyonu Adımları: Öncelik Sırası Önemlidir
Hız optimizasyonunda hangi adımı önce atacağınız, ne yapacağınız kadar önemli. Aşağıdaki sıralama genel öneme göre; kendi sitenizin doğru sırası PageSpeed Insights analizi belirliyor. SEO danışmanlığı kapsamındaki teknik denetim bu sıralamayı sitenize özel olarak ortaya koyuyor.
-
Önce sunucu yanıt süresini (TTFB) değerlendirin
TTFB 1 saniyenin üzerindeyse diğer adımların etkisi sınırlı kalıyor. Diğer tüm optimizasyonların tavanını TTFB belirliyor; bu adımı atlamak zamanı boşa harcamaktır.
-
LCP elementini tespit edin ve optimize edin
PageSpeed Insights "Largest Contentful Paint Element" olarak gösteriyor. Görsel ise WebP formatına çevirin, boyutu optimize edin ve
fetchpriority="high"ile önce yükleyin. -
INP sorunlarını JavaScript katmanında çözün
Üçüncü taraf scriptler ve yavaş interaktif elementler başlangıç noktası. Render engelleyen scriptleri
deferile erteleyin. -
CLS değerini sıfıra yaklaştırın
Genellikle en hızlı çözülen metrik. Tüm görsellerde
widthveheighttanımlayın, banner ve reklam alanları için yer tutucular belirleyin.
Görsel Optimizasyonu: WebP Formatı, Sıkıştırma ve Lazy Load
Görseller, ortalama web sayfasındaki toplam veri yükünün %50-60'ını oluşturuyor. Optimize edilmemiş görsel, LCP'nin en yaygın nedeni. WebP formatı JPEG'e kıyasla %25-35 daha küçük dosya boyutu sağlıyor; kalite korunuyor, modern tarayıcıların tamamı destekliyor. Sıkıştırma için TinyPNG veya Squoosh gibi araçlarla kayıpsız sıkıştırma birkaç dakikada yapılabiliyor, geliştirici bilgisi gerektirmiyor. Lazy load ise ekran dışındaki görsellerin yüklenmesini, kullanıcı o alana kaydırana kadar erteleyen teknik; HTML loading="lazy" özelliğiyle modern tarayıcılarda yerel destek var.
CSS ve JavaScript: Küçültme, Erteleme ve Kritik Yolu Temizleme
"Render engelleyen kaynak" (render-blocking resource), tarayıcının sayfayı boyamadan önce indirmek ve işlemek zorunda kaldığı dosya. CSS ve JavaScript dosyaları sıklıkla bu sorunu yaratıyor. Küçültme (minify): boşluklar, yorumlar ve gereksiz karakterler kaldırılarak dosya boyutu küçültülür; içerik değişmez. Erteleme (defer/async): kritik olmayan JavaScript dosyalarına defer özelliği eklenerek tarayıcının sayfa boyamasını bekletmeden yüklenmesi sağlanır. Kritik CSS: sayfanın ilk görünür alanı için gereken minimum CSS satırlarını HTML <head> içine gömmek, geri kalanı eş zamanlı yüklemek; bu teknik LCP süresini anlamlı biçimde kısaltabiliyor.
Önbellekleme (Cache) ve CDN: Yanıt Süresini Kalıcı Olarak Kısaltmak
Önbellekleme (caching): sunucunun her istek için yeniden sayfa üretmek yerine, önceden üretilmiş sayfanın kopyasını sunması. WordPress siteleri için WP Rocket veya W3 Total Cache bu işlevi yapılandırıyor. Doğru kurulumda TTFB ve genel yükleme süresi dramatik biçimde düşebilir. CDN (Content Delivery Network): statik içeriklerinizi dünyanın farklı noktalarındaki sunuculara dağıtarak kullanıcıya en yakın noktadan sunar. Türkiye merkezli site için yurt içi ziyaretçilerde CDN etkisi sınırlı olabilir; ancak uluslararası kitleye ulaşıyorsanız veya statik içerik ağırlıklı bir siteniz varsa kritik hale gelir. Cloudflare'in ücretsiz planı çoğu küçük-orta ölçekli site için başlangıç noktası.
Sunucu ve Hosting Seçimi: TTFB'yi Etkileyen Temel Faktörler
Hosting altyapısı TTFB'yi en çok etkileyen değişken. Paylaşımlı hosting planlarında kaynaklar çok sayıda site arasında bölünür; trafik yoğunluğunda sunucu yanıt süresi uzar. TTFB açısından kritik hosting kriterleri:
- Sunucu lokasyonu: Hedef kitlenize coğrafi olarak yakın sunucu yanıt süresini azaltıyor.
- SSD depolama: HDD'ye kıyasla veri okuma hızı anlamlı biçimde yüksek.
- PHP sürümü: Güncel PHP sürümleri (8.x) WordPress sitelerinde TTFB'yi doğrudan etkiliyor.
- Veritabanı önbellekleme: Redis veya Memcached gibi araçlar, tekrar eden sorgu sonuçlarını bellekte tutuyor; her istekte veritabanına gidilmiyor.
Hangi Hız Sorununu Kendiniz Çözersiniz, Hangisi Uzman Gerektirir?
Her hız sorunu aynı teknik derinliği gerektirmiyor. Bazıları doğru araçla geliştirici bilgisi olmadan çözülebilir; bazıları yanlış yapılırsa sayfayı daha da yavaşlatabilir.
| Hız Sorunu | Kendiniz | Uzman | Neden? |
|---|---|---|---|
| Görsel sıkıştırma ve WebP dönüşümü | ✓ | TinyPNG / Squoosh ile yapılabiliyor | |
| Cache eklentisi kurulumu (WordPress) | ✓ (dikkatli) | Yanlış yapılandırma sorun çıkarabilir; belgeleri takip edin | |
| LCP görselini preload etme | ✓ | HTML <head> müdahalesi gerekiyor; hata riski var | |
| JavaScript defer/async yapılandırması | ✓ | Yanlış uygulanan defer sayfa işlevselliğini bozabiliyor | |
| TTFB yüksek: hosting veya sunucu sorunu | ✓ | Sunucu yapılandırması, PHP sürümü, veritabanı optimizasyonu | |
| INP iyileştirme: JavaScript long task analizi | ✓ | Chrome DevTools profiling + uygulama katmanında değişiklik | |
| CDN kurulumu (Cloudflare ücretsiz) | ✓ | Temel kurulum kılavuz takibiyle yapılabiliyor | |
| Core Web Vitals eşiklerini sürekli tutmak | ✓ | Güncelleme ve değişiklik süreçlerinde teknik gözetim gerekiyor |
Hız Optimizasyonu için Geliştirici veya Uzman Tutmak Gerekir mi?
Duruma göre. Görsel optimizasyonu, cache eklentisi ve CDN kurulumu; bunlar teknik bilgisi olmayan site sahiplerinin de yapabileceği adımlar. Ancak yüksek TTFB sorunu, INP iyileştirmeleri, JavaScript düzeyinde optimizasyonlar ve özel geliştirme içeren sitelerdeki CLS sorunları teknik uzmanlık gerektiriyor. Başlamadan önce PageSpeed Insights ile sayfanızı analiz edin: hangi metriğin nerede durduğunu görünce neleri kendiniz yapabileceğiniz de netleşiyor.
Web Sitesi Hızının Yapay Zeka Arama Motorlarındaki Etkisi
Hız performansının önemi artık yalnızca Google ile sınırlı değil. ChatGPT, Gemini ve Perplexity gibi yapay zeka motorları, yanıt üretirken kaynak sayfalar seçiyor. Bu seçimde teknik erişilebilirlik ve hız fark yaratıyor.
107.000 sayfa üzerinde yapılan araştırma, Core Web Vitals skorları yüksek sayfaların AI arama motorlarında daha sık kaynak gösterildiğini ortaya koyuyor. Bu doğrudan bir sıralama sinyali değil; ancak YZ modellerinin içeriği ayrıştırma ve erişim hızı üzerinde etkisi var.
Hızlı yüklenen sayfaların GEO açısından üç avantajı: Bot erişilebilirliği (YZ tarayıcıları yavaş sayfalarda zaman aşımı yaşayabiliyor; hızlı sayfalar tam içerik indekslemesine izin veriyor), yapısal temizlik (optimize edilmiş sayfalar genellikle temiz HTML hiyerarşisi ve okunabilir içerik blokları içeriyor; YZ modelleri bu yapıyı tercih ediyor) ve sinyal bütünlüğü (teknik sağlık ile içerik kalitesi bir arada olduğunda kaynak olarak gösterilme olasılığı artıyor).
Yapay zeka motorlarında görünürlük inşasını daha geniş bir çerçevede ele almak istiyorsanız GEO Optimizasyonu sayfasına bakabilirsiniz.
Web Sitesi Hızı Yapay Zeka Arama Motorlarında Görünürlüğü Etkiler mi?
Dolaylı ama anlamlı bir etkisi var. YZ motorları içerik seçerken birincil kriter içerik kalitesi; ancak erişilemeyen veya çok yavaş yüklenen sayfalara ulaşmakta güçlük çekiyorlar. 107.000 sayfalık araştırma, iyi Core Web Vitals skoruna sahip sayfaların AI arama referanslarında daha sık göründüğünü ortaya koyuyor. Teknik performansınızı yüksek tutmak, içeriğinizin hem insan hem AI için erişilebilir olduğunu güvence altına alıyor.
Sonuç: Hız Optimizasyonunun Başlangıç Noktası Teşhistir
Web sitesi hızlandırma, yapılacaklar listesini yukarıdan aşağıya işaretlemekle başlamıyor. Başlangıç noktası, sayfanızın hangi metriğinin neden sorunlu olduğunu net biçimde görmek. Core Web Vitals çerçevesi (LCP, INP ve CLS) ve TTFB verisi bir arada, "nerede kayıp verdiğinizi" ölçülebilir biçimde gösteriyor. Önce teşhis, sonra önceliklendirme, sonra müdahale. Bu sıra hem zaman hem kaynak israfını önlüyor.
Görselleri sıkıştırmak birkaç dakika alıyor; INP sorununun kaynağını bulmak bazen saatler. İkisini aynı aciliyetle ele almak doğru değil. Sitenizin teknik performansını ve organik görünürlüğünü bütünsel olarak değerlendirmek istiyorsanız Teşhis ve İnşa süreci bunu sistematik biçimde yapıyor: veriyle, 2-3 iş gününde.