Does Viewfy need write access to my main branch?

No. Everything arrives as a pull request on a branch, which is the entire delivery model. You review the diff and merge it, or close it. Nothing reaches your default branch without a human clicking merge, so the worst case for a bad suggestion is a closed PR in your history.

What if my marketing site is not in a git repo?

Then the pull request part does not apply and you lose most of the benefit. The blog posts and the X and Threads publishing still work, but SEO and AI visibility fixes have nowhere to land as code. Repo-based sites, docs sites and app frontends are where this model pays off.

How many pull requests should I expect to review?

Enough to stay in a habit, not enough to become a second job. Content arrives daily as a post PR. Technical fixes arrive when there is something real to fix, scoped one concern per PR rather than bundled, so a reviewer can answer yes or no without opening 40 files.

Can I keep my own writing style rules?

Yes, and Viewfy runs its own hard style rules already: no em dashes, no filler buzzwords, and an information-gain gate that a draft has to pass. Those rules are published on the /rules page. If your house style is stricter, the drafts follow yours, because a PR that fails your lint is just noise.

GitHub Marketing Integration: Tools That Fit Your Git Workflow

A github marketing integration means marketing work lands where code lands: a pull request. Viewfy does that. Daily blog posts, SEO and AI visibility fixes, opened as PRs on your repo.

No second dashboard to log into. No queue of suggestions quietly aging until someone has a slow afternoon.

What does a github marketing integration actually change?

It moves the marketing backlog into the code review queue you already read. A tool that tells you your titles are thin has handed you a task. A branch with the new titles, a diff, and a one-paragraph reason has handed you a decision.

That difference is the whole point of the angle here: fewer context switches. Your team already has a habit for reviewing changes. Marketing gets to borrow it instead of inventing a parallel ritual with its own logins, its own export format, and its own weekly nag.

A recommendation is homework. A diff is a yes or a no.

Why is a pull request better than a marketing dashboard?

Because a pull request has an end state. It gets merged, closed, or it rots visibly in your repo where everyone can see it rotting. Dashboard recommendations have no end state, which is why most of them have none.

Three practical reasons a PR wins for a small team:

The change is reviewable by whoever is already on review duty, with no new tool access.
Git history records what changed and when, so you can revert a bad meta description as easily as a bad function.
Nobody has to translate a screenshot of advice into an actual file edit. The edit is the deliverable.

If you want the longer version of this argument with tool comparisons, marketing automation for developers covers which categories can even reach a repo.

Which marketing changes belong in a pull request, and which don't?

Anything that lives in your codebase belongs in a PR. Anything that needs judgment about your positioning, pricing, or customers does not, at least not as a silent auto-merge.

Good PR material

Title tags and meta descriptions. Missing sitemap entries. robots.txt and llms.txt. Structured data. Internal links. A new blog post as a markdown file. Heading structure on a landing page. Prerendered content for routes that only exist client side.

Bad PR material

Category rewrites. Claims you cannot verify. Numbers copied from a past screenshot instead of pulled live. On Viewfy's own landing page the proof strip reads counts out of the database and hides itself when the count is zero, which is the rule we apply to customer content too: if a number cannot be regenerated, it does not ship.

What does the review actually cost a shipping team?

Minutes, if the PR is scoped honestly. The reviewer needs to answer two questions: does this touch anything that can break, and is the copy true.

A well-built marketing PR keeps those answers short by staying on low-risk surfaces. In Viewfy's own frontend, every landing string sits in one i18n file and the landing shell is prerendered separately from the app shell. Copy and meta edits never touch app routes. That is the shape we look for in a customer repo before opening anything: find the file where words live, keep the diff there, leave the router alone.

When a fix genuinely needs to touch logic, it gets its own PR with a title that says so, not a bundle labeled "SEO improvements" with 40 files in it.

What does Viewfy find that a crawl report usually misses?

The gap between what your site says it allows and what your infrastructure actually serves. That is where launched products lose AI visibility, and it rarely shows up in a standard SEO score.

Our scan of 383 Show HN products found 27% unreadable to AI crawlers and 17% blocked from Claude. Not blocked on purpose. Blocked because robots.txt says yes while a CDN rule or a client-side-only render says no.

The other common miss is discoverability of your best pages. Viewfy's own repo had this: /check, /merged and /rules are indexable routes and the three highest-intent pages on the site, and none of them were in sitemap.xml. The audit page, the proof wall, and the house rules, all invisible to crawlers. That is a six-line diff and it was sitting there while we shipped features.

What does Viewfy ship, and where does it land?

Four surfaces, one review habit. Content and fixes arrive as pull requests, social goes out to X and Threads, and paid runs on Viewfy's own ad account.

Item	Detail
Content delivery	Daily blog post, opened as a pull request on your repo
Technical fixes	SEO and AI visibility changes, also as pull requests
Social	Posts on X and Threads
Paid	Meta ads run on Viewfy's own ad account
Show HN scan	383 products, 27% unreadable to AI crawlers, 17% blocked from Claude
Getting started	First post is free, no card

How does this compare to a scheduler or an agency?

A scheduler owns your posting calendar and stops there. An agency owns strategy and sends you a deck. A github marketing integration owns the part that usually stalls: the change actually reaching production.

If your bottleneck is publishing volume on social, a scheduler is fine, and Viewfy vs Later and Viewfy vs Hootsuite lay out where each stops. If your bottleneck is positioning and enterprise-scale campaigns, read AI growth agent vs an agency before you buy either. And if you're comparison shopping the whole category, Viewfy alternatives for startup growth in 2026 is the honest map.

How do you test this on your own repo without committing?

Point it at your URL and read the first pull request. That is the test. If the diff is wrong, close it. Closing a PR costs one click and no invoice.

The standard we hold ourselves to: the post should still be worth publishing if you delete the line that mentions us. Same for the fixes. A sitemap entry does not care who wrote it.

First post is free, no card, at viewfy.ai.