How to audit an Apify Actor listing before you publish

A useful Apify Actor listing tells a prospective user what job the Actor performs, what they need to provide, and what they will receive. An audit is a way to find gaps in that explanation before you publish or revise a listing. The score is a starting point for review, rather than evidence that the Actor will rank or convert well.

ActorConsole's public listing audit checks the available search title, search description, main description, and README. Here is a repeatable way to use those checks without letting a score replace your judgment.

1. Write down the job before editing the title

Use one sentence to describe the intended task: "Given a list of public product URLs, return each product name, displayed price, currency, and source URL." This is an illustrative listing brief, not a claim about an existing Actor.

Check every public claim against the actual implementation. If the Actor does not return historical prices, avoid describing it as a price-history tool. If access requires a particular input or authentication method, explain that requirement. A more specific promise is easier for a user to evaluate and easier for you to test.

2. Run the public audit and inspect each assessed check

Open the audit tool, enter the public Actor identifier or URL accepted by the form, and run the audit. Review the search preview and the individual checks. The current editorial guidelines are:

• Search title: 20–60 characters.
• Search description: 80–160 characters.
• Main description: at least 80 characters.
• Usage documentation: at least 300 characters when README content is available.
• Structured documentation: Markdown headings when README content is available.

Those ranges are tool guidelines. They are not Apify ranking rules, and rendered text width varies. A title can satisfy the character check while remaining vague; a description can be long enough while omitting the actual output. Read the copy as a user would.

3. Treat unavailable documentation as a separate review task

The public source may not return README content. When that happens, the documentation checks are marked unavailable and excluded from the assessed score. A high score across the remaining checks does not establish that the README is complete.

Open the Actor page and inspect the README directly. Look for a short purpose statement, a minimal working input, the shape of the output, important limitations, and instructions for interpreting failures or empty results. Export the audit if you want to keep a record of which checks were actually assessed.

4. Make examples easy to reproduce

Choose the smallest input that demonstrates the primary task. Show a corresponding output and explain the fields a user will depend on. Use sample values that are clearly illustrative, and remove account credentials or private records from examples.

For the product-URL example above, an output explanation might identify productName, displayedPrice, currency, sourceUrl, and collectedAt. Only document fields that the Actor actually returns. If a page has no visible price, explain the supported empty-value behavior rather than promising that a price is always available.

Apify also emphasizes clear README documentation and ongoing testing in its Actor publishing guidance. Use that guidance alongside a real run of your Actor; a copy audit cannot establish whether the scraper or integration behaves correctly.

5. Review proposals before applying them

If you manage the Actor in ActorConsole, generate improvements from the Actor workspace and compare the proposal with the current fields. Select only the changes that are supported by the Actor. Review the confirmation and inspect each application result. A queued job or a partly completed batch does not mean every field was updated.

The listing improvement guide explains that review flow. The publishing guide covers the separate Store-status workflow. Review both when your task involves updating a listing and making the Actor public.

A final pre-publication checklist

• The title names a concrete task.
• The description identifies the expected data and a use case.
• A minimal example agrees with a real test run.
• The README explains required inputs, output fields, limitations, and empty results.
• Unavailable audit checks have been reviewed manually.
• Proposed edits have been checked and their application results inspected.
• Pricing units and publication readiness have been reviewed separately.

Start with the public listing audit. If pricing is part of the same release, work through the cost-based pricing example before applying a pricing proposal.