+10.6score from 54 to 65
Describe the site with schema.org JSON-LD
None of the 4 pages read pass. The homepage publishes no structured data at all: no JSON-LD, no microdata, no RDFa.
Read prompt
My website timeajob.com scored 54/100 on Good for Bots (Fair). Good for Bots measures one thing: whether a language model can read a site and cite it.
I need you to: describe the pages with schema.org JSON-LD.
The check it fails is "Describes itself to machines with schema.org JSON-LD", worth 10.64 points. What the scanner saw: None of the 4 pages read pass. The homepage publishes no structured data at all: no JSON-LD, no microdata, no RDFa.
The scan checked a sample of 4 pages. It does not establish which other pages have the same issues. Use the findings below to locate the responsible templates, components or configuration, and apply the fix wherever the same issue occurs. Pages in the sample with findings:
- https://timeajob.com/: The homepage publishes no structured data at all: no JSON-LD, no microdata, no RDFa.
- https://timeajob.com/changelog/: The page at /changelog/ publishes no structured data at all: no JSON-LD, no microdata, no RDFa.
- https://timeajob.com/contact/: The page at /contact/ publishes no structured data at all: no JSON-LD, no microdata, no RDFa.
- https://timeajob.com/data-deletion/: The page at /data-deletion/ publishes no structured data at all: no JSON-LD, no microdata, no RDFa.
The pages identified as having no structured data need markup added through their
templates. Review the other public page types for the same gap. Use the homepage
example below where it fits, and describe each content page with types that match
its visible content. A passing homepage does not need its markup replaced.
Review structured data across the site's public page types, including those
outside the reported sample. Add or repair it in the templates that generate
each type, using that page's content. Verify a page from each template and keep
existing valid markup. Structured data gives a reader explicit names, types and
relationships for the entities the page describes.
Put a `<script type="application/ld+json">` block in the HTML the server returns. On the
home page describe the organisation and the site; on a content page describe the content
itself: an `Article` for a post, a `Product` for a product, a `BreadcrumbList` for the
trail above it.
Every entity must:
- declare `"@context": "https://schema.org"`;
- declare a `@type` that schema.org defines;
- carry a name: `name`, or `headline` for an article. A type with no name asserts that
something exists without saying what, which is worth nothing to a reader;
- describe what is on the page. Structured data that disagrees with the visible content
is worse than none.
A minimal, correct home page block:
```html
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://timeajob.com/#organization",
"name": "Example Corp",
"url": "https://timeajob.com",
"logo": "https://timeajob.com/logo.png"
},
{
"@type": "WebSite",
"@id": "https://timeajob.com/#website",
"name": "Example Corp",
"url": "https://timeajob.com",
"publisher": { "@id": "https://timeajob.com/#organization" }
}
]
}
</script>
```
The addresses in that example are this site's. The names are not. Replace `Example Corp`
with the organisation's real name, which is the one thing here that cannot be filled in
from the outside.
Work out how to generate this in whatever stack this project uses, from the same data
that renders the page, so the two cannot drift apart.
Two mistakes account for most broken structured data in the wild. Avoid both:
1. **Do not let the template escape the JSON.** A templating engine that escapes variables
by default will turn every `"` into `"`, and the block will look perfectly correct
in the page source while no consumer on earth can parse it, because HTML entities
inside a `<script>` are never decoded. Use the raw output form the templating engine
provides:
`dangerouslySetInnerHTML` in React, `{{{ }}}` in Handlebars, `| safe` in Jinja or
Nunjucks, `@Html.Raw` in Razor.
2. **Do not inject the block with JavaScript.** Tag managers and client-side SEO plugins
add it after the page loads, so a crawler that does not run scripts, which is most of
them, sees nothing at all. The block belongs in the HTML the server sends.
Several separate blocks on one page are fine; the specification requires consumers to
merge them all. A single `@graph`, as above, is just tidier.
The whole report, as markdown, is at https://goodforbots.com/r/timeajob.com.md?scan=cmusm32h702un01o0x4g0893k. Read it first: this prompt covers one finding, and the report has everything the scan saw.
When you are done, summarise what you changed and how to check it against a running instance. Do not try to run the Good for Bots scan yourself: it only sees what is already deployed, it is rate-limited, and re-running it is the site owner's call once the change ships.
