Rankbench
Topics
Skip to help content

Reviewing a submission

Updated · First published


Review guest post submissions is the queue, described as "Check each submitted guest post for fit and quality. Approved posts move to final reviewer assignment."

The queue

One row per submitted article: the title and its version, the author, when it was submitted, how many links it makes, how many external domains those touch, the metrics completion, and its status.

A Review status filter narrows it to submitted, under review, approved, changes requested or rejected.

Review opens the package.

The review queue with submitted articles
The link and domain counts are visible before you open anything, which is often enough to triage.

What you are looking at

The submitted package is immutable. The article, its links and the domain figures are a snapshot from the moment it was sent, and they do not change while you read.

That is why the writer's draft locks when they send it. You are both looking at the same thing.

The article renders as the reader would see it, with every link highlighted. Beside it, the link table and the domain figures for each external site the article points at.

Two disclosures hold things you only occasionally need: the decision trail, and previous versions.

Preview and review mode

Preview is reading. Review is marking up.

In review mode, select text or click an image to attach a comment to it: "Select text or click an image to add a rework comment."

Use these rather than general comments wherever you can. A comment attached to the sentence it is about is unambiguous; a general note asking somebody to tighten the middle section starts a conversation.

Comments you leave are visible to the author.

General comments

There is also a general comment box, for direction that is not about one sentence: the piece is aimed at the wrong reader, the structure does not work, this overlaps something you published last month.

The product's own advice is to use highlighted comments for specific text and general ones for overall direction.

The three decisions

Approve accepts the latest submitted version and moves the article towards publication.

Request changes sends it back to the author. Your note goes to them word for word, and their editing reopens.

Reject declines it. This is final for the current review.

An approval can carry an optional note, which the author sees alongside it.

The decision controls with the note field
A change request needs a real note. The product will not let you send one back empty.

The rule the product enforces

You cannot send an article back without saying why.

A change request needs a note of at least ten characters, and where you are requesting rework from highlighted comments, at least one open author-visible comment has to exist first.

This is not bureaucracy. An article returned with no explanation comes back unchanged, and both of you have wasted a week.

The reject path asks for a note too.

The trail you are leaving

Every decision, comment and version is kept and cannot be edited afterwards.

Six months later that record answers the questions that actually come up: have we published this person before, what did we ask for last time, why did we turn down the piece that a competitor later ran.

What happens after approval

The article moves to final reviewer assignment. On a small site that step is quick; on a larger one it is where a second pair of eyes comes in. See final review and the Approver role.

Then you publish it and submit the live URL. See publishing and the live check.

Where to go next

Final review and the Approver role, then publishing and the live check.

Still stuck?

Open Rankbench and the page this article describes — most screens explain themselves as you go.