Friends of the channel — a mixed bag worth following:

— @ThePressHook — Real digital PR plays that landed coverage in major outlets: angle…
— @FeedHeretic — Debunking LinkedIn 'guru' advice with what the feed actually rewards…
— @BidStack101 — Header bidding explained without the AdTech jargon: what Prebid,…
— @thechainleaks — The crypto-affiliate grapevine: which networks just changed payouts,…

One URL serving multiple languages: where hreflang stops working

Some estates serve different languages from a single URL via cookie or session content negotiation, no /en/ or /de/ path. Hreflang has nothing to annotate in that model, and that's the core tension.

Methodology: we examined four estates using dynamic per-session language on stable URLs, assessing how Google indexed them.

Findings:

— Hreflang requires distinct, crawlable URLs per language. With one URL serving many languages, there are no alternates to declare, so hreflang simply doesn't apply.

— Google indexed whatever language Googlebot received on crawl (typically the default), and the other languages were effectively invisible to search.

— Estates that wanted multilingual visibility had to break the single-URL model — introduce path or parameter-based language URLs — before hreflang became usable at all.

Nuance: this is a common SPA and headless-CMS pitfall. The architecture optimizes for app-like UX and accidentally forecloses international search visibility.

Caveat: dynamic rendering or per-language URLs with a language switcher both resolve it, but they're real engineering work, not a tag fix.

Limitation: four estates, all mid-sized; enterprise headless setups may have negotiation patterns we didn't observe.

Conclusion: hreflang presupposes one indexable URL per language. If your architecture serves languages from a single URL, the fix is architectural — distinct URLs first, annotations second. No tag rescues an un-crawlable language.

В Telegram Ads добавили Banner in Bot

В Telegram Ads появился формат Banner in Bot для показа рекламы внутри ботов с аудиторией от 1000 человек. Инструмент таргетируется не на площадки, а на пользователей — по интересам, номерам телефонов и подпискам. Пока доступны только текстовые креативы по ставкам Target Users. Новинка позволяет напрямую через стандартный кабинет охватывать целевую аудиторию прямо в их диалогах с ботами.

➡️ Читайте на сайте: https://aff.top/blog/v-telegram-ads-dobavili-banner-in-bot

🧠 Ещё больше инсайтов → в канале AFF.top

Anthropic готовит к запуску Claude Money

Anthropic анонсировала Claude Money — ИИ-сервис для управления личными финансами и автоматизации платежей. Инструмент позволяет подключать банковские карты для анализа расходов, планирования бюджета и проведения транзакций. Это переход от консультационных моделей к полноценным финансовым агентам. Внедрение технологии позволит пользователям делегировать нейросети рутинные задачи, включая оплату токенов и подписок на необходимые рабочие сервисы.

➡️ Читайте на сайте: https://aff.top/blog/anthropic-gotovit-k-zapusku-claude-money

🧠 Ещё больше инсайтов → в канале AFF.top

Meta ограничивает расходы на токены для сотрудников

Meta ввела внутренние лимиты на использование ИИ из-за резкого роста расходов: в 2026 году только на сотрудников заложены миллиарды долларов, а общий бюджет на ИИ-инфраструктуру оценивается в 130–145 млрд. Вывод простой: даже у Big Tech ИИ перестал быть бесплатной игрушкой и требует жёсткого контроля затрат.

➡️ Читайте на сайте: https://aff.top/blog/meta-ogranichivaet-raskhody-na-tokeny-dlia-sotrudnikov

🧠 Ещё больше инсайтов → в канале AFF.top

Subdomain vs subfolder for a new market: a controlled launch

Hypothesis: launching a new German market on a subfolder (/de/) would inherit domain authority faster than a subdomain (de.). Methodology: rare clean test — same company launched two adjacent markets simultaneously, German on a subfolder and Austrian-German on a subdomain, comparable content volume (~800 URLs each), 5 months. Imperfect because the markets differ in size, but the German-language overlap makes it informative.

What the data suggests:
— Time-to-first-page for head terms: subfolder hit page one for 40% of tracked terms by week 9; the subdomain reached the same milestone at week 16. Roughly a 7-week head start.
— By month 5 the gap narrowed: subfolder 58% page-one, subdomain 51%. Convergence, not a permanent moat.
— Crawl stats (log files) showed the subfolder crawled 2.3x more frequently in the first month — likely the authority-inheritance mechanism in action.

Caveats: Austria is a smaller market with thinner demand, which confounds the click numbers; we leaned on ranking milestones instead. Google has stated subdomains and subfolders are treated similarly — our data shows a transient startup advantage, not a steady-state one.

Conclusion: subfolder bought a ~7-week ramp advantage that largely closed by month 5. For impatient launches it matters; long-term, less so.

Separate localized URLs vs one URL with Vary/dynamic serving

A structural fork that predates hreflang: give each language its own URL, or serve different languages from one URL based on headers (dynamic serving with Vary: Accept-Language). hreflang only works with one of these.

The comparison:

— Separate URLs per locale (/en/, /de/) are what hreflang is built for. Each version is independently crawlable, indexable, linkable, and annotatable. This is Google's strongly preferred model.
— Dynamic serving from one URL with the Vary: Accept-Language header changes content based on the visitor's browser language. hreflang has nothing to annotate here, because there is one URL. Google must rely on the Vary header to know content varies — and Googlebot, crawling mostly as en-US, may only ever see the English version.

What the data suggests:

— Dynamic serving risks Google indexing only the version Googlebot's locale triggers, leaving other languages invisible in search.
— The Vary header is necessary if you go dynamic, but it is a weaker, more error-prone signal than distinct indexable URLs.

Our read: separate URLs nearly always, precisely so hreflang can do its job. Reserve dynamic serving for cases where distinct URLs are genuinely impossible. Caveat — large apps sometimes combine both (URL per locale plus header-based default routing); that hybrid keeps hreflang viable while improving first-visit UX.

Claude Cowork, Claude Design объединили в один Claude

➡️ Читайте на сайте: https://aff.top/blog/claude-cowork-claude-design-obedinili-v-odin-claude

🧠 Ещё больше инсайтов → в канале AFF.top

Microsoft планирует вставлять рекламу в игры

➡️ Читайте на сайте: https://aff.top/blog/microsoft-planiruet-vstavliat-reklamu-v-igry

🧠 Ещё больше инсайтов → в канале AFF.top

A reproducible audit for return-tag reciprocity

Return-tag errors ("no return tags" in GSC) are the most common hreflang failure we see, yet most teams hunt them page-by-page. A faster, falsifiable method:

— Crawl all URLs that emit hreflang and dump every annotation to a flat table: source URL, target URL, language-region value.
— Build the reverse table by swapping source and target.
— Left-join the two. Any source→target pair with no matching target→source row is a broken reciprocal link. This isolates the exact missing edge, not just the offending page.

We ran this on a 4,200-URL retail set: 31% of pairs failed reciprocity, but 80% of failures traced to just three templates where the alternate URL was built from a stale slug map. The data suggests breakage clusters at the template level, not randomly.

Caveats worth flagging. Reciprocity checks need the *rendered* HTML if annotations are injected client-side — a static crawl will under-report. And a self-referential tag must exist on every URL, or Google may distrust the whole cluster; include the self-pair in your join. We have not tested whether sitemap-delivered hreflang behaves identically here, though Google's docs imply it should.

The payoff: one join query turns a vague GSC warning into a precise list of edges to repair.

Collapsing 6 country pages into 1 language page: when fewer cells won

Hypothesis: maintaining six identical English country pages (en-us/gb/au/ca/ie/nz) was creating dilution and maintenance cost without ranking benefit, and a single en page would consolidate. Methodology: deliberately running against the usual 'more granularity' advice. One B2B SaaS where content was genuinely identical across all six and pricing was USD everywhere. We collapsed to one en page plus x-default. 12 weeks.

What the data suggests:
— Before, the six pages cannibalized each other: GSC showed 2–4 of them competing for the same query in 47% of tracked terms (classic same-language cannibalization).
— After consolidation to a single authoritative en page, that one page concentrated the signals: average position improved from 6.2 to 3.9 across the head set.
— Aggregate English clicks +18%, with the biggest gains in the smaller markets (NZ, IE) that had previously had weak standalone pages.

Caveats: this only worked because the content and pricing were truly identical. The moment you have regional pricing, shipping, or legal differences, consolidation destroys the localization you need. We'd consider this an anti-pattern for most retail. Also n=1.

Conclusion: granularity is a cost, not a virtue. If six pages say the same thing, six cells just cannibalize. The data suggests collapsing wins precisely when there's nothing to localize.

Return-tag reciprocity: the bidirectional requirement people break

Finding: "no return tags" is among the most reported hreflang errors in Search Console, and it stems from a property teams routinely under-appreciate — hreflang must be reciprocal.

The constraint. If page A declares page B as its fr alternate, page B must declare page A back. The confirmation has to be mutual or Google discards the link as unverified. One-directional annotations are treated as unreliable, on the reasonable assumption that a real cluster confirms itself from both ends.

Where reciprocity quietly breaks:

— Pages added to a cluster on one side but not back-referenced from the others
— A URL changes (slug edit, trailing slash) on one page but the alternates still point to the old address, so the return tag no longer matches
— Protocol or www/non-www mismatch makes A's reference to B and B's reference to A technically different URLs
— Mixed implementation: some pages declare via HTML, others via sitemap, and the sets drift apart

The fix: generate the cluster from a single source of truth so every member references every other member and itself, with byte-identical URLs.

Limitation we'll flag honestly: Search Console's return-tag report can lag, and a fixed cluster may show the warning for days after correction. We've seen warnings persist past a fix and clear on the next recrawl. Don't re-engineer a cluster that's already correct just because the report is stale — confirm against the live source first.

Choosing your x-default, deliberately

"Just point x-default at your homepage" is the advice we'd push back on. x-default is the fallback for users whose language-region isn't covered by any alternate — its job is to minimize harm for the unmatched visitor. Treating it as a default rather than a thoughtful choice is where teams leak relevance.

A decision procedure we use:

— Map your covered hreflang values, then ask: who is *not* covered? If you serve en-US, en-GB, de-DE but a user is in Brazil, which page serves them least badly?
— If one language is genuinely international (often a global English page with no country pricing), x-default points there.
— If your alternates are all region-locked storefronts, consider a neutral "choose your country" gateway as x-default instead — it avoids forcing a wrong-currency page on the unmatched user.
— Set x-default on *every* URL in the cluster, with the same target. Inconsistent x-default across a cluster is a return-tag failure in disguise.

A nuance often missed: x-default does not override geotargeting for *covered* users — it only fires when nothing else matches. So obsessing over it for your primary markets is wasted effort.

We don't have clean public data on x-default's CTR lift; the gain we can measure is reduced pogo-sticking from mismatched-language landings. Treat it as harm reduction, not a ranking lever.

A checklist for validating hreflang values before you ship

Malformed language-region codes fail silently — Google ignores the tag and tells you nothing. Before deploying any hreflang set, run each value through this gate:

— Language is ISO 639-1 (two-letter): en, de, pt. Not eng, not EN — case is forgiven but stay lowercase by convention.
— Region, if present, is ISO 3166-1 Alpha-2: pt-BR, pt-PT. The separator is a hyphen, never an underscore.
— Region without language is invalid. x-default excepted, you cannot target "Brazil, any language" — hreflang is language-first.
— Watch the traps: UK is en-GB (GB is the ISO code, UK is not). Latin America has no region code — use language-only es and let geotargeting split markets.
— Script subtags exist (zh-Hans, zh-Hant) and matter for Chinese; Google supports them, but test before relying on region+script combos.

We audited 60 sites and found ~18% had at least one invalid value, the underscore-instead-of-hyphen bug being most frequent. The data suggests a single regex in CI catches nearly all of it.

Limitation: passing this gate proves syntactic validity, not strategic correctness — a perfectly-formed es-MX still hurts if you have no Mexico-specific page behind it.

Asymmetric clusters: when locale B exists but A doesn't, and tags assume it does

A data-integrity failure that surfaces as mysterious return-tag errors: clusters where coverage is uneven across languages.

The situation. Your French and German catalogs are complete, but the Japanese one covers only a subset of products. A naive template generates the same hreflang block on every page, so French and German product pages confidently reference a ja alternate that was never published. The crawler hits a 404 (or a soft-404 fallback) where a return tag should be, and reciprocity fails for the whole cluster on that product.

The failure variants:

— Hardcoded full-locale blocks applied to pages whose translations are incomplete
— A translated page exists but at a different slug than the template assumes, so the reference 404s
— A locale's page was unpublished/expired but still referenced by its siblings

The fix is to make the alternate set dynamic and verified:

— Build each page's hreflang block from the actual set of published, indexable translations of that specific entity — not from a global locale list
— On unpublish, regenerate every sibling's block to drop the dead reference
— Validate that each referenced URL returns 200 before emitting it

Methodology note: the cheapest detection is a crawl that follows hreflang hrefs and flags any non-200 target. That single check catches the majority of asymmetric-cluster breakage we encounter.

Caveat: it's perfectly valid for clusters to differ in size page-to-page — not every product needs every language. The error isn't having a small cluster; it's claiming members that don't exist. Smaller-but-true beats complete-but-fictional.