Handing fixes to developers
To hand Rubric's fixes to a developer, export the Action Plan as action-plan.csv from the report, then turn each row into a ticket that names the check, the affected pages and the exact markup it expects. Ask the developer to verify every fix in view-source, not the inspector, because non-JavaScript engines only read what the server sends. A precise checklist plus a view-source check is what makes a fix stick.
- →Export the ranked fixes with the
action-plan.csvdownload button in the report. - →Give each ticket the exact markup the check expects and where it goes, not a vague instruction.
- →Verify in view-source, never the inspector: engines that skip JavaScript only see the server's raw HTML.
Export the Action Plan as a checklist
The report has a download button for action-plan.csv, one of the four CSV exports Rubric produces alongside pages.csv, broken-links.csv and sitemap-issues.csv. The action-plan file gives you the ranked fixes as rows you can paste straight into a ticket tracker, drop into a shared sheet, or hand over as a checklist.
Each row identifies the check behind the fix, the pillar it belongs to (Known, Findable or Trusted) and the scope it affects, so a developer can act on it without logging into Rubric. See exporting-your-data for what the other CSVs contain and exporting-to-csv-and-sheets for importing them into a spreadsheet.
Give each check the exact markup it expects
A check passes only when the specific element is present and valid, not when it has been attempted. A ticket that just says "add schema" or "improve the meta" produces guesses. Convert each row into a ticket that states four things: what is failing, which pages, the exact snippet or value expected, and where it goes.
Here is the pattern for two common fixes.
A missing meta description is a page-level fix. The expected element:
<meta name="description" content="A single, unique 50 to 160 character summary of this page's answer.">A missing Organization entity is a template fix that belongs in the shared <head>:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Co",
"url": "https://example.com/",
"logo": "https://example.com/assets/logo.png",
"sameAs": [
"https://www.linkedin.com/company/example-co",
"https://en.wikipedia.org/wiki/Example_Co"
]
}
</script>For the full entity pattern, including the linked Person block, see adding-organization-schema. For why the placement matters, see rendering-schema-without-javascript.
Verify in view-source, not the inspector
This is the single instruction that saves the most wasted developer time, so make it a required step on every schema or markup ticket.
Render parity is the match between what a person sees in a browser and what a non-JavaScript engine reads. ChatGPT, Perplexity and Claude do not run JavaScript, so they only read the raw HTML the server sent. The browser inspector (the Elements panel, or right-click then Inspect) shows the DOM after JavaScript has run, so it will happily display schema that those engines never see. That is exactly how a "fixed" check keeps failing.
To test the way an engine reads:
view-source: before the URL.application/ld+json; for a meta description, search for name="description".Close the loop with a re-crawl
A developer marking a ticket done is not the same as Rubric seeing the fix. Rubric reads the live page, so after the work ships, clear the CDN cache and re-run the crawl from the report header, or wait for the automatic re-check if the site is on your Watch list. The new report confirms which checks cleared and the Action Plan re-ranks around whatever is still open. See working-the-action-plan for the full re-run sequence.