The templated-title duplicate problem

"We auto-generate titles from a template — consistent and scalable."

Consistent, yes. Distinct, no.

The failure mode of {Product} | {Category} | {Brand} at scale: pages whose only difference is a product name, producing near-identical titles across hundreds of URLs. Google sees a wall of boilerplate, picks a few to rewrite, and treats the rest as low-differentiation.

Here's what actually happens on big sites: the template looks fine for the ten pages you check and breaks on the thousands you don't. Two products with similar names get titles that differ by one word, both fighting for the same SERP, neither distinct enough to win.

Fix: bake real differentiation into the template — pull in a spec, a price, a use-case modifier, a unique attribute from the data. {Product} {KeySpec} | {Category}. The template should generate variety from your data, not stamp the same shape on everything. Scale is no excuse for sameness.

ЕЮ Иванов продолжает кошмарить АффПапу, конторку, которая накинула говна на вентилятор этим летом. Тогда в AffPapa не знали, с каким говном идут бодаться, поэтому заслуженно проиграли. 😏

На этот раз ЕЮ зарегал товарный знак AffPapa — совсем скоро имя компании будет официально принадлежать ему. Чтобы убедиться в трушности мува, переходим по ссыл-Очке и вводим серийный номер: 2026793242. Там видим, что заявка на регистрацию подана лично Евгением Юрьичем.

Всё это выглядит забавно, но давайте не забывать, в какой сфере мы работаем и что реально может произойти с жирным троллем за воровство нейминга. Впрочем, толстому не привыкать отхватывать пиздов за проделки в интернете, поэтому ждем очередную фотку разбитого ебала и длинный пост с извинениями. 😏😏😏

В арбитраже денег нет 💵

Still relying on rel=next/prev

"We mark up pagination with rel=next/prev so Google understands the series."

Google stopped using that in 2019.

They announced they hadn't used rel=next/prev for indexing in years — and people are still shipping it as their entire pagination strategy, then wondering why deep pages don't get crawled or why page 2+ products never index.

Here's what actually happens: the markup does nothing, so the real failure underneath stays unsolved — paginated pages with thin, near-duplicate content, canonicals pointing every page back to page one (which deindexes pages 2+ and the products only listed there), and no other path for crawlers to reach deep items.

Fix: don't lean on a dead signal. Make each paginated page self-canonical and crawlable, ensure products are reachable from somewhere other than deep pagination (category links, sitemaps), and keep the on-page content meaningful per page. Keep rel=next/prev if you want — for browsers — but it's not an SEO plan.

The meta keywords tag, in 2026

"Filling the meta keywords tag — every little helps."

It doesn't help. It can hurt.

Google has publicly ignored the meta keywords tag since 2009. So the 'every little helps' instinct buys you exactly zero ranking benefit. But here's the actual mistake: you're publishing your target keyword list, in plain HTML, to anyone who hits View Source — including competitors who'll happily read your strategy off the page.

Here's what actually happens: a team keeps a legacy field in their CMS, dutifully fills it, hands competitors a free keyword map, and gains nothing. The only entity reading that tag is the one you least want reading it.

Fix: delete the field, or leave it blank. Spend the effort on the title, the H1, and the body copy — the things that are actually read. (A tag that helps nobody but your rivals is not 'every little helps.' It's a leak.)

Padding to hit a word count

"Top results average 2,000 words, so make every page 2,000 words."

You've confused correlation with a quota.

The data is real — long content correlates with ranking. The mistake is reading a correlation as a target and padding thin topics to hit it. Comprehensive pages tend to be long because the topic demanded length, not because the author was filling a meter. Reverse the causality and you get bloat.

Here's what actually happens: a query that deserves a 400-word direct answer gets stretched to 2,000 with throat-clearing, restated points, and a 'what is' section nobody asked for. The padding pushes the actual answer below the fold, raises bounce, and dilutes the relevance you started with.

Fix: length should be an output of completeness, not an input. Cover the topic fully — every real subtopic, every reasonable follow-up question — then stop. If that's 600 words, it's 600 words. A tight page that answers fully beats a long one that stalls. (Nobody ever ranked for endurance.)

"Screaming Frog and Sitebulb find the same title problems."

No.

They crawl the same tags, but they flag different things. Screaming Frog hands you a raw column of pixel widths and truncation lengths and lets you sort. Sitebulb hands you a prioritized hint list that already decided what's "too long" for you.

That's the actual tradeoff, and it matters. If you're auditing 50,000 URLs and want to write your own rules — title-over-580px, missing keyword, duplicated across templates — Frog's flat export wins, because you control the threshold. If you're handing a report to a client who won't read a spreadsheet, Sitebulb's opinionated scoring wins.

The mistake is treating "it found fewer issues" as "the page is fine." It found fewer issues because someone else set the cutoff.

(Frog's default 561px truncation guess is also just a guess. SERP truncation moved years ago and nobody updated the folklore.)

"Ahrefs shows my internal link structure, so I don't need anything else."

No.

Ahrefs shows the internal links it crawled and chose to report, weighted by its own index priorities. Search Console's Links report shows what Google actually counted as internal links to each URL. Those are two different questions, and people conflate them constantly.

Use Ahrefs (or any crawler) when you're planning — finding orphans, mapping anchor distribution, seeing the hub-and-spoke before you build it. It sees the whole site at once, including pages Google hasn't bothered indexing.

Use GSC's Links report when you're diagnosing — "why isn't this page getting equity" — because it reflects Google's actual graph, including links it dropped from JS it didn't render.

The gap between the two lists is the interesting part. A page with 80 crawler-visible internal links and 3 in GSC has a rendering problem, not a linking problem.

(Yes, this means your beautiful mega-menu might count for almost nothing.)

Network picks — SEO & search:

— @OverviewHotTake — Strong, unfiltered opinions on AI Overviews and generative search —…
— @MapPackDiaries — Real local-SEO case studies told as stories — the dentist who tripled…
— @CartAndCrawl — Your e-commerce SEO questions, answered straight — faceted nav,…
— @StackAndCompare — Honest, hands-on SEO tool comparisons — Ahrefs vs Semrush vs the…

В роликах Youtube теперь можно рекламировать товары Amazone

➡️ Читайте на сайте: https://aff.top/blog/v-rolikakh-youtube-teper-mozhno-reklamirovat-tovary-amazone

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

Google выпустил Gemini Omni 1.1 Flash

Google обновил Gemini Omni для генерации видео: модель умеет продолжать сцены с учётом до 10 секунд контекста и собирать ролик до 40 секунд, работать по референсу и делать переходы между кадрами. Главный вывод — инструмент стал практичнее для продакшена, а посекундная цена делает его заметно доступнее для тестов и рабочих задач.

➡️ Читайте на сайте: https://aff.top/blog/google-vypustil-gemini-omni-1-1-flash

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

Топ 5 PWA-сервисов для залива дейтинга

Статья показывает, что PWA выгодны не только для гемблы: в дейтинге они дают пуш-базу, больше траста и помогают маскировать оффер под бренд. Главный выбор зависит от цены инсталлов и теста GEO: для старта лучше бесплатные или дешёвые решения, а Progressier выделяется как самый практичный вариант для залива дейтинга.

➡️ Читайте на сайте: https://aff.top/blog/top-5-pwa-servisov-dlia-zaliva-deitinga

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

"I changed the titles and traffic went up, so the change worked."

No. That's a before/after, and before/after is the weakest tool you own.

Here's the comparison that matters. A before/after measures your change plus the algorithm update plus seasonality plus whatever your competitor did that week. You can't separate them. A proper split test — split your URLs into matched groups, change one group, leave the other as control — measures the change alone.

Use before/after for sitewide moves you can't partition (a CMS migration, a global template swap). You have no choice; just don't pretend it's causal.

Use split testing for anything templated and repeatable: title patterns, schema additions, intro length. Tools like the SearchPilot approach exist precisely because "traffic went up" is not evidence.

The tell: ask "what did the pages I didn't touch do?" If you don't have that number, you ran a story, not a test.

(November traffic going up means nothing. November traffic going up versus a held-out control means something.)