Google Indexes One Copy of a Licensed Game Page. It Probably Isn't Yours.

Every portal licensing the same HTML5 catalogue publishes the same game descriptions and thumbnails, so Google picks one page per game and drops the rest.

This is the part of catalogue licensing nobody quotes a price for. You buy a thousand games, you get a thousand game pages, and every other licensee of that catalogue gets the same thousand pages — same title tags, same one-paragraph blurb, same category assignment, frequently the same thumbnail file served off the same CDN. Then everybody waits for search traffic that exactly one of them is going to receive.

The overlap is bigger than most buyers picture. GameDistribution's own about page puts its catalogue past 19,000 games running across upwards of 4,800 publishing portals. Even if only a fraction of those are live and indexed, the competitor count for any given game page is not four or five. It is hundreds, and every one of them shipped the identical words.

🔁 The Duplicate You Inherited With the Catalogue

A catalogue drop is not just game files. It is a metadata bundle: display title, short description, long description, category tags, control instructions, age guidance, thumbnail set. That bundle exists so integration takes an afternoon instead of a quarter, and on that measure it works. Nobody is doing anything wrong by shipping it.

The consequence is still real. Once that bundle is live on your site, the only genuinely unique things on your game page are your domain name and your template chrome — header, footer, sidebar, ad slots. Everything a search engine would use to decide the page is worth showing came from a file that several hundred other operators also received.

Retailers have lived with this for two decades and it is worth noting why their version is less severe. A shop running manufacturer copy still has a price, a stock status, a delivery estimate, and reviews from its own customers. Those are first-party facts sitting on the page whether anyone wrote copy or not. A game page running licensor copy has none of that by default. It is the boilerplate and nothing else.

🧭 Google Does Not Punish This. It Just Picks Someone Else.

The word "penalty" gets used here constantly and it is the wrong frame. Google's documentation treats duplication as a selection problem: if you do not specify a canonical, Google identifies which version of the URL it considers the best one to show, consolidates the signals, and serves that. Nothing is punished. Copies are simply not shown.

You can watch this happen in Search Console. The Page Indexing report has two statuses that describe it exactly. Duplicate without user-selected canonical — "This page is a duplicate of another page, although it doesn't indicate a preferred canonical page. Google has chosen the other page as the canonical." And the more uncomfortable one, Duplicate, Google chose different canonical than user — "This page is marked as canonical for a set of pages, but Google thinks another URL makes a better canonical."

Read that second status carefully. You declared yourself the canonical version and Google overruled you. Google's own canonicalization troubleshooting guidance says the quiet part directly: "Even if you explicitly designate a canonical page, Google might choose a different canonical for various reasons, such as the quality of the content."

When the content is byte-identical, quality is not the tiebreaker — everything else is. Domain age, link profile, how often people come back. A portal that launched in March is going to lose that comparison to one that launched in 2019, on every single title, forever, as long as the pages stay the same. The failure mode is not a red warning in a dashboard. It is absence, which is considerably harder to diagnose because nothing on your site looks broken.

🚫 The Canonical Tag Is Not the Fix Anyone Thinks It Is

Two instincts show up as soon as an operator understands the problem, and both are wrong.

The first is to point the canonical at the licensor's own game page, on the theory that this is the honest thing to do. It is also a written instruction to send your traffic somewhere else. You paid for a licence to run the game. Do not annotate it as somebody else's.

The second is to ask the licensor to canonical to you. Google stopped recommending the canonical link element for this scenario in May 2023 — Search Engine Land covered the reversal at the time, and the guidance now sits in Google's own canonicalization docs. The reasoning is that syndicated pages are often very different from the original, so the tag does not do the job reliably. Google's suggested alternative is that partners block indexing of the republished content altogether, which is not something you can meaningfully ask of a licensor serving several hundred other licensees.

None of which makes canonical tags useless. They do real work inside your own domain, where /game/tower-blocks, /game/tower-blocks?ref=home and /categories/puzzle/tower-blocks are three URLs for one thing. Consolidate those. Just do not expect a tag to solve a problem that lives across four hundred domains you do not control.

✍️ Write the Part the Licensor Cannot Write

The licensor's description has to work for every licensee, which is precisely why it works particularly well for none of them. It is written to be inoffensive across a telecom portal, a kids' site and an arcade aggregator simultaneously.

You know things the licensor does not. You know how the title performs against your traffic — your device mix, your countries, your connection speeds, your audience. That is first-party information, and it is the only kind of content on a game page that is structurally impossible for a competitor to copy from the same catalogue drop.

Concretely, per page, the things worth adding:

• Observed session length on your portal, not the genre average. "Most rounds here run about four minutes" is a fact only you have.
• Device and input reality. Whether it plays properly on touch, whether it wants a keyboard, whether it is usable one-handed on a phone in portrait.
• Connection behaviour. Whether it loads on a weak 4G connection and whether it keeps running when the connection drops. This matters enormously in markets where it is the default condition.
• A difficulty and audience note in your own words. Who it suits, who will bounce off it.
• Three specific next games from your catalogue, hand-picked rather than generated by a "related" widget.

That last one earns its place twice. It is unique content, and it is an internal linking structure your competitors — running the same games with the same auto-generated related-games module — do not have.

Do not do this to a thousand pages

Nobody is going to hand-write 1,049 game pages, and attempting it is how the project dies in week three. Play concentrates: a small head of titles takes the overwhelming share of plays on almost any portal. Pull the forty pages that actually receive search impressions in Search Console, write those properly, and leave the long tail on licensor copy where it costs you nothing you were going to get anyway.

Size the ambition to how a game page is actually used, too. Poki's 2026 State of Web Gaming report — fieldwork run 11–19 May 2026 across 2,000 weekly-or-more web gamers in the US and UK — puts a typical session at 11 to 20 minutes covering two to three individual titles. A game page is a junction, not a destination. Optimise it for the next click, not for time spent reading about the game.

⚠️ Generate Your Way Out and You Trip a Different Policy

The obvious shortcut is to point a language model at all 1,049 descriptions and have it paraphrase. Before anyone budgets for that, read what Google's spam policies actually say about scaled content abuse: it is "when many pages are generated for the primary purpose of manipulating search rankings and not helping users." The listed examples include using generative AI tools to produce many pages without adding sufficient value, and combining content from multiple sources without adding sufficient value.

Note what triggers it and what does not. The method is not the problem — Google says so explicitly. Purpose and value are. And a paraphrase of a licensor blurb adds no information whatsoever. It is the same duplicate wearing different adjectives. It has not helped a single reader decide whether to play the game, and it has now converted a ranking problem into a policy question.

There is a version of AI-assisted writing here that is entirely defensible: feed the model your own analytics — session length, drop-off point, device split, which titles players go to next — and have it draft from facts nobody else holds. The output carries information. That is a different activity from spinning, even though it uses the same tool.

One adjacent trap for publishers. If you are bolting a games section onto an established news or media domain, Google's site reputation abuse policy covers "third-party content published on a host site mainly because of that host's already-established ranking signals." A games area built as a genuine product for your readers is not what that policy targets. A games area built because the domain ranks is. The distinction Google draws is motivation, and it is worth being able to answer that question honestly before someone else asks it.

⏱️ The Game Is in an iframe, and Your INP Bill Includes It

Almost every portal embeds the licensed game in an iframe. That has a measurement consequence most operators have not checked.

Interaction to Next Paint is assessed at the 75th percentile of real users: web.dev puts good responsiveness at 200 milliseconds or under, and anything above 500 milliseconds as poor. The part that matters here is how iframes are handled. Interactions inside an embedded frame count toward the parent page's INP — as web.dev puts it, "End users won't be aware what is in an iframe or not." But the Event Timing API "does not report event entries for interactions that occur within iframes," even though the metric includes them.

The practical effect: your own real-user monitoring can report a clean INP while the field data Google actually uses reports something worse, and the gap is entirely the game. web.dev's own remedy is for sub-frames to report their event-timing entries up to the parent frame. If your portal has never done that, your performance dashboard has been measuring the page around the game rather than the game.

Two adjacent habits worth fixing at the same time. Set an explicit width and height, or an aspect ratio, on the game container so the browser reserves the box before the game arrives. And do not autoload the iframe — ship a poster image with a play button and instantiate the frame on click. The engine stays off the main thread until somebody has actually expressed intent, which is better for the metric and better for the player on a slow device.

📊 Four Numbers, Not a Rankings Report

1. Count of your /game/ URLs sitting under the two duplicate statuses in the Search Console Page Indexing report. If they are in there, the rest of this is not theoretical for you.
2. Submitted-versus-indexed ratio for game pages specifically, segmented away from the rest of the site. Sitewide indexing coverage hides this completely.
3. Field INP for the game-page URL group, taken from field data rather than a lab tool, and compared against what your own RUM claims.
4. Next-click rate off a game page. Given two-to-three-title sessions, this is closer to a revenue metric than anything on the page itself.

🚫 Five Ways Portals Get This Wrong

• Publishing a thousand pages of licensor copy and blaming the catalogue. The games were never the problem. The metadata layer was, and it was always yours to build.
• Canonicalising to the licensor. A deliberate, machine-readable instruction to rank someone else instead of you.
• Rewriting at scale with nothing new to say. Same duplicate, more adjectives, plus a scaled content abuse question you did not previously have.
• Trusting in-page RUM on an iframe portal. The one part of the page you did not build is the part your monitoring cannot see.
• Treating individual game pages as the whole plan. Category, collection and curation pages are entirely yours to shape — "puzzle games that work offline," "two-minute games for a commute" — and they carry no inherited duplication at all. On most portals that is where the differentiating work pays fastest.

🎮 Where a Licensed Catalogue Fits

Forestry Games has licensed games since 2017 and runs a catalogue of 1,049 titles across HTML5 and Android, alongside in-house HTML5 development, white-label portals and branded IP work with partners including Disney, Nickelodeon, Cartoon Network and Warner Bros.

The point worth taking from all of the above is a licence-scope question, and it applies to any licensor you talk to, not just this one. Before signing, confirm in writing that you may rewrite and republish game descriptions and titles under your own byline, and whether thumbnails and key art may be re-cut or replaced. Some licences are silent on it, some restrict it, and a few brand-controlled titles restrict it for good reason. If the answer is no, you have just learned that those pages will never be differentiable, and you can price the deal accordingly.

🧭 What to Do This Quarter

Open the Page Indexing report and filter for your game URL path. Count what sits under the two duplicate statuses. That number is your actual problem size, and until you have it, every other decision here is a guess.

Then take the forty game pages with real search impressions and rewrite them with facts you own — session length, device behaviour, connection tolerance, hand-picked next games. Fix the iframe measurement gap so you can tell whether the performance number you have been reporting is the real one. Build three or four curation pages that no catalogue drop could have supplied. Leave the tail alone.

If you are still choosing a catalogue, add the rewrite-rights question to your due diligence list and ask it before price. The games are the easy part of the purchase. The pages you wrap around them are the part that decides whether anybody ever finds them.