Google Search Essentials: Technical Requirement'lar, Spam Policy'leri ve Temel Pratikler

Sürüm notu: Bu yazı Google Search Essentials ve spam policy sayfalarının Kasım 2026 hâlini esas alır; kod örnekleri .NET 10 ile derlenip denenmiştir.

Önce Tahmin Et

Bookstore'a iki özellik eklendi: okurlar kitaplara yorum yazabiliyor ve "okuma listesi" oluşturup linkini arkadaşlarıyla paylaşabiliyor. Üç ay sonra Search Console'da garip sorgular görünüyor: kitapla hiç ilgisi olmayan ilaç ve kumar aramaları, ve bunların hepsi /lists/ altındaki sayfalara gidiyor. Sence bu durumda Google kimi suçlar: spam'i yazanları mı, siteyi mi? Bunu engellemek için hangi tek satırlık header yeterli olurdu? Bir de şunu düşün: bu yorumlardaki link'ler senin sitenin "oyu" sayılır mı?

Search Essentials'ın Üç Parçası

Google Search Essentials, eskiden "Webmaster Guidelines" adını taşıyan belgenin bugünkü hâli. Üç parçadan oluşuyor:

• Technical requirement'lar: Google Search'ün bir sayfayı gösterebilmesi için sayfadan istediği asgari şeyler.
• Spam policy'leri: bir sayfanın veya sitenin daha aşağıda sıralanmasına ya da sonuçlardan tamamen çıkarılmasına yol açabilen davranışlar.
• Key best practice'ler: sitenin nasıl göründüğünü ve sıralandığını en çok etkileyen şeyler.

Sıralama önemli: ilk ikisi "olmazsa olmaz", üçüncüsü "iyi olur". Belgenin her yerinde aynı uyarı tekrarlanıyor: bunlara uymak, Google'ın içeriği crawl edeceği, index'leyeceği veya göstereceği anlamına gelmez. Search Essentials bir sözleşme değil, bir uygunluk listesi.

Technical Requirement'lar: Gerçekten Asgari

Liste üç maddeden ibaret ve çoğu site farkında bile olmadan bunları karşılıyor:

Googlebot engellenmemiş olmalı. Sayfa herkese açık olmalı ve Googlebot ona erişebilmeli; giriş gerektiren sayfalar crawl edilmez. Google burada önemli bir not düşüyor: robots.txt ile engellenen bir URL (Uniform Resource Locator) yine de sonuçlarda görünebilir. Bir sayfayı index dışında tutmak istiyorsan noindex kullan ve crawl'a izin ver.

Sayfa çalışıyor olmalı. Google yalnızca HTTP (Hypertext Transfer Protocol) 200 (success) status code'uyla sunulan sayfaları index'ler; client ve server hata sayfaları index'lenmez. Kontrol yeri Search Console'daki URL Inspection aracı.

İçerik index'lenebilir olmalı. Metin Google'ın desteklediği bir dosya tipinde olmalı ve içerik spam policy'lerine uymalı.

Üç madde kısa ama bir geliştirici için her birinin arkasında bir hata sınıfı var: yanlışlıkla production'a çıkan staging'deki Disallow: /, her şeye 200 dönen bir SPA (Single-Page Application) ya da içeriği yalnızca bir görselin içinde olan sayfa. Bunların teşhisi bu serinin altıncı yazısında, kod tarafındaki çözümleri Teknik SEO (Search Engine Optimization) serisinde.

Spam Policy'lerinin Haritası

Google web search için spam policy'leri tek bir sayfada topluyor. Hepsini ezberlemen gerekmiyor; bir geliştiricinin hangi policy'ye nerede dokunduğunu bilmesi yeterli:

Listede bunlardan başka keyword stuffing, link spam, scraping, thin affiliation, misleading functionality ve Google'a izinsiz otomatik sorgu göndermeyi kapsayan machine-generated traffic da var. Son maddeye dikkat: bu, rank takip etmek için Google sonuç sayfalarını kazıyan araçları da kapsıyor.

2024–2026 Arasında Ne Değişti?

Mart 2024'te üç yeni policy eklendi: scaled content abuse, site reputation abuse ve expired domain abuse. Scaled content abuse'un ifadesi özellikle önemli: içerik "nasıl üretilmiş olursa olsun" kural geçerli. Yani sorun AI ile üretmek değil, değer katmadan toplu üretmek; örnekler arasında generative AI araçlarıyla değer katmadan çok sayıda sayfa üretmek açıkça var.

13 Nisan 2026'da malicious practices policy'sine back button hijacking eklendi: sitenin tarayıcı geçmişini veya başka tarayıcı fonksiyonlarını manipüle ederek kullanıcının geldiği sayfaya hemen dönmesini engellemesi. Bir SPA'da "kullanıcı ayrılmasın" diye history.pushState ile sahte geçmiş kayıtları basan kod artık doğrudan bir policy ihlali.

14 Nisan 2026'dan itibaren Google, kullanıcıların gönderdiği spam raporlarını manual action için kullanabileceğini yazıyor; 23 Nisan'da bunun ne zaman ve neden olabileceği netleştirildi.

15 Mayıs 2026'da Google, spam policy'lerinin Google Search'teki generative AI cevaplarına da uygulandığını açıkça yazdı: AI Overviews ve AI Mode cevaplarını manipüle etmeye yönelik girişimler de spam. Bu konuyu GEO (Generative Engine Optimization) serisinde ayrıca açacağız.

Ağustos 2026'da site reputation abuse'un EEA (European Economic Area, Avrupa Ekonomik Alanı) içindeki uygulaması değişti: EEA'da bu tür sayfalar manual action yerine ana domain'den ayrı bir bölüm gibi değerlendirilebiliyor ve kendi değerleriyle sıralanıyor. EEA dışında manual action yolu sürüyor.

26 Ekim 2026'da user-generated spam rehberi güncellendi: link ile paylaşılan içeriğin index'lenmesini engelleme ve Search Console'da kötüye kullanımı izleme konuları eklendi. Bu, Bookstore'un okuma listesi hikâyesinin ta kendisi.

Manual Action ve Algoritmik Tespit

Google ihlalleri "otomatik sistemler ve gerektiğinde insan incelemesi" ile tespit ediyor. Otomatik tarafta SpamBrain gibi spam detection system'leri çalışıyor; bunlar sana bir bildirim göndermez, sadece sıralama düşer veya sayfa görünmez olur. İnsan incelemesi sonucunda ise manual action verilir ve Google bunu Search Console'daki Manual actions raporunda ve mesaj merkezinde bildirir.

Bu ayrım teşhiste kritik. Manual action varsa ne yapacağın belli: sorunu düzelt, Search Console'dan reconsideration request gönder. Manual action yoksa ve trafik düştüyse, sorun bir spam sistemi, bir core update ya da tamamen teknik bir hata olabilir. Core update'leri ve ne zaman beklemen gerektiğini serinin üçüncü yazısında konuşacağız.

Geliştirici Açısı: Kullanıcı İçeriği ve Link ile Paylaşılan Sayfalar

Baştaki hikâyeye dönelim. Google'ın user-generated spam rehberindeki önerilerden ikisi doğrudan kod: paylaşım veya yardımcı amaçlı sayfaları varsayılan olarak index dışında tutmak ve güvenilmeyen içerikteki link'lere ugc veya nofollow eklemek. Okuma listeleri Search için değil, link'i bilen kişi için var. ASP.NET Core'da bunu endpoint metadata'sıyla ifade etmek temiz bir yol:

namespace Bookstore.Web.Seo;

public sealed record NoIndexMetadata;

public static class NoIndexExtensions
{
    public static TBuilder NoIndex<TBuilder>(this TBuilder builder) where TBuilder : IEndpointConventionBuilder =>
        builder.WithMetadata(new NoIndexMetadata());

    public static IApplicationBuilder UseNoIndexHeader(this IApplicationBuilder app) =>
        app.Use(async (context, next) =>
        {
            context.Response.OnStarting(() =>
            {
                if (context.GetEndpoint()?.Metadata.GetMetadata<NoIndexMetadata>() is not null)
                {
                    context.Response.Headers["X-Robots-Tag"] = "noindex";
                }
                return Task.CompletedTask;
            });
            await next();
        });
}

app.UseNoIndexHeader();

// okuma listeleri link ile paylaşılır, Search için değildir
app.MapGet("/lists/{token}", (string token) =>
        Results.Content($"<h1>Reading list {token}</h1>", "text/html"))
    .NoIndex();

Header, response başlamadan hemen önce, endpoint'in metadata'sına bakılarak ekleniyor. Gerçek istek:

$ curl -si http://localhost:5481/lists/q7Hk2
HTTP/1.1 200 OK
Content-Length: 27
Content-Type: text/html
Date: Sun, 08 Nov 2026 09:06:25 GMT
Server: Kestrel
X-Robots-Tag: noindex

<h1>Reading list q7Hk2</h1>

Dikkat: bu sayfayı robots.txt ile engellemiyoruz. Engellersek Googlebot sayfayı indiremez, header'ı da göremez; dışarıdan link alan URL içeriği okunmadan sonuçlarda görünebilir. noindex ancak crawl serbestken çalışır. X-Robots-Tag'in ayrıntıları ve PDF gibi HTML (HyperText Markup Language) olmayan dosyalara uygulanması Teknik SEO serisinin "noindex ve X-Robots-Tag" yazısında.

Yorumlardaki link'ler için ikinci adım: içeriği encode et, link'leri sen üret ve rel değerini yazarın güvenilirliğine göre ver.

using System.Net;
using System.Text.RegularExpressions;

namespace Bookstore.Web.Seo;

public static partial class ReviewLinkRenderer
{
    [GeneratedRegex(@"https?://[^\s<>""]+")]
    private static partial Regex UrlPattern();

    public static string Render(string reviewText, bool authorIsTrusted)
    {
        string rel = authorIsTrusted ? "ugc" : "ugc nofollow";
        string encoded = WebUtility.HtmlEncode(reviewText);
        return UrlPattern().Replace(encoded, m => $"<a href=\"{m.Value}\" rel=\"{rel}\">{m.Value}</a>");
    }
}

Great book &lt;3 see <a href="https://cheap-pills.example/buy" rel="ugc nofollow">https://cheap-pills.example/buy</a>
Errata: <a href="https://bookstore.example/errata/42" rel="ugc">https://bookstore.example/errata/42</a>

Yeni hesabın yorumundaki link ugc nofollow alıyor, itibarlı okurun linki yalnızca ugc. Google'ın rehberi aynı mantığı sayfa seviyesinde de öneriyor: itibarı olmayan yeni kullanıcıların içeriğini noindex ile başlatıp itibar kazandıkça index'lemeye izin vermek. Önce gelen WebUtility.HtmlEncode da ayrıca bir XSS (Cross-Site Scripting) önlemi; bu konu Web Güvenliği (OWASP Top 10) serisinde.

Key Best Practice'ler

Search Essentials'ın üçüncü parçası kısa bir liste: helpful, güvenilir ve people-first içerik üret; insanların arayacağı kelimeleri title, ana başlık, alt metni ve link metni gibi görünür yerlerde kullan; link'lerin crawl edilebilir olsun; siteni ilgili topluluklarda tanıt; görsel, video, structured data ve JavaScript için verilen özel rehberlere uy; sitene uygun arama özelliklerini etkinleştir; görünmemesi gereken içerik için doğru yöntemi kullan. Listenin ilk maddesi, serinin üçüncü yazısında konuşacağımız ranking system'lerin ve E-E-A-T'nin (Experience, Expertise, Authoritativeness, Trustworthiness: deneyim, uzmanlık, otorite ve güvenilirlik) giriş kapısı.

Üretimde Dikkat

Search Console'u doğrula ve bildirimlerini aç. Manual action ve güvenlik sorunu bildirimleri yalnızca doğrulanmış property sahiplerine gelir; doğrulanmamış bir sitede hacklendiğini Google'dan değil, müşteriden öğrenirsin.

Kullanıcı içeriği üreten her yeni özellik için bir "Search'te görünmeli mi?" kararı ver ve kodda varsayılanı noindex yap. Google'ın rehberi de izlemeyi öneriyor: Page indexing ve Performance raporlarında index'lenen sayfa, impression veya platformunla ilgisiz sorgularda ani sıçrama, kötüye kullanımın en erken işareti.

Server log'unda paylaşım URL'lerine gelen trafiği izle. Okuma listelerine bir gecede binlerce dış referrer'dan istek geliyorsa birisi bu sayfaları spam için kullanıyor demektir.

Sık Düşülen Tuzaklar

"White hat / black hat" folkloruyla düşünmek. Bu ikili ayrım sektörün argosu; Google'ın belgelerinde bir karşılığı yok. Bağlayıcı olan, spam policy'lerinin kendisi. "Gri" diye satılan bir taktiği tartışırken soru "hangi şapka?" değil, "hangi policy'ye giriyor?" olmalı.

Policy'leri yalnızca SEO ekibinin işi sanmak. Back button hijacking, cloaking, sneaky redirect ve hacked content doğrudan frontend ve backend kodunda doğar. Code review'da bu policy'leri bilen biri olmalı.

AI ile üretilen içeriği tek başına sorun sanmak ya da tam tersine, "Google AI'a bir şey demiyor" deyip yüzlerce şablon sayfa basmak. Kural üretim biçimine değil, ölçeğe ve kullanıcıya katılan değere bakıyor. Bu mit serinin yedinci yazısında ayrıca ele alınacak.

Spam'i silip bırakmak. Hacklenmiş veya spam dolmuş sayfaları temizledikten sonra açığı kapatmazsan aynı içerik geri gelir; manual action varsa reconsideration request göndermeden önce kök nedeni düzelt.

Küçük Bir Deneme

★☆☆ Kendi projende kullanıcının ürettiği veya link ile paylaşılan bütün sayfa tiplerini listele. Her biri için "index'lenmeli mi?" sorusuna tek kelimeyle cevap ver.

★★☆ NoIndexMetadata'yı Razor Pages için de çalışır hâle getir: bir page'e convention ile metadata ekle ve curl -si ile header'ı doğrula.

★★★ ReviewLinkRenderer'ı genişlet: yazarın onaylı yorum sayısı 5'ten azsa yorum sayfasına <meta name="robots" content="noindex"> eklesin; 5 ve üzerindeyse index'lemeye izin versin. İki durumu da gerçek istekle göster.

Kuralları gördük; bir sonraki yazıda kuralların öbür yüzüne, Google'ın sıralamayı nasıl yaptığına geçiyoruz: ranking system'ler, core update'ler ve çokça yanlış anlaşılan E-E-A-T.