10+ oluşturdumSEO34 gün içinde temsilci becerileri. İlk denemede altısı çalıştı. Diğer dördü bana, AI SEO becerileri hakkında çoğu LinkedIn gönderisinin gözden kaçırıldığı klasör yapısı hakkında size göstereceğim her şeyi öğretti.
Bu aracıları güvenilir kılan şey, daha iyi yönlendirmeler değildir. Arkalarındaki mimari budur. Sıfırdan bir aracı oluşturmanın, test etmenin, düzeltmenin ve güvenle göndermenin yolu burada açıklanmıştır.
Çoğu AI SEO becerisi neden başarısız oluyor?
LinkedIn'de tipik bir "AI SEO istemi" şöyle görünür:
Siz bir SEO uzmanısınız. Aşağıdaki web sitesini analiz edin ve önerilerle birlikte kapsamlı bir denetim sağlayın.İşte bu. Bir istem. Belki bazı biçimlendirme talimatları. Kişi çıktının ekran görüntüsünü yayınlar, 500 beğeni alır ve yoluna devam eder. Çıktı profesyonel görünüyor. İyi okuyor. Ayrıca %40'ı yanlış.
Biliyorum çünkü tam olarak bu yaklaşımı denedim. Kurulumun başlarında bir temsilciyi bir web sitesine yönlendirdim ve "SEO sorunlarını bulun" dedim. 20 bulguyla geri döndü. Sekiz yoktu. Temsilci, rapor verdiği URL'lerden bazılarını hiç ziyaret etmemişti.
Üç sorun tek istem becerilerini öldürür:
- Araç yok:Temsilcinin web sitesini gerçekten kontrol etmesinin hiçbir yolu yoktur. Eğitim verilerinden ve tahminlerden çalışıyor. “Bu sitenin kanonik etiketleri var mı?” aracı, HTML'yi alıp ayrıştırmak yerine sitenin muhtemelen nasıl görüneceğini hayal eder.
- Doğrulama yok:Çıktının doğru olup olmadığını kimse kontrol etmiyor. Temsilci, "15 sayfada eksik meta açıklamalar" diyor. Hangi 15? Bu sayfalar dizine eklendi mi? Kasıtlı olarak indekslenmemişler mi? Kimse sormuyor. Kimse doğrulamıyor.
- Bellek yok:Aynı beceriyi iki kez çalıştırdığınızda farklı çıktılar elde edersiniz. Farklı yapı. Farklı önem derecesi etiketleri. Bazen tamamen farklı bulgular. Tutarlılık yok çünkü şablon yok, şema yok, geçmiş çalıştırmaların kaydı yok.
Yeteneğiniz tek bir dosyadaki bilgi istemiyse, bir beceriniz yok demektir. Yazı tura atıyorsunuz.
Bildiğiniz SEO araç seti ve ihtiyacınız olan AI görünürlük verileri.
Çalışma alanları olarak SEO aracısı becerilerini geliştirin
Sistemimizdeki her temsilcinin bir çalışma alanı vardır. Bunu yeni işe alınan birinin ihtiyaç duyduğu her şeyle dolu bir masası gibi düşünün. Web sitelerini tarayan ve mimarilerinin haritasını çıkaran aracı için çalışma alanı şöyle görünür:
temsilci-çalışma alanı/
AGENTS.md talimatları, kurallar, çıktı formatı
SOUL.md kişiliği, ilkeleri, kalite çıtası
komut dosyaları/
crawl_site.js aracının taramak için çağırdığı araç
XML site haritalarını okumak için parse_sitemap.sh aracı
referanslar/
Criteria.md Gürültüye karşı neyin sorun olarak sayıldığı
gotchas.md dikkat edilmesi gereken bilinen yanlış pozitifler
hafıza/
run.log geçmiş yürütme geçmişi
şablonlar/
Output.md beklenen çıktı yapısıAltı bileşen. Bir bilgi istemi dosyası bunun belki %20'sini kapsar.
AGENTS.md kullanım kılavuzudur
AGENTS.md'ye binlerce kelimelik metodoloji yazdım. "Siteyi taramak" yerine adımları sıraladım: "Site haritasıyla başlayın. Site haritası yoksa site haritası referansları için /sitemap.xml, /sitemap_index.xml ve robots.txt'yi kontrol edin.
Tarama gecikmesine saygı gösterin. Bir tarayıcı kullanıcı aracısı dizesi kullanın, asla çıplak bir istek değil. Eğer 403 alırsanız, modeli not edin ve bunu bir blok olarak bildirmeden önce farklı başlıklarla deneyin.”
Komut dosyaları aracının araçlarıdır
Aracı, web sitesi verilerini analiz etmek için crawl_site.js –url düğümünü çağırır. Curl komutlarını her seferinde sıfırdan yazmaz. Birine alet kutusu vermekle ona kendi anahtarını yapmasını söylemek arasındaki fark budur.
Referanslar karar çağrılarıdır
Bu, neyin sorun olarak sayılacağına ilişkin kriterleri içerir. Dikkat edilmesi gereken bilinen yanlış pozitifler. Öğrenmem 20 yılımı alan uç vakalar. Temsilci belirsiz bir şeyle karşılaştığında bunları okur.
Bellek kurumsal bilgidir
Burada geçmiş koşuların kaydını tutuyorum:
- Geçen sefer bulduğu şey.
- Tarama ne kadar sürdü?
- Ne kırıldı.
Bir sonraki uygulama sonuncudan yararlanır.
Şablonlar tutarlılığı zorunlu kılar
İşte burada istediğim çıktı hakkında spesifik bilgiler elde ediyorum: "Tam olarak bu yapıyı kullanın. Tam olarak bu alanları. Bu önem ölçeğini kullanın." Çıktı şablonları, 1. çalıştırmada elde ettiğiniz kalitenin aynısını 14. çalıştırmada elde etmek arasındaki farktır.
İzlenecek yol: Tarayıcıyı sıfırdan oluşturma
Size tarayıcıyı tam olarak nasıl oluşturduğumu göstereyim. Bir sitenin mimarisinin haritasını çıkarır, her sayfayı keşfeder ve bulduklarını rapor eder.
Versiyon 1: Saf yaklaşım
Talimatı verdim: "Bu web sitesini tarayın ve tüm sayfaları listeleyin."
Aracı kendi HTTP isteklerini yazdı, yalın kıvrılma kullandı ve dokunduğu ilk site tarafından engellendi. Her modern CDN, tarayıcı kullanıcı aracısı dizisi olmayan istekleri engeller, bu nedenle varışta ölmüştür.
Sürüm 2: Bir komut dosyası eklendi
Craw_site.js'yi Playwright'ı kullanarak oluşturdum. Bu sürüm, başsız bir tarayıcı ve gerçek bir kullanıcı aracısı kullanıyordu. Aracı, kendi isteklerini yazmak yerine betiği çağırır.
Bu, küçük sitelerde işe yaradı ancak 200 sayfanın üzerindeki her yerde çöktü. Hız sınırlaması ve devam etme yeteneği olmadığı için sunucuları bizi bloke edene kadar dövdü.
Sürüm 3: Hız sınırlama ve devam ettirmeyle tanışın
CDN korumalı siteler için varsayılan olarak saniyede iki istekle ve hiçbir zaman iki saniyede bir olmayacak şekilde kısıtlama ekledim. Aracı, robots.txt dosyasını okur ve izin istemeden hızını ayarlar. Ayrıca çöken taramanın kaldığı yerden devam edebilmesi için denetim noktası dosyalarını da ekledim.
Bu, çoğu sitede işe yaradı ancak JavaScript oluşturulmasını gerektiren sitelerde başarısız oldu.
Sürüm 4: JavaSript oluşturma
Bu sefer bir tarayıcı oluşturma modu ekledim. Aracı, bir sitenin tek sayfalık bir uygulama (React, Next.js, Angular) olup olmadığını algılar ve otomatik olarak tam tarayıcı oluşturmaya geçer.
Ayrıca, oluşturulan HTML ile kaynak HTML'yi karşılaştırır ve gerçek sorunları şu şekilde buldum: Kaynak HTML'nin boş bir kabuk olduğu ancak oluşturulan sayfanın içerikle dolu olduğu siteler. Google bunu düzgün bir şekilde oluşturup oluşturmayabilir. Şimdi ikisini de kontrol ediyoruz.
Bu sürüm her şeyde işe yaradı ancak çıktılar çalıştırmalar arasında tutarsızdı.
Versiyon 5: Şablonlar ve hafıza zamanı
Bu sürüm için şablonlar/output.md'yi tam alanlarla ekledim: URL sayısı, site haritası kapsamı, engellenen yollar, yanıt kodu dağıtımı, kullanılan oluşturma modu ve bulunan sorunlar. Bu şekilde her çalıştırma aynı yapıyı üretir.
Ayrıca Memory/runs.log'u da ekledim. Temsilci her yürütmeden sonra bir özet ekler. Bir dahaki sefere çalıştırıldığında günlüğü okur ve "Son tarama 485 sayfa buldu. Bu tarama 487 sayfa buldu. İki yeni sayfa eklendi." gibi sonuçları karşılaştırabilir.
Sürüm 5, bugün çalıştırdığımız sürümdür. İnşaatın bir gününde beş yineleme.
CRWLER'IN EVRİMİ
v1: Ham kıvrılma → her yerde engellendi
v2: Oyun yazarı komut dosyası → büyük sitelerde çöktü
v3: Hız sınırlayıcı → JS sitelerini yönetemedi
v4: Tarayıcı oluşturma → tutarsız çıktı
v5: Şablonlar + bellek → kararlı, tutarlı, güvenilir
Süre: 1 gün. Ders: İlk versiyon asla çalışmaz.Desen her zaman aynıdır: Küçük başlayın, bir duvara çarpın, duvarı düzeltin, bir sonraki duvara çarpın.
Bir günde beş versiyon, beş başarısızlık anlamına gelmez. Bu, artık kalıcı olarak kodlanan beş ders anlamına geliyor. 20 yılda teslimat sistemlerini dört kez yeniden kurdum. Süreç değişmiyor. Zarif olanla başlarsınız, sonra gerçek ortaya çıkar ve sonunda işe yarayanla karşılaşırsınız.
Uç:İlk denemede mükemmel beceriyi geliştirmeye çalışmayın. İşe yarayabilecek en basit şeyi oluşturun. Gerçek veriler üzerinde çalıştırın ve başarısızlığını izleyin. Başarısızlıklar size daha sonra tam olarak ne eklemeniz gerektiğini söyler. Tarayıcımızın her sürümü belirli bir hataya doğrudan yanıttı. Hayal ettiğimiz bir özellik değil. Karşılaştığımız bir sorun.
Temsilcileri doğru araçlarla donatın
Bu verdiğim en önemli mimari karar.
Talimatlarınıza “site haritasını getirmek için curl kullan” yazdığınızda, aracı her seferinde sıfırdan bir curl komutu oluşturur. Bazen doğru başlıkları ekler. Bazen öyle değil. Bazen yönlendirmeleri takip eder. Bazen unutur.
Aracıya parse_sitemap.sh adlı bir komut dosyası verdiğinizde, aracı bu komut dosyasını çağırır. Betik her zaman doğru başlıklara sahiptir, her zaman yönlendirmeleri takip eder ve her zaman uç durumları ele alır. Temsilcinin kararı, aracın NE ZAMAN çağrılacağına ve sonuçlarla NE yapılacağına bağlıdır. Araç NASIL'ı yönetir.
Temsilcilerimizin her şeye yönelik araçları vardır:
- crawl_site.js: Hız sınırlama, devam ettirme ve oluşturma özelliklerine sahip oyun yazarı tabanlı tarayıcı
- parse_sitemap.sh: XML site haritalarını getirir ve ayrıştırır, URL'leri sayar, iç içe geçmiş dizinleri algılar
- check_status.sh: HTTP yanıt kodlarını uygun kullanıcı aracısı dizeleriyle test eder
- extract_links.sh: Sayfa HTML'sinden iç ve dış bağlantıları çeker
Aracı, hangi araçların kullanılacağına ve hangi parametrelerin ayarlanacağına karar verir. Tarayıcı, karşılaştığı şeye göre kendi tarama hızını seçer. Robots.txt dosyasını okur ve ayarlar. Korkuluklar içinde muhakemesi vardır.
Bunu şu şekilde düşünün: Yeni işe alınan bir kişiye veritabanının nasıl oluşturulacağına ilişkin talimatlar değil, bir CRM verirsiniz. Araçlar CRM'dir. Talimatlar bunları kullanma sürecidir.
Aşamalı açıklama: Her şeyi bir kerede atmayın
İşte daha önce yaptığım bir hata: Her şeyi AGENTS.md'ye koyuyorum. Her kural. Her uç durum. Her şey. Binlerce kelime.
Ajanın kafası karıştı. Çok fazla bağlam vardı ve ortak görevler yerine belirsiz uç durumlara öncelik vermeye başladı. Bir WordPress blogunda karma yönlendirme sorunlarını kontrol etmek için zaman harcayacaktır.
Çözüm: aşamalı açıklama.
Vakanın %80'ini etkileyen temel kurallar AGENTS.md'de bulunmaktadır. Temsilcinin her çalıştırmada bilmesi gereken şey budur.
Edge vakaları references/gotchas.md'ye gider. Aracı, belirsiz bir şeyle karşılaştığında bu dosyayı okur. Her görevden önce değil. Sadece ihtiyacı olduğunda.
Ciddiyet puanlaması kriterleri references/criteria.md'de mevcuttur. Temsilci bir sorun bulduğunda bunu kontrol eder ve sorunun ne kadar kötü olduğuna karar vermesi gerekir. Peşin değil.
Bu, vasıflı bir çalışanın çalışma şekliyle aynıdır. Temel süreci ezbere biliyorlar. Tuhaf bir şey ortaya çıktığında el kitabını kontrol ediyorlar. Her e-postayı yanıtlamadan önce el kitabının tamamını tekrar okumazlar.
Temsilci çıktınız tutarsız ancak talimatlarınız ayrıntılıysa sorun genellikle çok fazla bağlamdan kaynaklanır. Temsilciler, yeni işe alınanlar gibi, her görevden önce sindirmek zorunda oldukları 50 sayfalık bir kılavuza göre, net öncelikler ve bir referans rafı ile daha iyi performans gösterirler.
10 sorun: Sizi yakacak başarısızlık modları
Bu derslerin her biri bana saatlere mal oldu. Artık temsilcilerimizin referansları/gotchas.md dosyalarında kodlanmış durumdalar, böylece bir daha tekrarlanamayacaklar.
Ajanlar doğrulayamadıkları verileri halüsinasyona uğratıyor
Araştırma görevlisinden hukuk firmalarını bulmasını ve avukatlarını saymasını istedim. Her sayıyı uydurdu. Hiçbir web sitesini ziyaret etmemişti.
Temsilcilerden yalnızca gerçekten alıp doğrulayabilecekleri verileri üretmelerini isteyin. Bildiklerini (eğitim verileri) kanıtlayabileceklerinden (getirilen veriler) ayırın.
Bilgi aracılar arasında aktarılmaz
İlk günde keşfettiğim bu düzeltmenin (CDN blokajlarını önlemek için bir tarayıcı kullanıcı aracısı dizesi kullanın) her yeni aracıya yeniden öğretilmesi gerekiyordu. 34. günde, yepyeni bir temsilci aynı sorunla karşılaştı.
Temsilciler anıları paylaşmazlar. Paylaşılan dersleri, birden fazla aracının başvurabileceği ortak bir gotchas dosyasında kodlayın.
Çıkış formatı çalıştırmalar arasında değişiyor
Aynı istem farklı alan adlarıyla sonuçlanabilir: "not" ve "değerlendirme". "lead_score" ve "qualification_rating" karşılaştırması. İki kez çalıştırırsanız iki farklı şema elde edin.
Çözüm: Tam alan adlarıyla katı çıktı şablonları oluşturun. "Rapor yazmak" değil. "Tam olarak bu şablonları bu alanlarla kullanın."
Temsilciler mevcut olmayan sorunları güvenle rapor ediyor
İlk üç denetim tamamen güvenle hatalı pozitif sonuçlar verdi.
Düzeltme daha iyi bir istem değildi. Daha iyi bir patrondu. Tek görevi herkesin çalışmasını doğrulamak olan özel bir inceleme temsilcisi. Kod incelemesinin insan geliştiriciler için de geçerli olmasının nedeni aynıdır.
Çıplak HTTP istekleri her yerde engelleniyor
Her modern CDN, tarayıcı kullanıcı aracısı dizisi olmayan istekleri engeller. Tarayıcı bunu ikinci denetimde tüm sitenin 403'leri döndürmesiyle öğrendi.
Tek gereken tek satırlık bir düzeltmeydi ve bu artık Gotchas dosyasında. Her yeni temsilci bunu ilk gün okur.
URL yollarını tahmin etmeyin
Temsilciler, olması gerektiğini düşündükleri URL'leri oluşturmayı severler: /about-us, /blog, /contact. Çoğu zaman bu URL'ler 404'tür.
Benim kuralım: Önce ana sayfayı getir, navigasyonu oku, gerçek bağlantıları takip et. Asla tahmin etme.
'Bitti' ve 'inceleniyor' durumları önemli
Temsilciler bulgularını yayınlarken görevleri "tamamlandı" olarak işaretledi. Yanlış. “Bitti” onaylandığı anlamına gelir. "İncelemede", insan doğrulamasını beklemek anlamına gelir.
Bu küçük ayrım, aynı anda iş ilan eden 10 temsilciniz olduğunda iş akışının netliği üzerinde büyük bir etkiye sahiptir.
Kategoriler aşırı spesifik olmalıdır
"Fintech" çok geniş kapsamlı olduğu için potansiyel müşteri arama açısından işe yaramaz. “Houston'daki PI hukuk firmaları” çalışıyor. Bir kategorideki her şirket diğer tüm şirketlerle doğrudan rekabet etmelidir.
Satış kategorilerindeki ilk denemem “Kişisel finans ve fintech” oldu. Bir kripto borsası bir bütçeleme uygulamasıyla rekabet edemez. Ders 20 dakikada öğrenildi.
Asla bir LLM'den veri derlemesini istemeyin
Uydurma sonuçlar istemediğiniz sürece. Bir temsilciden beş ayrı rapordaki bulguları tek bir belgede özetlemesini istedim. Hiçbir kaynak raporunda yer almayan bulguları icat etti.
Veri derlemelerini her zaman programlı olarak oluşturun. Senaryosunu yaz. Asla ısrar etmeyin.
Temsilciler hiç planlamadığınız şeyleri deneyecek
Araştırma temsilcisi asla kurmadığımız bir API'yi çağırmaya çalıştı. API'nin var olduğunu bildiği için erişimimiz olduğunu varsaydı.
Çözüm: Hangi araçların mevcut olduğu konusunda açık olun. Komut dosyaları klasöründe bir komut dosyası yoksa aracı onu kullanamaz. Sınırlar yaratıcı başarısızlıkları önler.
İlk önce incelemeciyi oluşturun
Bu mantığa aykırıdır. İnşa etme konusunda heyecan duyduğunuzda, işçileri inşa etmek istersiniz. Tarayıcı. Analizörler. Eğlenceli kısımlar.
İlk önce gözden geçireni oluşturun. İnceleme katmanı olmadan kaliteyi ölçmenin hiçbir yolu yoktur. İlk denetimi gönderiyorsunuz ve harika görünüyor. Ancak bulguların %40'ı yanlıştır. Bir müşteriniz veya iş arkadaşınız bunu fark edene kadar bunu bilemezsiniz.
İnceleme temsilcimiz her uzman temsilcinin bulgularını okur. Şunları kontrol eder:
- Kanıtlar iddiayı destekliyor mu?
- Ciddiyet gerçek etki için uygun mu?
- Farklı uzmanlar arasında kopyalar var mı?
- Temsilci kontrol ettiğini söylediği şeyi kontrol etti mi?
Bu tek temsilci, kalite konusunda yaptığım en büyük gelişmeydi. Herhangi bir hızlı ayardan daha büyük. Tüm yeni araçlardan daha büyük.
270 dahili bağlantı önerisi genelinde insan onay oranı: %99,6. Bu sayı, bir incelemecinin her birini doğrulaması nedeniyle mevcuttur.
20 yıldır insan SEO ekiplerinde de aynı modeli görüyorum. Harika işler çıkaran ekipler en iyi analistlere sahip ekipler değildir. En iyi inceleme sürecine sahip olanlar onlardır. Analiz masa bahisleridir. İnceleme üründür.
YAPI DÜZENİ (ZOR YOLDAN ÖĞRENDİM)
İlk olarak ne yaptım: İşçi inşa et → Gemi çıktısı → Kalite sorunlarını keşfet → Derleme incelemecisi
Ne yapmalıydım: İnceleyiciyi oluştur → Çalışanları oluştur → İncelenen çıktıyı gönder → Her ikisini de yinele
Gözden geçiren kişi kaliteyi tanımlar. Önce onu inşa edin. Diğer her şey buna göre ölçülür.Uç:Birden fazla aracı oluşturuyorsanız inceleyici, oluşturduğunuz ilk aracı olmalıdır. Çıktı üreten şeyi oluşturmadan önce "iyi çıktının" neye benzeyeceğini tanımlayın. Aksi takdirde, biçimlendirmeyle birlikte halüsinasyonlar gönderiyorsunuz. Bunu geriye dönüp baktığımda utanç verici olan üç denetimde öğrendim.
Doğrulama standardı (Haksız avantajımız)
İncelemeyi yapan kişi teknik hataları yakalar. Ancak "teknik olarak doğru"dan daha yüksek bir çıta var.
Gerçek müşterilere sahip gerçek bir SEO ajansımız ve 50 yıllık deneyime sahip bir ekibimiz var. Her temsilcinin bulgusu tek bir soruyla doğrulanır: "İtibarımızı bu konuda riske atar mıyız?"
Bunu gerçekten bir müşteriye gönderip rapora adımızı yazıp geliştiriciye bunu oluşturmasını mı söylerdik?
Aşağıda her bulgu için kullandığımız dört test bulunmaktadır:
- Google mühendis testi:Bu müşterinin kuzeni Google'da çalışıyorsa bu bulguyu okuyup başını sallar mı? “Evet, bu gerçek bir mesele, bu mantıklı” derler mi? Cevap hayır ise gönderilmez.
- Geliştirici testi:Bir geliştirici tek bir takip sorusu sormadan bunu tekrarlayabilir mi? "Kurallarınızı düzeltin" başarısız oluyor. “CANONICAL_BASE_URL'yi üretim .env'nizde http'den https'ye değiştirin” geçer.
- Ajans itibar testi:Bu bulguyu bir müşteri toplantısında savunabilir miyiz? Bunu teknik bir CMO'ya açıklamaktan utanırsam kesilir.
- Uygulama testi:Bu gerçekten düzeltmek için yeterince spesifik mi? "Sayfa hızınızı artırın" değil, "kahraman videonuz 3,4 MB, yani toplam sayfa ağırlığının %72'si. Mobil cihazlara sıkıştırılmış bir sürüm sunun. Dosya burada."
Bu bizim haksız avantajımızdır. Biz boşlukta acenteler oluşturmuyoruz. AI SEO araçları geliştiren çoğu kişi hiçbir zaman gerçek bir denetim yapmamıştır. “İyi”nin neye benzediğini bilmiyorlar. Yapıyoruz. 20 yıldır gerçek müşterilerle teslimat yapıyoruz. Bu nedenle onay oranımız %99,6.
Korumalı alan testi: Eklenen hatalar konusunda eğitim alın
Bir temsilciyi gerçek müşteri sitelerinde eğitemezsiniz. Cevaplarını bildiğiniz bir test ortamı yaratırsınız. Bilerek yerleştirdiğimiz SEO sorunlarını içeren iki sanal alan web sitesi oluşturduk:
- 27'den fazla yerleşik soruna sahip WordPress tarzı bir site: eksik kanonikler, yönlendirme zincirleri, yetim sayfalar, yinelenen içerik, bozuk şema işaretlemesi.
- Yaklaşık 90 yerleşik sorunla React/Next.js/Angular kalıplarını simüle eden bir Node.js sitesi: boş SPA kabukları, karma yönlendirme, eski önbelleğe alınmış sayfalar, hidrasyon uyumsuzlukları, gizleme.
Eğitim döngüsü:
- Aracıyı korumalı alana karşı çalıştırın.
- Temsilcinin bulgularını bilinen sorunlarla karşılaştırın.
- Ajan bir şeyi mi kaçırdı? Talimatları düzeltin.
- Ajan yanlış pozitif mi rapor etti? Gotchas.md'ye ekleyin.
- Yeniden çalıştırın. Tekrar karşılaştırın.
- Yalnızca sanal alanı tutarlı bir şekilde geçtiğinde gerçek verilere dokunur.
Bunu bir sürüş testi kursu gibi düşünün. Gerçek yollardaki her kaza, parkurda yeni bir engel haline gelir. Yeni sürücüler otoyola çıkmadan önce bilinen her türlü zorlukla karşı karşıya kalıyor.
Korumalı alan yaşayan bir test paketidir. Gerçek bir denetimde doğrulanan her sorun yeniden ele alınır. Daha da zorlaşır. Ajanlar daha da iyiye gidiyor.
Tutarlılık: Seksi olmayan sır
Sıkıcı olduğu için kimse bunun hakkında yazmıyor. Ancak demoyu üründen ayıran şey tutarlılıktır.
Çıktıyı tutarlı kılan üç şey:
- Şablonlar:Her aracının şablonlar/output.md'de bir çıktı şablonu vardır: Tam alanlar, yapı ve önem ölçeği. Çıktı her çalıştırmada farklı görünüyorsa daha iyi bir istem gerekmez. Bir şablon dosyasına ihtiyacınız var.
- Günlükleri çalıştırın:Her yürütmeden sonra aracı, Memory/runs.log dosyasına bir özet ekler. Zaman damgası, site, taranan sayfalar, bulunan sorunlar, süre. Bir sonraki çalıştırma bu günlüğü okur. Geçen sefer ne olduğu biliniyor. Karşılaştırma yapabilir ve "Son çalıştırmada 14 sorun bulundu. Bu çalışmada 16 sorun bulundu. 2 yeni sorun belirlendi" gibi çıktılar sağlayabilir.
- Şema uygulaması:Alan adları kilitlidir: "öncelik" değil "önem", "sayfa_url" değil "url", "özet" değil "açıklama". Alan adlarının sürüklenmesine izin verdiğinizde aşağı yöndeki araçlar bozulur. Şablonlar bunu kalıcı olarak çözer.
Aracı çıktınız her çalıştırmada farklı görünüyorsa, daha iyi bir istem yerine bir şablon dosyasına ihtiyacınız vardır. Bunu yeterince vurgulayamam. Herhangi bir temsilci için kaliteyi artırmanın en hızlı yolu katı bir çıktı şablonudur.
Çalışmasını sağlayan yığın
Altyapıyla ilgili kısa bir not çünkü araçlar önemlidir.
Temsilcilerimiz OpenClaw'da çalışıyor. Uyandırmaları, oturumları, belleği ve araç yönlendirmeyi yöneten çalışma zamanıdır. Bunu, aracıların üzerinde çalıştığı işletim sistemi olarak düşünün. Bir temsilci bir görevi bitirdiğinde ve bir sonrakini alması gerektiğinde, OpenClaw bu geçişi yönetir. Bir aracının son oturumda ne yaptığını hatırlaması gerektiğinde OpenClaw bu belleği sağlar.
Paperclip şirketin işletim sistemidir. Organizasyon şemaları, hedefler, sorun takibi, görev atamaları. Ajanların koordine ettiği yer burası. Tarayıcı bir sitenin haritasını çıkarmayı tamamladığında ve bunu uzman aracılara devretmesi gerektiğinde, Paperclip bu aktarımı kendi sorun sistemi aracılığıyla yönetir. Aracılar birbirleri için görevler oluştururlar. Görev sırasında otomatik uyanma.
Claude Code oluşturucudur. Her komut dosyası, her aracı talimat dosyası, her araç, Opus 4.6'yı çalıştıran Claude Code ile oluşturuldu. 20 yıllık SEO uzmanlığına ve sıfır geleneksel programlama eğitimine sahip bir titreşim kodlayıcıyım. Claude Code, alan bilgisini çalışan yazılıma dönüştürür.
Kombinasyon: OpenClaw aracıları çalıştırır. Ataç bunları koordine eder. Claude Code her şeyi inşa eder.
Tek platformdan Google ve AI aramalarını takip edin, optimize edin ve kazanın.
Sonuç
Bu süreç, tam URL'ler ve düzeltme talimatları dahil olmak üzere denetim başına 12 ila 20 geliştiriciye hazır bildirimle 14'ten fazla denetimin tamamlanmasıyla sonuçlandı. Tamamı haftalar değil saatler içinde üretilir.
Özel bir inceleme süreciyle doğrulanan, iki sitedeki 270 bağlantıya ilişkin dahili bağlantı önerilerinde %99,6'lık bir onay oranına sahibiz.
Yedi uzman temsilciyle eşleştirilen 80'den fazla SEO kontrolünü tamamladık. Her kontrolün beklenen sonuçları, kanıt gereklilikleri ve hatalı pozitif kuralları vardır. Her bulgu spesifiktir (ör. "ana uygulama JavaScript paketinin %78'i kullanılmamaktadır. Düzeltilecek dosyaların tamamı buradadır").
Bu düzeydeki özgüllük beceri mimarisinden gelir. Klasör yapısı. Araçlar. Referanslar. Şablonlar. İnceleme katmanı. İstem değil.
Gerçekten işe yarayan SEO aracı becerileri geliştirmek istiyorsanız, bilgi istemleri yazmayı bırakın ve çalışma alanları oluşturmaya başlayın. Temsilcilerinize talimatlar değil araçlar verin. İstemcilerde değil, sanal alanlarda test yapın.
İlk önce gözden geçireni oluşturun. Şablonları zorunlu kılın. Her şeyi günlüğe kaydedin. İlk versiyon başarısız olacaktır. Beşinci versiyon sizi şaşırtacak.
Aracı çıktısını bu şekilde tekrarlanabilir bir şeye dönüştürürsünüz. İster ilk denetim ister 14'üncü denetim olsun, aynı sistem aynı kaliteyi üretir çünkü her adım yapılandırılmış, doğrulanmış ve kodlanmıştır.
Yapay zekanın daha akıllı olması nedeniyle değil. Çünkü mimarlık öyle.
