Google Dizinleme API

TL;DR — Google Indexing API, site sahiplerinin Google’a “bu sayfa değişti, lütfen yeniden tarayın” demesini butonlara tıklamak yerine kod ile yapmasını sağlayan bir yöntemdir. Ancak çoğu rehberin atladığı bir ayrıntı var: Google bunu yalnızca iş ilanı sayfaları ve canlı yayın sayfaları için resmi olarak destekler. Blog yazılarınızın veya ürün sayfalarınızın daha hızlı dizinlenmesi için bir kısayol değildir — Google bunu defalarca söyledi.

Indexing API nedir

Bir sayfa yayınladığınızda veya değiştirdiğinizde, normalde Google’ın kendi programına göre geri gelip sayfayı yeniden taramasını beklersiniz. Indexing API, bunun yerine Google’a bir bildirim göndermenin bir yoludur — “hey, bu URL yeni/güncellendi” veya “bu URL artık yok, kaldırın.” Bunu bir panelde tıklayarak değil, kod ile (Google’ın sunucularını çağıran küçük bir program) yaparsınız.

Bu kulağa güçlü geliyor ve öyle de — tam olarak yapılmak üzere tasarlandığı şeyler için.

Anlaşılması gereken tek şey

Google, Indexing API’yi yalnızca iki tür sayfa için resmi olarak destekler:

1. İş ilanları — JobPosting yapılandırılmış verisine sahip sayfalar (iş listeleri, hızla sona eren ve hızlıca kaldırılması gerekenler).
2. Canlı yayınlar — BroadcastEvent yapılandırılmış verisine sahip sayfalar (yalnızca yayın sırasında önemli olan canlı video etkinlikleri).

Hepsi bu. Her ikisi de hızla bayatlayan zamana duyarlı içeriklerdir, bu yüzden Google onlar için hızlı bir şerit oluşturdu.

İş ilanlarınız veya canlı yayınlarınız yoksa, Indexing API sizin aracınız değildir — “saatler içinde dizinlenin” diyen bir eklenti veya SaaS ne derse desin.

Görmezden gelmeniz gereken efsane

Çevrimiçi en büyük efsane şudur: “Herhangi bir sayfayı hızlıca dizinlemek için Indexing API’yi kullanın.” Bu şekilde çalışmaz ve Google, normal sayfalar için kullanılmasını defalarca kötüye kullanım olarak nitelendirdi. İnsanlar yine de yapıyor çünkü araçlar bunu bir büyüme taktiği olarak satıyor — ancak Google, kötüye kullanım nedeniyle erişiminizi iptal edebilir (ve edeceğini söylüyor).

İkinci bir tuzak daha var: bir URL gönderip “başarılı” yanıtı aldığınızda, bu yalnızca Google’ın isteğinizi aldığı anlamına gelir. Sayfanın dizinlendiği anlamına gelmez. Pek çok araç bu çizgiyi bulanıklaştırır; Google’ın kendi belgeleri bu konuda nettir.

Daha hızlı dizinleme için bunun yerine ne yapmalı

Normal sayfalar (bloglar, ürünler, makaleler) için gerçekten yardımcı olan şeyler sıkıcı ama gerçektir:

• Google Search Console’da bir XML site haritası gönderin.
• Yeni sayfalarınıza sitenizdeki diğer sayfalardan bağlantı verin.
• Sayfayı gerçekten dizinlenmeye değer kılın (kalite, ince içerik değil).
• Tek seferlik için, Search Console’un URL İnceleme aracındaki “Dizine eklemeyi iste” özelliğini kullanın — idareli olarak.

Teknik sürümü mü istiyorsunuz — kurulum, gerçek API yöntemleri, kotalar ve Google’ın birebir alıntıları? Gelişmiş sekmesine geçin.

TL;DR — Indexing API, URL_UPDATED ve URL_DELETED bildirimlerini kabul eden, Google Cloud kimlik doğrulamalı bir REST API’dir (v3). Google, bunu yalnızca JobPosting ve BroadcastEvent içindeki VideoObject (canlı yayın) sayfaları için resmi olarak destekler — genel içerik için değil. Durum uç noktasından gelen bir 200, alındığını doğrular, dizinlemeyi değil. Google’ın tutumu yıllar içinde sertleşti: 2022 (“mantıklı değil”) → Eylül 2024 (belgelere bir spam uyarısı eklendi) → Mayıs 2025 (Mueller: “spammer’lar Indexing API’yi kötüye kullanıyor… düzgün kullanın ya da kullanmayın”). Kotayı şişirmek için birden fazla hesap dahil kötüye kullanım, erişimin iptal edilmesine neden olabilir. Genel sayfalar için kaldıraçlarınız site haritaları, iç bağlantılar, kalite ve ara sıra GSC “Dizine eklemeyi iste” özelliğidir — ve Google’ın IndexNow’u desteklemediğini unutmayın.

Indexing API aslında nedir

Indexing API, Google’ın bir URL’nin eklendiğini/güncellendiğini (URL_UPDATED) veya kaldırılması gerektiğini (URL_DELETED) bildirmek için çağırdığınız, bir Google Cloud hizmet hesabı aracılığıyla kimlik doğrulaması yapılan programatik bir push kanalıdır: bir REST API (v3). Sitemaps ve Search Console’un yanında, Google’ın URL’leri keşfetmesi ve yenilemesi için bir yol olarak durur — ancak içerik türü açısından bunların en dar kapsamlısıdır.

How Search Works sunumumda, Indexing API’yi “sınırlı kullanım durumları” etiketiyle bir URL keşif kaynağı olarak listeliyorum — bu, hikayenin tamamını iki kelimeyle anlatır. Gerçektir, çalışır ve yalnızca web’in çok küçük bir kısmı için onaylanmıştır.

Google’ın resmi olarak desteklediği kullanım alanları

Bu, yük taşıyan gerçektir, bu yüzden Google’ın söylediği gibi ifade edeceğim. Indexing API “yalnızca JobPosting veya BroadcastEvent içine gömülü VideoObject içeren sayfaları taramak için kullanılabilir.” İşte bu kadar — iki yapılandırılmış veri türü:

• JobPosting — iş ilanı sayfaları. Bunların süresi dolar ve bayat işler kötü bir kullanıcı deneyimidir, bu nedenle zamanında ekleme/kaldırma önemlidir.
• BroadcastEvent içinde VideoObject — canlı yayın etkinlik sayfaları. Bunlar yalnızca yayın sırasında (ve hemen çevresinde) geçerlidir.

Neden yalnızca bu ikisi? Her ikisi de doğası gereği zamana duyarlı ve kısa ömürlüdür. Google’ın verdiği gerekçe, değişikliklerin hızlı bildirilmesinin, normal taramanın sorunsuz hallettiği kalıcı sayfalardan çok daha önemli olduğudur.

Nasıl çalışır

Ön koşullar

Kurulum önemsiz değildir — bu tek tıklamalık bir özellik değildir:

• Indexing API’nin etkinleştirildiği bir Google Cloud projesi. Google’ın dediği gibi, “Google’a istemcinizden bahsetmeniz ve API’ye erişimi etkinleştirmeniz gerekir.”
• JSON anahtar dosyasına sahip, güvenli bir şekilde saklanan bir hizmet hesabı.
• Sitenin Search Console doğrulaması, ardından hizmet hesabınızı delege edilmiş site sahibi olarak ekleyin.
• OAuth: “Indexing API’ye yapılan her çağrı, özel anahtarınız karşılığında aldığınız bir OAuth belirteciyle doğrulanmalıdır,” https://www.googleapis.com/auth/indexing kapsamı kullanılarak.

İki yöntem (artı bir durum kontrolü)

• URL_UPDATED — “Google’a taranacak yeni bir URL veya daha önce gönderilmiş bir URL’deki içeriğin güncellendiğini bildirmek için.” URL’yi "type": "URL_UPDATED" ile POST edin. Başarılı bir çağrı HTTP 200 alır — Google’ın kendi ifadesi, bunun “Google’ın bu URL’yi yakında yeniden taramayı deneyebileceği anlamına geldiği,” tarayacağı veya taramanın dizine eklemeyle sonuçlanacağı anlamına gelmediğidir.
• URL_DELETED — kaldırma talep etmeden önce Google, “URL’nin bir 404 veya 410 durum kodu döndürmesi veya sayfanın” bir noindex meta etiketi içermesi gerektiğini şart koşar — bu bir ya/ya dadır, “sayfayı sil ve ayrıca noindex ekle” değil. Bu doğru olduğunda, Google’ın onu bırakması için URL’yi "type": "URL_DELETED" ile POST edin.
• Durum (GET) — meta verileri döndürür (latest_update, latest_remove, notify_time). Kritik uyarı, kelimesi kelimesine: GET isteği “yalnızca bir isteği başarıyla gönderip göndermediğinizi döndürür.” Google’ın gerçekten bir şeyi dizine ekleyip eklemediğini veya kaldırıp kaldırmadığını size söylemez.
• Toplu işleme — HTTP bağlantılarını azaltmak için “Indexing API’ye yapılan 100’e kadar çağrıyı tek bir HTTP isteğinde birleştirebilirsiniz.” Kota yine URL başına sayılır: bir toplu işteki 10 istek yine 10 istek kota kullanır.

Kotalar

Google’ın varsayılan kotasının yalnızca tek bir sayı değil, üç ayrı boyutu vardır:

• Proje başına günde 200 yayın isteği — hem URL_UPDATED hem de URL_DELETED çağrılarını birlikte kapsar. Bu, çoğu kılavuzun atıfta bulunduğu sayıdır.
• Proje başına dakikada 180 getMetadata (durum) isteği.
• Proje başına tüm uç noktalar genelinde dakikada 380 istek.

Üçü de “test için başlangıç varsayılan kotası” olarak tanımlanıyor — bunların ötesine geçmek, bir istek formu aracılığıyla “kullanım ve kaynak sağlama için ek onay gerektirir” ve Google, “kotanın belge kalitesine bağlı olarak artabileceğini veya azalabileceğini” belirtiyor. Günlük kotayı şişirmek için birden fazla hizmet hesabı veya proje oluşturma şeklindeki yaygın “hack”, Google’ın tam olarak yasakladığı şeydir (aşağıya bakın).

Normal sayfalar için kullanabilir misiniz? Google’ın gerçekte söyledikleri

Kısa cevap: hayır, desteklenen bir şekilde değil — ve Google bu konuda dikkat çekici şekilde tutarlı ve giderek daha açık sözlü oldu.

Belgeler bir spam uyarısı taşıyor. Eylül 2024 civarında Google, hızlı başlangıç kılavuzuna bu tutumu açıkça belirten bir dil ekledi: “Indexing API aracılığıyla yapılan tüm gönderimler titiz spam tespitinden geçer,” ve “birden fazla hesap kullanımı veya kullanım kotalarını aşmanın diğer yolları dahil olmak üzere Indexing API’yi kötüye kullanma girişimleri, erişimin iptal edilmesiyle sonuçlanabilir.”

Temsilciler bunu yıllardır söylüyor. Mayıs 2022’de John Mueller bunu inşaat araçları benzetmesiyle çerçeveledi: API “çok özel türdeki içerikler için tasarlanmıştır,” ve başka yerlerde kullanmak “gerçekten mantıklı değil.” Mayıs 2025’e gelindiğinde ton daha keskinleşti — Mueller: “Spammer’ların Indexing API’yi bu şekilde kötüye kullandığını çok görüyoruz, bu yüzden belgelenen ve desteklenen kullanım durumlarına bağlı kalmanızı öneririm,” ve “Onu düzgün kullanın ya da hiç kullanmayın. İnsanların onu her koşulda kullanabileceğini önermek isteseydik, bunu belgelerdik.”

Bu yay — 2022 “mantıklı değil” → 2024 belgelerde spam uyarısı → 2025 “spammer’lar kötüye kullanıyor… düzgün kullan ya da hiç kullanma” — tek seferlik bir durum değil, çok yıllık bir model. Kapsam ayrıca API’nin, normal siteleri uygunmuş gibi ele alan blog yazarları ve SEO’lar tarafından fiilen istila edildiğini de belirtti.

Gerçek risk, tam olarak ifade edilmiş. Mueller algoritmik bir ceza vaat etmekten kaçınıyor. Dürüst çerçeve şudur: desteklenmiyor ve yönergelere aykırı, uygunsuz şekilde gönderilen içerik dizinde kalmayabilir ve erişiminiz iptal edilebilir. Bunu garantili bir manuel işlem olarak abartmayın — ama bedava olduğunu da varsaymayın.

Durum uç noktası efsanesi

Bu, kendi satırını hak ediyor çünkü birçok araç bunu yanlış anlıyor: başarılı bir gönderim makbuz onayıdır, dizine ekleme vaadi değildir. Durum GET “yalnızca bir isteği başarıyla gönderip göndermediğinizi döndürür.” Bir gösterge paneli size bir 200’ün ardından yeşil bir “dizine eklendi” rozeti gösteriyorsa, API’nin asla söylemediği bir şeyi çıkarım yapıyordur.

Indexing API vs Request Indexing vs IndexNow

Üç şey sürekli birbirine karıştırılıyor. Bunlar farklı mekanizmalardır:

• Indexing API (Google): programatik, ancak içerik JobPosting/BroadcastEvent ile sınırlı. Üçünün en darı.
• Request Indexing (GSC URL Inspection): sahip olduğunuz herhangi bir sayfa için çalışır, ancak manueldir, her seferinde bir URL ve ara sıra kullanım içindir — ve bir istektir, garanti değil.
• IndexNow: açık, çapraz motor push protokolü (Bing, Yandex, Yep, Seznam, Naver) — ve Google bunu kullanmıyor. Indexing API’nin çapraz motor karşılığı ve gerçekten savunduğum şey: Ahrefs Site Audit’te IndexNow entegrasyonunun yayınlanmasına yardımcı oldum. Ama Google’a ulaşmıyor.

(Tam döküm Frameworks sekmesinde.)

Genel sayfalar için bunun yerine ne yapmalı

İş ilanı veya canlı yayın paylaşmıyorsanız, Indexing API sizin aracınız değil ve Google bunu defalarca söyledi. Gerçek Google kaldıraçlarınız gösterişsiz olanlar:

• Sitemaps — kapsam ve keşif için.
• İç bağlantılar — öksüz sayfalar zorlanır; bağlantılı sayfalar bulunur.
• İçerik kalitesi — Google neyin dizine eklenmeye değer olduğuna karar verir; ince sayfalar ne kadar zorlarsanız zorlayın “Keşfedildi – şu anda dizine eklenmedi” durumunda takılı kalır.
• GSC “Request indexing” — gerçek tek seferlik durumlar için, idareli.

Çapraz motor gönderimi için (Bing ve benzerleri, Google değil), IndexNow doğru araçtır. Ve sayfaların neden ilk etapta dizine eklenmediğini neden önemsiyorsanız, bu bir tarama sıklığı ve kalite sorunudur, bir API sorunu değildir.

AI özeti

Gelişmiş sürümün yoğunlaştırılmış bir değerlendirmesi:

• Nedir: Google Cloud tarafından doğrulanmış bir REST API (v3) — Google’a URL_UPDATED / URL_DELETED bildirimleri göndermek için.
• Önemli olan tek gerçek: resmi olarak yalnızca JobPosting ve BroadcastEvent (canlı yayın) sayfaları için desteklenir — genel içerik için değil. Her ikisi de tasarım gereği zamana duyarlıdır.
• 1 numaralı efsane: “her sayfayı hızlıca dizine ekler.” Öyle değil; Google daha geniş kullanımı kötüye kullanım olarak adlandırır. Başarılı bir gönderim yalnızca Google’ın isteği aldığını doğrular, hiçbir şeyin dizine eklendiğini değil.
• Google’ın tutumu zamanla sertleşti: 2022 “mantıklı değil” → Eylül 2024 belgelere spam uyarısı eklendi → Mayıs 2025 Mueller “spam gönderenler kötüye kullanıyor… düzgün kullanın, ya da kullanmayın.”
• Risk: desteklenmiyor/kurallara aykırı; ~200/gün kotasını aşmak için birden fazla hesap erişimin iptal edilmesine neden olabilir. Mutlaka manuel bir ceza değil — ancak içerik kalıcı olmayabilir.
• IndexNow ile aynı değil (çapraz motor, Bing/Yandex/vb. — Google onu kullanmaz) veya GSC Request Indexing (herhangi bir sayfa, manuel, ara sıra).
• Normal sayfalar için: site haritaları + iç bağlantılar + kalite + ara sıra GSC Request Indexing.

Resmi dokümantasyon

Google’dan birincil kaynak belgeler.

Google — Indexing API

• Indexing API Quickstart — genel bakış, JobPosting/BroadcastEvent kısıtlaması ve spam algılama uyarısı.
• How to Use the Indexing API — URL_UPDATED / URL_DELETED yöntemleri ve durum uç noktası uyarısı.
• Prerequisites — Cloud projesi, hizmet hesabı, OAuth kapsamı ve Search Console’da devredilen sahiplik.
• Quota and pricing — varsayılan kota (200) ve daha fazlası için gereken onay.

Google — genel sayfalar için bağlam

• Ask Google to recrawl your URLs — site haritaları ve normal içerik için Search Console “Request indexing” yolu.
• In-Depth Guide to How Google Search Works — URL keşfinin ve tarama → dizin → sunum hattının nereye uyduğu.

Kaynaktan alıntılar

Google’dan kayıtlara geçen ifadeler. Her bağlantı, kaynak sayfadaki alıntılanan pasaja atlayan bir derin bağlantıdır.

Google belgeleri — kısıtlama

• “The Indexing API can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject.” (çeviri) «Indexing API yalnızca bir VideoObject içine gömülü JobPosting veya BroadcastEvent içeren sayfaları taramak için kullanılabilir.» — Google Search Central, Indexing API Quickstart. Alıntıya git
• “The Indexing API allows site owners to directly notify Google when their job posting or livestreaming video pages are added or removed.” (çeviri) «Indexing API, site sahiplerinin iş ilanı veya canlı yayın video sayfaları eklendiğinde veya kaldırıldığında Google’ı doğrudan bilgilendirmesine olanak tanır.» Alıntıya git

Google belgeleri — spam uyarısı (belgelere yaklaşık Eylül 2024’te eklendi)

• “All submissions through the Indexing API undergo rigorous spam detection.” (çeviri) «Indexing API üzerinden yapılan tüm gönderimler sıkı spam tespitinden geçer.» Alıntıya git
• “Any attempts to abuse the Indexing API, including the use of multiple accounts or other means to exceed usage quotas, may result in access being revoked.” (çeviri) «Indexing API’yi kötüye kullanma girişimleri, birden fazla hesap kullanımı veya kullanım kotalarını aşmanın diğer yolları dahil, erişimin iptal edilmesiyle sonuçlanabilir.» Alıntıya git

Google dokümanları — durum uç noktası uyarısı (efsane yıkıcı)

• “The GET request doesn’t tell you when Google indexes or removes a URL; it only returns whether you successfully submitted a request.” (çeviri) «GET isteği, Google’ın bir URL’yi ne zaman dizine eklediğini veya kaldırdığını söylemez; yalnızca bir isteği başarıyla gönderip göndermediğinizi döndürür.» — Google Search Central, Indexing API Nasıl Kullanılır. Alıntıya git

Google dokümanları — kota

• “The default value is set to 200.” (publish requests/day) — Google Search Central, quota & pricing. Jump to quote
• “The default value is set to 180.” (getMetadata status requests/minute) and “The default value is set to 380.” (all endpoints/minute) — the two other quota dimensions most guides skip. Jump to 180 · Jump to 380
• “The quota may increase or decrease based on the document quality.” — Google Search Central, quota & pricing. Jump to quote

Google dokümanları — toplu işleme ve kaldırma

• “…you can combine up to 100 calls to the Indexing API into a single HTTP request.” — Google Search Central, How to Use the Indexing API. Jump to quote
• “…the URL must return a 404 or 410 status code or the page must contain” a noindex meta tag — before requesting removal. — Google Search Central, How to Use the Indexing API. Jump to quote
• “An HTTP 200 response means that Google may try to recrawl this URL soon.” — Google Search Central, How to Use the Indexing API (on URL_UPDATED). Jump to quote

John Mueller, Google Arama Savunucusu — Bluesky, ~Mayıs 2025

• “We see a lot of spammers misuse the Indexing API like this, so I’d recommend just sticking to the documented & supported use-cases.” (çeviri) «Bu şekilde birçok spam göndericinin Indexing API’yi kötüye kullandığını görüyoruz, bu yüzden yalnızca belgelenmiş ve desteklenen kullanım durumlarına bağlı kalmanızı öneririm.»
• “I’d just use it properly, or not use it. If we wanted to suggest that people could use it regardless, we’d document it as such.” (çeviri) «Ben sadece düzgün kullanırdım ya da hiç kullanmazdım. İnsanların yine de kullanabileceğini önermek isteseydik, bunu böyle belgelerdik.» Kapsamı okuyun

John Mueller, Google — SEO ofis saatleri, Mayıs 2022 (“inşaat araçları” çerçevesi)

• “The indexing API is meant for very specific kinds of content. And using it for other kinds of content doesn’t really make sense.” (çeviri) «Indexing API yalnızca çok belirli türdeki içerikler için tasarlanmıştır. Ve onu başka türdeki içerikler için kullanmak gerçekten mantıklı değil.»
• “It’s not that it’s illegal or that it will cause problems if you put construction vehicles on your medical website. But it doesn’t really make sense.” (çeviri) «Tıbbi web sitenize inşaat araçları koymanız yasa dışı olduğu veya sorunlara yol açacağı için değil. Ama gerçekten mantıklı değil.» Haberin tamamını okuyun

Indexing API — hızlı başvuru

Desteklenen kullanım durumları (tam liste budur)

İki yöntem

Toplu işleme: 100’e kadar çağrıyı tek bir HTTP isteğinde birleştirin — kota yine de URL başına sayılır, toplu işlem başına değil.

Hızlı bilgiler

• Varsayılan kotanın üç bölümü vardır: günde 200 yayın isteği, dakikada 180 durum (getMetadata) isteği, tüm uç noktalarda dakikada 380 istek. Bunun ötesindeki kota Google’ın onayını gerektirir ve belge kalitesine göre değişebilir.
• 200 ≠ dizine eklenmiş. Başarılı bir yanıt yalnızca gönderimin alındığını onaylar, başka bir şey değil.
• Kotayı aşmak için birden fazla hesap kullanmak = erişimin iptal edilmesi (belgelere göre).
• Kimlik doğrulama: Google Cloud projesi + hizmet hesabı + OAuth, kapsam https://www.googleapis.com/auth/indexing, hizmet hesabı GSC’ye devredilmiş sahip olarak eklenir.
• IndexNow değildir (çapraz motor, Google değil). Sitemap’lerin veya GSC Request Indexing’in yerine geçmez.

Minimal bir yayın çağrısı (yalnızca desteklenen içerik için)

Bu, tek bir URL_UPDATED bildiriminin şeklidir. Yalnızca JobPosting veya BroadcastEvent yapılandırılmış verilerine sahip sayfalar için kullanın — API’nin izin verdiği kullanım budur. Kimlik doğrulama adımı (hizmet hesabı anahtarınızı bir OAuth belirteciyle değiştirme) kısaltma amacıyla atlanmıştır; pratikte belirteci almak için bir Google API istemci kitaplığı kullanırsınız.

İstek

POST https://indexing.googleapis.com/v3/urlNotifications:publish
Authorization: Bearer <OAUTH_TOKEN>
Content-Type: application/json

{
  "url": "https://example.com/jobs/senior-seo-analyst",
  "type": "URL_UPDATED"
}

Bir kaldırma işlemini bildirmek için (sayfa kaldırıldıktan veya noindex yapıldıktan sonra):

{
  "url": "https://example.com/jobs/senior-seo-analyst",
  "type": "URL_DELETED"
}

Durumu kontrol etme — yanıtın yalnızca isteğin alındığını söylediğini, herhangi bir şeyin dizine eklenip eklenmediğini söylemediğini unutmayın:

GET https://indexing.googleapis.com/v3/urlNotifications/metadata?url=https%3A%2F%2Fexample.com%2Fjobs%2Fsenior-seo-analyst
Authorization: Bearer <OAUTH_TOKEN>

Burada 200 yanıtı “gönderiminizi aldık” anlamına gelir — Google’ın URL’yi dizine eklediğinin (veya kaldırdığının) onayı değildir.

Birden fazla URL’yi toplu işleme: 100 ayrı istek göndermek yerine, 100’e kadar bireysel çağrıyı https://indexing.googleapis.com/batch adresine tek bir çok parçalı HTTP isteğinde birleştirebilirsiniz — ancak kota yine de URL başına sayılır, bu nedenle 100 çağrılık bir toplu işlem günlük kotanızın 100 isteğini kullanır. Google’ın API istemci kitaplıkları (Java, Python, JavaScript, PHP, .NET) toplu işlem biçimlendirmesini sizin için halleder; elle yapmak nadiren buna değer.

Indexing API vs Request Indexing vs IndexNow

Karar çerçevesi: neye sahip olduğunuzu ve hangi motoru önemsediğinizi belirleyin, ardından kanalı seçin.

Nasıl seçilir

1. İş ilanlarınız veya canlı yayınlarınız var ve otomatikleştirmek mi istiyorsunuz? → Indexing API.
2. Genel sayfaları Bing/Yandex/Yep’e göndermek mi istiyorsunuz? → IndexNow.
3. Google’ın normal bir sayfayı bir kez yeniden taramasını mı istiyorsunuz? → GSC “Request indexing.”
4. Google’da genel sayfaları ölçekte dizine ekletmek mi istiyorsunuz? → Tek bir düğme yok. Site haritaları + iç bağlantılar + kalite. (Ve sabır — tarama sıklığına bakın.)

Zihinsel model: Indexing API, bir API olduğu için üçünün en güçlüsü gibi görünür, ancak içerik türüne göre en dar olanıdır. Güç ve kapsam aynı şey değildir.

Araçlar

• Google Cloud Console — projeyi oluşturun, Indexing API’yi etkinleştirin ve kimlik doğrulaması yapacağınız hizmet hesabı JSON anahtarını oluşturun.
• Google Search Console — URL Inspection — normal sayfalar için gerçek aracınız budur: bir URL’nin nasıl tarandığını/işlendiğini/dizine eklendiğini kontrol edin ve ara sıra tek seferlik işlemler için “Request indexing” kullanın.
• Google Search Console — Sitemaps & Coverage — site haritaları gönderin ve neyin dizine eklendiğini, “Discovered – currently not indexed” veya hariç tutulduğunu görün.
• Google API client libraries — Indexing API çağrıları için OAuth belirteç değişimini halletmenin en temiz yolu (JWT imzalamayı elle yapmak yerine).
• IndexNow integration (Ahrefs Site Audit, vb.) — çapraz motor gönderim kanalı için (Bing ve diğerleri, Google değil). İnsanların Indexing API’nin genel sayfalar için vermesini dilediği programatik gönderim davranışını istediğinizde doğru araç.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• What Is Googlebot & How Does It Work? — Indexing API’nin Google’ın URL keşif kaynakları (bağlantılar, site haritaları, RSS, GSC ve API) arasındaki yeri.
• How to Fix “Discovered – currently not indexed” — gerçek “sayfalarım neden dizine eklenmiyor” sayfası; çözüm kalite ve iç bağlantılardır, bir gönderim API’si değil.
• The Beginner’s Guide to Technical SEO — tarama ve dizine eklemenin büyük resimdeki yeri.

Konuşmalarım

• How Search Works (SlideShare) — keşif, tarama, işleme, dizine ekleme ve sıralama konusundaki anlatımım; URL keşif slaytı Indexing API’yi “sınırlı kullanım durumları” olarak etiketler. (Her zamanki feragatnamem geçerlidir: “Bu, sistemlere dair benim anlayışımdır… %100 eksiksiz veya doğru olmayacak.”)

IndexNow hakkında (çapraz motor kardeşi — Google’ın bunu kullanmadığını unutmayın)

• Ahrefs Site Audit’te IndexNow entegrasyonu — Google yerine Bing/Yandex/Yep için gerçekten onayladığım push kanalı.
• Site Audit içinde IndexNow’a sayfa gönderme.

Diğerlerinden

• Google, Indexing API Dokümantasyonuna Spam Uyarısı Ekledi (Search Engine Journal, Eylül 2024) — spam algılama dilinin ne zaman eklendiğini belgeler.
• Google, Indexing API’yi Desteklenmeyen İçerik İçin Kullanmayı Bırakın Diyor (Search Engine Roundtable, Mayıs 2025) — Barry Schwartz, Mueller’ın API’yi kötüye kullanmayı bırakma konusundaki Bluesky uyarısını ele alıyor.
• Indexing API’nin Kötüye Kullanımı SEO Sorunlarına Yol Açabilir (StanVentures, Mayıs 2025) — Mueller’ın Mayıs 2025 Bluesky alıntılarını aynen yeniden üretir ve erişim iptali riskini açıklar.
• Google, Indexing API’yi Normal Bir Web Sitesi İçin Kullanmanın İyi mi Kötü mü Olduğunu Yanıtlıyor (iLoveSEO, Mayıs 2022) — Mueller’ın “inşaat araçları” ofis saatleri çerçevesinin dökümü.
• Google, Indexing API’sinin Blogcular Tarafından İstila Edildiğini Söylüyor (Optimixed) — blogcuların ve SEO’ların etiket dışı kullanımının API’yi nasıl boğduğunu ele alıyor.
• r/TechSEO — tarama/dizin hata ayıklama topluluğu.

Yaygın sorunlar

İnsanların Indexing API ile gerçekten karşılaştığı sorunlar, belirti → neden → çözüm sırasıyla.

”200 yanıtı aldım ama sayfa hâlâ dizine eklenmedi”

• Belirti: URL_UPDATED çağrısı (veya durum GET isteği) başarılı döner, ancak sayfa aramada hiç görünmez veya Search Console hâlâ “Keşfedildi – şu anda dizine eklenmedi” diyor.
• Neden: Bir 200 yalnızca Google’ın bildirimi aldığını doğrular. Google’ın kendi belgelerine göre, durum uç noktası “yalnızca bir isteği başarıyla gönderip göndermediğinizi döndürür” — size bir şeyin tarandığını, dizine eklendiğini veya kaldırıldığını söylemez.
• Çözüm: API yanıtını bir dizine ekleme onayı olarak görmeyi bırakın. Gerçek dizine ekleme durumunu Search Console’daki URL İnceleme aracında veya Kapsam raporunda kontrol edin. Sayfa makul bir bekleme süresinden sonra hâlâ dizine eklenmediyse, sorun keşif/kalite ile ilgilidir (Gelişmiş sekmesindeki “Bunun yerine ne yapmalı” bölümüne bakın), API çağrısıyla değil.

”Indexing API erişimim iptal edildi”

• Belirti: Önceden çalışan çağrılar başarısız olmaya başlar veya Google Cloud/Search Console, hizmet hesabının erişiminin kaldırıldığını gösterir.
• Neden: Google açıkça şunu belirtir: “Indexing API’yi kötüye kullanma girişimleri, birden fazla hesap kullanımı veya kullanım kotalarını aşmanın diğer yolları dahil, erişimin iptal edilmesine neden olabilir.” En yaygın tetikleyici, JobPosting/BroadcastEvent olmayan sayfaları göndermek veya ~200/gün varsayılan kotayı aşmak için ek hizmet hesapları oluşturmaktır.
• Çözüm: Ne gönderdiğinizi denetleyin — genel içerikse (blog gönderileri, ürün sayfaları, JobPosting veya BroadcastEvent yapılandırılmış verisi olmayan herhangi bir şey), durun. API’nin bunu desteklediği belgelenmemiştir ve Mueller doğrudan şunu söylemiştir: “Onu düzgün kullanırdım ya da hiç kullanmazdım.” Desteklenen kullanım durumunun içinde kalmaktan başka belgelenmiş bir itiraz yolu yoktur.

”Normal sayfalar için gönderimler hiçbir şey yapmıyor gibi görünüyor”

• Belirti: Normal bir makale veya ürün sayfası için URL_UPDATED gönderiyorsunuz ve hiçbir şey değişmiyor — ne daha hızlı tarama, ne daha hızlı dizine ekleme.
• Neden: İçerik türü, Google’ın desteklediği iki türden biri değil. Indexing API “yalnızca JobPosting veya BroadcastEvent içine gömülü VideoObject içeren sayfaları taramak için kullanılabilir.” Bu kapsam dışındaki gönderimler belgelenmiş, desteklenen bir sinyal değildir.
• Çözüm: Bu düzeltilecek bir hata değil — yanlış araç. Genel sayfalar için site haritası, iç bağlantılar ve (ara sıra tek seferlikler için) Search Console’un URL İnceleme aracındaki “Dizine ekleme iste” özelliğini kullanın.

”Kota sınırına ulaşıyorum”

• Belirti: Gönderimler başarısız olmaya veya kısıtlanmaya başlıyor — ya günde yaklaşık 200 civarında, ya da günde 200’ün altında bile olsa daha kısa patlamalar halinde.
• Neden: Google aslında üç ayrı varsayılan kota uygular: günlük 200 yayın (URL_UPDATED/URL_DELETED) isteği, dakikada 180 durum (getMetadata) isteği ve tüm uç noktalarda birleşik dakikada 380 istek. Bir dizi durum kontrolü, günlük 200 sınırına ulaşmadan çok önce dakikalık limitlerde kısıtlanmanıza neden olabilir. Bunların herhangi birini aşmak “kullanım ve kaynak sağlama için ek onay gerektirir” ve Google, verilen kotanın “belge kalitesine bağlı olarak artabileceğini veya azalabileceğini” belirtir.
• Çözüm: Meşru olarak günde bu kadar çok JobPosting veya BroadcastEvent sayfası yayınlıyorsanız/güncelliyorsanız, Google Cloud üzerinden kota artışı talep edin — bunu aşmak için ekstra hizmet hesapları veya projeler oluşturmayın, çünkü bu, erişimin iptal edilmesine neden olan kötüye kullanım türü olarak açıkça belirtilmiştir.

Kontrol Listeleri

Indexing API’ye dokunmadan önce

• Göndermek istediğiniz sayfaların gerçekten JobPosting yapılandırılmış verisi veya BroadcastEvent içine gömülü VideoObject taşıdığını doğrulayın — Google’ın desteklediği tek iki içerik türü.
• Hiçbiri geçerli değilse, burada durun. API yerine site haritaları, iç bağlantılar, içerik kalitesi ve ara sıra GSC “Dizine ekleme iste” özelliğini kullanın.
• Gönderim hacminizin varsayılan ~200/gün kotasına gerçekçi bir şekilde sığıp sığmayacağına veya bir artış talep etmeniz gerekip gerekmeyeceğine karar verin.

Kurulum

• Bir Google Cloud projesi oluşturun (veya seçin) ve içinde Indexing API’yi etkinleştirin.
• Bir hizmet hesabı oluşturun ve JSON anahtar dosyasını indirin; güvenli bir şekilde saklayın (asla herkese açık bir depoya işlemeyin).
• Zaten değilse sitenizi Search Console’da doğrulayın.
• Hizmet hesabının e-postasını Search Console’da yetkili site sahibi olarak ekleyin.
• Hizmet hesabı anahtarını https://www.googleapis.com/auth/indexing kapsamıyla bir OAuth belirteci ile değiştirebildiğinizi doğrulayın (genellikle elle yazılmış JWT imzalama yerine bir Google API istemci kitaplığı aracılığıyla).

Bildirim gönderme

• Doğru yöntemi seçin: yeni veya değiştirilmiş desteklenen bir sayfa için URL_UPDATED, sayfa kaldırıldıktan veya URL_DELETEDlendikten sonra noindex.
• URL’yi doğru type alanıyla birlikte https://indexing.googleapis.com/v3/urlNotifications:publish adresine POST edin.
• Bir 200 yanıtını yalnızca alındı onayı olarak kabul edin — sayfanın dizine eklendiğinin veya kaldırıldığının kanıtı değil.
• Gerçek dizine ekleme durumunu doğrulamanız gerekiyorsa Search Console’da (URL İnceleme veya Kapsam) takip edin.

Yönergeler içinde kalmak

• Bu API aracılığıyla yalnızca JobPosting/BroadcastEvent sayfaları gönderin — başka hiçbir şey.
• Kotayı aşmak için yalnızca birden fazla hizmet hesabı veya proje oluşturmayın; bunun yerine meşru bir artış talep edin.
• Bir sayfanın uygun olup olmadığından emin değilseniz, bunu “uygun değil” olarak kabul edin ve bunun için site haritaları/iç bağlantılar/Dizine ekleme iste özelliğini kullanın.

Test

Indexing API hakkında gerçekte neyin akılda kaldığını kontrol etmek için beş soru.

Değişiklik günlüğü