Temizlik Şirketlerinde Hizmet Sayfası SEO: Bir Hizmet Sayfası Nasıl Yapılandırılmalı?


Bir temizlik şirketinin hizmet sayfası, hizmet adını H1’e yazıp altına birkaç paragraf “profesyonel ve kaliteli hizmet sunuyoruz” metni eklemekten ibaret değildir.
İnşaat sonrası temizlik, depo temizliği, dış cephe temizliği veya yangın sonrası temizlik gibi hizmetler gerçekten ayrı kullanıcı ihtiyaçları oluşturuyorsa her biri kendi commercial search intent’inin sahibi olabilir.
Bu durumda hizmet sayfasının görevi yalnız keyword taşımak değil:
olmalıdır.
Güçlü bir temizlik hizmet sayfası, tek bir ticari ihtiyacın canonical owner’ı olarak çalışan ve kullanıcının aramadan teklif talebine kadar olan yolculuğunu tamamlayan sayfadır.
DigitalPlus’ın sektör genelindeki yaklaşımını Temizlik Şirketi SEO hizmetimizde inceleyebilirsiniz.
Hizmet sayfasının temel görevi belirli bir commercial service intent’i karşılamaktır.
Örneğin:
aynı işletme tarafından sunulabilir.
Ancak kullanıcı açısından bunların problemi, operasyonu ve satın alma değerlendirmesi aynı değildir.
“Depo temizliği” arayan kullanıcı büyük ticari alan, raf sistemleri, zemin, operasyon zamanı ve ekip kapasitesiyle ilgilenebilir.
“İnşaat sonrası temizlik” arayan kullanıcı ise kaba inşaat kalıntıları, ince temizlik, boya ve harç kalıntıları veya teslim öncesi hazırlık gibi farklı ihtiyaçlara sahip olabilir.
Bu nedenle service page:
bir hizmet adı değil, bir kullanıcı görevinin owner’ı
olarak düşünülmelidir.

Hayır.
İşletmenin hizmet listesinde bir isim bulunması o hizmetin otomatik olarak ayrı SEO landing page hak ettiği anlamına gelmez.
Yeni hizmet URL’si için şu sorular sorulmalıdır:
Bu sinyaller yeterince güçlü değilse yeni URL açmak yerine mevcut ana hizmet page içinde alt bölüm kullanmak daha temiz olabilir.
Hizmet listesi ≠ URL listesi.
Site genelinde hizmet, alt hizmet ve lokasyon ownership kararlarını Temizlik Şirketi SEO Site Mimarisi rehberinde ayrıca ele alıyoruz.
Örneğin:
Dış cephe temizliği
ana hizmet olsun.
Bunun altında:
gibi alt hizmetler bulunabilir.
Bu alt kapsamların her birini otomatik olarak yeni URL’ye çevirmek gerekmez.
Önce relationship belirlenmelidir:
DIŞ CEPHE TEMİZLİĞİ
│
├── Cam cephe
├── Kompozit cephe
└── Endüstriyel cephe
Eğer alt hizmet:
oluşturmuyorsa ana service page içinde kalabilir.
Ancak gerçek bağımsız service intent oluşuyorsa child owner değerlendirilebilir.
Parent-child relationship kurmak, her child için URL açmak anlamına gelmez.
Kullanıcı hizmet page’e geldiğinde ilk birkaç saniyede şu soruların cevabını anlayabilmelidir:
Bu nedenle hero alanında genellikle:
bulunabilir.
Örneğin:
Depo ve Antrepo Temizliği
başlığı altında:
“Depo, antrepo ve lojistik alanlarında zemin, raf çevresi ve operasyon alanlarının profesyonel ekip ve ekipmanla temizlenmesi.”
gibi hizmeti gerçekten tarif eden kısa bir giriş kullanılabilir.
“Kaliteli, güvenilir, profesyonel ve müşteri memnuniyeti odaklı hizmet” gibi bütün sektörlerin aynı anda kullanabildiği sıfat yığını ise kullanıcının hizmeti anlamasına pek yardımcı olmaz.
Service page primarily ticari hizmet aramalarının owner’ı olmalıdır.
Örneğin:
| Query | Muhtemel Intent | Owner |
|---|---|---|
| Depo temizliği | Commercial | Depo temizliği hizmet page |
| Profesyonel depo temizliği | Commercial | Depo temizliği hizmet page |
| Depo temizliği nasıl yapılır? | Informational | Supporting content |
| Depo temizliği kaç saat sürer? | Informational / commercial investigation | Service veya support, SERP’e göre |
| Başakşehir depo temizliği | Local commercial | Service veya location owner, demand’e göre |
Hizmet page’i bütün informational sorguları kendine toplamaya çalışmamalıdır.
Aksi durumda sayfa hizmet landing page’den 6.000 kelimelik ansiklopediye dönüşebilir.
Commercial owner gerekli bilgiyi cevaplar; bütün konu evrenini tek URL’de sahiplenmeye çalışmaz.
H1 hizmeti açık biçimde tanımlamalıdır.
Örneğin:
Depo ve Antrepo Temizliği
veya:
İnşaat Sonrası Temizlik Hizmeti
gibi başlıklar kullanıcının sayfanın ne hakkında olduğunu doğrudan anlamasını sağlar.
Buna karşılık:
İstanbul’un En İyi Profesyonel Uygun Fiyatlı Depo Temizliği Firması
gibi H1’ler hizmet açıklamak yerine keyword ve superiority claim koleksiyonuna dönüşür.
H1’in görevi olabildiğince çok query varyasyonu taşımak değildir.
H1 primary service entity’yi açıklamalıdır.
Temizlik hizmetlerinde kullanıcı için en önemli sorulardan biri:
“Bu hizmet tam olarak neyi kapsıyor?”
sorusudur.
Bu nedenle hizmet page yalnız genel tanım vermemelidir.
Gerçek operasyona göre:
gibi bilgiler verilebilir.
Örneğin depo temizliği page’inde:
gerçek hizmet kapsamına göre açıklanabilir.
Information gain, rakibin paragrafını daha uzun yazmak değil; kullanıcının hizmeti satın almadan önce gerçekten bilmesi gereken detayları sunmaktır.
Evet, gerçek süreç kullanıcı kararına yardımcı oluyorsa.
Örneğin:
gibi bir workflow kullanıcıya ne beklemesi gerektiğini anlatabilir.
Ancak her temizlik hizmetinde aynı:
Analiz → Planlama → Uygulama → Mutlu Müşteri
şablonunu kullanmak yine gerçek operasyon bilgisini ortadan kaldırır.
Service page üzerindeki süreç, o hizmetin gerçek çalışma şeklinden çıkmalıdır.
Hizmete göre evet.
Örneğin:
kullanıcı açısından operasyon kapasitesini anlamaya yardımcı olabilir.
Ancak yalnız ekipman listesi doldurmak için her page’e aynı makineleri yazmak gerekmez.
Ekipman:
bu hizmet nasıl ve hangi koşullarda uygulanıyor?
sorusuna cevap verdiğinde değerlidir.
Temizlik hizmetlerinde fiyat çoğu zaman:
gibi değişkenlere bağlıdır.
Sabit fiyat verilemiyorsa kullanıcıya fiyatın hangi faktörlerle belirlendiği açıklanabilir.
Örneğin:
“Depo temizliği fiyatı alanın metrekaresi, raf ve zemin yapısı, mevcut kirlilik ve operasyon kapsamına göre belirlenir.”
gibi açıklama gerçek karar bilgisi sunar.
“En ucuz fiyat garantisi” gibi doğrulanamayan satış dili yerine teklif sisteminin nasıl çalıştığı anlatılmalıdır.
Bir service page işletmenin gerçekten hizmet verdiği coğrafyayı açıklayabilir.
Ancak bütün ilçe isimlerini paragraf içine doldurmak gerekmez.
Örneğin:
“İstanbul Avrupa Yakası’nda ve seçilmiş çevre bölgelerde depo temizliği hizmeti sunuyoruz.”
gibi gerçek operasyon kapsamı anlatılabilir.
Ardından gerçek location pages bulunuyorsa uygun şekilde bağlantı kurulabilir.
Örnek relationship:
DEPO TEMİZLİĞİ
│
├── Başakşehir
├── Bağcılar
└── Küçükçekmece
Ancak bu ilişki:
/basaksehir-depo-temizligi/
/bagcilar-depo-temizligi/
/kucukcekmece-depo-temizligi/
şeklinde üç yeni page gerektiği anlamına gelmez.
Temizlik şirketlerinde Google Business Profile ve hizmet alanı ilişkisini Temizlik Firmaları İçin Yerel SEO rehberinde ele alıyoruz.
Service page:
Ne sunuyoruz?
sorusunun owner’ıdır.
Location page:
Nerede hizmet veriyoruz?
sorusunun owner’ı olabilir.
| Page | Ana Görev |
|---|---|
| Depo temizliği | Hizmet intent |
| Başakşehir temizlik | Lokasyon intent |
| Başakşehir depo temizliği | Demand ve SERP’e göre service/location relationship |
Service ve location entity’lerini aynı şey gibi modellemek URL çoğalmasına yol açar.
Örneğin:
İnşaat sonrası temizlik hizmeti
commercial intent taşıyabilir.
Buna karşılık:
daha informational veya commercial-investigation intent taşıyabilir.
Supporting content’in görevi ana service page’in rakibi olmak değildir.
Model:
SUPPORTING CONTENT
↓
SERVICE OWNER
↓
CONTACT / QUOTE
Bilgilendirici article gerektiğinde kullanıcıyı ilgili commercial service page’e taşır.

Anchor kullanıcının ulaşacağı page’in görevini açık biçimde anlatmalıdır.
Örneğin:
“Profesyonel uygulama için inşaat sonrası temizlik hizmetimizi inceleyebilirsiniz.”
gibi contextual link doğal olabilir.
Buna karşılık her blog yazısının sonuna:
şeklinde bütün services’ın linklerini yığmak güçlü contextual linking değildir.
Internal link relationship’i konu yakınlığından çıkmalıdır.
Evet, supporting content kullanıcının service decision’ını gerçekten destekliyorsa.
Örneğin depo temizliği hizmet page:
gibi ilgili rehberlere bağlantı verebilir.
Böylece commercial page kullanıcıya gerekli derinliği sunarken bütün informational coverage’ı kendi gövdesine doldurmak zorunda kalmaz.
Gerçek ilişki varsa evet.
Örneğin:
İnşaat sonrası temizlik
sonrasında:
ile gerçek user journey relationship bulunabilir.
Ancak bütün services’ı bütün pages’e site-wide biçimde bağlamak gerekmez.
İlgili hizmet linklerinin amacı:
“Google’a daha fazla anchor gönderelim”
değil, kullanıcının gerçek next step’ini göstermektir.
Teknik olarak URL 200 dönebilir, sitemap’te bulunabilir ve hatta indekslenmiş olabilir.
Ancak site navigation içinde hiçbir gerçek internal link almıyorsa architecture açısından zayıf kalabilir.
Ana hizmet owners uygun şekilde:
üzerinden crawlable links almalıdır.
Sitemap orphan page tedavisi değildir.
Temizlik sektöründe kullanıcı hizmetin gerçekten uygulanabildiğine dair kanıt görmek isteyebilir.
Gerçek kanıtlar:
olabilir.
Ancak her service page’e:
“10.000 mutlu müşteri, %100 memnuniyet, sektör lideri”
gibi kaynağı belli olmayan rakam ve iddialar eklemek güven sinyali değildir.
Proof doğrulanabilir olduğunda değerlidir.
Temizlik sektöründeki gerçek saha yaklaşımını Tek Temizlik SEO vaka çalışmasında inceleyebilirsiniz.
Stock temizlikçi görselleri sayfanın gerçekten verilen hizmeti anlatmakta genellikle sınırlı değer sunar.
Mümkün olduğunda:
görselleri kullanılabilir.
Alt text de görselin ne gösterdiğini açık biçimde anlatmalıdır.
Örneğin:
“İnşaat sonrası temizlik sırasında zemindeki harç kalıntılarının temizlenmesi”
gibi açıklayıcı alt text,
“İstanbul en iyi ucuz temizlik şirketi profesyonel temizlik”
gibi keyword torbasından daha faydalıdır.
Kullanıcıların gerçekten satın alma kararı öncesinde sorduğu sorular varsa SSS bölümü yararlı olabilir.
Örneğin:
işletmenin gerçek operasyonuna göre cevaplanabilir.
FAQ alanının amacı long-tail keyword sayısını artırmak değildir.
Gerçek pre-sale objections ve questions cevaplanmalıdır.
Service page kullanıcının ticari niyet taşıdığı bir landing page’dir.
Bu nedenle iletişim aksiyonunu sayfanın yalnız son satırında saklamak gereksizdir.
Uygun yerlerde:
aksiyonları gösterilebilir.
Ancak her paragrafın altına dev bir “HEMEN ARA” butonu koymak da kullanıcı deneyimini satış panayırına çevirebilir.
CTA’lar kullanıcı yolculuğunun doğal karar noktalarında bulunmalıdır.
Service page yalnız impressions ve clicks üzerinden değerlendirilmemelidir.
Ölçülebilecek aksiyonlar:
olabilir.
Mümkün olduğunda event’lere page veya service context eklenebilir.
event = generate_lead
service_context = depo_temizligi
page_type = service
Böylece yalnız:
“SEO’dan 20 form geldi.”
değil:
“Hangi hizmet page gerçek talep üretti?”
sorusu da cevaplanabilir.
Title temel service intent’i açık biçimde taşımalıdır.
Örneğin:
Depo ve Antrepo Temizliği | ABC Temizlik
gibi bir title kullanılabilir.
Lokasyon gerçek primary intent’in parçasıysa title’a doğal biçimde dahil edilebilir.
Ancak:
Depo Temizliği İstanbul Avrupa Yakası Başakşehir Bağcılar Ucuz Profesyonel En İyi Firma
gibi title yapıları arama niyetini açıklamak yerine bütün keyword listesine aynı anda saldırır.
Meta description kullanıcıya page’de ne bulacağını ve hizmetin temel değerini açıklayabilir.
Örneğin:
“Depo ve antrepolarda zemin, raf çevresi ve operasyon alanları için profesyonel temizlik hizmeti. Kapsam ve teklif için iletişime geçin.”
gibi description ticari görevi açıklar.
Meta description keyword frekans alanı değildir.
Bir hizmet için canonical owner belirlenmişse aynı service intent’i temsil eden alternatif URL’lerin kontrol edilmesi gerekir.
Örneğin:
/depo-temizligi//depo-temizleme//profesyonel-depo-temizligi/aynı commercial intent için oluşturulmuşsa üç ayrı owner tutmak mantıklı olmayabilir.
Doğru URL korunur, diğerleri mevcut durumuna göre:
ile yönetilebilir.
Canonical URL ownership kararından sonra gelir.
Uygun structured data mevcut sayfa ve işletme bilgisini açıklayabilir.
Ancak schema:
Önce gerçek işletme ve doğru content architecture kurulmalıdır.
İyi bir service page şu sorulara açık cevap verir:
Bu sorular cevaplanıyorsa page’in değeri yalnız kelime sayısından gelmez.
H1
↓
Hizmetin kısa ve açık tanımı
↓
CTA
↓
Hizmet kapsamı
↓
Kimler / hangi alanlar için?
↓
Uygulama süreci
↓
Gerekliyse ekipman ve operasyon
↓
İlgili gerçek lokasyonlar
↓
Gerçek proof
↓
İlgili hizmetler
↓
Supporting content
↓
FAQ
↓
Teklif / iletişim CTA
Bu şablon değişmez tasarım kuralı değildir.
Hizmetin kullanıcı ihtiyacına ve işletmenin gerçek operasyonuna göre bölümler değişebilir.
Yeni hizmet adı var.
↓
İşletme bunu gerçekten ayrı hizmet olarak sunuyor mu?
Hayır → URL açma.
Evet ↓
Ayrı search demand var mı?
Hayır → ana hizmet içinde ele al.
Evet ↓
Ayrı search intent var mı?
Hayır → existing owner’ı güçlendir.
Evet ↓
SERP bağımsız service pages gösteriyor mu?
Hayır → yeni URL kararını yeniden değerlendir.
Evet ↓
Sayfaya özgün ve gerçek hizmet bilgisi üretilebilir mi?
Hayır → thin service page açma.
Evet ↓
Başka URL aynı intent’in owner’ı mı?
Evet → ownership’i konsolide et.
Hayır ↓
Yeni canonical service owner değerlendir.
Bir temizlik şirketinin on hizmeti olabilir.
Bunun sonucu otomatik olarak yüzlerce:
hizmet × alt hizmet × ilçe
URL’si üretmek değildir.
Doğru sistem:
ana hizmet → gerekli alt hizmet → gerçek location relationship → supporting content → internal linking → ölçülebilir teklif talebi
üzerinden kurulur.
Her service page’in site içinde açık bir görevi ve tek primary ownership alanı olmalıdır.
DigitalPlus temizlik şirketi SEO çalışmalarında önce hangi hizmetlerin gerçekten bağımsız commercial owner hak ettiğini belirler, ardından içerik, local ve internal-link relationships’i bu yapı etrafında kurar.
Temizlik sitenizde service ownership ve URL mimarisini geliştirmek için Temizlik Şirketi SEO hizmetimizi inceleyin.
Mevcut hizmet sayfalarının teknik ve mimari sorunlarını URL seviyesinde incelemek için SEO Audit talep edebilirsiniz.
Hayır. Hizmet gerçekten ayrı kullanıcı ihtiyacı ve search intent oluşturuyorsa bağımsız URL değerlendirilebilir. Küçük hizmet varyasyonlarını otomatik olarak yeni landing page’e dönüştürmek gerekmez.
Ana hizmet daha geniş commercial ihtiyacın owner’ıdır. Alt hizmet ise ana hizmetin belirli kapsamını temsil eder. Alt hizmet yalnız bağımsız intent ve yeterli sayfa değeri varsa ayrı URL olabilir.
Sabit bir kelime sayısı yoktur. Sayfa kullanıcının hizmeti değerlendirmek için ihtiyaç duyduğu kapsam, süreç, operasyon, location, proof ve iletişim bilgilerini yeterli biçimde sunmalıdır.
Gerçek hizmet alanını açıklamak için doğal biçimde kullanılabilir. Ancak bütün ilçeleri keyword listesi gibi sayfaya doldurmak veya her ilçe için duplicate service page açmak doğru yaklaşım değildir.
Hayır. Service page hangi hizmetin sunulduğunu, location page ise hizmetin nerede sunulduğunu sahiplenebilir. İki entity arasında ilişki olması aynı URL görevi taşıdıkları anlamına gelmez.
Kullanıcının satın alma kararını destekleyen gerçekten ilgili bilgilendirici içerikler varsa bağlantı verilebilir. Her blogu veya bütün hizmetleri birbirine bağlamak gerekmez.
Bilgilendirici içerik commercial service ile gerçek konu ilişkisi taşıyorsa contextual link verilmesi doğal bir support → commercial relationship oluşturur.
Sabit fiyat mümkün değilse fiyatı belirleyen alan büyüklüğü, hizmet kapsamı, ekipman, personel veya kirlilik seviyesi gibi faktörler açıklanabilir.
Gerçek operasyon, ekipman veya uygulama fotoğrafları kullanıcının hizmeti ve işletmenin çalışma kapasitesini değerlendirmesine yardımcı olabilir. Stock görseller gerçek saha kanıtının yerine geçmez.
Hayır. Sitemap URL keşfine yardımcı olur ancak önemli service pages site navigation, parent pages, related services, locations veya supporting content üzerinden crawlable internal links de almalıdır.
Önce hangi URL’nin primary commercial owner olduğu belirlenmelidir. Aynı intent’i taşıyan gereksiz alternatif URL’ler mevcut trafik, backlink ve teknik durumlarına göre birleştirilebilir, yönlendirilebilir veya canonical yapısı düzenlenebilir.
İş modeline göre telefon, WhatsApp, teklif formu, form başlangıcı, başarılı lead ve keşif talebi gibi aksiyonlar ölçülebilir. Mümkünse lead’e hangi hizmet page’in kaynak olduğu bilgisi de eklenmelidir.
Sitenizin mevcut durumunu çıkaralım; önceliklendirilmiş bir yol haritasıyla dönelim.
Ücretsiz SEO Audit Talep Et