Sites
Sites is where you give Trakkr the keys to a website you operate, so it can read that site properly, push approved fixes back, and publish content without you copy-pasting. The page is at /sites and its heading is Site connections.
Your brand already carries a website URL. That is enough for tracking, research, and reporting. A site connection is the separate step that turns measuring into doing. It needs a paid plan.
Brand and site are different objects
A brand is an identity that AI talks about. Nike. Notion. Your company. It has prompts, competitors, citations, and a visibility score, and it lives in Trakkr's data layer. You can track a brand whose website you have never touched.
A site is a web property you operate, connected with credentials you supply. It has a platform, a URL, a status, and a set of capabilities the connection actually proved it has. Sites live in your CMS or your repo. Trakkr borrows access.
:::comparison headers=Brand,Site What it is|An identity AI talks about|A web property you operate Where it lives|Trakkr's data layer|Your CMS, your repo, your stack What it holds|Prompts, score, competitors, citations|Pages, posts, schema, files, credentials How many|One per business|Often several per brand
GitHub is deliberately the odd one out. Nothing goes live directly. Every change opens a pull request against the branch you picked, your team reviews it, your CI runs, and you merge when you are ready.
Reading the page
Site connections has two tabs.
Sites lists each connection with its status. Open one to reach its config drawer, which has Overview, Publishing, and either Field mappings (Webflow) or Repo mappings (GitHub). Publishing defaults live here: post type, author, categories, and publish mode. Set them once per site and every article you push uses them. The drawer also carries Verify again, which re-runs the capability check.
Changes is the fix pipeline, split three ways: Pending, Applied, and History. With more than one site connected, a picker filters to a single connection or All sites.
A pending fix is one small change to one URL, with the current value and the proposed value side by side. Approve them one at a time or in bulk. Trakkr applies each through the same connection it read from, then re-verifies later and marks the change verified. If someone re-edits the page, the CMS overrides it, or a pull request closes unmerged, that shows in History too.
What each platform can write
"Connected" does not mean every fix is available everywhere. This table is the adapter code, not an aspiration.
| Platform | Content Trakkr can write | Supported fixes |
|---|---|---|
| WordPress | Posts and pages, draft or live | Meta title and description, social preview tags, canonical URL, schema, image alt text, llms.txt, robots.txt |
| Webflow | CMS collection items, draft or live | Meta title and description, social preview tags, canonical URL, mapped image alt text, plus robots.txt and llms.txt where the token allows it |
| Shopify | Pages and blog articles, draft, scheduled, or live | Meta title and description only |
| GitHub | Content and page files, through pull requests | Meta title and description, social preview tags, canonical URL, schema, heading structure, llms.txt, robots.txt |
Notable gaps: Shopify writes no alt text, schema, canonical, social tags, or crawler files. Webflow writes no schema (that needs a separate Webflow App OAuth connection) and no heading changes. WordPress writes no heading changes. GitHub writes no image alt text.
How reverting works
Before Trakkr applies a fix, it records the current value. A revert sends that value back through the same connection and logs the restore in History. A change whose current value could not be read is not eligible for automatic Agent action at all, which is the point of capturing it first.
Reverts follow the same platform lines as writes. Meta title and description can be restored on all four platforms. Social tags, canonical, llms.txt, and robots.txt can be restored on WordPress, Webflow, and GitHub. Schema on WordPress and GitHub. Alt text on WordPress and Webflow. Heading structure on GitHub only.
Content behaves slightly differently from fixes:
- Updating existing content can be restored when the original title, body, excerpt, or slug was recorded in the change history.
- Creating new content has to be deleted to undo. WordPress and Webflow support that. Shopify and GitHub do not expose it as an automatic revert.
- GitHub reverts are pull requests. The first pull request never changed the live site until you merged it, and the revert is another reviewable pull request.
Not every change in your CMS is a Trakkr change. If someone edited the same field by hand after Trakkr did, read the current value before reverting. History shows what Trakkr captured, wrote, and later restored.
Where a connected site is used
| Feature | How it uses the connection |
|---|---|
| Site Optimization | Audit findings become pending fixes. Without a connection you get the audit and apply the fixes by hand |
| Content | Publish appears only for connected sites. Otherwise you copy the markdown out |
| Agent | In chat, the Agent proposes a fix and applies it after you confirm. A standing automation can change the site only for a separately granted work area, and only where the platform can snapshot and revert that fix type |
| Automations | A rule can trigger a fix or a publish through the connection as part of a chain |
Three things deliberately do not use Sites. Crawler tracking installs at your edge (Cloudflare, Vercel, Netlify, your CDN) or through the WordPress plugin. AI Pages is its own edge worker. Traffic reads from those sources. Connecting a site here will not enable any of them.
Common questions
Do I need a connected site to use Trakkr?
No. Tracking, research, perception, competitors, citations, and reporting all work from your brand's URL alone. A connection adds the ability to change that website from inside Trakkr instead of copying changes out by hand.
Can one site belong to two brands?
Not today. A site belongs to a single brand. If two brands genuinely share a CMS instance, connect it twice, once per brand, with separate credentials.
What happens when a connection breaks?
The site's status changes with a short reason: expired token, revoked permissions, unreachable URL, or a blocked REST API. The site stays in your list, fixes already applied stay on your website, and reconnecting repeats the authentication flow.
Why is my fix not being applied?
Usually one of three things. The connection is in an error state, the platform does not support that fix type (Shopify and alt text, for example), or it is sitting in a GitHub pull request nobody has merged. The fix status tells you which.
Is GitHub really a CMS?
For Trakkr's purposes, yes. The connection points at a repo holding your site's content: Markdown, MDX, Astro collections, Docusaurus pages, Next.js routes. Trakkr reads the repo, maps URLs to file paths, and opens pull requests to change them.
Does disconnecting undo my fixes?
No. Disconnecting removes Trakkr's access to make further changes. Anything already applied stays applied. If you want something reverted, do it from History before you disconnect.