How to Submit a PolyTrack Track: Review and Publishing Process

Submitting a track is more than pasting a code

PolyTrackCodes accepts community track submissions through the Submit Your Track page. The goal is simple: help good custom PolyTrack maps become clear, playable, public track pages that other players can trust.

But a strong submission is not just a working code. It needs enough context for reviewers to understand the track, enough visual information for players to preview it, and enough accuracy that the final page does not mislead someone who is deciding what to play next.

This guide explains how to submit a track, what kind of submissions are most likely to pass review, what usually blocks approval, and what happens between submission, approval, publication, and search visibility.

Those are separate steps. A moderator may approve a playable track before its public page is ready for search engines. Keeping the steps separate lets us publish useful creator pages without automatically sending thin, duplicated, or unfinished pages into search results.

Before you submit: test the track yourself

Before opening the form, import your own code back into PolyTrack and drive the track at least once from start to finish.

This quick check catches the most common problems:

• The code was copied incompletely.
• The track does not load in the current version.
• The start, checkpoints, or finish are missing or broken.
• The difficulty feels very different from what you planned.
• A jump or landing that seemed fun in the editor is unreliable in a real run.
• The submitted version is not the final version you meant to share.

If the track cannot be imported, reviewers cannot approve it. If the track imports but feels unfinished, it may need revision before it becomes a public page.

What the submit form asks for

The submission form asks for the information needed to build a useful public track page.

The required fields are required for a reason. They are not just form rules; they are the basic information needed to review and publish a track responsibly.

Email is required, but it is not public

Email is required so we can send the result of the review. It is not displayed publicly on the track page.

We may use it to send:

• The published track link if your submission is approved
• A revision note if the track needs changes
• A short rejection reason if the track is not a fit

Use an email address you can actually receive. If your email is invalid, the form will not accept the submission.

The overview image matters a lot

Every new submission needs a full track overview image. The best image is a zoomed-out editor screenshot that shows the entire layout.

A good overview image should:

• Show the whole track, not only the starting area
• Be taken from the editor or a top-down view when possible
• Make the route shape readable
• Include enough visual context for players to understand the layout
• Be clear enough that the track does not look like a random close-up

The overview image should not be:

• A driving-camera screenshot
• A cropped image of only the car
• A blurry preview
• A random thumbnail unrelated to the track
• A placeholder or default image

Players often decide whether to import a track by looking at the preview first. A strong overview image makes your track easier to trust.

Choose the right difficulty

Difficulty should describe the real driving experience, not the creator's personal skill level.

Use this rough guide:

Overrating a track can scare away the right audience. Underrating it can frustrate new players. The best rating is honest.

Pick the category that describes the main experience

The category should tell players what kind of track they are about to play.

• Racing: Standard route, corners, flow, and lap-style driving
• Speedrun: Built around time optimization, fast lines, and repeatable runs
• Drift: Sliding, angle control, and linked corners are central
• Stunt: Jumps, loops, flips, wall rides, or spectacle sections
• Technical: Precision, narrow paths, difficult turns, or control training
• Art: Visual design or creative layout is the main point
• Tutorial: Built to teach a mechanic or help new players practice

If a track has multiple elements, pick the one that defines the experience. A racing track with one jump is usually still Racing. A jump-heavy route where landing is the whole challenge is probably Stunt.

Write a useful description

A good description helps both reviewers and players. It does not need to be long, but it should be specific.

Weak description:

Cool track. Try it.

Better description:

A medium racing track with two fast tunnel sections, a downhill jump after checkpoint 3, and a tight final chicane. Brake early before the last corner if you want a clean finish.

Try to include at least two concrete details, such as:

• What kind of route it is
• The hardest section
• A driving tip
• Whether it is beginner-friendly or built for experienced players
• Any unusual mechanic, shortcut, or theme
• What changed if this is an updated version

Specific descriptions make approval easier because reviewers can compare the submitted text with the actual track.

If this is an update, explain what changed

If you are improving a previously submitted or published track, choose the update option.

For updates, include:

• The original track link or title
• What changed in the new version
• Whether the difficulty changed
• Whether checkpoints, finish, jumps, or route shape changed
• Why the new version is better

Good update note:

Fixed the landing after checkpoint 3, widened the final chicane, and changed the difficulty from Hard to Medium because the new route is more forgiving.

This helps reviewers compare the new code against the earlier version instead of guessing.

What reviewers check

After a track is submitted, reviewers look at both the form details and the track itself.

The review usually includes these checks:

1. Import check: Does the code load correctly?
2. Basic structure: Does the track have a usable start, route, checkpoints, and finish?
3. Title and author: Is the creator credit clear and reasonable?
4. Description match: Does the description match what the track actually does?
5. Difficulty match: Is the selected difficulty fair?
6. Category match: Is the track in the right browsing group?
7. Overview image: Is the submitted image a real full-track preview?
8. Duplicate check: Is this original, or is it too similar to something already published?
9. Playability check: Does the track feel like a real playable submission rather than a fragment?
10. Policy check: Is the content appropriate for a public community library?

Some tracks also get a deeper review through internal tools such as the decoder and review racer. Those tools help inspect route shape, checkpoints, preview quality, and possible risk sections before a final decision.

The full review and publishing process

Every submission follows the same general path.

1. Automatic pre-screening

The submission is first checked for obvious problems. This includes malformed track codes, unusable titles, descriptions with too little information, suspicious placeholder content, and codes that appear invalid or duplicated.

If the problem is clear, the form can ask for a correction immediately. This keeps broken submissions out of the moderation queue and gives the creator a useful next step instead of making them wait for a manual response.

2. Moderator review

A moderator then reviews the submission details and the track itself. The possible outcomes are:

• Approved: The track is suitable for publication.
• Needs revision: The idea may be good, but the code, image, description, difficulty, category, or route needs work.
• Declined: The submission is broken, duplicated, inappropriate, misleading, or not suitable for the public library.

Approval is based on the whole submission. A working code alone is not enough if the public page would give players no useful information about the track.

3. Public page confirmation

After approval, the track record and public page are prepared. We confirm that the detail page opens, the track code is available, the overview image loads, and the published page matches the approved submission.

This is why an approved track may not receive its final public link at the exact moment a moderator makes the decision. The page still needs to be confirmed online.

4. Search quality check

Once the page is available, it receives a separate search-quality decision:

• Eligible: The page has enough original, track-specific information to be included in the track sitemap.
• Pending quality: The page works for players, but its description or supporting information still needs improvement before search inclusion.
• Excluded: The page should remain outside search, such as an automatically named, clearly duplicated, or very low-value page.

A page that is pending quality can still be opened directly and its code can still be copied. It is simply kept out of search until the content is strong enough.

5. Sitemap and IndexNow submission

Eligible pages are added to the live track sitemap using the official www.polytrackcodes.com address. After the public page is confirmed and added to that sitemap, its URL is submitted through IndexNow so participating search engines can discover the update sooner.

IndexNow submission is a discovery notification, not a promise of ranking or inclusion. Search engines still decide whether and when to crawl, index, and rank a page. If a notification fails, the public track page stays online and the failed attempt can be retried.

In short, the path is:

Submit → pre-screen → moderator review → public page confirmation → search quality check → sitemap → IndexNow

This example uses fictional names and URLs. Real creator emails, track codes, private notes, access details, and account information are never shown in public guides.

What makes a submission more likely to pass

Strong submissions usually have these traits:

• The code imports cleanly.
• The track can be finished.
• The title is readable and not random characters.
• The description names real parts of the track.
• The difficulty is honest.
• The category matches the actual gameplay.
• The overview image shows the full layout.
• The route has a clear idea, not just random blocks.
• The track is original or clearly improved from an earlier version.
• The submission includes enough information that the final page can help other players.

The review is not only about whether the track is hard or beautiful. We care about whether the final public page will be useful.

Common reasons submissions do not pass

Submissions may be declined or sent back for revision when:

• The code cannot be imported.
• The overview image is missing, cropped, or not a full-track view.
• The title is unclear or looks like spam.
• The description is too vague to help players.
• The selected difficulty is far from the actual experience.
• The selected category is misleading.
• The video link is not a public web URL.
• The submission is a duplicate or too similar to an existing track.
• The route is unfinished, broken, or only a fragment.
• The track uses inappropriate or policy-violating content.

If your track is declined, that does not always mean the idea is bad. Often it means the submission needs a cleaner code, a better overview image, clearer notes, or a more accurate difficulty rating.

What happens after approval

Approval is not the final step by itself. We separate the workflow so public pages do not go live half-finished.

The normal creator-facing path looks like this:

1. The submission is reviewed.
2. If it is approved, the track record is prepared for publication.
3. The public track page, image, and code are checked online.
4. The page receives its separate search-quality status.
5. A result email is sent to the submitter when the public link is ready.

This separation matters. A track can be approved internally but still need online confirmation before we send the final published link.

When everything is confirmed, the creator receives a link to the public page. That page can then be shared with other players even if search engines have not indexed it yet.

How long review takes

Review time depends on the current queue and the quality of the submission.

A clean submission is faster to review because the important pieces are already there: working code, clear image, useful description, accurate category, and valid email.

A messy submission takes longer because reviewers may need to decode the track, test it, inspect whether it is a duplicate, rewrite unclear information, or decide whether to request changes.

How to submit a better second version

If your first version needs changes, submit an improved version instead of sending the same code again.

Before resubmitting:

• Fix the issue mentioned in the review note.
• Import-test the new code.
• Capture a fresh full-track overview image.
• Choose the update option.
• Include the original title or link.
• Explain exactly what changed.

A clear update note helps reviewers move faster and gives your improved version a better chance.

Final checklist before you submit

Use this checklist before clicking submit:

• I tested the code by importing it myself.
• The track can be finished.
• The title is readable.
• The author name is how I want to be credited.
• My email is valid.
• The description explains the actual track.
• The difficulty is honest.
• The category matches the main gameplay.
• The overview image shows the full layout.
• The video link, if included, starts with http or https.
• If this is an update, I explained what changed.

If you can check all of those, your submission is much easier to review and much more likely to become a useful public track page.

Ready to share your track? Start here: Submit Your Track.