Kullanıcı Adı Değişince İç Linkleri Otomatik Güncelleme: İndekslenen Sayfalarda Anchor Eşleştirme ve 301 ile Uyum

Chat sitelerinde kullanıcı adı değişimi sadece profil sayfasını etkilemez; kullanıcı adı/slug bazlı iç linklerin anchor metni veya hedefi, indekslenen içeriklerde hızla tutarsız hale gelir. Bu yüzden “URL’yi 301 ile taşıdım, bitti” yaklaşımı çoğu senaryoda gerçekten güvenli değildir. Özellikle Chat sitesinde kullanıcı adı değişimi sonrası indekslenen sayfalarda iç link güncellemesi nasıl otomatik yapılır (anchor eşleştirme) probleminde, anchor düzeyi eşleştirmenin doğru tasarlanması gerekir.

Bu rehberde, kullanıcı adı değiştiğinde indekslenen sayfalarda iç linkleri otomatik güncellemek için anchor eşleştirme (mapping), render-time üretim, background rewriter, SSR+cache invalidation ve doğrulama ölçümleri gibi teknik parçaları bir araya getiriyoruz. Hedef; sıralama kaybı, bozuk iç link (404) ve “yanlış eşleştirme/partial match” gibi riskleri mümkün olan en düşük seviyeye indirmek.

Sorun çerçevesi: Kullanıcı adı değişimi sonrası indekslenen sayfalarda iç link niye bozulur?

Kullanıcı adını değiştiren bir kullanıcı genelde sadece kendi profil URL’sini güncellemez; diğer sayfalardaki bağlantı hedeflerini de dolaylı olarak etkiler. Chat platformlarında mesajlar; “@kullanıcıadı” şeklinde anchor metinle, ya da slug/userId içeren linklerle indekslenebilir.

İndekslenen sayfalarda iç link bozulmasının temel nedeni, link üretim mantığının geçmişte farklı alanlar üzerinden çalışmasıdır. Mesela mesaj çıktısı “/users/ahmetk” gibi bir slug’a bağlı şekilde saklanmışsa, kullanıcı adı “Ahmet K” ya da “ahmetk2” oldu diye anchor metin/target eşleşmesi kendiliğinden güncellenmez.

Bir diğer neden de template, cache veya CDN kaynaklı gecikmelerdir. Kullanıcı adı değişse bile eski HTML şablonları hâlâ stale durumda kalabilir; bu da Google’ın gördüğü sürüm ile sizin kullanıcı arayüzünüz arasında belirgin bir tutarsızlık yaratır.

Kapsam ayrımı: Anchor metin vs hedef URL (slug/userId) ve neden ikisini ayrı ele almak gerekir?

Anchor düzeyinde iki ayrı “doğruluk” konusu var: anchor metni ve hedef URL. Anchor metni, mesaj içinde görünen “@AhmetK.” ifadesi gibi okunur bir metindir. Hedef URL ise gerçekte hangi profil sayfasına gittiğinizi belirleyen slug/userId temelli bir adrestir.

İkisini ayrı ele almamak, özellikle normalizasyon gerektiği durumlarda hataya davetiye çıkarır. Örneğin “AhmetK.”, “ahmetk” ve “Ahmet K” aynı kullanıcıya işaret etse bile anchor metni değişmezse kullanıcı deneyimi ve snippet tutarlılığı etkilenebilir. Hedef URL ise aynı kullanıcıya gitmiyorsa SEO açısından daha kritiktir; çünkü iç link bozulur, crawl ve internal PageRank akışı zarar görebilir.

Ön koşullar: Stabil primary key (userId) kullanımı, slug/username alanlarının rolü

Anchor eşleştirme otomasyonunun bel kemiği stabil primary key kullanımıdır. Kullanıcı adı/slug değişebilir; fakat userId değişmemelidir. Bu sayede hangi kullanıcıya bağlandığımızı güvenle sabitleyebiliriz.

Slug/username alanlarının rolünü şöyle ayırın: Slug/username sunum ve URL tasarımı için değişebilir bir katmandır; anchor metni ise metin görünümü sağlar. Gerçek eşleştirme ise userId üzerinden yapılmalıdır. Eğer mesajlerde link üretiminde doğrudan userId kullanmıyorsanız, mapping kurmadan otomatik güncelleme yapmak ciddi risk taşır.

Mimari tasarım: Anchor eşleştirme mapping tablosu + event akışı (username_changed)

Kullanıcı adı değiştiğinde sadece 301 redirect güncellemek yerine “anchor hedefini” de güncelleyecek bir mapping tablosu kurmalısınız. Buradaki fikir şu: eski slug/username → userId → güncel slug/username zincirini kalıcı biçimde saklamak.

Akış genellikle şu şekilde ilerler: Kullanıcı adı değişimi gerçekleşir, sistem bir username_changed domain event üretir. Bu event bir queue’ya düşer; worker’lar mapping kaydını günceller ve indekslenen sayfalara yansıtma stratejisine göre batch süreçler başlatır.

legacyUsername/legacySlug	userId	currentUsername/currentSlug	from_event_ts
AhmetK	102938	AhmetK_ (ör. ahmetk)	2026-03-10T12:30:00Z
ahmetk	102938	ahmet-k	2026-04-01T09:05:00Z

Mapping stratejileri: userId->currentSlug + legacySlug->userId + anchor-text normalization

Mapping tasarımında iki yönlü düşünün. Birincisi: userId’den mevcut slug’a gidiş (userId → currentSlug). İkincisi: geçmiş slug/username’den userId’ye dönüş (legacySlug → userId). İkisini ayrı yönlerde optimize etmek, hem render-time üretimde hem de background güncellemelerde performansı korur.

Anchor-text normalization (metin standardizasyonu) kritik bir katmandır. Mesela mesaj içinde görünen “@AhmetK.” ile eşleştirme için nokta, büyük-küçük harf, boşluk karakteri ve bazı özel işaretleri tolere eden bir normalize fonksiyonu kurun. Bu fonksiyonun çıktısını mapping tablosunda anahtar gibi saklamak, partial match riskini azaltır.

Otomasyon mekanizmaları: (a) render-time link üretimi (b) background rewriter (c) sitemap/kanonik uyumu

Üç farklı otomasyon katmanı tasarlamak, “tek noktaya bağımlılık” riskini azaltır. Birincisi render-time link üretimi: Mesaj HTML’i her istek geldiğinde anchor’ları mapping üzerinden yeniden üretebilir. İndekslenen sayfalarda güncel HTML görmek için SSR kullanıyorsanız bu yaklaşım özellikle etkilidir.

İkincisi background rewriter: İndekslenen sayfalara ait saklanan içerik (ör. cached render, pre-rendered HTML, static snapshot) güncellenir. Bu işlem, kullanıcı adı değişimi event’inden sonra queue worker ile batch yapılır.

Üçüncüsü sitemap/kanonik uyumu: İndekslenmiş içeriklerin canonical mantığı, yeni hedef URL’leriyle uyumlu olmalıdır. Kanonik, sadece sayfa URL’si için değil, mesaj sayfasında bulunan profil bağlantılarında yönlendirme doğruluğu için de “tutarlılık sinyali” sağlar. Bu yüzden canonical stratejisi ile iç link eşleştirmesini birlikte ele almak gerekir.

İndekslenen sayfalarda güncelleme yöntemleri: SSR template güncellemesi + cache invalidation + stale page revalidation

İndekslenen sayfalarda değişiklik görmek istiyorsanız iki hedefiniz olmalı: (1) kullanıcı arayüzünüzün yeni linkleri göstermesi (2) arama motorlarının göreceği HTML’in güncellenmesi. Sadece client-side script ile anchor güncellemek, crawl sırasında yeni HTML yakalanmazsa tek başına yeterli olmayabilir.

SSR tarafında mesaj/yorum template’i, anchor hedeflerini mapping üzerinden üretmelidir. Ardından cache invalidation uygulanır: profil sayfası değişince ilgili mesaj sayfalarının cache anahtarlarını tetikleyecek bir “dependency graph” veya en azından “kullanıcıya bağlı sayfalar” listesi gerekir.

Son olarak “stale page revalidation” yaklaşımıyla, eski HTML’in raf ömrü dolunca otomatik re-render yapılması sağlanır. Böylece Google’ın gördüğü içerik zaman içinde güncellenir; aynı zamanda tüm içerik anında yeniden yazılmaz.

Anchor eşleştirme algoritması: exact match, normalized match, sınırlandırma kuralları (partial match engeli)

Anchor eşleştirmenin en büyük riski partial match hatalarıdır. Örneğin “ali” anchor’ı, “ali.b” kullanıcı adının parçasını da yakalayabilir ve yanlış kullanıcıya bağlanır. Bu yüzden eşleştirmeyi “içeriyor mu” gibi bir mantıkla kurmayın.

Önerilen yöntem: Önce exact match deneyin. Exact match başarısız olursa, normalize edilmiş anchor metnini normalize edilmiş legacyUsername/legacySlug anahtarlarıyla karşılaştırın. Son adım olarak eşleştirmeyi doğrulamak için bir sınırlandırma kuralı ekleyin (ör. boundary karakterleri, token bazlı match, nokta/emoji sonrası ayrıştırma).

• Exact match: Anchor metnini olduğu gibi (veya trim/HTML decode sonrası) legacy anahtarlarla birebir karşılaştırın.
• Normalized match: “AhmetK.” → “ahmetk” normalizasyonu sonrası eşleştirin.
• Partial match engeli: “startsWith/contains” kullanmayın; yalnızca tam token eşleşmesine izin verin.
• Fallback ve güvenlik: Eşleşme yoksa userId tahmin etmeyin; ya eski linki bırakın ya da noindex/redirect stratejisiyle güvenli bir davranış belirleyin.

301 ile uyum: URL taşınırken iç linkleri güncellemenin sıralama/kayıp etkisi

301 redirect, yanlış URL’lerin doğru hedefe taşınmasında kritiktir; ancak iç linklerin anchor düzeyinde güncellenmemesi yine de kayıp yaratabilir. Neden? Çünkü Google’ın internal link sinyali, hangi sayfadan hangi hedefe gittiğiyle ilgilidir; yanlış veya gecikmeli hedefler crawl bütçesini artırır ve redirect chain’i uzatır.

Kullanıcı adı değişiminden sonra “profile eski slug → yeni slug 301” yapmanız gerekir. Fakat asıl etki, mesaj sayfası içinde yer alan linklerin hedef URL’sini de güncelleyince ortaya çıkar. Böylece redirect chain azalır, crawl daha direkt ilerler ve indekslenen sayfaların iç tutarlılığı korunur.

Edge-case’ler: kullanıcı ismi çakışmaları, geri dönüşlü ad değişimleri, özel karakter/emoji, büyük-küçük harf

Kullanıcı ismi çakışmaları en zor senaryolardan biridir. Örneğin eski bir slug boşaldıktan sonra başka biri alabilir. Bu durumda legacySlug → userId mapping’i zaman damgasıyla saklamalı ve eşleştirmeyi “bu mesajın üretim zamanı ile mapping aralığı” üzerinden doğrulamalısınız.

Geri dönüşlü ad değişimleri de düşünülmeli. Kullanıcı adı A’dan B’ye, sonra tekrar A’ya dönüyorsa mapping tablosu versiyonlanmalıdır. Aynı legacy anahtar farklı dönemlerde farklı userId’lerle eşleşmiş olabilir; bu yüzden mapping kaydında valid_from / valid_to alanları veya event sırası bilgisi şart.

Özel karakter/emoji ve büyük-küçük harf farklılıkları için normalize fonksiyonunu deterministik yapın. Mesela “AhmetK.” nokta sonrası normalize olurken “AhmetK🙂” veya “Ahmet-K” gibi varyasyonlarda hangi kuralların uygulanacağını netleştirin.

Gözlemlenebilirlik: log’lar, hata ayıklama, metrikler (404 iç link, redirect chain, index değişimi)

Anchor eşleştirme otomasyonunda ölçmeden ilerlemek risklidir. En azından şu logları tutun: mapping lookup sonucu (exact/normalized/fallback), seçilen hedef (userId), anchor metni orijinal ve normalize hali ve üretim zamanı.

Metrikler tarafında 404 iç link oranı, redirect chain uzunluğu, kullanıcı adı değişiminden sonra indekslenen sayfa sayısındaki değişim gibi KPI’lar izlenmelidir. Ayrıca “mapping hit rate” ve “eşleşme başarısız” oranı, algoritmanın doğruluğunu anlamanızı sağlar.

Örnek teknik akış: username_changed event’i sonrası queue worker ile batch güncelleme

Event temelli bir mimari kurarak yükü yayabilirsiniz. Aşağıdaki akış örnek olup pratikte “bağlı sayfalar listesi” veya “kullanıcıya bağlı mesajlar” üzerinden batch çalışır.

1. Kullanıcı panelinden kullanıcı adı güncellenir ve “username_changed” domain event’i publish edilir.
2. Event içinde userId, legacyUsername, legacySlug, currentUsername, currentSlug ve valid_from bilgisi bulunur.
3. Queue worker mapping tablosunu günceller (legacy → userId → currentSlug).
4. Worker, bu kullanıcıya referans veren mesaj sayfalarını bulur ve stale snapshot/SSR cache’lerini invalid eder.
5. Arka planda rewriter, indekslenmiş içerik HTML’lerini anchor hedefleriyle yeniden yazar.
6. Son adımda doğrulama job’u, belirli örnek sayfalarda linklerin güncellendiğini kontrol eder.

Örnek kod/pseudo-code: link üretiminde userId bazlı hedefleme ve fallback kuralları

Aşağıdaki pseudo-code, render-time üretimde nasıl güvenli bir şekilde hedefleme yapılacağını gösterir. Buradaki ana fikir: userId olmadan “tahmin ederek” link üretmeyin.

function renderMentionLink(anchorText, context){
  normalized = normalizeAnchor(anchorText) // "AhmetK." -> "ahmetk"
  // 1) exact/normalized mapping lookup
  mapping = lookupMentionMapping(normalized, context.productionTime)

  if(mapping && mapping.userId){
     targetUserId = mapping.userId
     currentSlug = getCurrentSlug(targetUserId) // userId -> currentSlug
     return buildUrl("/users/" + currentSlug)  // anchor hedefi güncel
  }

  // 2) fallback: mapping yoksa güvenli davranış
  // a) eski linki tut (redirect zinciri kalsın) veya
  // b) mention'ı düz metne çevir (link sinyali kaybolur ama yanlışlık azalır)
  return buildSafeFallbackUrl(anchorText, context)
}

Örnek mapping tablosu: legacyUsername/legacySlug -> userId -> currentUsername/currentSlug

Bu mapping tablosu, hem anchor düzeyi üretimde hem de background rewriter’da kullanılabilir. Örnekle netleştirelim: Legacy anchor “@AhmetK” bir mesajda geçiyor olabilir. Biz o anki üretim zamanına göre legacyUsername’ı normalize eder, userId’yi bulur ve mevcut slug’a döneriz.

Örnekteki gibi legacyUsername/legacySlug anahtarları, userId üzerinden currentUsername/currentSlug’a eşlenir. Böylece mesajlar geçmişte farklı slug’a bağlansa bile, güncel profil URL’sine doğru yönlendirilir.

Örnek anchor düzeyi normalizasyon: “AhmetK.” vs “ahmetk” vs “Ahmet K”

Normalizasyonun başarısı, metin varyantlarında eşleştirme sağlayabilmesidir. Örneğin aynı kullanıcı için anchor varyantları şunlar olabilir: “AhmetK.”, “ahmetk” ve “Ahmet K”. Normalize fonksiyonunuzun şu kuralları izlemesi beklenir: nokta/whitespace temizleme, Unicode case folding, bazı ayraçları (örn. “-” ve boşluk) eşdeğer sayma.

Sonuç olarak “AhmetK.” → “ahmetk”, “Ahmet K” → “ahmetk” olur. Böylece exact match başarısız olsa bile normalized match üzerinden doğru userId bulunur.

Örnek yanlış eşleştirme senaryosu: “ali” kullanıcısı ile “ali.b” eşleşmesi (partial match) nasıl engellenir?

Hayali bir yanlış senaryoyu düşünün: “ali” anchor metnini içeren bir mesaj vardır. Eğer eşleştirme stratejin “contains('ali')” gibi bir yaklaşım kullanırsa “ali.b” kullanıcısına da bağlanabilir. Bu, ciddi kalite sorunu doğurur; hem kullanıcı deneyimi hem de SEO tutarlılığı bozulur.

Engelleme için boundary bazlı tokenizasyon ve sadece tam eşleşme kuralını uygulayın. Ayrıca normalized anahtarları ayırmak için “.` gibi ayraçların” normalize edilme biçimini dikkatle belirleyin. Yani “ali.b” normalize edilip “ali.b” anahtarına düşmelidir; “ali” ile aynı anahtara dönüşmemelidir.

Yaygın hatalar

En sık görülen hata, anchor eşleştirmeyi tamamen 301 redirect’e bırakmaktır. Redirect zinciri çalışır; ancak iç linklerin HTML’de güncellenmemesi hem crawl bütçesini tüketir hem de “indekslenen sayfada eski anchor/target” tutarsızlığı kalır.

Bir diğer yaygın hata, partial match ile hızlı eşleştirme yapmaktır. “Başlangıçla eşleşir” veya “içeriyor” tarzı yaklaşımlar, özellikle kısa kullanıcı adlarında ciddi yanlış eşleştirmeler üretir. Bu nedenle exact + normalized match ve tam token sınırlandırması uygulanmalıdır.

Üçüncü hata olarak cache/SSR güncellemesini unutmaktır. Mapping doğru olabilir; fakat stale sayfalar revalidate edilmezse Google yeni linkleri görmez. Bu yüzden cache invalidation ve rewriter stratejisiyle birlikte çalışmayı kurgulayın.

Nasıl kontrol edilir? Adım adım doğrulama ve kontrol listesi

Otomasyon sonrası doğrulama, “doğru tasarımın doğru çalıştığını” kanıtlar. Aşağıdaki kontrol listesi pratik bir MVP doğrulamasıdır:

1. Mapping doğruluğunu test edin: Test kullanıcı üzerinde legacyUsername/legacySlug varyantlarını normalize edip eşleşmenin doğru userId’ye gittiğini loglarla doğrulayın.
2. İndekslenen sayfa örneklerini karşılaştırın: Kullanıcı adı değişiminden önce ve sonra ilgili mesaj sayfalarının SSR çıktısında profil linklerinin hedefinin güncellenip güncellenmediğini inceleyin.
3. HTTP/redirect zincirini ölçün: Googlebot benzeri isteklerde yeni sayfa linkleriyle oluşan redirect chain’i kontrol edin; 301 hâlâ var ama zincir kısalmalı.
4. Search Console sinyallerini izleyin: İç link bozulmaları 404/soft 404 ve index değişim sinyalleri olarak geri dönebilir.

Google Search Console ile tespit

Bu problemi anlamanın bir yolu da Google Search Console’da ortaya çıkan dolaylı sinyalleri okumaktır. Özellikle “keşfedilen ama dizine eklenmeyen” durumlar ve URL denetimi sonuçları, iç linklerin güncellenmediği senaryolarda crawl davranışının değiştiğini gösterebilir.

Ek olarak, site genelinde tarama hatası veya 404 artışı, yanlış hedeflenen iç linklerin dolaylı göstergesi olabilir. Eğer redirect chain belirgin şekilde uzuyorsa, bu da iç linklerin güncellenmediğini düşündürür.

Cache/SSR kaynaklı hangi durumlarda güncelleme görünmez?

Bazen mapping doğru olsa bile değişiklik gözükmez. Bunun tipik sebebi cache katmanlarının invalidation kurgusunun eksik olmasıdır. Mesaj sayfaları kullanıcı adı değişimiyle doğrudan “dependency” ilişkisine bağlanmadıysa stale sayfa üretimi güncellenmez.

Bir diğer sebep, render-time link üretiminin yalnızca client-side çalışmasıdır. Botlar veya SSR öncesi HTML içerik eski kalıyorsa, rewriter veya SSR template güncellemesi şart olur. Ayrıca CDN üzerinden servis edilen pre-rendered snapshot’lar “revalidate” edilmediği sürece güncel HTML görünmez.

Uygulama planı: MVP (minimum çalışan kurulum) → kademeli genişletme

Başlangıçta hedefiniz “uçtan uca doğru çalışan” bir pioner kurmak olmalı; tüm ekosistemi bir anda yeniden yazmaya kalkmamalısınız. MVP’de önce en sık kullanılan mention/link türleriyle başlayın.

Önerilen yol haritası: İlk sprintte userId tabanlı mapping + exact/normalized eşleştirme + render-time link üretimini hayata geçirin. İkinci sprintte background rewriter ile indekslenmiş sayfalarda stale snapshot güncellemesini ekleyin. Son olarak metrik panelleri, hata geri bildirimi ve mapping versiyonlama kurallarını olgunlaştırın.

Sık yapılan hatalar ve SSS

İç linkleri güncellemezsem 301 her şeyi çözer mi? Çoğu durumda redirect çalışır; ancak iç link HTML’inde eski hedef kalırsa redirect zinciri artar, crawl bütçesi etkilenir ve indekslenen sürümde tutarsızlık kalır. Bu yüzden anchor hedefini de güncellemek daha doğru olur.

Anchor metni güncellenmezse sıralama etkiler mi? Doğrudan sıralamayı her zaman bozmayabilir; fakat snippet, kullanıcı güveni ve tutarlılık etkilenebilir. Ayrıca yanlış metinle eşleştirme riski varsa, anchor metni de normalize kurallarıyla güncellenmelidir.

mapping tablosu olmadan sadece 301 ile anchor otomasyonu yapılır mı? Pratikte hayır. 301 yalnızca URL taşır; mesaj içindeki anchor üretiminde hangi userId’nin kast edildiğini bilemez. Mapping olmadan güvenli eşleştirme yapmak zorlaşır ve yanlış yönlendirme olasılığı artar.

Kullanıcı adı tekrar tekrar değişirse mapping nasıl versiyonlanmalı? mapping kayıtlarını valid_from/valid_to veya event sırası bilgisiyle versiyonlayın. Böylece eski legacy slug’a ait mesajlar doğru dönemin userId’sine bağlanır.

Google Search Console’da hangi raporlar bu sorunu yakalar? URL denetimi, keşif/dizine eklenme davranışları ve tarama hatası sinyalleri izlenmelidir. Özellikle iç link hedefleri bozulunca 404/soft 404 artışı veya indeks davranışında değişim görülebilir.

İyileştirme fikirleri: tutarlılık, güvenlik ve performans dengesini kurun

Anchor eşleştirme otomasyonu yalnızca doğruluk değil performans ve güvenlik de gerektirir. Mapping lookup’u çok pahalı olursa render-time gecikir; bu yüzden normalize anahtarları için indeksleme ve uygun cache katmanı kullanın.

Ayrıca false positive (yanlış eşleşme) riskini düşürmek için eşleştirme kural setini daraltın: partial match engeli, boundary kontrolleri ve zaman damgası doğrulaması bu riski azaltır. Böylece kullanıcı adı değişimi sonrası indekslenen sayfalarda iç link tutarlılığı korunur.

Ek okuma: Benzer SEO problemleriyle bağ kurma

Kullanıcı adı değişimi sonrası iç link tutarlılığına yaklaşırken, chat platformlarında indeksleme mantığını etkileyen diğer konu başlıklarını da göz önünde bulundurun. Örneğin “Undo / Geri Al” gibi akışların HTTP geçişleri ve indeksleme modeline etkisini anlamak, güncelleme stratejinizi daha doğru tasarlamanıza yardımcı olur.

Ayrıca chat mesajlarında bağlantı önizleme (Open Graph) gibi davranışların noindex/robots kararlarıyla ilişkisi, indekslenen sayfalarda spam sinyallerini yönetmenin bir parçasıdır. Bu iki başlık, iç linklerin güncel tutulmasının neden kritik olduğunu destekleyen bağlam sağlar:

• Chat’te “Undo / Geri Al” Mesaj Akışı SEO’ya Zarar Verir mi? Doğru HTTP Geçişleri (302/410/404) ve İndeksleme Modeli
• Chat Mesajlarında Link Önizleme (Open Graph) İndekslenmeli mi? Noindex/Robots, İnce İçerik ve Spam Sinyali Karar Rehberi

MVP sprint checklist: hızlı başlangıç ve sürdürülebilirlik

Son olarak, ekiplerin 1-2 haftada çalışır bir kurulumla başlaması için kısa bir checklist bırakıyorum: userId tabanlı mapping tablosunu oluşturun, username_changed event’ini queue’ya bağlayın, render-time mention link üretimini mapping üzerinden yapın ve cache invalidation + stale revalidation planını netleştirin.

Bu şekilde sadece 301 ile “URL taşındı” seviyesinde kalmaz; anchor eşleştirme düzeyinde de indekslenen sayfalarda tutarlılığı güvenli biçimde sağlarsınız. Böylece platform büyüdükçe (daha fazla mesaj, daha fazla mention) otomasyonunuz kontrol edilebilir kalır.