Policies and Approvals

Open Workspace, then Policies, and choose the site. The page reads from top to bottom: the hard rules, the site’s rules, approval chains, protected pages and groups, holds, caps and windows, the kill switch, emergency policies, and who changed what.

A site with no rule of its own shows Every change needs approval. Use the recommended policy adds rules that let small, reversible, low-risk changes run by themselves: links, structured data from business facts, and meta descriptions once their quality bar passes. Changes these rules allow run without a person’s approval, and your workspace is responsible for the rules it turns on.

Some rules are in code. They hold for every site and no policy can loosen them.

• Approval is always needed for high-risk changes, protected pages, redirects, noindex, deletion and canonical changes on pages with clicks, robots.txt, changes to more than 25 pages, anything that cannot be undone, and model-written text whose quality bar has not passed.
• Nothing is ever hard-deleted: a deletion is an unpublish and a 301 redirect, both reversible.
• A protected page needs an approver who did not write or edit the change.
• Nothing runs while the kill switch is on or a Critical incident is open, except emergency policies.
• Neither Nori nor any model approves or carries out a change, and neither does QueryRev staff.

A rule matches kinds of change, such as titles, meta descriptions, structured data, content sections, internal links or redirects, on the whole site or on some pages, and says what happens to a matching change.

When several rules match, the strictest wins and every matching chain is required. When no rule matches, one member who may approve is enough. A rule can be narrowed to low-risk changes only, or kept off money pages, and every rule keeps its versions in the record.

An approval workflow in QueryRev is a chain of steps. Each step says who approves and how many votes it needs, and can exclude whoever wrote or edited the change. Steps run in order, and a reject at any step ends the chain. The Default chain is any one member who may approve.

Editing a chain changes it for every rule that uses it. An approver can also ask a question instead of voting: the chain then waits, and everyone on it sees the question.

Protect a page, or a group of pages by the start of their path, a path pattern, a page role or a value tier. Every change on a protected page needs an approver who did not write or edit it, and a group covers pages added to it later.

• Verification hold: a page inside a verification window waits, so one change is measured before the next one lands on the same page.
• Publish windows: the days and hours changes may run, in the site’s time zone.
• Freeze dates: days when nothing runs, such as a sale or a launch.
• Auto cap: how many changes may run by themselves in a day.
• Write cap: how many item writes a day, and how fast.

Lowering a cap, adding a freeze or narrowing a window tightens the policy; anything else loosens it.

The kill switch pauses every execution and rollback on a site at once, for example while a theme update is in progress. Say why when you turn it on; the reason is shown beside the switch. Anyone who may execute on the site can turn it on, and only a Founder can turn it off.

Emergency policies are the one exception: steps approved in advance that may run without a person while a Critical or High incident is open on a page, such as removing an injected link. Each run writes an emergency entry to the Change Ledger and alerts at once.

A Founder may loosen and tighten the policy. An SEO Manager may only tighten it: add approvers, protect pages, lower caps or turn the kill switch on. Other roles can read it. Who Changed What, at the foot of the page, lists every change to the policy with its author and time.