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.