# Make your listing useful and discoverable

Explain a released Block or Project Type clearly, demonstrate its results, and share the right public page.

## Start with the result
A useful listing lets someone decide whether the capability fits their work before installing it. Name the actual task. Explain what they start with, what they can change, and what they get. Keep requirements and limits next to the relevant claim.

A Block is a reusable capability or workspace. Inside a Project Type, its placement is a Step. A Project Type describes the ordered production workflow. Do not describe a full workspace as a single file converter just because its contract declares an input and an output.

## Write a description someone can use
Use a short summary for the listing card and a fuller explanation for the listing page. Base both on the released source and behavior you have tested. An AI-generated explanation needs the same review as one you write yourself.

For an image-processing Block, a useful description might explain that it takes an image, changes line thickness, and returns an image, then identify which controls and limitations the implementation actually supports. Only use that description if the released code performs those operations. Avoid untested claims about quality, speed, model support, or guaranteed results.

For a Project Type, explain the order of work and what the user will still need to provide or review. Include its real Blocks and a representative finished result. A long list of keywords does not help someone choose a workflow.

## Show a representative demonstration
Creators can edit the presentation of their own published Block or Project Type. In the listing presentation controls, upload an image or a short MP4 you have permission to publish. Current limits are 8 MB for images and 12 MB for MP4 previews. The upload belongs to the selected release; check the preview again after releasing a new version.

Show the starting material, the relevant controls, and the result from that release. For a Project Type, show how the workflow reaches the finished output. A demo should make the capability easier to assess. Do not publish private project material or include credentials in a recording.

The interactive preview and an uploaded demonstration serve different purposes: the preview lets someone try the capability with sample content; the recording can explain how you used it. Hosted actions and runtime constraints still apply. Read [Test and preview a Block](/docs/build/testing) before describing what a preview proves.

## Give it useful context
- Add or choose a recommended workflow for a Block so people can see where it fits.
- Keep the released inputs, outputs, semantic roles, and requested permissions accurate.
- Use the version history when the behavior changes, and preserve source attribution and licensing when remixing.
- Link a tutorial to the specific Block or Project Type it actually uses.
- Use your public creator username. Keep email addresses and private customer feedback out of public package metadata.

Read [Versions, checkpoints, and remixes](/docs/distribute/versioning) and [Publish and share](/docs/distribute/publishing).

## Share the public listing
Open the listing and use its normal page URL when sharing a tutorial or demonstration. The main listing follows the current public release. A version URL is appropriate when a tutorial depends on that exact version. Private drafts are not public listing pages.

Public Community visibility and curated Marketplace approval are separate. Publishing a Community release does not imply that StillMade has selected or endorsed it for the curated Marketplace.

Reviews currently contain one rating and one comment and are visible to the listing creator and administrators. They do not appear in public search snippets or public rating totals. Do not claim a public star rating on the strength of private feedback.

## Search visibility has limits
Public pages include readable descriptions, creator attribution, related links, and search metadata. Search engines choose which pages to index and show. Uploading a video or adding markup does not guarantee higher rankings or stars in search results.

Google and AI search need accessible, useful content. There is no special phrase to repeat or hidden instruction to put in a package. The downloadable [documentation for an LLM](/docs/llms-full.txt) is an authoring resource, not a ranking switch.

If you sponsor a tutorial or provide compensation for coverage, disclose it and ask the publisher to qualify paid links appropriately. Do not buy links intended to pass ranking credit. See [Google's link spam policies](https://developers.google.com/search/docs/essentials/spam-policies#link-spam), [AI search guidance](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide), and [video guidance](https://developers.google.com/search/docs/appearance/video).