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.

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 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.