Skip to content
busyless
Book a call

Game studio SEO strategy

Regulated marketing

The storefront is the search engine, and Google only feeds it

Written by Eugene SuslovLast reviewed 28 August 2026No affiliate links
Sector
Software and tech
Model
Ecommerce, National service
Competition
High
Time to results
6 to 12 months, and it lands as wishlists first
Typical monthly
$500 to $6,000

Key takeaways

  1. 1The storefront is the search engine. Steam, the App Store and Google Play run their own ranking on their own signals, and no amount of work on your website changes what happens inside them directly.
  2. 2Your website's job is the wishlist, not the sale. That single reframe decides what you publish, what you measure and why launching the site on launch day is too late.
  3. 3"Games like [something]" is the most valuable query shape in this industry and it is answered by Reddit threads and listicles. Answering it honestly, including naming games that fit better, is the whole opportunity.
  4. 4The devlog is a following, not a funnel. It is read by other developers, which is worth having and is not the same thing as reaching buyers. Budget it as a separate activity.
  5. 5Somebody owns your game's wiki. If it is Fandom, then Fandom outranks you for your own mechanics, and getting that back is a decision to make early rather than after launch.

SEO for game developers is a different job from the rest of this directory, and the difference is not one of degree. Everywhere else, ranking on Google is how a customer finds the business and then buys from it. Here, the place people actually search is a storefront you do not control, and Google sits upstream of it.

Somebody looking for a game types into Steam, the App Store, Google Play or YouTube. They type into Google too, but usually to answer a question about a game they have already heard of, or to find one like something they finished last week.

So a game studio SEO strategy is built around a different conversion. The thing your website is trying to produce is a wishlist addition, a demo download or a newsletter signup, and every one of those is a promise to come back rather than a transaction.

That reframe changes almost everything downstream. It changes what you publish, because the questions worth answering are the ones asked before somebody has decided. It changes when you publish, because a site that goes live on launch day has missed the entire window in which wishlists accumulate.

It also changes what you measure. Sessions are close to meaningless here. Wishlist actions, demo installs and the conversion at launch are the numbers, and the reporting section below is written around the fact that none of them attribute cleanly.

One note on scope. This page is written for a studio marketing its own games. A great many studios also sell development, art or porting services, and that is a genuinely different search problem with a different buyer, so it gets its own cluster below rather than being folded in.

Who already ranks in game development

Before any game studio SEO work is worth doing, it is worth being precise about who occupies the results page, because in this industry the answer is unusually varied. Some of it is a storefront running its own algorithm. Some of it is a database that ranks for your own game's name. Some of it is a person on YouTube whose video is the search result.

What is on the results page

  • Video results, frequently above everything else. For a query about a game, a creator's playthrough is often the most useful answer and the engines treat it that way.
  • Storefront listings ranking for the game's own name, above the developer's site, on Steam, the App Store and Google Play.
  • Reddit threads, especially on "games like" and "is it worth it" queries, where the discussion format is genuinely a better answer than any single page.
  • Review aggregation panels and score boxes on the game's name.
  • Fandom and wiki results on mechanics, items, endings and characters, usually within days of a game gaining an audience.
  • "Best [genre] games" listicles from the enthusiast press, which own the genre head terms almost completely.

  • Steam

    store.steampowered.comClaim it

    Not a directory to be listed in: a search engine with its own ranking, its own tag taxonomy, its own Discovery Queue and its own periodic events. Your store page is the highest-value page you will ever write and it does not live on your domain. Read the Steamworks documentation rather than a blog post about it, because the mechanics change.

  • The App Store and Google Play

    apps.apple.comClaim it

    The same shape on mobile, with a stricter relationship between the title, the subtitle, the keyword field and what you rank for. Both also carry policy requirements that reach the marketing, including published odds for paid randomised items.

  • SteamDB

    steamdb.info

    Ranks for your own game's name, frequently above your website, and publishes concurrent player counts and price history whether you like it or not. Not claimable and not adversarial. Treat it as part of your search result and make sure your own pages answer the questions it raises.

  • HowLongToBeat

    howlongtobeat.com

    Owns the length question completely, and length is a real purchase objection at every price point. You will not outrank it. You can answer the question on your own page in a way it cannot, by saying what a first run looks like and what changes on a second.

  • Fandom and community wikis

    fandom.com

    The gatekeeper studios create for themselves. A wiki appears within days of a game finding players, and once it exists it outranks the developer for the game's own mechanics, items and endings. Whether you host the wiki, support an independent one or cede it is a decision worth making before launch rather than after.

  • Reddit

    reddit.com

    Where the games-like question is actually answered, and increasingly where the engines take the answer from. Not a channel to optimise. A place where a developer who participates honestly, under their own name, over a long period, is treated very differently from one who arrives at launch.

  • The enthusiast press and review aggregators

    metacritic.com

    IGN, PC Gamer, Rock Paper Shotgun, Eurogamer and the aggregators own the genre head terms and the review queries. Concede those. The press kit and the review-copy process are what you control, and they are covered in the templates below.

  • YouTube and Twitch

    youtube.com

    For several genres this is the discovery surface and search is secondary to it. Not a ranking play. It is the reason the creator disclosure rules in the compliance section matter more here than almost anywhere else.

Four discovery surfaces down the side with the entry points available on each. Search, video and community each hold three. The storefront row holds a single slot, flagged, because there is one store page and one algorithm.
The flagged row is not a gap to fill. There is no redundancy available on a storefront, which is exactly why the three rows above it matter.

What people actually search

The clusters below are ordered by how close they sit to a wishlist, not by volume. The most searched things about any game are asked after somebody already owns it, which is useful for retention and community and does nothing for the launch.

Games like

Commercial investigation

> games like [well known game] but shorter

The page that wins it: An honest comparison page that names the games your game is and is not like

The single most valuable query shape here and the one with no analogue in any other industry. The person asking has finished something, liked it, and is looking for the next one. Answer it properly, including by naming games that fit better than yours, and you become the page that gets linked in the thread.

Mechanic and constraint

Commercial investigation

> colony sim with mod support and no combat

The page that wins it: A page per real mechanic or constraint your game actually satisfies

The long tail here is unusually specific because players describe games by what they do rather than by category. Almost nobody builds pages for it, and the searches are tiny individually and very high intent.

Your own game, before release

Navigational

> [your game] release date

The page that wins it: One page per game, on your domain, kept current

Looks like a query you automatically own and frequently is not. Storefronts, aggregators and wikis all rank for it, and a studio with four games and one portfolio page has nothing to put in the results.

Platform and compatibility

Commercial investigation

> is [your game] on steam deck

The page that wins it: A compatibility and requirements page as text, not an image

Controller support, deck verification, cloud saves, Mac and Linux, cross-play, offline play. Each one decides the purchase for somebody, and on most studio sites all of it is inside a screenshot of the store page.

Length, difficulty and content

Informational

> how long is [your game]

The page that wins it: A what-to-expect page covering length, difficulty options and content warnings

Answered by third parties by default. Answering it yourself is also the accessibility and content-warning page, which matters to a real part of the audience and almost never exists.

Devlog and craft

Informational

> how we built [a system] in [an engine]

The page that wins it: Genuine technical write-ups, published on your own domain

The cluster indie studios most overrate as marketing. It is read by other developers, which builds hiring reach, conference invitations and peer links, all of which are worth having. It is not a route to players, and treating it as one is how a year of writing produces no wishlists.

Work for hire and co-development

Commercial investigation

> unreal engine co-development studio

The page that wins it: A separate section written for a publisher, not a player

A different buyer, a different vocabulary and a much longer cycle. Publishers search by engine, by platform, by discipline and by port target. It belongs in its own section with its own navigation, because a page trying to address a producer and a player at once addresses neither.

Community and modding

Informational

> [your game] mod tools

The page that wins it: Documentation on your own domain, linked from the store page

Post-purchase, so it does nothing for a launch, and it is what keeps a game alive between updates. It is also the cluster most easily lost to a wiki you do not control.

Four discovery surfaces converging on a single wishlist addition: a creator's video, a thread on Reddit, your comparison page and a festival demo. The wishlist then produces three outcomes: the storefront starts surfacing you, an email on launch day, and reviews in the first week.
The website is not trying to sell anybody a game. It is trying to produce the thing in the middle, which is what makes the three on the right happen.

What the rules change

Games are more regulated than most people in the industry expect, and the rules reach the marketing rather than only the product. None of this is legal advice, every item names its source, and the ones with dates on them are the ones to re-check first.

1

Paid creator coverage has to be disclosed, and mostly is not

Federal Trade Commission Endorsement Guides, revised in 2023, and Section 5 of the FTC Act

What it means

A material connection between a studio and a creator has to be disclosed clearly and conspicuously. Payment is the obvious case, but so are free keys given on terms, early access conditioned on coverage, revenue shares, and hardware. The disclosure has to be where the audience will see it, which for a video means in the video and not only in the description.

So do this

Write the disclosure requirement into the creator agreement itself and make it a condition of the key rather than a request. Keep the correspondence. Then check what actually went out, because the failure here is almost never a decision and almost always nobody looked.

2

COPPA reaches your website, your analytics and your Discord

Children's Online Privacy Protection Act and the FTC's COPPA Rule, which the Commission amended in 2025

What it means

If a game or a site is directed to children, or if you have actual knowledge that you are collecting personal information from children under 13, the rule applies. Persistent identifiers count as personal information, which is what pulls ordinary analytics and advertising tags into scope. The definition of directed to children looks at subject matter, visuals, music, characters and the audience you actually have.

So do this

Decide honestly whether your game is directed to children, in writing, and have somebody other than marketing sign it. If it is, the tag stack on the website is a compliance question before it is a measurement one. Check the current compliance dates for the 2025 amendments rather than relying on a summary.

3

You may not advertise a rating you do not hold

ESRB in North America, PEGI in Europe, and IARC for storefronts including Google Play, Nintendo and Microsoft

What it means

Ratings are issued by boards with their own rules about how the rating and the content descriptors are displayed in advertising, including on a website and in a trailer. The boards also have rules about what marketing may show relative to the rating, and a rating can be revised if the submitted content was not representative.

So do this

Publish the rating and the content descriptors as text on the game's page, in the form the board requires, rather than as part of a key art image. Then check the trailer against the rating, because the trailer is advertising and the board has an opinion about it.

4

Paid randomised items need published odds

Apple App Review Guidelines and Google Play developer policy, both of which require disclosed odds; several national regulators, including in Belgium and the Netherlands, have gone further

What it means

Where a player pays for a chance at a randomised item, the platforms require the probabilities to be disclosed before purchase. Beyond the platform rules, a number of jurisdictions have treated some paid randomised mechanics as gambling, and the position differs by country and continues to move.

So do this

Publish the odds where a player sees them before paying, and publish them on the website too rather than only inside the client. If you sell in Europe, get the position for each market you actually sell in rather than assuming one answer covers it.

5

In-game chat is within scope of the accessibility rules

Twenty-First Century Communications and Video Accessibility Act; the FCC's waiver for advanced communications services in games expired at the end of 2018

What it means

Text and voice communication features inside a game are advanced communications services, and the industry-wide waiver ended, so the accessibility obligations have applied since the start of 2019. Separately, the website itself is subject to the ordinary accessibility expectations that apply to any commercial site.

So do this

Treat chat accessibility as a product requirement rather than a marketing one, and publish what your accessibility features actually are on a real page. That page also happens to be one of the best-converting pages you can write, because a real part of the audience is searching for exactly it.

6

The storefront has its own rules about reviews and keys

Valve's Steamworks distribution documentation, and the equivalent policies on the other storefronts

What it means

Storefronts distinguish between reviews left by people who bought the game and reviews left by people who received a key, and they treat them differently. They also have rules about what a key may be used for, about how a store page may describe the product, and about what counts as manipulating a score.

So do this

Read the current Steamworks documentation before designing any review or key programme, and never build a process that asks for a review in exchange for anything. The FTC rule on consumer reviews is the second reason not to, and it applies whatever the storefront says.

Three lanes. The studio sends a key, with the disclosure terms attached as a condition. The creator publishes the piece and makes the disclosure. The regulator looks at the piece and at the material connection behind it.
The obligation sits on the creator and the exposure sits with the studio. The moment the key goes out is the only lever in the picture.

Proving expertise

Games are not a YMYL category, so the quality bar is ordinary. What matters here is a different thing: proving that a real studio with real people is behind the game, because the market has a long history of announcements that never shipped.

  • Named people, with roles. A studio page listing six humans with what each of them does is worth more here than any amount of copy about passion.
  • A shipped history, including the small things. Game jam entries, prototypes and cancelled projects all count as evidence that the studio finishes things.
  • A devlog with dates on it that has been running for longer than the current project. It is the cheapest proof of continuity there is.
  • Engine, platform and toolchain stated plainly, which matters both to players worrying about compatibility and to publishers evaluating you for work.
  • A press kit that is complete, current and reachable without an email address.
  • Public participation under your own name, in the communities where your genre lives, over a period that predates the launch.
  • Accessibility features documented specifically rather than claimed generally.

How to build a game studio SEO strategy

The order below is the whole of the game studio SEO strategy, and it is built backwards from the launch. Everything in the first two phases exists to make the wishlist window usable, because that window closes and does not reopen.

  1. 1

    Weeks 1 to 3

    Own the ground you already have

    • Build one real page per game on your own domain, with the release date, the platforms, the requirements and the rating as text rather than inside an image
    • Put UTM parameters on every outbound link to a storefront, from the site, the newsletter, the social profiles and the press kit, because wishlist attribution is impossible to reconstruct afterwards
    • Publish the press kit as HTML with the assets downloadable from it, rather than as a ZIP or a page that only renders in a viewer
    • Name the team, with roles, and put a date on the devlog
    • Decide who owns the wiki, and write the decision down

    You end up with
    A domain that has something to rank, a tagged link to the store from every surface you control, and a press kit a journalist can use without emailing you

  2. 2

    Weeks 3 to 10

    Answer the questions asked before a decision

    • Write the games-like page for the two or three titles yours is genuinely adjacent to, and name the ones that fit better
    • Write a page per real mechanic or constraint, using the words players use rather than the words on your design document
    • Write the what-to-expect page: length, difficulty options, content warnings and accessibility features
    • Write the compatibility page and keep it current, because it is answered wrongly by third parties by default
    • Go and participate in the communities where the genre lives, under your own name, without linking anything for the first month

    You end up with
    Coverage of the queries that sit upstream of a wishlist, and a presence in the places where the games-like question is actually answered

  3. 3

    Weeks 8 to 20

    Feed the storefront

    • Rewrite the store page against what you learned from the mechanic pages, because the tags and the first two lines are doing most of the work
    • Plan the demo and the festival appearance as a traffic event, with the site ready before it rather than after
    • Set up the review-copy process properly, with the disclosure requirement written into the agreement
    • Publish the devlog on a real cadence and accept that its audience is developers
    • Build the accessibility page and, if you have one, the mod documentation, on your own domain

    You end up with
    A store page that reflects how players actually describe the game, and a set of moments the website is prepared for rather than surprised by

  4. 4

    Weeks 16 to 30

    Measure wishlists, then conversion

    • Report wishlist actions by source from the storefront's own reporting, reconciled against your UTM data, with the gap stated
    • Track the mechanic and games-like cluster in Search Console separately from everything else, because it is the part you can influence
    • Watch the wishlist-to-purchase conversion at launch and in the first sale, which is the real quality signal on everything above
    • Report the developer-audience metrics separately, so the devlog is judged as hiring and reputation work rather than as marketing

    You end up with
    A report that separates what you influenced from what the storefront did, and that never presents a session count as a result

Technical fixes with the best payoff

The defects below are endemic because studio websites are usually built by the people making the game, in the last two weeks before an announcement, on a template chosen for how the trailer looks in it. Every one of them is cheap to fix and expensive to leave.

  • The site is a trailer and a logo

    An afternoon

    The standard studio site is a full-viewport video with a wordmark over it and a link to the store. There is no heading, no description, no requirements and no text of any kind, so there is nothing to rank and nothing for an answer engine to quote.

    Keep the trailer. Put a real page underneath it: what the game is, what you do in it, how long it is, what it runs on, what it costs and who made it. This is usually the single highest-return hour of work available on a game studio website.

  • Outbound links to the store carry no parameters

    An hour, and it has to be first

    The storefront can tell you where a wishlist came from only if you told it. An untagged link is anonymous, and once the launch has happened there is no way to reconstruct which page or which post produced anything.

    A tagged link from every surface, with a naming convention written down somewhere both marketing and the developer can see. Do this in week one, because it is the only item on this list that cannot be done retroactively.

  • The press kit is a ZIP file

    Half a day

    A journalist on deadline needs the description, the fact sheet, the trailer link, the screenshots and a contact, in a form they can copy from. A download that has to be extracted is a barrier at exactly the wrong moment, and it ranks for nothing.

    An HTML press kit with everything as text and the assets downloadable individually and as a bundle. Include the rating, the platforms, the release date, the price and the studio history. Then keep it current, which is the part that fails.

  • There is no page per game

    A day per game

    A studio with four titles usually has one portfolio page listing all of them, so each game has no URL of its own, no title tag of its own and nothing to accumulate. Older titles keep selling for years and this is how that revenue is left on the table.

    One page per game, including the ones you are not promoting any more, with its own metadata, its own requirements and its own store links. Retire nothing.

  • The requirements and the compatibility answers are images

    An hour per game

    System requirements, controller support, deck compatibility and platform lists are frequently published as a screenshot of the store page. They are among the most searched things about a game and they are invisible.

    Text, in a table, on the game's page, updated when it changes. It is also what an answer engine needs in order to say yes when somebody asks whether your game runs on their hardware.

  • The devlog lives on somebody else's domain

    A day to set up, then free

    Devlogs get published to itch.io, to the storefront's news feed and to a social platform, and nowhere on the studio's own site. Those are all reasonable places to syndicate to. None of them builds anything you keep.

    Publish on your own domain first and syndicate outward, with a canonical link back. The audience is the same either way; the difference is which domain accumulates the result.

  • The wiki was ceded without anybody deciding to

    A decision, then a sprint if you host it

    A community wiki appears on a hosted platform within days of a game finding players, and it then ranks above the developer for mechanics, items and endings. It happens by default, so most studios never make a decision about it.

    Decide before launch. Host it, support an independent one, or accept the hosted one deliberately and link to it. All three are defensible. Discovering it afterwards is not.

  • The site is English only while the store page is not

    A sprint, and only for the pages that convert

    Storefront pages get localised because the platform makes it easy, and the website does not, so the biggest non-English markets arrive at a page they cannot read on their way to a wishlist.

    Localise the game page and the compatibility page first, in the languages your store analytics say you already sell in. Not the devlog, and not the whole site.

A trailer and a wordmark at the centre of a ring, with five callouts naming what has to exist as text underneath it: what you do in the game, requirements and platforms, length and difficulty and content warnings, accessibility features named individually, and the age rating with its descriptors.
All five already exist, on the store page or in somebody's head. None of them is on the domain you own.

Structured data that applies here

The types below fit this industry specifically. Most of them earn no rich result on their own, which is worth knowing before anyone sells the work on that basis. What they do is describe the entity precisely, which matters for how search engines and answer engines resolve who you are.

  • VideoGame

    The page for each individual game

    A real schema.org type with genuinely useful properties, and almost nobody in the industry uses it. gamePlatform, applicationCategory, genre, playMode and processorRequirements all describe things players actually search for. Do not add aggregateRating unless real, verifiable ratings exist on your own page.

    VideoGame.jsonld
    {
  "@context": "https://schema.org",
  "@type": "VideoGame",
  "name": "[GAME TITLE]",
  "url": "https://[YOUR-DOMAIN]/games/[GAME-SLUG]",
  "description": "[ONE OR TWO SENTENCES DESCRIBING WHAT YOU DO IN THE GAME]",
  "image": "https://[YOUR-DOMAIN]/[KEY-ART.JPG]",
  "genre": ["[GENRE]", "[SUB-GENRE]"],
  "gamePlatform": ["PC", "[PLATFORM]", "[PLATFORM]"],
  "operatingSystem": "Windows 10, macOS [VERSION]",
  "applicationCategory": "Game",
  "playMode": "SinglePlayer",
  "processorRequirements": "[MINIMUM CPU]",
  "memoryRequirements": "[MINIMUM RAM]",
  "storageRequirements": "[INSTALL SIZE]",
  "datePublished": "[YYYY-MM-DD]",
  "contentRating": "[ESRB RATING, E.G. ESRB T]",
  "inLanguage": ["en", "[LANGUAGE CODE]"],
  "author": {
    "@type": "Organization",
    "name": "[STUDIO NAME]",
    "url": "https://[YOUR-DOMAIN]"
  },
  "publisher": {
    "@type": "Organization",
    "name": "[PUBLISHER NAME]"
  },
  "offers": {
    "@type": "Offer",
    "url": "[STOREFRONT URL]",
    "price": "[PRICE]",
    "priceCurrency": "USD",
    "availability": "https://schema.org/PreOrder"
  }
}
  • VideoObject

    Any page carrying a trailer or a gameplay video

    The trailer is usually the most important asset on the page and it is usually an unmarked embed. Marking it up gives the engines the title, the duration, the thumbnail and the upload date, and it is what makes the video eligible to appear as a video result rather than as an invisible iframe.

    VideoObject.jsonld
    {
  "@context": "https://schema.org",
  "@type": "VideoObject",
  "name": "[GAME TITLE] - [TRAILER NAME]",
  "description": "[WHAT THE TRAILER SHOWS, IN ONE SENTENCE]",
  "thumbnailUrl": "https://[YOUR-DOMAIN]/[THUMBNAIL.JPG]",
  "uploadDate": "[YYYY-MM-DD]",
  "duration": "PT[M]M[S]S",
  "contentUrl": "https://[YOUR-DOMAIN]/[TRAILER.MP4]",
  "embedUrl": "[YOUTUBE OR HOSTED EMBED URL]",
  "publisher": {
    "@type": "Organization",
    "name": "[STUDIO NAME]",
    "logo": {
      "@type": "ImageObject",
      "url": "https://[YOUR-DOMAIN]/[LOGO.PNG]"
    }
  }
}
  • Organization

    The studio page, referenced from every game page

    One node for the studio, given a stable identifier and referenced by the game pages rather than restated on each. This is also where the founding date and the profiles live, and it is the node that makes a small studio legible as a real company rather than a name on a trailer.

    Organization.jsonld
    {
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://[YOUR-DOMAIN]/#studio",
  "name": "[STUDIO NAME]",
  "url": "https://[YOUR-DOMAIN]",
  "logo": "https://[YOUR-DOMAIN]/[LOGO.PNG]",
  "foundingDate": "[YYYY]",
  "founder": {
    "@type": "Person",
    "name": "[FOUNDER NAME]"
  },
  "numberOfEmployees": {
    "@type": "QuantitativeValue",
    "value": "[NUMBER]"
  },
  "sameAs": [
    "[STEAM DEVELOPER PAGE URL]",
    "[YOUTUBE CHANNEL URL]",
    "[LINKEDIN COMPANY URL]"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "press",
    "email": "[PRESS EMAIL]"
  }
}
  • Event

    A launch, a demo window or a festival appearance

    Use it only for something with a real start and end that a person could attend or take part in: a playtest window, a demo period during a festival, a launch date. Not for a marketing beat. It is the one node here that is genuinely time-bound, so it needs retiring when it passes.

    Event.jsonld
    {
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "[GAME TITLE] demo - [FESTIVAL OR EVENT NAME]",
  "startDate": "[YYYY-MM-DDT00:00:00-07:00]",
  "endDate": "[YYYY-MM-DDT23:59:00-07:00]",
  "eventAttendanceMode": "https://schema.org/OnlineEventAttendanceMode",
  "eventStatus": "https://schema.org/EventScheduled",
  "location": {
    "@type": "VirtualLocation",
    "url": "[STOREFRONT DEMO URL]"
  },
  "description": "[WHAT IS PLAYABLE AND FOR HOW LONG]",
  "organizer": {
    "@type": "Organization",
    "name": "[STUDIO NAME]",
    "url": "https://[YOUR-DOMAIN]"
  }
}
  • FAQPage

    The compatibility page and the what-to-expect page

    Only mark up questions that are visibly on the page, and only one FAQPage node per page. The compatibility questions are the natural fit here, because they are genuinely asked in exactly this form and the answers are short.

    FAQPage.jsonld
    {
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Does [GAME TITLE] have controller support?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "[FULL SUPPORT, PARTIAL SUPPORT OR NONE, AND WHICH CONTROLLERS]"
      }
    },
    {
      "@type": "Question",
      "name": "How long is [GAME TITLE]?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "[A FIRST RUN TAKES ABOUT X HOURS. COMPLETING EVERYTHING TAKES ABOUT Y]"
      }
    },
    {
      "@type": "Question",
      "name": "Is [GAME TITLE] playable offline?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "[YES OR NO, AND WHAT REQUIRES A CONNECTION]"
      }
    }
  ]
}
  • BreadcrumbList

    Every game page and every devlog post

    Small, dull and worth having, because a studio site with several games and a devlog develops a real hierarchy quickly and the engines will otherwise guess at it. It also gives the game page a visible position in a set rather than looking like a standalone landing page.

    BreadcrumbList.jsonld
    {
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://[YOUR-DOMAIN]/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Games",
      "item": "https://[YOUR-DOMAIN]/games"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "[GAME TITLE]",
      "item": "https://[YOUR-DOMAIN]/games/[GAME-SLUG]"
    }
  ]
}

What it costs

The bands below are editorial estimates, not quotes, and they are unusually wide in this industry because a solo developer and a thirty-person studio are both described by the word here. What they buy is roughly consistent; what varies is how much of it somebody has to do themselves.

Do it yourself

$0 to $200
  • A real page per game, written by whoever knows the game best, which is usually the right person anyway
  • The press kit, the compatibility page and the what-to-expect page
  • Tagged links, a free analytics setup and the storefront's own reporting
  • Community participation, which costs time rather than money and is the highest-value thing on this list

Who it suits

A solo developer or a two-person team before their first commercial launch

Where it stops

It cannot produce the games-like and mechanic cluster at any volume, because that is writing and writing takes hours nobody in a two-person team has spare.

Lean

$500 to $1,500
  • A writer producing the comparison and mechanic pages on a real cadence
  • Localisation of the two or three pages that actually convert, in the markets you already sell in
  • A proper press kit and a review-copy process run by somebody who is not the creative director
  • Rank tracking on the cluster you can influence, rather than on the genre head terms

Who it suits

A studio with one shipped title and another in development

Where it stops

It does not buy a community presence. That is a person spending real time in real places under their own name, and it cannot be bought in by the hour.

Funded

$2,000 to $6,000
  • The above, plus a devlog that is actually maintained and a hiring audience that comes with it
  • A localisation programme rather than a one-off pass
  • The work-for-hire section built out properly for publishers, if that is a real line of business
  • Reporting that reconciles storefront wishlist data against your own, with the gap stated rather than hidden

Who it suits

A funded studio with a publisher relationship or a second commercial title

Where it stops

None of it changes the storefront's algorithm. Budget can improve what you feed it and cannot buy placement inside it.

How to do it with no budget

More of this is free here than in any other industry in the directory, because the highest-value assets are things only you can write and the highest-value channel is a place you already spend time.

  1. 1

    Tag every outbound link to the storefront

    1 hour

    A spreadsheet and a naming convention

    The only item here that cannot be done retroactively. Do it before the next announcement, not after.

  2. 2

    Write the games-like page for the two titles yours is genuinely adjacent to

    4 hours

    Your own knowledge of the genre

    Name the games that fit better than yours. It is the reason the page gets linked rather than dismissed.

  3. 3

    Put the requirements, platforms, rating and length on the page as text

    1 hour per game

    Your own store page, copied out

    It is already written. It is just in an image or on somebody else's domain.

  4. 4

    Build the press kit as HTML

    3 hours

    Any static page on your own site

    Description, fact sheet, trailer, screenshots, logos, rating, contact. Then put a review date on it.

  5. 5

    Read the Steamworks documentation on tags, the store page and visibility rounds

    2 hours

    Valve's own documentation

    Free, current, and better than any third-party summary of it. Almost nobody does this before their first launch.

  6. 6

    Participate in the genre's communities under your own name

    Ongoing

    Reddit, Discord, forums

    Without linking anything for the first month. This is the single highest-return activity on the list and the one that cannot be delegated.

  7. 7

    Set up Search Console and segment the mechanic cluster

    1 hour

    Google Search Console

    Filter to the queries that describe a game rather than name one. That segment is the part of the report you can actually influence.

The tool stack

The stack here is smaller than in most industries, because the storefront supplies the reporting that matters and no third-party tool can see inside it. Spend on writing before you spend on software.

  • Track the mechanic and comparison cluster

    Search ConsoleExternalVisit site

    Segment the queries that describe a kind of game from the ones that name yours. The first segment is what you influence and the second is mostly brand demand you created elsewhere.

    Free routeFree, and it is the right tool for this specific job

  • Pull keyword and SERP data at scale for the comparison cluster

    DataForSEOSEO APIRead the review

    Worth it when you are building the mechanic cluster properly, because the useful queries are long, specific and numerous. Priced per request rather than per seat, which suits a studio doing this in bursts around a launch.

    Free routeSearch Console plus manual searching, which is slower and adequate below a few hundred pages

  • Publish the devlog and the game pages on your own domain

    PayloadHeadless CMSRead the review

    The requirement is a real content model with a page per game and a devlog that syndicates outward. Anything that gives you that is fine; the failure mode is publishing to the storefront's news feed and nowhere else.

    Free routeA static site generator, which is what most studios already have

  • Generate the VideoGame and VideoObject markup

    Schema Markup GeneratorFree toolOpen the tool

    Use it to get the shape right, then keep the block in your template rather than regenerating it per game. The blocks above are already filled in for this industry.

    Free routeIt is free

  • Read wishlist actions by source

    Steamworks reportingExternalVisit site

    The single most important report you have, and it only works if the links were tagged. Reconcile it against your own analytics and report the gap rather than picking whichever number is higher.

    Free routeIncluded with the storefront

  • Work out what the content programme has to return

    Content Marketing ROI CalculatorFree toolOpen the tool

    Useful here mainly to make the wishlist assumption explicit. Put your own wishlist-to-purchase conversion in it rather than a benchmark, and if you do not have one yet, say so rather than borrowing somebody else's.

    Free routeIt is free

Take it from here

Everything below is yours to take. Fill the [BRACKETS] and it is ready to use. Start with the link-tagging convention, because it is the only item on this page that stops working the moment you skip it.

Checklist

The naming scheme for every outbound link to a storefront, plus the audit that finds the ones already leaking.

STORE LINK TAGGING CONVENTION
Studio: [STUDIO NAME]      Game: [GAME TITLE]
Owner: [NAME]              Date set: [YYYY-MM-DD]

WHY THIS EXISTS
The storefront can only tell you where a wishlist came from if the link
carried a parameter. An untagged link is anonymous and cannot be
reconstructed after the fact. This is the one item that has to be done
before the next announcement rather than after it.

THE PATTERN
[STORE URL]?utm_source=[SOURCE]&utm_medium=[MEDIUM]&utm_campaign=[CAMPAIGN]

  utm_source    where the click came from      website / newsletter / reddit /
                                                youtube / discord / press
  utm_medium    the kind of placement          page / post / signature / kit /
                                                banner / video-description
  utm_campaign  the beat it belongs to         announce / demo-[EVENT] /
                                                launch / sale-[MONTH]

WORKED EXAMPLE
[STORE URL]?utm_source=website&utm_medium=page&utm_campaign=announce

RULES
[ ] Lower case everywhere. The reporting is case sensitive and will split
    Website and website into two rows.
[ ] No spaces. Use hyphens.
[ ] Never reuse a campaign name for a different beat.
[ ] One person owns this list. Write their name at the top of this file.

THE AUDIT: EVERY PLACE A STORE LINK EXISTS TODAY
Go through this list and tag or retag each one.

[ ] Home page primary button
[ ] Game page primary button
[ ] Game page secondary links (demo, DLC, soundtrack)
[ ] Press kit
[ ] Newsletter template footer
[ ] Newsletter, each individual send
[ ] Every social profile bio link
[ ] Pinned posts on each social profile
[ ] YouTube channel links and every video description
[ ] Discord server, channel topic and pinned message
[ ] Email signatures
[ ] Any partner, publisher or festival page you can edit
[ ] itch.io project page
[ ] Any devlog post that links to the store

UNTAGGED SHARE
After the next beat, record what proportion of store referrals arrived
without a parameter: [   %]. Report that number alongside every wishlist
figure. It never reaches zero, and pretending it does is how the reporting
stops being believed.

What to publish

Everything below is written for somebody who has not decided yet. That is the constraint that rules out most of what studios publish, which is written for somebody who already cares.

  • The honest comparison page

    One per adjacent title, two or three in total

    It answers the highest-value query shape in the industry, and the honesty is what makes it work: a page that names the games that fit better than yours gets recommended by people who are not you.

  • A page per mechanic or constraint

    One a fortnight, indefinitely

    Players describe games by what they do. Each of these pages is tiny, specific and almost uncontested, and collectively they are how somebody finds a game they did not know existed.

  • The what-to-expect page

    One per game, revised at each major update

    Length, difficulty, content warnings and accessibility in one place. It answers a purchase objection, it serves an audience that is genuinely underserved, and third parties are answering it for you today.

  • The compatibility page

    One per game, updated whenever it changes

    Requirements, controller support, deck status, platforms, offline play and cross-play, as text. It is the most searched practical thing about any game and it is usually a screenshot.

  • The devlog

    Monthly, and judged on hiring and reputation rather than on wishlists

    Genuine technical write-ups earn peer links, conference invitations and job applications. Valuable, and worth doing for those reasons rather than for the ones people claim for it.

  • The press kit

    Once, then reviewed before every beat

    It is the only asset here whose audience is a person on a deadline, and it is the difference between being covered and being skipped.

  • The work-for-hire section

    Once, then a case page per project you are permitted to name

    A publisher searching for a co-development or porting partner is a completely different buyer, and they search by engine, platform and discipline. If it is a real line of business it needs its own section.

And what not to

  • Announcement posts as a content strategy. They reach people who already follow you, which is the audience you did not need to reach.
  • Lore and worldbuilding before launch. It is the writing everybody wants to do and it is read by people who have already bought the game.
  • "Top 10 games like ours" pages that exist to rank rather than to help. They are transparently self-serving, they do not get linked, and they are the version of the comparison page that fails.
  • Chasing the genre head terms. The enthusiast press owns them, they have owned them for fifteen years, and a studio site is not going to take them.
  • A blog that mixes devlog, announcements and marketing in one feed. The three have different audiences and the feed serves none of them.

The expensive mistakes

Treating Google as the discovery channel

Costs you A year of work aimed at the wrong conversion, and a report full of sessions

Treat the storefront as the search engine and the website as what feeds it. Measure wishlists, demos and signups.

Launching the website at launch

Costs you The entire window in which wishlists accumulate, which does not reopen

The site exists from the announcement, and everything on it is aimed at somebody who is deciding whether to wishlist.

Untagged links to the store

Costs you Permanent loss of the only attribution you were ever going to get

Tag every outbound link before the next announcement. It takes an hour and it cannot be done later.

Letting the devlog become the marketing plan

Costs you A following made of other developers, and no wishlists

Keep the devlog, budget it as hiring and reputation work, and write the comparison and mechanic pages separately.

Ceding the wiki by default

Costs you A hosted wiki outranking you for your own mechanics, permanently

Decide before launch. Host it, support one, or accept one deliberately and link to it.

Sending keys to creators without a disclosure requirement

Costs you A regulatory exposure you did not know you had, on somebody else's channel

Write the disclosure into the agreement as a condition of the key, keep the correspondence, and check what went out.

Reporting traffic to the studio

Costs you Decisions made on a number that does not predict anything here

Report wishlist actions and demo installs as leading indicators, units and revenue as business indicators, and state the attribution gap.

What to measure

Attribution is worse here than anywhere else in this directory, and pretending otherwise is the fastest way to lose a studio's trust. The storefront holds the conversion, your analytics hold the visit, and the join between them is a UTM parameter you either set or did not.

Leading indicators

Move first. They predict, they do not prove.

  • Wishlist actions by source

    Steamworks reporting, joined to your own UTM data

    The number that matters most and the one that only works if the links were tagged. Report it with the untagged share stated, because there always is one.

  • Impressions on the mechanic and comparison cluster

    Search Console, filtered to queries that describe a game rather than name one

    The slowest indicator and the one that compounds. It is also the only segment in the report that is genuinely a result of the writing rather than of a trailer.

  • Demo installs and time played

    Storefront reporting

    A far better predictor than any traffic number, because it is the first thing a person does that costs them something.

  • Newsletter and Discord joins

    Your own list and server

    The audience you can reach at launch without asking a platform's permission. Worth reporting separately from wishlists, because they behave differently at a sale.

Business indicators

The ones a manager acts on.

  • Wishlist to purchase conversion at launch and at the first sale

    Storefront reporting

    The quality signal on everything above. A large wishlist with a poor conversion usually means the page promised something the game is not.

  • Units and revenue by region

    Storefront reporting

    The number that decides whether the localisation pass was worth doing, and it is the only honest input to that decision.

  • Review count and score in the first two weeks

    Storefront reporting

    It feeds the storefront's own visibility mechanics, which is the closest thing to a ranking factor in this industry. Never build a process that asks for a review in exchange for anything.

  • Inbound work-for-hire enquiries

    Your own CRM or inbox

    Reported separately if that is a real line of business, because it has a different cycle and a different buyer and it will otherwise be lost inside the game numbers.

The verdict

The hard part of this industry is not the writing. It is accepting that the results page that decides your revenue belongs to somebody else, and that your website's job is to send well-prepared people into it.

Once that is accepted the work is unusually tractable. The comparison and mechanic clusters are almost uncontested, the assets are things only you can write, and the highest-return activity is participating honestly in places you already read.

The shortest assessment of game studio SEO services I know is three questions long. Will they tag the outbound store links before anything else? Will they report wishlists rather than sessions? Can they tell you which queries the storefront answers and which ones you can?

Most firms selling SEO services for game developers answer none of those well, because all three make the engagement look smaller and slower. I would not sign without the first one, since it is the only thing on the list that cannot be recovered later.

FAQ

Game development SEO questions

  • Is SEO even worth doing when Steam is where people search?
    Yes, but for a different outcome. Search is how somebody finds a game they did not know existed, usually through a comparison or a mechanic query, and how they answer questions before wishlisting. It is not how they buy.
  • How long before this produces anything?
    Six to twelve months for the comparison and mechanic cluster to build, and it lands as wishlists rather than sales. The compatibility and press-kit work pays back in weeks, because those queries already exist.
  • Should we host our own wiki?
    It depends on whether you have someone to run it. Hosting it keeps the traffic and the mechanics queries; supporting an independent one keeps the community goodwill. The wrong answer is discovering after launch that a hosted wiki now outranks you.
  • Does the devlog help us sell games?
    Rarely. It reaches other developers, which is genuinely valuable for hiring, peer links and reputation. Keep it, and budget it as that rather than as a route to players.
  • What do we do about creators and disclosure?
    Write the disclosure requirement into the agreement as a condition of receiving the key, keep the correspondence, and check what actually went out. The FTC Endorsement Guides are the source and the failure is almost always that nobody looked.
  • Do we need a separate site for work-for-hire?
    Not a separate site, a separate section with its own navigation. A publisher searching for a co-development partner and a player searching for a game want completely different pages, and one page cannot serve both.
  • Are the budget figures on this page quotes?
    No. They are editorial estimates and the bands are wide on purpose, because a solo developer and a thirty-person studio are both described by the word here. Treat them as a shape, not a price.
  • What is the one thing to do first?
    Tag every outbound link to the storefront. It takes an hour, it is the only item on this page that cannot be done retroactively, and without it none of the reporting below works.

Run it yourself, or have someone own it

Everything above is written to be run without us, and the free path is genuinely most of the value for a single-location business. Where these plans stall is almost never the plan. It is that nobody owns it after the first month. That is the job we do, with search as one distribution layer inside a wider system rather than the whole engagement.

See how that worksAll industries