Sites
:::summarybox learn The difference between a brand and a site, and why Trakkr needs both How to connect WordPress, Webflow, Shopify, or a GitHub repo What Trakkr can do once a site is connected: publish, push meta, fix schema, manage llms.txt Why one brand often has more than one site How Sites plumbs into Optimize, Content, and the Agent
If your marketing site is on Webflow, your blog is on WordPress, and your docs sit in a Next.js repo on GitHub, that's one brand and three sites. Each site has its own connection, capabilities, and publishing destination, but they all roll up to the same brand's visibility, prompts, and reporting.
Connecting a site
To get to the Sites page, click Integrations in the sidebar, then pick the Sites category (or go straight to /sites). The first time you open it you'll see an empty Connected Sites tab and a Connect destination button in the header. That button opens a wizard that asks two things: which platform, and how to authenticate.
Each platform has its own front door:
| Platform | How you authenticate | What you get |
|---|---|---|
| WordPress | OAuth handoff to your wp-admin, or a username plus an application password | Read and write to posts, pages, meta, media, robots.txt, llms.txt |
| Webflow | OAuth into your Webflow workspace, then pick a site | Publish to collections, update SEO fields, manage field mappings for alt text and meta |
| Shopify | Install the Trakkr app from the Shopify App Store | Publish pages and blog articles, update SEO title and description |
| GitHub | GitHub App install, pick the repo and base branch | Open pull requests for content, meta, schema, and file changes |
After you authenticate, Trakkr performs a verification round-trip: it calls your CMS, confirms the credentials work, and asks what the connection can do. That last part is the capabilities check. A Webflow connection does not update schema, and a Shopify connection does not list image alt text as supported. You'll see the available capabilities on the site's card after it connects.
GitHub is the odd one out, on purpose. Instead of pushing changes live, every fix opens a pull request against the branch you picked. Your team reviews it, your CI checks it, and you merge when you're ready. Trakkr tracks the pull request state and shows it in the History tab.
What Trakkr can do once a site is connected
A connected site unlocks two categories of action: publishing and fixes.
Publishing means pushing content from Trakkr's content editor into your CMS as a draft, scheduled post, or live page. The Publishing tab is where you set defaults: which post type, which author, which categories, which publish mode. You set those once per site and every article you push uses them.
Fixes are the more interesting half. When Optimize audits your site and finds issues, the ones that are mechanically fixable become fix proposals. A proposal is one small change to one specific URL: "rewrite this page's meta description from X to Y, because it's truncated and missing the brand name." You review proposals on the Pending Fixes tab, approve them individually or in bulk, and Trakkr applies them through the same connection.
The platform matters. "Connected" does not mean every fix is available everywhere.
| Platform | Content Trakkr can write | Supported fixes | What Trakkr can revert |
|---|---|---|---|
| WordPress | Posts and Pages, including draft or live publishing | Meta title and description, social preview tags, canonical URL, schema, image alt text, llms.txt, robots.txt | Every listed fix when the original value was captured. It can also delete an article that Trakkr created. Heading changes are not supported. |
| Webflow | CMS collection items in draft or live mode | Meta title and description, social preview tags, canonical URL, mapped image alt text, plus robots.txt and llms.txt where the site API allows them | Every listed fix when the needed field or file access exists. It can also delete an article that Trakkr created. Schema and heading changes are not supported. |
| Shopify | Pages and blog articles in draft, scheduled, or live mode | Meta title and description | Meta title and description can be restored from the captured value. Trakkr cannot automatically delete a Page or article it created. Alt text, schema, crawler files, social preview tags, canonicals, and headings are not supported. |
| GitHub | Content and Page files through pull requests | Meta title and description, social preview tags, canonical URL, schema, llms.txt, robots.txt, and heading structure | Supported fixes can be reverted through another pull request. Image alt text and automatic deletion of a newly created article are not supported. |
Once a fix is applied, Trakkr re-verifies it on a schedule and shows the proposal as verified. If a change reverts (someone re-edits the page, the CMS overrides it, the PR is closed without merging), you'll see that in the History tab too.
How reverting works
Before Trakkr applies a supported fix, it records the current value. A revert sends that value back through the same connection and records the restore in History. This is why a change with no readable current value is not eligible for automatic Agent action.
Content needs a separate distinction:
- Updating existing content can be restored when the original title, body, excerpt, or slug was recorded in the change history.
- Creating new content requires deletion to undo it. WordPress and Webflow support that removal. Shopify and GitHub do not expose it as an automatic Trakkr revert.
- GitHub fixes are pull requests. The first pull request does not change the live site until your team merges it. A revert is another reviewable pull request.
Not every change in a CMS is a Trakkr change. If someone edits the same field directly after Trakkr, review the current value before reverting. The history shows what Trakkr captured, wrote, and later restored.
Multiple sites under one brand
You can connect as many sites as you want to a single brand. The Sites page filters by site when you have more than one, and most of the deeper tabs (Pending Fixes, Applied Fixes, History) let you scope to a specific connection.
Common shapes:
- Marketing site on one platform, blog on another. Webflow for the homepage and landing pages, WordPress for the content engine. Two sites, two sets of fix proposals.
- Production site plus a staging repo. A WordPress connection for live changes, and a GitHub connection for safer, PR-reviewed changes to the React app behind it.
- A multi-language setup. Each language gets its own connection if it lives on its own CMS instance.
Each site keeps its own credentials, capabilities, and publishing settings. They share the brand's prompts, visibility score, and reporting. Disconnecting a site doesn't affect your brand or its data. It just removes Trakkr's ability to push changes to that property.
How Sites plumbs into the rest of Trakkr
| Feature | How it uses a connected site |
|---|---|
| Optimize | Audit findings turn into fix proposals on connected sites. Without a connection, you get the audit but you apply the fixes by hand. |
| Content | The Publish button only appears for connected sites. Otherwise you copy the markdown out. |
| Agent | In chat, the Agent can suggest a fix and apply it after you confirm. A standing automation can change the site only for a separately granted work area, and only when this platform can snapshot and revert the fix. |
| Automations | An automation can trigger a fix or a publish through a site connection as part of an automated chain. |
A few features deliberately don't use Sites. Crawler Tracking works through an edge-side install on Cloudflare, Vercel, Netlify, or your CDN, separate from your CMS connection. AI Pages is its own edge integration. Traffic reads from those crawler and visitor pixels. None of those need a site connection here, and connecting one won't enable them. They're a different layer.
Common questions
Do I need a site connected to use Trakkr?
No. Tracking, research, perception, competitor analysis, citations, and reporting all work off your brand's URL alone. Connecting a site adds the ability to do things to that website from inside Trakkr, instead of copying changes out by hand.
Can one site belong to multiple brands?
Not today. A site is owned by a single brand. If two brands share a CMS instance (uncommon, but it happens with portfolio sites), you'd connect it twice, once per brand, using separate credentials.
What happens when a connection breaks?
You'll see the site's status change to error with a short reason: expired token, revoked permissions, unreachable URL, or hardened firewall. The site stays in your list and previously applied fixes stay on your website. Click Reconnect on the card to repeat the authentication flow.
Why isn't my fix being applied?
Three usual suspects: the connection has an error, the platform does not support the fix type (Shopify and alt text, for example), or the fix is waiting in a GitHub pull request that has not been merged yet. The fix status will tell you which.
Is GitHub a CMS?
For Trakkr's purposes, yes. A GitHub connection points at a repo that contains your site's content (Markdown files, MDX, Astro collections, Docusaurus pages, Next.js routes). Trakkr reads the repo, maps URLs to file paths, and opens PRs to change them. You still review and merge those PRs the way you would any code change.
Disconnecting, does it undo my fixes?
No. Disconnecting removes Trakkr's access to push more changes. Anything already applied to your site stays applied. If you want to revert something, do it from the History tab before you disconnect.