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 runs 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, its own capabilities, and its own 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 runs a verification round-trip: it actually calls your CMS, confirms the credentials work, and asks what the connection can do. That last part is the capabilities check. It's why Webflow connections without custom-code scopes can't update schema, and why a Shopify connection won't list image alt-text as supported. You'll see the capabilities right 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 runs against it, you merge when you're ready. Trakkr tracks the PR's state and shows it back 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.
| Fix type | What it changes | Where it lands |
|---|---|---|
| Meta title and description | Page metadata | Live (or PR, on GitHub) |
| Alt text | Image accessibility | Live in WordPress and Webflow |
| Schema markup | JSON-LD structured data | Live where supported, PR on GitHub |
| Heading structure | H1-H6 hierarchy | Page body |
| llms.txt and robots.txt | Site-level crawler files | Root of the connected site |
| Canonical URL, OG tags | Page-level SEO and social | Page head |
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.
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 | When the agent suggests a fix, it can apply it directly if a site is connected. The chat shows a "Connect destination" chip if not. |
| Workflows | A workflow 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 runs 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 to be connected 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 flip to error with a short reason: expired token, revoked permissions, unreachable URL, hardened firewall. The site stays in your list and previously applied fixes stay on your website. Click Reconnect on the card to re-run the auth flow.
Why isn't my fix being applied?
Three usual suspects: the connection's status is error, the platform's capabilities don't include the fix type (Shopify and alt text, for example), or the fix is queued for a GitHub PR that hasn't been merged yet. The proposal's 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 roll something back, do it from the History tab before you disconnect.