John Flaxman's randoms

Bir HTML sayfasını AMP'ye çevirmek için beş şey gerekiyor: <html ⚡> ve zorunlu AMP iskeleti (charset, viewport, canonical, AMP çalışma zamanı, boilerplate stili), tüm CSS'in tek bir <style amp-custom> bloğunda ve 75.000 baytın altında toplanması, kendi yazdığınız JavaScript'in ve onclick gibi olay özniteliklerinin kaldırılması, <img>, <video>, <iframe> gibi etiketlerin genişlik ve yüksekliği belli AMP bileşenlerine çevrilmesi ve son olarak sayfanın resmî AMP doğrulayıcısından hatasız geçmesi.

Bunu elle yapabilirsiniz, ama uzun bir sayfada saatler sürer. Ben bu AMP çeviri işini kendi yazdığım AMP converter aracıyla yapıyorum; araç dönüşümü tarayıcıda yapıyor, sonucu resmî doğrulayıcıyla kontrol ediyor ve kalan hataları satır numarasıyla gösteriyor. Aşağıda hem kuralları hem adımları hem de en sık doğrulama hatalarını anlatıyorum.

Kısa cevap: hayır, AMP 2026'da SEO için gerekli değil. AMP bir sıralama faktörü değil; Google AMP sayfalarını diğer sayfalar gibi dizine ekliyor ve sıralıyor. Top Stories karuseli için AMP şartı 2021'de kalktı, AMP rozeti de aynı yıl kaldırıldı. 1 Temmuz 2026'dan beri Google Arama, AMP sonucuna tıklayan kullanıcıyı Google'ın önbelleğine değil, doğrudan yayıncının kendi alan adındaki AMP sayfasına gönderiyor.

Belirleyici olan biçim değil, deneyim: Core Web Vitals ve genel sayfa deneyimi. Hızlı ve temiz bir normal HTML sayfa, AMP'nin bir zamanlar sağladığı her yere girebiliyor. AMP'yi tutmak için mantıklı nedenler var ama hepsi "zaten çalışıyor" ya da "SEO dışı bir ihtiyaç" kategorisinde.

Türkiye'de bahis ve "deneme bonusu" spam'inde sık gördüğüm bir örüntü var: spam'ciler kendi alan adlarıyla sıralama alamadıkları için AMP sayfalarını başkasının alan adına yerleştiriyor. Bu genelde ele geçirilmiş bir sitenin klasörü, kimsenin takip etmediği bir alt alan adı ya da canonical ve amphtml ilişkisinin iki ilgisiz alan adı arasında kötüye kullanılması şeklinde oluyor. Amaç, güvenilir bir alan adının itibarıyla sıralama alıp kullanıcıyı sık değişen asıl bahis adresine aktarmak.

Google bunların hepsini spam sayıyor: hacklenmiş içerik, site itibarı istismarı, cloaking ve sinsi yönlendirme. Bu yazı savunma tarafı için: alan adınızın bu şekilde kullanılıp kullanılmadığını nasıl anlarsınız, nasıl temizlersiniz, bir daha nasıl önlersiniz. Kurulumla ilgili hiçbir ayrıntı vermiyorum.

Google'ın AI Bakışı (AI Overviews) ve AI Modu, 18 Şubat 2026'dan beri Türkiye'de kademeli olarak açılıyor. Google hangi sorguda çıkacağına dair bir liste vermiyor; yalnızca üretken yapay zekânın o sorguya gerçekten fayda katacağına karar verdiğinde göründüğünü söylüyor. Türkiye'deki ilk ajans verisi ise AI Bakışı'nın en çok bilgi amaçlı sorgularda, daha az da satın alma ve araç sorgularında çıktığını gösteriyor.

Alıntılanmak için ayrı bir optimizasyon yok. Sayfanın dizinde olması ve arama sonucunda snippet ile gösterilmeye uygun olması yetiyor; gerisi bildiğimiz SEO: net cevap, özgün bilgi, taranabilir metin, iyi sayfa deneyimi. Aşağıda Türkiye'ye özgü verileri, kaynak seçimini ve kendi sorgularınızı elle nasıl kontrol edeceğinizi topladım.

AI Bakışı ve AI Modu'ndan gelen tıklamalar Search Console'da ayrı bir satır olarak görünmüyor; normal Performans raporunun "Web" arama türünün içinde, klasik organik tıklamalarla karışık duruyor. Haziran 2026'da gelen ve 31 Ağustos 2026'dan beri tüm sitelerde açık olan Generative AI performans raporu ise yalnızca gösterim veriyor: tıklama, TO ve sorgu yok.

Yani Google tarafında "AI Bakışı'ndan şu kadar tıklama geldi" diyebileceğiniz bir sayı yok. Ölçebildikleriniz şunlar: Search Console'da sayfa bazında AI gösterimi, GA4'te ChatGPT, Gemini, Claude gibi asistanlardan gelen yönlendirme trafiği, Bing'de Copilot alıntıları ve sunucu loglarında yapay zekâ botlarının ziyaretleri. Aşağıda her birini, sınırlarıyla birlikte anlatıyorum.

Search Console MCP sunucusu, yapay zekâ asistanınızla Search Console API arasında duran küçük bir programdır. Asistan "geçen ayın en çok tıklanan sorgularını getir" dediğinde sunucu sizin yetkinizle API'yi çağırıyor, sonucu asistana veriyor. Kurulum dört adım: Google Cloud'da Search Console API'yi açmak, bir OAuth istemcisi ya da hizmet hesabı oluşturmak, bu hesaba Search Console'da erişim vermek ve sunucuyu MCP istemcinizin yapılandırmasına eklemek.

10 Ekim 2026 itibarıyla Google'ın resmi bir Search Console MCP sunucusu yok; kullanılabilenler GitHub'daki topluluk projeleri. Bu yüzden hangi projeyi seçtiğiniz ve ona hangi yetkiyi verdiğiniz, kurulumun kendisinden daha önemli.

Önce sitenin dizinde olup olmadığını netleştirin. Bunu site: sorgusuyla değil, Search Console'daki URL Denetimi aracıyla yapın. Sayfa dizinde değilse sebep neredeyse her zaman şu listeden biridir: noindex etiketi ya da X-Robots-Tag başlığı, robots.txt engeli, başka bir adresi gösteren canonical, Googlebot'un sayfaya ulaşamaması, sitenin yeni olup hiçbir yerden bağlantı almaması ya da manuel işlem.

Sayfa dizindeyse ama aradığınızda çıkmıyorsa sorun dizine eklenme değil, sıralamadır. İkisi farklı işlerdir ve farklı çözümler ister. Aşağıdaki sırayı izlerseniz çoğu durumda on beş dakika içinde hangi gruptan olduğunuzu anlarsınız.

Türkiye'de verilen bir erişim engeli, Türkiye'deki internet erişim sağlayıcıları üzerinden uygulanır ve yalnızca Türkiye'den gelen erişimi keser. Googlebot ise varsayılan olarak ABD merkezli görünen IP adreslerinden tarar. Bu yüzden engellenen bir site çoğu zaman Google'da dizinde kalır, Search Console'da her şey normal görünür ama Türkiye'deki kullanıcılar arama sonucuna tıkladığında siteye ulaşamaz.

Kısacası sorun dizinde değil, kullanıcı tarafında. Trafik, dönüşüm ve zamanla sitenin aldığı dolaylı sinyaller zarar görür. Hukuki tarafta tek sağlıklı yol resmi süreçtir: kararı öğrenmek, gerekiyorsa itiraz etmek ya da ihlal konusu içeriği kaldırmak. Alan adı değiştirerek engelden kaçmak ise hem SEO hem hukuk açısından ayrı bir risk alanı açar.

İşletme profilinize kısa sürede çok sayıda 1 yıldızlı yorum geliyorsa ve yorumların arkasında yeni açılmış ya da müşteriniz olması mümkün olmayan hesaplar varsa, büyük ihtimalle sahte yorum saldırısıyla karşı karşıyasınız. Yapılacak iş belli: kanıtları hemen kaydedin, her yorumu Google'ın İnceleme Yönetim Aracı üzerinden bildirin, para isteyen biri varsa ödeme yapmadan şantaj bildirim formunu kullanın, reddedilen bildirimler için tek seferlik itiraz hakkınızı kullanın.

Google sahte yorumları "sahte etkileşim" kapsamında yasaklıyor ve kaldırıyor. Ama süreç birkaç gün, bazen daha uzun sürüyor. O sürede yapacağınız şey; sakin, belgeli ve politikaya dayanan bir müdahale.

Dört altyapı da temel işleri belgeliyor: title ve meta açıklamalarını düzenleyebiliyorsunuz, URL'leri değiştirebiliyorsunuz, site haritası otomatik üretiliyor ve 301 yönlendirmesini panelden ekleyebiliyorsunuz. Farklar daha ince yerlerde çıkıyor: robots.txt'ye doğrudan erişim, canonical'ı sayfa bazında yönetebilmek, filtre URL'lerinin dizine girmesini kontrol etmek, hreflang ve <head> alanına serbestçe kod ekleyebilmek.

Asıl sınır çoğu zaman özelliğin olup olmaması değil, kontrolün kimde olduğu. SaaS bir altyapıda sunucuya, şablonun tamamına ve URL yönlendirme mantığına siz değil platform karar verir. Aşağıdaki tablo, 10 Ekim 2026 itibarıyla resmi yardım ve özellik sayfalarında bulabildiklerimden oluşuyor. Bulamadığım her şeyi "doğrulanamadı" diye işaretledim. Bu, özelliğin olmadığı anlamına gelmiyor; belgelerde bulamadığım anlamına geliyor.