Does this work with Next.js, Astro, Hugo, and similar?

Yes. We write files, and the framework is your choice; anything that builds content from Markdown or MDX in a Git repo fits. We learn your specific frontmatter and layout conventions from the content already in the repo.

Statamic sites fit this integration naturally because Statamic stores content as flat files, and its own REST and GraphQL APIs are read-only, so the Git workflow is the honest write path. We commit entries in your site's existing format.

Can content publish without a PR review?

Only if your repo allows it. We can commit to a branch that auto-merges or push with your rules, but we default to open PRs because the review step is the point of choosing a Git workflow. Your branch protection rules always win.

Git / MDX integration

Approved work lands in Git / MDX, without copy-paste.

Open commit-ready MDX or Markdown pull requests in your repo, published through your own deploy pipeline.

Connect it All integrations

Back to integrations

How it works

SearchHandled connects to your repository as a GitHub App or with a fine-grained personal access token and delivers content as commits on a branch, opened as a pull request. Files follow your repo's existing conventions: frontmatter fields, file naming, directory layout, and image handling are learned from the content already there. Your team reviews the PR like any other change.

Publishing states map onto your workflow rather than an API: a branch with an open PR is the draft, merging is publishing, and your CI or a scheduled merge is scheduling. Because going live depends on your build pipeline rather than on us, we verify the deploy hook fired after merge and surface build failures instead of assuming a merged PR means a live page. This integration also fits flat-file systems like Statamic naturally, since Statamic's own REST and GraphQL APIs are read-only.

Best forEngineering-led teams with a static site, docs site, or MDX blog who want content to arrive as reviewable pull requests.

Setup, step by step

Install the SearchHandled GitHub App on the target repository, or create a fine-grained PAT scoped to it.
Point us at the content directory and confirm the branch we should open PRs against.
We scan existing content to learn your frontmatter fields, naming conventions, and component usage, and you confirm the mapping.
We open a small test PR so you can check the diff shape, then merge or close it.
Optionally connect your deploy hook or CI status so we can verify builds after merges.

What lands in Git / MDX

Element	How it lands
Title and body	Converted to the native format, then verified by reading the entry back.
SEO metadata	Mapped to the platform's own fields, and flagged where it has none.
Images	Uploaded to your media storage with alt text. Never hotlinked.
Internal links	Rewritten to your live URLs and checked against redirects.
Publish state	Branch, review, and merge.

Field mapping is confirmed against your own content model during setup. Connectors are on every plan; the number of connected sites is what varies.

Best practices

Review PRs like code, because they are

Content arrives as diffs, so your normal review flow applies: CI runs, preview deploys build, and a reviewer approves. Resist the urge to bypass checks for content PRs; the checks are what keeps a bad build off production.

Keep frontmatter conventions consistent

We lint against the conventions already in your repo, which works best when those conventions are actually consistent. If half your posts use publishDate and half use date, pick one and we will follow it.

Use preview deploys for editorial review

If your pipeline builds PR previews, editorial review can happen on the rendered page rather than the raw MDX diff, which is a much better experience for non-engineers.

Scope repository access narrowly

Grant the App or PAT access to the content repository only, not your whole org. Content delivery never needs more than contents and pull request permissions on one repo.

Use it in the full SEO workflow

The connector is the last mile, not the strategy. Read the GitHub SEO content workflow for the evidence gates, draft state, review rules, publish checks, and measurement loop that surround this integration.

Known issues

What practitioners actually report, from official docs, issue trackers, and community forums.

Publishing depends on your build pipeline, not the API

A merged PR does not mean a live page. If the build fails or the deploy hook never fires, content sits merged but unpublished, and nothing in the GitHub API alone reveals that.

How we handle itWe open PRs, then verify the deploy hook fired after merge and surface build failures to you, rather than marking a delivery complete on merge alone.

docs.github.com

MDX component conventions vary per repo

MDX mixes components with content, and a commit that compiles in one repo can break the build in another because the components, imports, or frontmatter schema differ.

How we handle itWe lint new content against your repo's existing frontmatter and component conventions before opening the PR, so the PR that arrives is one that builds.