Bir dönem yayıncılık dünyasında AMP tartışmaya kapalı bir zorunluluktu: Google'ın haber karuselinde görünmek istiyorsanız sayfalarınızın AMP sürümünü üretmeniz gerekiyordu. Bugün aynı soruyu soran çok sayıda site sahibi var ama sorunun bağlamı tamamen değişti. Artık asıl soru "AMP'ye nasıl geçerim" değil, "elimdeki AMP'yi tutmalı mıyım, yoksa temizleyip normal sayfalarımı mı hızlandırmalıyım" oluyor.
Bu yazıda AMP'in ne vaat ettiğini, Google tarafında neyin değiştiğini, AMP'in bugün hâlâ ne getirdiğini ve neyi elinizden aldığını olabildiğince tarafsız anlatacağım. Ardından AMP'siz aynı hız sonuçlarına ulaşmanın yolunu ve elinizde AMP varsa nasıl güvenli bir şekilde çıkacağınızı adım adım göstereceğim. Kısa cevabı en başta vereyim: çoğu site için AMP artık gerekli değil, ama "gereksiz" ile "zararlı" arasındaki fark neyi ölçtüğünüze bağlı.
AMP Ne Vaat Ediyordu ve Ne Değişti#
AMP (Accelerated Mobile Pages), mobil sayfaları hızlandırmak için iki şeyi bir arada yapıyordu. Birincisi kısıtlı bir HTML alt kümesi tanımlıyordu: kendi JavaScript'inizi çalıştıramaz, görselleri kendi bileşenleriyle koyar, CSS'i sıkı bir boyut sınırı içinde satır içi yazardınız. Bu kısıtlar sayfanın yavaşlamasını yapısal olarak engelliyordu. İkincisi ve asıl hızlandırıcı olanı, sayfanın Google'ın AMP önbelleğinden servis edilmesi ve arama sonuçları sayfasında önceden yüklenmesiydi; kullanıcı bağlantıya dokunduğunda sayfa zaten hazır olduğu için anında açılıyordu.
Kritik değişiklik şuydu: Google, sayfa deneyimi güncellemesiyle birlikte haber karuselinde görünmek için AMP zorunluluğunu kaldırdı ve arama sonuçlarındaki AMP şimşek rozetini de emekliye ayırdı. Sıralamada dikkate alınan şey artık sayfanın AMP olup olmadığı değil, Core Web Vitals metrikleridir. Yani AMP'in en güçlü satış argümanı — "AMP olmadan karusele giremezsin" — ortadan kalktı.
Bu değişiklik AMP'i işe yaramaz yapmadı; sadece zorunlu olmaktan çıkarıp bir tercihe dönüştürdü. Bugün AMP'in getirdiği tek gerçek teknik avantaj, önbellekten önceden yükleme sayesinde algılanan açılış süresinin neredeyse sıfır olmasıdır. Bunu normal bir sayfayla tam olarak taklit etmek zordur ama pratikte fark, çoğu sitede kullanıcı davranışını değiştirecek büyüklükte değildir.
| Konu | AMP zorunluluğu döneminde | Bugün |
|---|---|---|
| Haber karuseli | AMP şart | AMP şart değil |
| Arama sonucu rozeti | Şimşek ikonu vardı | Kaldırıldı |
| Sıralama sinyali | AMP dolaylı avantaj | Core Web Vitals |
| Görünen alan adı | Google önbellek URL'i | Kendi alan adınız |
| Ana hız kaynağı | Önbellekten ön yükleme | Sayfanın kendi optimizasyonu |
AMP'in Teknik Kısıtları#
AMP'in hızını sağlayan şey aynı zamanda maliyetidir: yapabileceklerinizi daraltır. En belirgin kısıtlar şunlardır.
Kendi JavaScript'inizi çalıştıramazsınız. Standart AMP sayfasında yalnızca AMP'in kendi bileşenleri çalışır; özel etkileşimler için sınırlı ve korumalı bir çalıştırma ortamı vardır. Bir ürün yapılandırıcı, canlı fiyat hesaplayıcı ya da sepet etkileşimi kurmanız pratikte mümkün değildir.
CSS boyutu sınırlıdır ve satır içi olmak zorundadır. Satır içi stil için sıkı bir üst sınır vardır (uzun süre 50 KB idi, sonradan yükseltildi) ve harici stil dosyası kullanamazsınız. Orta karmaşıklıkta bir tasarımda bu sınıra çarpmak kolaydır; sonuç genellikle AMP sürümünün görsel olarak sadeleştirilmesi, yani iki farklı tasarımın bakımıdır.
Sayfalarınızın iki sürümü olur. Normal sayfa ve AMP sayfası ayrı ayrı üretilir, ayrı ayrı test edilir ve ayrı ayrı bozulur. Deneyimimde AMP kaynaklı sorunların çoğu hız değil, senkron olmayan içerik sorunudur: normal sayfa güncellenir, AMP sürümü eski kalır.
Gerekli işaretleme de kendi başına bir yüktür. Minimum bir AMP belgesi kabaca şöyle başlar:
<!doctype html>
<html amp lang="tr">
<head>
<meta charset="utf-8">
<link rel="canonical" href="https://firmaniz.com/yazi/ornek">
<meta name="viewport" content="width=device-width">
<script async src="https://cdn.ampproject.org/v0.js"></script>
<style amp-custom>
body { font-family: system-ui, sans-serif; }
</style>
</head>
<body>
<amp-img src="/gorsel/kapak.jpg" width="1200" height="675" layout="responsive" alt="Kapak"></amp-img>
</body>
</html>
Normal sayfanız da AMP sürümünü bildirmek zorundadır:
<link rel="amphtml" href="https://firmaniz.com/yazi/ornek/amp">
İki sayfa arasındaki bu canonical ve amphtml bağının kopması, AMP kurulumlarında en sık gördüğüm SEO hatasıdır: canonical yanlış yönü gösterdiğinde Google iki sayfayı ayrı içerik sanabilir.
Doğrulamayı elle yapmak yerine otomatikleştirin:
# AMP doğrulayıcı (npm paketi)
npm install -g amphtml-validator
amphtml-validator https://firmaniz.com/yazi/ornek/amp
# Hızlı bir kontrol: canonical ve amphtml bağı doğru mu
curl -s https://firmaniz.com/yazi/ornek | grep -o 'rel="amphtml"[^>]*'
curl -s https://firmaniz.com/yazi/ornek/amp | grep -o 'rel="canonical"[^>]*'
AMP'siz Aynı Hıza Ulaşmak#
AMP'in dayattığı disiplini, kısıtlarını kabul etmeden kendiniz uygulayabilirsiniz. AMP aslında yeni bir teknoloji icat etmedi; sadece iyi bilinen kuralları zorunlu hale getirdi. Aynı kuralları gönüllü uygularsanız sonuç da benzer olur:
- Kritik CSS'i satır içi yazın, gerisini erteleyin. AMP'in yaptığı tam olarak budur.
- Görsellere boyut verin ve duyarlı
srcsetkullanın; AMP'inlayout="responsive"özelliği bunun karşılığıdır. - Üçüncü parti betikleri geciktirin ya da tamamen çıkarın. AMP bunu yasaklayarak çözüyordu.
- Yazı tiplerini sınırlayın ve
font-display: swapkullanın. - Tam sayfa önbelleği kurun ki sunucu tarafı gecikmesi devreden çıksın.
Bu beş maddenin ayrıntılı uygulaması için mobil hız optimizasyonu yazısına, LCP tarafındaki ince ayarlar için LCP nasıl iyileştirilir yazısına bakabilirsiniz. Kuralların zamanla gevşemesini engellemek içinse performans bütçesi belirleme yazısındaki yöntemi kullanın — bütçe, AMP'in kısıtlarını kendi kurallarınıza çevirmenin en pratik yoludur.
AMP'in tek gerçek üstünlüğü olan "önceden yükleme" tarafını da kısmen taklit edebilirsiniz. Kullanıcının gitmesi muhtemel bağlantıları tarayıcıya önceden bildirmek belirgin fark yaratır:
<link rel="preconnect" href="https://cdn.firmaniz.com" crossorigin>
<link rel="prefetch" href="/yazi/populer-icerik" as="document">
Sunucu tarafında ise HTML'in tamamını hazır tutmak, yani her isteği PHP'ye ve veritabanına götürmemek en büyük kazancı sağlar. Bunun uç noktası, sayfaları önceden üretip statik dosya olarak servis etmektir; bu yaklaşımı statik site üreticilerinin hız avantajı yazısında ayrıntılı ele aldım. Statik HTML'in AMP'e göre avantajı, hiçbir kısıt kabul etmeden benzer bir ilk bayt süresi vermesidir.
AMP Hangi Durumlarda Hâlâ Anlamlı#
Dürüst olmak gerekirse AMP'in hâlâ savunulabilir olduğu birkaç senaryo var:
Yüksek hacimli haber yayıncılığı. Günde yüzlerce içerik üreten, trafiğinin büyük kısmı Google Discover ve haber yüzeylerinden gelen bir yayıncıysanız, önbellekten ön yüklemenin sağladığı anlık açılış hâlâ ölçülebilir bir fark yaratabilir. Burada da karar duyguyla değil, kendi analitiğinizle verilmelidir.
Ana sitesi ağır ve yakın vadede düzeltilemeyecek olanlar. Devasa bir eski sistem üzerinde çalışıyorsanız ve mobil sayfalarınızı hızlandırmak aylar sürecekse, AMP kısa vadeli bir yara bandı olabilir. Ama bunu kalıcı çözüm sanmayın; iki sürüm bakımı zamanla asıl siteyi düzeltmekten daha pahalıya gelir.
E-posta AMP'i. Bu tamamen ayrı bir konudur ve arama ile ilgisi yoktur; e-posta içinde etkileşimli içerik göstermeye yarar. Bu yazının kapsamı dışında ama "AMP öldü" cümlesinin doğru olmadığını hatırlatır.
Buna karşılık AMP'ten uzak durmanız gereken durumlar çok daha yaygındır: e-ticaret siteleri (etkileşim ve dönüşüm izleme kısıtları), kurumsal siteler (zaten az sayıda sayfa, kolayca hızlandırılabilir), form ve hesaplama içeren siteler, özel tasarımı önemseyen markalar.
| Site türü | AMP tavsiyesi | Sebep |
|---|---|---|
| Haber / yayıncılık (yüksek hacim) | Değerlendirilebilir | Discover ve ön yükleme etkisi |
| Blog / içerik sitesi | Gerek yok | Normal sayfa kolayca hızlanır |
| E-ticaret | Önerilmez | Etkileşim ve izleme kısıtı |
| Kurumsal tanıtım | Gerek yok | Sayfa sayısı az, optimizasyon basit |
| Web uygulaması | Uygun değil | Özel JavaScript çalışmaz |
AMP'ten Güvenli Çıkış Planı#
Elinizde çalışan bir AMP kurulumu varsa, onu bir gecede silmek trafik kaybettirebilir. Sıralı ve ölçülü bir geçiş şöyle olmalıdır:
- Önce normal sayfalarınızı hızlandırın. AMP'i kaldırdığınızda kullanıcıların ineceği sayfa normal sürümdür; o sayfa yavaşsa çıkış maliyeti yüksek olur. Mobil LCP değerinizi 2.5 saniyenin altına indirmeden bir sonraki adıma geçmeyin.
- Trafiği ölçün. Search Console'da AMP sayfalarınızın aldığı tıklama ve gösterim payını, Analytics'te AMP kaynaklı oturumların dönüşüm oranını çıkarın. Payı düşükse karar zaten kolaydır.
- Aşamalı kaldırın. Tüm siteyi birden değil, bir kategoriyi ya da içeriklerin
%10'unu AMP'siz bırakıp dört-altı hafta izleyin. Tıklama ve sıralama farkı yoksa devam edin. - Yönlendirmeleri doğru kurun. AMP URL'lerini normal karşılıklarına kalıcı olarak yönlendirin ve
amphtmlbağlantısını normal sayfalardan kaldırın.
# /yazi/ornek/amp -> /yazi/ornek kalıcı yönlendirme
location ~ ^/(.*)/amp/?$ {
return 301 /$1;
}
Apache veya paylaşımlı hosting kullanıyorsanız aynı işi .htaccess ile yapabilirsiniz:
RewriteEngine On
RewriteRule ^(.*)/amp/?$ /$1 [R=301,L]
Yönlendirme kurallarını elle yazmak yerine htaccess yönlendirme üretici aracımızla üretebilirsiniz.
amphtmletiketini kaldırın ve site haritanızı güncelleyin. AMP URL'leri site haritasında kalmaya devam ederse Google bir süre daha onları taramaya çalışır.- Dört hafta izleyin. Search Console'da tarama hatalarını, sıralama değişimlerini ve Core Web Vitals raporunu takip edin. AMP'ten çıkışın etkisi genellikle iki-altı hafta içinde netleşir.
Sık Yapılan Hatalar#
AMP'i hız çözümü sanmak. AMP sayfanız hızlıysa bunun büyük kısmı Google önbelleğinden gelir, kendi sunucunuzdan değil. Kullanıcı sitenize başka bir kanaldan girdiğinde yine yavaş sayfanızla karşılaşır. Yani AMP, altyapı sorununuzu çözmez, yalnızca bir kanalda saklar.
Canonical yönünü ters kurmak. AMP sayfası normal sayfayı canonical ile göstermeli, normal sayfa da AMP sürümünü amphtml ile bildirmelidir. Bunu ters çevirdiğinizde Google'a AMP sürümünü asıl içerik olarak sunmuş olursunuz ve kendi alan adınızdaki sayfa değer kaybeder.
İki sürümü senkron tutmamak. İçerik güncellenirken AMP sürümünün geride kalması, kullanıcının eski fiyat ya da eski bilgi görmesine yol açar. Bu, hız kaybından çok daha pahalı bir hatadır.
AMP'i aniden ve topluca kaldırmak. Yönlendirme kurmadan silinen AMP URL'leri 404 üretir; Discover ve haber yüzeylerinden gelen trafiğin bir kısmı geri gelmez. Kaldırma her zaman 301 yönlendirmesiyle birlikte yapılmalıdır.
Ölçmeden karar vermek. Hem kalma hem gitme kararı veriye dayanmalıdır. AMP sayfalarınız toplam organik tıklamanın %2'sini getiriyorsa tartışma bitmiştir; %40'ını getiriyorsa aşamalı ve dikkatli ilerlemelisiniz.
Sıkça Sorulan Sorular#
AMP kullanmazsam Google'da sıralamam düşer mi#
Hayır. AMP bir sıralama faktörü değildir ve haber karuselinde görünmek için de zorunlu değildir. Sıralamada dikkate alınan şey sayfa deneyimi metrikleridir; AMP olmayan hızlı bir sayfa, AMP olan yavaş bir sayfadan daha iyi konumlanabilir. Ancak AMP'i kaldırırken teknik hata yaparsanız (yönlendirme kurmamak, canonical bozmak) trafik kaybedersiniz; kaybın sebebi AMP'in yokluğu değil, geçişin yanlış yapılmasıdır.
AMP'i kaldırmak trafiğimi düşürür mü#
Doğru yapıldığında genellikle kayda değer bir düşüş olmaz; bazı sitelerde kendi alan adında görünmenin marka etkisiyle tıklama oranı bile artar. Riski azaltmak için önce normal sayfalarınızı hızlandırın, kaldırmayı aşamalı yapın, tüm AMP URL'lerini 301 ile yönlendirin ve site haritanızı güncelleyin. Etkiyi görmek için en az dört hafta bekleyin; daha kısa sürede yapılan değerlendirmeler mevsimsel dalgalanmayla karışır.
AMP sayfalarım normal sayfalarımdan gerçekten hızlı mı#
Doğrudan karşılaştırma çoğu kişinin sandığından daha karmaşıktır. AMP sayfası arama sonucundan açıldığında Google önbelleğinden ve önceden yüklenmiş olarak gelir, dolayısıyla neredeyse anında açılır. Aynı AMP sayfasını kendi sunucunuzdan açtığınızda ise fark çok küçülür. Adil kıyas için her iki sürümü de kendi sunucunuzdan, aynı ağ koşullarında ölçün; genellikle iyi optimize edilmiş normal sayfa AMP'e çok yaklaşır.
AMP yerine ne kullanmalıyım#
Ayrı bir teknoloji aramanıza gerek yok; AMP'in dayattığı disiplini kendi sayfanıza uygulamanız yeterli. Kritik CSS'i satır içi yazın, görselleri doğru boyutta ve modern formatta gönderin, JavaScript'i azaltıp erteleyin, üçüncü parti betikleri sıkı denetleyin ve tam sayfa önbelleği kurun. İçeriğiniz sık değişmiyorsa sayfaları önceden üretip statik olarak servis etmek, AMP'in hız hedefine kısıtsız biçimde ulaşmanın en temiz yoludur.
WordPress'te AMP eklentisini kaldırmak güvenli mi#
Eklentiyi kaldırmadan önce mutlaka yönlendirme planınızı hazırlayın, çünkü çoğu eklenti AMP URL'lerini kendi kurallarıyla üretir ve silindiğinde bu adresler 404 dönmeye başlar. Sıralama şu olmalı: önce sunucu ya da .htaccess düzeyinde AMP yollarını normal sayfalara 301 ile yönlendirin, sonra eklentiyi devre dışı bırakın, ardından site haritasını yeniden oluşturun ve Search Console'da tarama hatalarını izleyin. Yedek almadan işlem yapmayın.
AMP dışında mobil hız için en çok neye odaklanmalıyım#
Sırayla üç şey: gönderdiğiniz JavaScript miktarı, görsellerin boyutu ve sunucunun ilk bayt süresi. Mobil cihazın işlemcisi zayıf olduğu için JavaScript, indirilen bayttan daha pahalıya mal olur. Görseller ise toplam ağırlığın çoğunu oluşturur ve ekran genişliğine uygun boyut göndermek tek başına büyük kazanç sağlar. Sunucu tarafında TTFB'yi 200 ms bandına çekmek, geri kalan tüm optimizasyonların üzerine kurulacağı zemindir.
Kapanış#
AMP, ortaya çıktığı dönemde gerçek bir soruna karşılık veriyordu ve web'in mobil hız konusunda ciddileşmesine katkısı oldu. Ama artık bir zorunluluk değil, dar bir senaryo için değerlendirilebilecek bir tercihtir. Aklınızda kalması gereken dört şey: AMP artık sıralama ya da karusel şartı değil; hızın büyük kısmı önbellekten ön yüklemeden geliyor; aynı disiplini kendi sayfanıza uygulayarak kısıt kabul etmeden benzer sonuç alabilirsiniz; ve çıkış yapacaksanız önce normal sayfaları hızlandırıp sonra 301 yönlendirmeleriyle aşamalı ilerleyin.
Normal sayfalarınızı AMP seviyesine çıkarmanın yolu büyük ölçüde sunucudan ve önbellekten geçer. Hazır önbellek yapılandırmasıyla gelen WordPress hosting ve web hosting paketlerimiz ilk bayt süresini düşük tutar; tam kontrol isterseniz VDS üzerinde tam sayfa önbelleği ve Brotli sıkıştırmayı kendi ölçülerinize göre kurabilirsiniz. AMP'ten çıkış sırasında yönlendirme ve ölçüm tarafında destek isterseniz sunucu yönetimi hizmetimizden yararlanabilir, teknik SEO tarafı için SEO sayfamıza göz atabilirsiniz.