Teknik SEO Promptları: ChatGPT ile Robots.txt, Yönlendirme, Schema ve Hız Analizi

Teknik SEO promptları, ChatGPT'yi robots.txt incelemesinden yönlendirme haritasına kadar tekrar eden teknik işlerde hızlı bir yardımcıya dönüştürür. Ancak model sitenizi taramaz; ona verdiğiniz dosya ve çıktıyı yorumlar. Bu yazıda müşteri projelerinde kullandığım, kopyalayıp uyarlayabileceğiniz istem şablonlarını ve her birinin sonucunu nasıl doğruladığımı paylaşıyorum.

Teknik SEO promptları nedir?

Teknik SEO promptları, ChatGPT gibi bir dil modeline tarama, dizine ekleme, yönlendirme, yapısal veri ve hız sorunlarını analiz ettirmek için yazdığınız yapılandırılmış talimatlardır. İyi bir istem rolü, girdiyi, kuralları ve çıktı biçimini tanımlar. Sonuç her zaman resmi araçlarla doğrulanır.

Buradaki kritik nokta girdi. Model sitenize bağlanıp sayfaları gezmez; web araması açık olsa bile tam bir tarama yapmaz. Dolayısıyla ona robots.txt dosyanızı, bir Lighthouse raporunu, bir tarama aracının CSV çıktısını ya da sunucu günlüğünden bir kesit verirsiniz. Model bu veriyi okur, desenleri bulur ve size düzeltme önerir.

Genel teknik SEO kavramlarını teknik SEO nedir yazısında anlattım. Bu yazı ise doğrudan uygulamaya odaklanıyor: hangi işte hangi istemi yazarsınız ve çıktıya ne zaman güvenirsiniz.

Şablonlardaki köşeli ayrıntıları kendi sitenize göre değiştirin. Örneğin sektörünüzü, CMS adınızı ve sunucu türünüzü istemin başına eklediğinizde model daha isabetli öneriler verir. WordPress, Shopify veya özel yazılım gibi bilgiler, önerilen çözümün uygulanabilir olup olmadığını doğrudan etkiler.

ChatGPT teknik SEO'da neyi yapabilir, neyi yapamaz?

Modelin güçlü olduğu alanlar metin ve desen işleridir. Örneğin uzun bir URL listesini gruplar, düzenli ifade yazar, JSON-LD taslağı çıkarır, .htaccess kuralını açıklar ve hata mesajlarını sade dile çevirir.

Zayıf olduğu alanlar ise canlı veri gerektiren işlerdir. Sayfanın gerçekten dizinde olup olmadığını, Googlebot'un sayfayı nasıl işlediğini ya da gerçek kullanıcı hız verisini bilemez. Bu bilgiler Search Console, PageSpeed Insights ve sunucu günlüklerinde durur.

Kısacası doğru iş bölümü şöyle: veriyi resmi araçlar ve tarama yazılımları toplar, model bu veriyi düzenler ve yorumlar, son kararı ise siz verirsiniz. Aşağıdaki tablo, bu yazıdaki her istem için bu iş bölümünü özetliyor.

İyi bir teknik SEO promptu nasıl kurulur?

Her şablonda aynı dört parçayı kullanıyorum, çünkü bu yapı modelin tahmin yürütme alanını daraltır.

Girdinin boyutuna da dikkat edin. Çok büyük dosyalarda model sona doğru ayrıntıları kaçırabiliyor. Bu nedenle ben tarama çıktılarını önce filtreliyor, yalnızca incelemek istediğim sütunları ve sorunlu satırları gönderiyorum. Örneğin tüm siteyi değil, yalnızca 3xx ve 4xx dönen satırları veriyorum.

1. Rol: "Sen deneyimli bir teknik SEO uzmanısın" gibi bir çerçeve.
2. Girdi: dosyanın ya da verinin kendisi, açıkça sınırlanmış şekilde.
3. Kurallar: "yalnızca verilen veriye dayan", "emin değilsen KONTROL yaz", "Google'ın resmi belgelerine aykırı öneri verme".
4. Çıktı biçimi: tablo, madde listesi ya da doğrudan kopyalanabilir kod bloğu.

Ayrıca modelden her önerinin yanına bir risk seviyesi yazmasını isteyin. Böylece "bu kural tüm siteyi taramaya kapatabilir" gibi uyarılar gözünüzden kaçmaz. İstem yazımının genel teknikleri ayrı bir konu; burada yalnızca teknik SEO'ya özgü kalıplara odaklanıyorum.

robots.txt incelemesi için hangi promptu kullanmalısınız?

robots.txt dosyası küçük ama tek bir hatalı satır tüm siteyi taramaya kapatabilir. Benim şablonum şöyle:

İstem: "Aşağıdaki robots.txt dosyasını incele. Her User-agent grubu için hangi yolların engellendiğini tablo halinde yaz. CSS, JavaScript veya görsel dosyalarını engelleyen kuralları işaretle. Birbiriyle çakışan Allow ve Disallow satırlarını göster. Sitemap satırı eksikse belirt. Her bulgu için risk seviyesi ver."

Çıktıyı okurken bir kuralı hatırlayın: robots.txt taramayı kontrol eder, dizine eklemeyi değil. Google'ın robots.txt belgesi engellenen bir sayfanın başka sitelerden bağlantı alırsa yine de dizine girebileceğini açıkça belirtiyor. Model bazen robots.txt'yi dizinden çıkarma aracı gibi önerir; bu öneriyi reddedin.

Yeni bir dosya hazırlayacaksanız robots.txt oluşturucu ile temel iskeleti çıkarıp modele yalnızca özel kuralları kontrol ettirebilirsiniz.

Yapay zekâ botları için robots.txt kurallarını nasıl yazdırırsınız?

Son yıllarda en çok sorulan teknik konulardan biri bu. Modelden ilgili kuralları yazmasını isteyebilirsiniz, ancak bot adlarını mutlaka resmi kaynaktan kontrol edin, çünkü model eski ya da yanlış adlar üretebiliyor.

Resmi belgelere göre OpenAI eğitim için GPTBot, ChatGPT arama özellikleri için OAI-SearchBot kullanıyor. Anthropic tarafında ClaudeBot, Perplexity tarafında PerplexityBot var. Google-Extended ise ayrı bir tarayıcı değil; Google'ın Gemini modellerinin eğitimi ve temellendirmesi için içeriğinizin kullanımını kontrol eden bir belirteç. Bu belirteci engellemek Google Arama'daki sıralamanızı etkilemez.

İstem: "GPTBot ve Google-Extended için tüm siteyi kapatan, OAI-SearchBot için ise yalnızca /blog/ klasörünü açan robots.txt grupları yaz. Mevcut dosyamdaki diğer kuralları koru. Değişen satırları ayrıca listele."

Bu kararın stratejik boyutunu yapay zekâ sonrası teknik SEO yazısında tartıştım. Ayrıca yapay zekâ sistemlerine sitenizi özetlemek için llms.txt oluşturucu aracına bakabilirsiniz.

Yönlendirme haritası için teknik SEO promptları nasıl olmalı?

Site taşımalarında en çok zaman alan iş eski ve yeni URL'leri eşlemektir. ChatGPT burada gerçekten hız kazandırır, çünkü iki listeyi başlık ve yol benzerliğine göre eşleyebilir.

İstem: "A sütununda eski URL'ler ve sayfa başlıkları, B sütununda yeni URL'ler ve başlıklar var. Her eski URL için en uygun yeni URL'yi seç. Emin olmadığın eşleşmelere KONTROL yaz. Karşılığı olmayan sayfaları ayrı listele. Sonucu üç sütunlu tablo olarak ver: eski, yeni, güven düzeyi."

Ardından ikinci bir istemle kuralları yazdırırsınız: "Bu tabloyu Apache .htaccess için 301 kurallarına çevir. Zincir oluşturacak kural varsa uyar." Nginx kullanıyorsanız aynı istemi Nginx sözdizimi için yazın.

Doğrulama şart. Kuralları önce test ortamında deneyin, sonra yönlendirme denetleyici ile örnek URL'lerin tek adımda doğru hedefe gittiğini kontrol edin. Taşımanın tamamı için site taşıma kontrol listesi yazısına bakabilirsiniz.

Düzenli ifade (regex) yazdırmak için hangi istemi kullanmalısınız?

Search Console filtrelerinde, Google Analytics segmentlerinde ve yönlendirme kurallarında düzenli ifade gerekir. Çoğu kişi bu sözdizimini ezbere bilmez; model ise genelde doğru bir taslak üretir.

İstem: "Search Console performans raporunda kullanılacak bir düzenli ifade yaz. Soru kalıbıyla başlayan sorguları yakalasın: nasıl, nedir, neden, ne kadar, hangi. Search Console'un RE2 sözdizimini kullandığını dikkate al. İfadeyi ve yakalayacağı üç örnek, yakalamayacağı üç örnek sorguyu ver."

Son cümle önemli. Modelden pozitif ve negatif örnek istemek, ifadenin mantığını sizin test etmenizi kolaylaştırır. RE2 bazı gelişmiş özellikleri, örneğin geriye bakan eşleşmeleri desteklemez; bu yüzden sözdizimini baştan belirtmek hatayı önler.

Yazdığınız ifadeyi rapora uygulamadan önce birkaç gerçek sorguyla deneyin. Beklenmedik bir sonuç görürseniz modele o sorguyu verip ifadeyi düzeltmesini isteyin.

Schema işaretlemesi için teknik SEO promptları nasıl yazılmalı?

JSON-LD üretmek modelin en iyi yaptığı işlerden biri. Ancak burada da uydurma risk var: model sayfada olmayan puanları, fiyatları ya da yorumları işaretlemeye ekleyebilir. Bu, Google'ın yapısal veri yönergelerine aykırıdır.

İstem: "Aşağıdaki sayfa içeriği için schema.org JSON-LD üret. Yalnızca metinde açıkça geçen bilgileri kullan. Metinde olmayan alanları boş bırak ve ayrıca listele. Google'ın bu tür için zorunlu ve önerilen özelliklerini ayrı ayrı belirt. Sayfa türü: yerel işletme hizmet sayfası."

Çıktıyı Google'ın Zengin Sonuçlar Testi ile doğrulayın. Test hata vermese bile işaretlemenin sayfada görünen içerikle birebir örtüştüğünü kendiniz kontrol edin.

Hızlı başlangıç için schema oluşturucu aracını kullanabilirsiniz. Yapısal verinin mantığını ise schema markup nedir yazısında ayrıntılı anlattım.

hreflang hatalarını ChatGPT ile nasıl bulursunuz?

Çok dilli sitelerde en sık gördüğüm sorun eksik geri dönüş bağlantılarıdır. A sayfası B'yi gösteriyor ama B, A'yı göstermiyor. Google bu durumda etiketi yok sayabilir.

İstem: "Aşağıdaki tabloda her satır bir sayfa ve o sayfanın hreflang etiketleri. Her çiftin karşılıklı olup olmadığını kontrol et. Geçersiz dil veya bölge kodlarını işaretle. x-default eksik olan grupları listele. Sayfanın kendisine işaret eden hreflang satırı yoksa belirt."

Girdiyi bir tarama aracından CSV olarak çıkarırsınız. Model bu tabloyu okuyup eksikleri bulur. Kuralların kaynağı Google'ın yerelleştirilmiş sürümler belgesi; tartışmalı bir öneri gelirse oradan kontrol edin.

Etiketleri yeniden üretmeniz gerekirse hreflang oluşturucu işinizi hızlandırır. Konunun temeli için hreflang etiketi nedir yazısına göz atabilirsiniz.

Canonical ve yinelenen içerik denetimini nasıl yaptırırsınız?

Tarama aracınızdan URL, başlık, canonical ve durum kodu sütunlarını dışa aktarın. Bu tablo modele verebileceğiniz en verimli girdilerden biri.

İstem: "Bu tabloda canonical etiketi kendisinden farklı bir URL'yi gösteren sayfaları listele. Canonical hedefi 404, 301 veya noindex olan satırları işaretle. Aynı başlığa sahip birden fazla URL varsa grupla. Parametreli URL'lerin canonical durumunu ayrıca özetle."

Model bu tür çapraz kontrolleri hızlı yapar. Ancak canonical bir öneridir, direktif değildir; Google farklı bir URL'yi kanonik seçebilir. Bu nedenle modelin bulgularını Search Console'daki URL Denetleme aracında Google'ın seçtiği kanonik URL ile karşılaştırın.

Yinelenen başlık grupları çoğu zaman içerik yapısıyla ilgili daha derin bir soruna işaret eder. Böyle bir durumda sorunu tek tek sayfalarda değil, şablon düzeyinde çözmek gerekir.

Sitemap kontrolü için hangi prompt işe yarar?

XML sitemap'in amacı Google'a önemli ve dizine eklenebilir URL'leri göstermektir. Ancak birçok sitede sitemap yönlendirilen, noindex veya 404 dönen adreslerle dolu.

İstem: "Aşağıda sitemap'teki URL'ler ve tarama aracının bu URL'ler için döndürdüğü durum kodu, indexlenebilirlik ve canonical bilgisi var. Sitemap'te olmaması gereken URL'leri nedenleriyle listele. Sitemap'te olmayan ama indexlenebilir 200 dönen sayfaları ayrıca göster."

Bu karşılaştırma, sitemap ile gerçek site yapısı arasındaki farkı ortaya çıkarır. Temiz bir dosya üretmek için XML sitemap oluşturucu aracını kullanabilirsiniz.

Düzeltmeden sonra dosyayı Search Console'daki Site haritaları raporundan yeniden gönderin ve birkaç gün sonra keşfedilen sayfa sayısını kontrol edin.

Core Web Vitals teşhisinde ChatGPT nasıl yardımcı olur?

Lighthouse raporları uzun ve teknik. Model bu raporu okuyup önceliklendirmede gerçekten işe yarar. Ancak Lighthouse laboratuvar verisidir; Google'ın sıralamada kullandığı sinyaller gerçek kullanıcı verisine dayanır.

İstem: "Aşağıdaki Lighthouse JSON çıktısında LCP, CLS ve INP ile ilişkili denetimleri bul. Her sorun için olası kök nedeni, etkilediği metriği ve tahmini uygulama zorluğunu yaz. Sonucu en yüksek etki ve en düşük zorluk sırasına göre tablo halinde ver."

INP, Mart 2024'te FID'nin yerini alan etkileşim metriğidir; web.dev INP belgesi iyi eşiği 200 milisaniye ve altı olarak veriyor. Model eski yazılardan FID önerileri getirirse bu farkı hatırlatın.

Düzeltmelerin etkisini PageSpeed Insights'taki saha verisinden izleyin. Hızın sıralamaya etkisini site hızı SEO'yu nasıl etkiler yazısında ele aldım.

Sunucu günlüklerini (log) nasıl analiz ettirirsiniz?

Günlük analizi, Googlebot'un sitenizde gerçekte neyi taradığını gösteren tek kaynaktır. Dosyalar büyük olduğu için modele ham günlüğü değil, özetlenmiş bir kesiti verin.

İstem: "Aşağıda son yedi günün erişim günlüğünden Googlebot kullanıcı aracısına sahip satırlar var. En çok taranan dizinleri, 4xx ve 5xx dönen URL'leri, parametreli URL'lere harcanan istek oranını ve sitemap'te olup hiç taranmayan önemli sayfaları özetle."

Burada bir tuzak var: kullanıcı aracısı kolayca taklit edilir. Google, Googlebot'u doğrulamak için ters DNS sorgusu ya da yayımladığı IP aralıklarıyla karşılaştırma öneriyor. Bu nedenle modelin özetine geçmeden önce satırları doğrulayın ya da en azından doğrulanmamış veri olduğunu not edin.

Günlük dosyalarında IP adresleri kişisel veri sayılabilir. Modele göndermeden önce IP sütununu maskeleyin veya kaldırın.

JavaScript ve işleme (rendering) sorunlarında hangi istemi yazmalısınız?

JavaScript ağırlıklı sitelerde en önemli soru şu: Google'ın gördüğü HTML ile kullanıcının gördüğü sayfa aynı mı? Model bunu kendisi test edemez, ama iki çıktıyı karşılaştırabilir.

İstem: "Aşağıda aynı sayfanın ham HTML kaynağı ve işlenmiş HTML çıktısı var. Başlık, meta açıklama, canonical, H1, iç bağlantılar ve ana içerik metni açısından iki sürüm arasındaki farkları listele. Yalnızca işlenmiş sürümde görünen kritik öğeleri işaretle."

İşlenmiş HTML'i Search Console'daki URL Denetleme aracının canlı test sonucundan alabilirsiniz. Kritik içerik yalnızca JavaScript ile geliyorsa, sunucu tarafında işleme ya da önceden işleme seçeneklerini ekibinizle değerlendirin.

Bu karşılaştırma özellikle yeni bir çerçeveye geçiş yapan sitelerde sürprizleri önler. Örneğin bir React ya da Vue geçişinde iç bağlantıların yalnızca tıklama olayıyla çalıştığını, gerçek bağlantı etiketi taşımadığını bu testte yakalayabilirsiniz. Google yalnızca href özniteliği olan bağlantıları güvenilir biçimde takip eder. Ben her büyük sürüm öncesi birkaç şablon sayfada bu testi tekrarlıyorum.

Meta etiket ve başlık denetimi için hangi istem uygundur?

Yüzlerce sayfalık bir sitede eksik, çok uzun ya da tekrar eden başlıkları elle bulmak zahmetlidir. Tarama tablosunu modele verip toplu yeniden yazım da isteyebilirsiniz.

İstem: "Bu tabloda URL, title ve meta description var. 60 karakteri aşan başlıkları, boş açıklamaları ve birebir aynı başlıkları listele. Sorunlu satırlar için sayfanın konusunu koruyan yeni öneriler yaz. Marka adını başlık sonuna ekleme."

Öneriler başlangıç noktasıdır. Özellikle ürün sayfalarında modelin genel ifadelere kaçmasını engellemek için her satıra sayfanın ana anahtar kelimesini ayrı sütun olarak ekleyin.

Ayrıca modelden her öneri için karakter sayısını da yazmasını isteyin. Dil modelleri karakter saymakta bazen yanılıyor; bu yüzden sayıyı yine de bir araçla kontrol edin. Yeni başlıkları canlıya almadan önce Search Console'da o sayfanın mevcut tıklama oranını not edin ki değişikliğin etkisini ölçebilesiniz.

Uzunluk ve görünüm kontrolü için meta tag oluşturucu ve Google SERP önizleme araçlarını kullanabilirsiniz.

Kırık bağlantı ve iç link sorunlarını nasıl önceliklendirirsiniz?

Tarama araçları genelde yüzlerce kırık bağlantı listeler. Hepsini aynı anda düzeltmek mümkün değil; önceliklendirme gerekir.

İstem: "Bu tabloda kaynak sayfa, kırık hedef URL ve bağlantı metni var. Kırık hedefleri grupla. Her grup için kaç sayfadan bağlantı aldığını yaz. Hedefin yerine geçebilecek canlı URL'yi aşağıdaki canlı URL listesinden öner; uygun yoksa 'kaldır' yaz."

Bu istem, en çok iç bağlantı alan kırık hedefi en üste taşır. Böylece tek bir yönlendirmeyle onlarca bağlantıyı aynı anda onarırsınız.

Düzenli kontrol için kırık link kontrolü aracını kullanabilirsiniz. Genel bir sağlık görünümü için ise SEO analiz aracı hızlı bir başlangıç sunar.

Search Console dizin raporunu nasıl yorumlatırsınız?

Search Console'daki Sayfa dizine ekleme raporu, sayfaların neden dizinde olmadığını gruplar halinde gösterir. "Tarandı, şu anda dizine eklenmemiş" ya da "Alternatif sayfa, uygun kanonik etiketi var" gibi durumlar birçok site sahibinin kafasını karıştırıyor.

Bu raporun örnek URL listesini dışa aktarıp modele verebilirsiniz. İstem: "Aşağıda Search Console'un 'Tarandı, şu anda dizine eklenmemiş' grubundaki URL'ler var. Bu URL'leri yol yapısına göre grupla. Her grup için olası nedenleri sırala: ince içerik, yinelenen şablon, parametre, sayfalama. Hangi grubun önce incelenmesi gerektiğini gerekçesiyle yaz."

Model burada kesin teşhis koymaz, ama yüzlerce URL'yi anlamlı kümelere ayırır. Örneğin sorunların çoğunun etiket sayfalarından ya da filtre parametrelerinden geldiğini hızla görürsünüz. Ardından her kümeden birkaç örneği URL Denetleme aracıyla tek tek incelersiniz.

Durum adlarının anlamını modelden değil, Google'ın yardım sayfasından okuyun. Rapor adları zaman zaman güncelleniyor ve model eski adları kullanabiliyor.

Parametreli URL'ler ve tarama bütçesi için hangi prompt işe yarar?

E-ticaret sitelerinde filtre, sıralama ve oturum parametreleri binlerce URL varyasyonu üretir. Büyük sitelerde bu durum Googlebot'un önemli sayfalara ayırdığı zamanı azaltabilir.

İstem: "Aşağıda tarama aracından alınmış parametreli URL listesi var. Her parametreyi adıyla listele, kaç URL'de geçtiğini say ve işlevini tahmin et: filtre, sıralama, sayfalama, izleme veya oturum. Her parametre için önerilen yaklaşımı yaz: canonical, noindex, robots.txt engeli veya dokunma. Emin olmadığın satırlara KONTROL yaz."

Bu çıktı, geliştirici ekibiyle yapacağınız toplantı için iyi bir taslak olur. Ancak parametre engellemek geri dönüşü zor bir karardır. Örneğin arama talebi olan bir filtre sayfasını yanlışlıkla kapatırsanız trafik kaybedersiniz.

Google, tarama bütçesinin çoğunlukla çok büyük veya sık güncellenen siteler için önemli olduğunu belirtiyor. Birkaç yüz sayfalık bir sitedeyseniz bu analize öncelik vermeyin.

İstem kütüphanenizi nasıl düzenlemelisiniz?

Bu yazıdaki şablonları bir kez kullanıp unutmak yerine bir kütüphaneye dönüştürmenizi öneririm. Ben istemleri basit bir tabloda tutuyorum:

• İstem adı ve kullanım amacı
• Gerekli girdi ve biçimi (CSV, JSON, düz metin)
• İstem metni ve sürüm numarası
• Doğrulama aracı ve kontrol adımı
• Son güncelleme tarihi ve bilinen zayıf noktalar

Sürüm numarası küçük ama önemli bir ayrıntı. Bir istemi değiştirdiğinizde eski sonuçlarla yenileri karşılaştırabilirsiniz. Ayrıca Google bir kuralı güncellediğinde hangi istemlerin etkilendiğini hızla bulursunuz; örneğin FID'den INP'ye geçişte tüm hız istemlerini tek seferde güncellemek gerekmişti.

Kütüphaneyi ekip arkadaşlarınızla paylaşın. Böylece herkes aynı kurallarla çalışır ve sonuçlar kişiden kişiye değişmez.

Teknik SEO promptları kullanırken hangi hatalardan kaçınmalısınız?

Ekibimle yaptığımız denetimlerde yapay zekâdan gelen önerilerde tekrar eden hatalar görüyoruz:

• robots.txt ile dizinden çıkarma önerisi; doğru yol noindex etiketidir ve sayfa taramaya açık kalmalıdır.
• Sayfada görünmeyen puan veya yorumları schema'ya eklemek.
• Eski FID metriğine göre hız tavsiyesi vermek.
• Var olmayan bot adları ya da eski ürün adları kullanmak.
• Yönlendirme zincirlerini fark etmeden yeni kural eklemek.
• Googlebot kullanıcı aracısını doğrulamadan günlük verisine güvenmek.

Bu hataların ortak noktası şu: model makul görünen ama güncel resmi kurala aykırı bir cevap üretiyor. Bu yüzden istemlerime "Google Search Central belgelerine aykırı öneri verme; emin değilsen belirt" cümlesini standart olarak ekliyorum.

Çıktıları doğrulamak için hangi süreci izlemelisiniz?

Teknik değişiklikler geri dönüşü pahalı işlerdir. Hatalı bir robots.txt ya da yanlış bir yönlendirme kuralı haftalarca trafik kaybettirebilir. Bu nedenle model çıktısını asla doğrudan canlıya almıyorum. Aşağıdaki dört adımı her değişiklikte uyguluyorum.

1. Öneriyi resmi belgeyle karşılaştırın.
2. Test ortamında uygulayın.
3. İlgili Google aracıyla doğrulayın: Zengin Sonuçlar Testi, URL Denetleme, robots.txt raporu.
4. Canlıya aldıktan sonra Search Console'da ilgili raporu birkaç hafta izleyin.

Ayrıca istemleri ve modelin verdiği cevabı bir değişiklik günlüğüne kaydedin. Bir sorun çıktığında hangi değişikliğin nereden geldiğini hızla bulursunuz.

Hangi verileri ChatGPT ile paylaşmamalısınız?

Teknik SEO verileri sanıldığından daha hassas olabilir. Sunucu günlükleri IP adresi içerir, yapılandırma dosyaları iç sunucu yollarını ve bazen parolaları barındırır.

Şu kurala uyuyorum: modele yalnızca herkese açık olan ya da anonimleştirdiğim veriyi veririm. robots.txt ve sitemap zaten herkese açık. Günlüklerde ise IP'yi maskeler, .htaccess dosyalarında gizli değerleri temizlerim.

Kurumsal hesaplarda veri kullanım ayarlarını kontrol edin. Hassas projelerde API ya da kurumsal sürümler, varsayılan olarak eğitimde kullanılmama gibi ek güvenceler sunar. Ancak her durumda en güvenli veri, hiç göndermediğiniz veridir.

Teknik SEO promptları kimin işini kolaylaştırır?

En büyük kazancı, teknik SEO'yu bilen ama tekrar eden işlere çok zaman harcayan uzmanlar elde eder. Model onların yerine karar vermez; veriyi hızla düzenler ve ilk taslağı çıkarır.

Yeni başlayanlar için de faydalı, ama bir şartla: modelin açıklamalarını öğrenme aracı olarak kullanıp her öneriyi resmi belgelerle kontrol etmek. Aksi halde yanlış bir bilgiyi doğru sanarak siteye uygulama riski doğar.

Geliştiriciler açısından da istemler ortak bir dil sağlar. SEO ekibi sorunu istemle tanımlar, model kodu taslak olarak yazar, geliştirici inceleyip uygular. Böylece iki ekip arasındaki gidip gelmeler azalır.

Ajanslar ve danışmanlar için de ayrı bir fayda var: müşteriye teslim edilen raporlar daha hızlı hazırlanır. Ancak rapordaki her bulgunun arkasında doğrulanmış bir veri olmalı. Modelin cümlelerini olduğu gibi rapora koymak, özellikle yanlış bir teknik iddia içeriyorsa güveninizi zedeler.

Bu işleri ne zaman profesyonel desteğe bırakmalısınız?

Site taşıma, alan adı değişikliği, çok dilli yapıya geçiş ya da büyük bir tarama bütçesi sorunu gibi projelerde hata payı küçüktür. Bu tür işlerde istemler hızlandırıcıdır, ama sürecin sahibi deneyimli biri olmalıdır.

Ekibimle SEO danışmanlığı kapsamında bu istem şablonlarını kendi doğrulama adımlarımızla birlikte kullanıyoruz. Teknik altyapıyı baştan kurmanız gerekiyorsa web tasarım sürecinde SEO gereksinimlerini en başta planlıyoruz.

Kendiniz ilerlemek istiyorsanız tek bir işle başlayın. Örneğin bu hafta yalnızca robots.txt ve sitemap istemlerini kullanın, sonuçları doğrulayın, sonra diğer şablonlara geçin.

İlk haftanın sonunda hangi istemin size gerçekten zaman kazandırdığını, hangisinin fazla düzeltme gerektirdiğini not edin. Bu küçük değerlendirme, kütüphanenizi zamanla sizin sitenize özel hale getirir.