Opening Rankbank0.0s
Getting startedCreating your Rankbank accountAdding your first websiteProving your site is yoursWriter view and Site owner viewHow Rankbank tells you thingsYour dashboardRankbank Pro and billing
Site audit & search growthThe SEO overview, explainedHow Rankbank reads your siteThe site health scoreThe Problems to fix pageEvery problem type, explainedYour fix listFindings: how to read a cardEverything Rankbank looks forThe map of your siteConnecting Google Search ConsoleThe growth planSuggested linksTopics and content ideasAuthority: how much weight your site carriesThe Search traffic pagePast reads and history
Guest postsGuest posting on RankbankSubmitting your first guest postImporting from Google DocsWriting in the Rankbank editorReview & send: the last step before the editorsWhen the editors ask for changesTracking your guest postsFor site owners: opening your site to guest postsFor site owners: writing your guidelinesFor site owners: reviewing a submissionFor site owners: publishing and the live checkThe Content Library
Link exchangeLink swaps on RankbankSetting up your site for swapsPages you shareFinding a site to swap withSending a swap requestReviewing a swap request you receivedAsking a partner for a linkAnswering a link requestWhen the page is published somewhere you can't editHow Rankbank keeps watchThe partner ledger
Content calendarThe content calendarSetting up your calendarWhere the keywords come fromReading the calendarSteering an article before it's writtenReviewing and editing a draftConnecting where it publishesPublishing and what happens nextStyle & settings
TutorialsYour first site audit, from "read my site" to fixes you can ship this weekConnecting Search Console and turning its data into clicksWriting a guest post that gets accepted, the full pathRunning guest posts on your site without letting quality slipYour first link swap, start to finishKeeping your links alive, from wording changes to missing linksA month of content on autopilot, done properly
RankbankHelp center
Open Rankbank →
Getting startedCreating your Rankbank accountAdding your first websiteProving your site is yoursWriter view and Site owner viewHow Rankbank tells you thingsYour dashboardRankbank Pro and billing
Site audit & search growthThe SEO overview, explainedHow Rankbank reads your siteThe site health scoreThe Problems to fix pageEvery problem type, explainedYour fix listFindings: how to read a cardEverything Rankbank looks forThe map of your siteConnecting Google Search ConsoleThe growth planSuggested linksTopics and content ideasAuthority: how much weight your site carriesThe Search traffic pagePast reads and history
Guest postsGuest posting on RankbankSubmitting your first guest postImporting from Google DocsWriting in the Rankbank editorReview & send: the last step before the editorsWhen the editors ask for changesTracking your guest postsFor site owners: opening your site to guest postsFor site owners: writing your guidelinesFor site owners: reviewing a submissionFor site owners: publishing and the live checkThe Content Library
Link exchangeLink swaps on RankbankSetting up your site for swapsPages you shareFinding a site to swap withSending a swap requestReviewing a swap request you receivedAsking a partner for a linkAnswering a link requestWhen the page is published somewhere you can't editHow Rankbank keeps watchThe partner ledger
Content calendarThe content calendarSetting up your calendarWhere the keywords come fromReading the calendarSteering an article before it's writtenReviewing and editing a draftConnecting where it publishesPublishing and what happens nextStyle & settings
TutorialsYour first site audit, from "read my site" to fixes you can ship this weekConnecting Search Console and turning its data into clicksWriting a guest post that gets accepted, the full pathRunning guest posts on your site without letting quality slipYour first link swap, start to finishKeeping your links alive, from wording changes to missing linksA month of content on autopilot, done properly
  1. Help center
  2. /
  3. Guest posts
  4. /
  5. For site owners: reviewing a submission

For site owners: reviewing a submission

Updated August 24, 2026


This article is for site owners and their editors. The author's view of the same conversation is When the editors ask for changes.

A submission arrives with a notification headed "New guest post to review: {title}" and the line "Someone submitted an article for your site — it's waiting on your decision." It is filed under Action needed and it links straight to the review workspace. Notifications are in-app only, so the bell is where these show up.

The queue

Articles in the admin section opens Admin articles, described as "Review submitted article packages for your organisation."

A Review status filter narrows the list: All review states, Submitted, Under Review, Approved, Changes Requested, Rejected.

The columns give you enough to triage without opening anything:

  • Article title, with the version number beside it.
  • Author.
  • Submitted at.
  • Total links.
  • External domains.
  • Metrics completion, a fraction of how many of those domains Rankbank found public data for.
  • Status.

Each row has a Review action.

The admin articles queue listing submitted guest posts with their author, submission date, link counts and status, with the review status filter above.
Filter to Submitted to see what nobody has picked up yet.

Work Submitted first, then Under Review. A high external domain count on an otherwise short article is worth opening early.

What you are looking at

The review page is subtitled "Review the immutable submitted package. Source, links, and metric snapshots are read-only."

That is not a limitation, it is the design. You are reviewing a frozen snapshot of exactly what the author sent, including the link data as it stood at that moment. Nothing you do changes it, and nothing the author does changes it either, because their editor is locked while you read. If they resubmit, you get a new version rather than a moving target.

Four stat tiles sit at the top: Total links, External links, External domains, Metrics complete.

Article summary gives you the context: Author, Author email, Submitted at, Submission version, Destination website, Domain, Target country, and Accepted guideline, shown as {title} (v{n}).

That last field is the one to read before you judge anything. It names the exact version of your rules the author agreed to. If you tightened your rules last week, this article is not held to the new ones.

Source shows either the Google Doc address, clickable, or "Written in the Rankbank editor".

Preview mode and Review mode

The article itself sits in a workspace with a two-button toggle: Preview mode and Review mode.

Preview mode is for reading. Nothing is clickable, nothing gets attached, you just read the piece the way a visitor would.

Review mode turns the article into a commenting surface. It gets an amber border and a hint: "Select text or click an image to add a rework comment."

Select any run of text and a modal opens titled Comment on selected text, or click an image for Comment on selected image. Both explain what they do: "This creates an author-visible rework comment tied to the current submitted version." The modal shows the exact text you selected back to you, so there is no doubt about what the comment attaches to. Write the note and press Add rework comment.

The review workspace in Review mode with an amber border, a sentence selected in the article, and the "Comment on selected text" modal open showing the quoted selection and a comment field.
The selected sentence is quoted back inside the modal. The author sees the same quote.

This is the single best habit in the whole module. "The third section is unsupported" is an argument. The same sentence attached to the actual paragraph is a task.

At the bottom of the workspace, a bar counts what you have attached: "{n} open rework comments attached to this submitted version." Next to it, Send back for rework.

General comments

Not everything is about one sentence. Add general rework comment opens a modal for overall direction, and it says when to use it: "Use highlighted comments from the article preview for specific text or image feedback. General comments are useful for overall direction."

Here you choose a Comment type, one of Overall, Grammar, Seo, Links, Formatting, Images, Brand or Other, and a Visibility.

Visibility has two values and the difference is absolute.

Author visible comments are part of the conversation. The author reads them, replies to them, and marks them addressed.

Internal admin comments are for your team. They never notify the author, never appear on their page, and never reach them by any route. That is deliberate, so an editor can write "this is the third pitch from this agency" without it becoming a diplomatic incident.

You can Resolve and Reopen any comment. Authors cannot: they can only reply and press Mark Addressed. Resolution belongs to the person who raised the point.

The link summary

Link summary has three tabs: All external links, Passing links, and Needs attention, each with a count.

Every row shows the Link text, the External URL, its Status and a URL check. Start with Needs attention, since that is where a dead link or a redirect chain surfaces.

Domain metrics snapshot is the public data on each external domain as it stood when the author submitted: authority score, global rank, referring domains, when the underlying dataset was published, and the insight status. Rows where the data never arrived are normal, not suspicious. It is a signal, not a verdict, and the author sees the same figures.

The three decisions

Decision controls sit at the bottom of the page, under "Review decisions are recorded immutably and remain scoped to your organisation."

Start Review claims the article. It is only available while the status is Submitted, and it moves the article to Under review. The author gets a low-key notification: "The site has picked it up. Nothing to do — we'll tell you what they decide." Press it when you actually start, because it is the only signal the author gets that the article is not sitting in a void.

Approve takes an optional note. The dialog is Approve article package: "This approves the latest submitted version and prepares the Guest Post for publication." The author is notified with "The site accepted it. They'll take it from here and publish it." What comes next is publishing and the live check.

Request Changes requires a note of at least ten characters, and the dialog explains why it matters: "Tell the writer what to change — your note goes to them word for word, and editing reopens on their side." The field is labelled Your note to the writer, with the helper "A sentence or two is plenty. For line-by-line feedback, highlight text in the article preview instead."

Reject also requires a note. The dialog is Reject article package: "This rejection is final for the current Admin-review phase." There is no resubmit path afterwards, so the note is the only thing the author gets. Write a real one.

The decision controls at the bottom of the review page with Start Review, Approve, Request Changes and Reject buttons.
Start Review is only live while the article is Submitted. The other three stay available until a final decision is recorded.

The rule the product enforces

You cannot send an article back for rework without saying what is wrong with it.

Send back for rework in the review workspace stays disabled until at least one open, author-visible comment exists on the current submitted version. Try it anyway and you get: "Add at least one open author-visible review comment before sending this back for rework."

The rule is enforced in the database, not only in the interface. It exists because a bare "changes requested" with nothing attached is the worst thing an author can receive: they know you want something, they do not know what, and the next version is a guess.

Request Changes satisfies the same rule a different way. If no open author-visible comment exists yet, the note you type in that dialog becomes one, which is why the button works without pre-attaching anything. Use it when the feedback is genuinely overall. Use Review mode when it is about specific paragraphs, which is most of the time.

Approving is the other side of the same coin: it resolves the open author-visible comments on the version you approved, so nothing is left hanging when the article moves on to publication.

The trail you are leaving

Three disclosures hold the history, all closed by default with the same framing: open them when you need them, not as part of every review.

Review history, "Open only when you need the immutable decision trail.", lists every decision with its reviewer, note and timestamp.

Version history, "Open only when you need prior immutable source versions.", holds every version the author submitted, with its status, word count and source.

Rework comments, "Open only when you need general comments outside the highlighted article review.", holds the general comments.

None of it can be edited or deleted. Six months later, when somebody asks why an article ran or did not, the answer is on the page.

Warning

Decisions land on the latest submitted version only. If you have had a review tab open while the author resubmitted, Rankbank refuses your decision rather than applying it to the wrong package: "a conflicting review decision already exists for this submitted package". Reload the page and review the version that is actually in front of you.

Once a final decision has been recorded, the page says so with Decision recorded: "This submitted package already has a final Admin review decision."

← For site owners: writing your guidelinesFor site owners: publishing and the live check →

Still stuck?

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

On this page

The queueWhat you are looking atPreview mode and Review modeGeneral commentsThe link summaryThe three decisionsThe rule the product enforcesThe trail you are leaving
Rankbank — Editorial collaborationOpen RankbankHelp home