Freelance geliştiriciler için yerel SEO rehberi

Freelance geliştirici olarak çalışanların çoğunun bir ofisi yok; iş evden, kafeden ya da bir ortak çalışma alanından yürüyor. Buna rağmen müşteriler hâlâ şehir adıyla arıyor: "Bursa web geliştirici", "İzmir otomasyon danışmanı" gibi. Yerel SEO tam bu boşluğu dolduruyor: fiziksel bir vitrininiz olmasa bile belirli bir coğrafyada hizmet verdiğinizi arama motorlarına tutarlı ve dürüst biçimde anlatabilmek. Kendi sitemi kurarken en çok zamanımı alan şey kod değil, "adresim yok, ne yazacağım?" sorusuydu.

Bu yazıda ofissiz çalışan bir geliştiricinin yerel görünürlüğünü dört parça üzerinden ele alıyorum: hizmet alanı tanımı, tutarlı iletişim bilgisi, referans sayfaları ve yerel dizinler. Her bölümde doğrudan uygulanabilecek somut adımları anlatacağım. Sahte adres ve konum tuzaklarına ayrı bir bölüm ayırdım; çünkü gördüğüm kadarıyla bu alandaki en büyük zararı, kısa yol arayan iyi niyetli insanlar kendi elleriyle üretiyor.

İki kod örneği var: biri hizmet alanını yapılandırılmış veriyle tarif eden bir JSON-LD bloğu, diğeri iletişim bilgilerinin farklı sayfalarda aynı olup olmadığını denetleyen küçük bir Python betiği. Python tarafında standart kütüphane dışında yalnızca requests kullanıyorum.

Hizmet alanı tanımı: adres yerine kapsama

Yerel aramada ilk refleks Google İşletme Profili açmak oluyor. Burada ayrım önemli: Google'ın yönergeleri, müşteriyle yüz yüze temas kurmayan ve tamamen çevrimiçi çalışan işletmeleri profil için uygun saymıyor; müşterinin yerine gidip iş yapıyorsanız ise "hizmet alanı işletmesi" olarak tanımlanabiliyorsunuz, adresi gizleyip hizmet verdiğiniz bölgeleri belirtiyorsunuz. Hangi tarafa düştüğünüzü profil açmadan önce güncel yönergeden okumak gerekiyor; kurallar zaman içinde değişiyor ve burada özetlediğim kadarını bile kesin kabul etmenizi istemem.

Profil olsun olmasın, hizmet alanını asıl anlatacağınız yer kendi siteniz. Benim uyguladığım düzen şu:

• Gerçekçi bir bölge listesi: yaşadığınız şehir ve fiilen gittiğiniz çevre ilçeler. "Tüm Türkiye" yazmak yerel sinyal üretmiyor; uzaktan da çalıştığınızı ayrıca ve açıkça söylemek daha inandırıcı.
• Ayrı bir "hizmet bölgeleri" bölümü: ana sayfada ya da hizmetler sayfasında, her bölge için bir iki cümle. Bölge adını başlığa serpiştirmek değil, o bölgede ne yaptığınızı yazmak.
• Yapılandırılmış veri: schema.org'daki ProfessionalService tipi LocalBusiness'ın alt tipi ve areaServed alanıyla hizmet bölgesini adres vermeden tarif etmeye izin veriyor.

Aşağıdaki blok, sayfanın head bölümüne application/ld+json türünde bir script etiketi içinde eklenir. Adres alanını bilerek koymadım; olmayan bir adresi yazmak yerine alanı boş bırakmak doğru davranış.

{
  "@context": "https://schema.org",
  "@type": "ProfessionalService",
  "name": "Ad Soyad - Web ve Otomasyon Geliştirme",
  "url": "https://www.ornek-site.com/",
  "telephone": "+90-555-000-00-00",
  "email": "[email protected]",
  "description": "Küçük işletmeler için web uygulaması ve veri otomasyonu geliştirme. Bursa merkezli, uzaktan çalışmaya açık.",
  "areaServed": [
    { "@type": "City", "name": "Bursa" },
    { "@type": "City", "name": "İstanbul" }
  ],
  "serviceType": ["Web geliştirme", "Veri otomasyonu", "API entegrasyonu"],
  "sameAs": [
    "https://github.com/kullanici-adi",
    "https://www.linkedin.com/in/kullanici-adi/"
  ]
}

Dikkat edilecek bir nokta: Google'ın LocalBusiness zengin sonuç belgesi adres alanını zorunlu tutuyor. Adres vermediğinizde arama sonucunda zengin kart görmeyebilirsiniz; işaretleme yine de varlığınızı ve bölgenizi makineye tutarlı biçimde anlattığı için işe yarıyor. Zengin kart uğruna buraya uydurma bir adres yazmak ise son bölümde anlatacağım tuzağın ta kendisi.

Tutarlı iletişim bilgisi: tek kaynak, tek biçim

Yerel SEO literatüründe NAP kısaltması (name, address, phone) sık geçer; ofissiz çalışanda adresin yerini hizmet alanı ve e-posta alıyor ama mantık aynı: aynı bilgi her yerde aynı biçimde yazılmalı. Bir yerde "+90 555 000 00 00", başka yerde "0 (555) 000 0000", üçüncü bir yerde eski numaranız duruyorsa arama motoru bunların aynı kişiye ait olduğundan emin olamıyor; müşteri de olamıyor.

Bu işi elle takip etmeyi denedim, tutmadı. Şu an yaptığım şey, kimlik bilgilerini depodaki tek bir JSON dosyasında tutup site altbilgisini, iletişim sayfasını ve yukarıdaki JSON-LD bloğunu derleme sırasında oradan üretmek. Sitede dört yerde numara yazıyorsa dördü de aynı dosyadan geliyor; değişiklik tek satır. Dış sayfalar (dizinler, sosyal profiller) bu düzenin dışında kaldığı için onları ayrıca denetlemek gerekiyor. Aşağıdaki betik tam bunu yapıyor: verilen sayfaları çekiyor, Türkiye cep telefonu desenine uyan numaraları ayıklayıp E.164 biçimine normalize ediyor ve beklenen ad ile numaranın sayfada olup olmadığını raporluyor.

import re
import sys
import requests

BEKLENEN = {
    "ad": "Ad Soyad",
    "telefon": "+905550000000",
}

SAYFALAR = [
    "https://www.ornek-site.com/",
    "https://www.ornek-site.com/iletisim/",
    "https://www.ornek-dizin.com/firma/ad-soyad",
]

# +90 555 000 00 00 / 0555 000 00 00 / (0555) 000-00-00 yazimlarini yakalar
TEL_DESENI = re.compile(
    r"(?:\+?90|0)?[\s\-().]*5\d{2}[\s\-().]*\d{3}[\s\-.]*\d{2}[\s\-.]*\d{2}"
)

def normalize_tel(ham):
    r = re.sub(r"\D", "", ham)
    if len(r) == 10:                            # 5xx xxx xx xx
        r = "90" + r
    elif len(r) == 11 and r.startswith("0"):    # 05xx xxx xx xx
        r = "9" + r
    return "+" + r

def denetle(url):
    try:
        yanit = requests.get(url, timeout=15,
                             headers={"User-Agent": "nap-kontrol/1.0"})
        yanit.raise_for_status()
    except requests.RequestException as hata:
        return url, "ERISIM", str(hata)
    html = yanit.text
    bulunan = {normalize_tel(t) for t in TEL_DESENI.findall(html)}
    ad_var = BEKLENEN["ad"].lower() in html.lower()
    tel_var = BEKLENEN["telefon"] in bulunan
    baska = sorted(bulunan - {BEKLENEN["telefon"]})
    durum = "OK" if ad_var and tel_var and not baska else "UYUMSUZ"
    return url, durum, f"ad={ad_var} tel={tel_var} baska={baska}"

if __name__ == "__main__":
    sorunlu = 0
    for url in SAYFALAR:
        u, durum, ayrinti = denetle(url)
        print(f"{durum:8} {u}  {ayrinti}")
        sorunlu += durum != "OK"
    sys.exit(1 if sorunlu else 0)

Betiği haftalık bir zamanlanmış görevde koşturuyorum; çıkış kodu sıfır değilse bildirim geliyor. Dizin sayfalarında dizinin kendi numarası da yakalanabildiği için betik "baska" listesini yalnızca raporluyor, kararı size bırakıyor. Yerel işletme kayıtlarını toplu kontrol etme fikrini daha önce Google Maps ile firma listesi çıkarma yazısında tersten anlatmıştım; orada başkalarının kayıtlarını topluyorduk, burada kendi kaydınızın dağınık kopyalarını topluyorsunuz.

Referans sayfaları: bölgeyi anahtar kelimeyle değil işle anlatmak

Ofisi olmayan geliştiricinin elindeki en güçlü yerel sinyal, yaptığı işlerin nerede olduğu. "Bursa'da bir üretim firması için stok takip otomasyonu" cümlesi, sayfa başlığına "Bursa web tasarım" yazmaktan çok daha fazla şey söylüyor: gerçek bir bağlam, gerçek bir sektör ve gerçek bir yer. Referans sayfalarını bu mantıkla kuruyorum:

• Her proje için tek sayfa: müşterinin sektörü, bulunduğu şehir, izin verdiyse adı, çözülen problem ve kullanılan araçlar. Müşteri adını paylaşmak istemiyorsa sektör ve şehir yeterli; uydurma referans yazmak yerine az ama doğrulanabilir referans daha iyi.
• Şehir başına toplama sayfası: aynı şehirden üç dört proje birikince "Bursa'daki projeler" gibi bir sayfa anlamlı hâle geliyor. Sıfır projeyle açılmış şehir sayfaları ise ne müşteriye ne arama motoruna bir şey söylüyor.
• Kapı sayfası tuzağından uzak durmak: aynı metni şehir adı değiştirerek on kez çoğaltmak, Google'ın spam politikalarında "doorway" olarak adlandırılan kalıba giriyor. Gördüğüm kadarıyla bu sayfalar önce dizine giriyor, sonra sessizce görünürlük kaybediyor ve neyin cezalandırdığını anlamak aylar alıyor.
• Teknik içerik de yerel sinyal taşır: bir referans sayfasında kullandığınız yöntemi ayrı bir teknik yazıyla desteklemek hem güven veriyor hem de sayfalar arasında bağ kuruyor. Örneğin Excel tabanlı raporlama işlerinde Excel kalite kontrol otomasyonu yazısına referans sayfasından bağlantı veriyorum.

Yerel dizinler: az, doğru ve takip edilen

Dizin kayıtları konusunda iki uç görüyorum: hiç uğraşmayanlar ve otomatik araçlarla yüzlerce dizine aynı anda kayıt olanlar. İkincisi ilk bakışta verimli görünüyor; pratikte birkaç ay sonra elinizde adını bile hatırlamadığınız, güncelleyemediğiniz, eski numaranızı taşıyan onlarca kayıt kalıyor. Yukarıdaki tutarlılık betiğinin varlık sebebi biraz da bu.

Benim ölçütlerim:

• Dizin gerçekten kullanılıyor mu? Kendi sektörünüzü o dizinde arayın; sonuç sayfası boşsa ya da son kayıt yıllar önceyse zaman harcamayın.
• Giriş yapıp düzenleyebiliyor musunuz? Kayıt sahipliği sizde olmayan dizinler, numara değiştiğinde düzeltemeyeceğiniz bir tutarsızlık kaynağı.
• Kayıt listesi tek bir dosyada: dizin adı, kayıt adresi, giriş yöntemi, son kontrol tarihi. Bu listenin adres sütunu doğrudan yukarıdaki betiğin SAYFALAR girdisi oluyor.
• Mesleki profiller önce: GitHub, LinkedIn, freelancer platformları ve varsa yerel iş ağı siteleri, genel amaçlı firma rehberlerinden daha fazla iş getiriyor; en azından benim gördüğüm bu.

Dizinlerdeki bilgiyle sitenizdeki bilginin aynı kaynaktan üretilmesi işin özü. Kayıt sayısı değil, kayıtların birbirini doğrulaması sinyal üretiyor.

Sahte adres ve konum tuzakları

Bu bölümü en sona koydum ama en önemlisi bu. Ofisi olmayan geliştiriciye "görünürlük için bir adres lazım" diyen çok kişi çıkıyor ve öneriler hep benzer:

• Tanıdık ya da aile adresi: profil o adrese kayıtlı görünür, doğrulama kartı oraya gider. Orada iş yapmadığınız için Google'ın "işletmenin bulunduğu yer" tanımına uymuyor; sık rastlanan bir askıya alınma gerekçesi.
• Sanal ofis adresi: posta hizmeti veren ama içinde çalışmadığınız bir adres. Google'ın yönergeleri, mesai saatlerinde orada çalışan biri yoksa sanal ofisi kabul etmiyor; buna rağmen "herkes yapıyor" diye pazarlanıyor.
• Şehir başına ayrı profil: hizmet verdiğiniz her şehirde ayrı bir işletme kaydı açmak. Bu yinelenen kayıt sayılıyor ve gördüğüm vakalarda tek tek değil toplu hâlde kapatılıyor.
• Anahtar kelimeli işletme adı: "Ad Soyad Bursa Web Tasarım SEO" gibi adlar. İşletme adı gerçek dünyadaki adınız olmak zorunda; fazlası düzenleme kilidi ya da askıya alma getiriyor.
• Sitede uydurma adres: JSON-LD'ye ya da altbilgiye "zengin sonuç için" bir adres yazmak. Müşteri kapınıza gelmese bile, siteniz ile diğer kayıtlarınız arasında kalıcı bir tutarsızlık yaratıyor.

Risk yalnızca arama görünürlüğü değil. Askıya alınan profil, üzerine yıllarca yorum ve fotoğraf biriktirdiğiniz varlığı bir gecede görünmez yapıyor; itiraz süreci belgeye dayanıyor ve olmayan ofisin belgesi de olmuyor. Ayrıca ticari tanıtımda yanıltıcı adres kullanmanın Türkiye'de tüketici ve ticaret mevzuatı açısından da sonuçları olabilir; bu konuda hukuki görüş verecek durumda değilim, ama "yalnızca Google'ın kuralı" diye küçümsemenin doğru olmadığını söyleyebilirim. Kısacası: adresiniz yoksa yok. Hizmet alanı, tutarlı bilgi, gerçek referanslar ve az sayıda doğru dizin kaydı, sahte bir haritadaki iğneden çok daha kalıcı görünürlük üretiyor.

Bu yazıdaki JSON-LD bloğu ve tutarlılık betiği, kendi sitemde kullandığım düzenin sadeleştirilmiş hâli. Veri ve otomasyon tarafında yaptığım işlere ana sayfadan göz atabilir, kendi siteniz için benzer bir kurulumu konuşmak isterseniz sitedeki iletişim bölümünden (/#contact) bana ulaşabilirsiniz.