Short answer
If your website is built from a GitHub repository, AI Marketing Master can deliver each approved blog post as a pull request. It creates one new branch, adds one Markdown file with front matter (and the featured image, if any), and opens one pull request to your base branch. Your team reviews and merges it. The app never merges, never writes to the base branch and never deploys.
Who this is for
Many modern websites are not built in a website builder. They are generated from Markdown files in a repository, using tools such as static site generators or modern web frameworks, and the hosting rebuilds the site when the main branch changes. Developers like this setup because every change is reviewed. Marketing teams find it hard, because adding a blog post means asking a developer.
The GitHub connection gives both sides what they want: marketing gets approved posts into the repository without waiting, and developers keep full control of what is merged.
What lands in your repository
- A new branch made only for this post. The base branch is never written to directly.
- One Markdown file in your chosen content folder (by default content/blog), named with the date and a short slug.
- Front matter at the top of the file with the post details, followed by the approved body exactly as approved.
- The featured image, if the post has one, in an images folder next to the post.
- One pull request to your base branch, with a note that merging is your decision.
Setting up the connection
- Create a fine-grained personal access token in GitHub limited to the one repository that holds your website.
- Give it permission to write repository contents and pull requests, and nothing more.
- Enter the repository, the base branch (for example main) and the folder where posts belong.
- The app checks that the token can write to the repository and that the base branch exists. The token is stored encrypted and never shown again.
Honest status words
When the pull request is open, the post shows as Published, in blue, because the work has left the app but is not on your website yet. It turns green and shows Verified only after GitHub reports that the pull request was merged. If your hosting builds the site from the base branch, the app can also show the deploy status after the merge.
If something fails, for example the base branch was renamed, the status says so rather than pretending the post went out.
Safe to retry
If a step fails halfway, trying again reuses the same branch, the same file and the same pull request. You will not find three copies of one post in three pull requests.
Before you choose this route
Your site's front matter fields may differ from what the app writes. Ask your developer to check the first pull request and, if needed, adjust the site template to read the fields. If your website runs on WordPress or Shopify, use those connections instead; they publish directly without a merge step.
What it does not do
- Front matter field names may need matching to your site template.
- Posts only reach your live site after someone merges and your hosting rebuilds.
- One repository per connection, using a token you create.
Questions people ask
Does the app ever merge or deploy?
No. It opens a pull request and stops. Merging, and anything your hosting does after a merge, is your team's decision.
Which GitHub plans does this work with?
It works with repositories that accept a fine-grained personal access token with write access to contents and pull requests.
Can I edit the post inside the pull request?
Yes, your developer can change the file before merging. Keep in mind the app's record shows the version that was approved in the app.
Can it publish website pages as well as blog posts?
The GitHub route is designed for blog posts as Markdown files. Other page types need your developer to add them.
We only describe what the product really does today. Results depend on your business, your market and many things no tool controls.