Does Viewfy push directly to my main branch?

No. Work arrives as a pull request against your repo, so your CI, reviewers and branch protections stay in control. You read the diff, merge it, or close it. Nothing lands without a human clicking merge, which is the whole point of shipping growth changes through Git instead of a dashboard.

What counts as an AI visibility fix?

Anything that stops an AI crawler from reading your pages: JavaScript-only rendering with no prerendered shell, a CDN rule blocking a known crawler while robots.txt says yes, a missing llms.txt, or thin server responses. In Viewfy's scan of 383 Show HN products, 27% were unreadable and 17% blocked from Claude.

Can I use Viewfy if my marketing copy isn't centralized?

Yes, though the first PRs get bigger. Centralized strings, like Viewfy's own i18n translation file, make copy and meta edits low-risk because they never touch app routes. If your strings live across many components, expect a cleanup PR early so later changes stay small and reviewable.

What does the free first post include?

One post, no card. You drop a URL, you get the draft, and you keep it whether or not you continue. The test is simple: delete any Viewfy mention and see if the piece still earns the page. If it doesn't, you learned something cheap.

Is this a replacement for a social scheduler?

Mostly, for early-stage teams. Viewfy drafts and posts to X and Threads as part of the same run that produces the daily blog, so there's no separate queue to fill. Teams running many brands, approval chains or large content calendars will still want a dedicated scheduling tool.

Marketing Automation for Developers: Tools That Fit Git Workflows

Marketing automation for developers means growth work that arrives as a pull request, not a dashboard task. Viewfy writes a daily blog, opens SEO and AI visibility fixes on your repo, and posts to X and Threads.

That difference matters more than feature lists. Most growth tools end their job at a recommendation. A recommendation is a ticket you now own. A diff is a decision you make in thirty seconds.

Why do developer teams abandon most marketing automation tools?

Because the tool's output format doesn't match the team's work format. A scored audit with 42 issues is not work product, it's homework. Someone has to open the repo, find the right template, edit meta tags, rebuild, redeploy, then go back to the tool and mark it done.

So the audit sits there. The score stays red. Nobody is lazy, the handoff is just expensive.

Marketing automation for developers has to close the last mile itself. Recommendations create work. Pull requests remove it.

What does marketing automation for developers look like inside a repo?

It looks like a branch, a diff, and a description you can argue with. Viewfy reads the repo, finds the parts that hurt discovery, and opens the change as a PR against your default workflow. Your CI runs. Your reviewers review. If the change is wrong, you close it.

A real example from Viewfy's own codebase: frontend/public/sitemap.xml omitted /check, /merged and /rules. Those are the free audit, the proof wall, and the house style page. Three indexable routes, all high intent, none discoverable by crawlers. That's a four-line diff, not a strategy deck.

The same shape works for canonical tags, missing structured data, an unlinked orphan page, or a robots.txt that permits crawling while the CDN quietly returns a block.

What belongs in an SEO pull request, and what never should?

Small, reversible, reviewable changes belong. Anything that touches app behavior does not.

Belongs in the PR:

meta titles and descriptions
sitemap and robots entries
structured data blocks
internal links and anchor text
copy strings that live in one file

Never in the PR:

routing changes
build config rewrites
new dependencies for a meta tag
tracking scripts nobody asked for

Viewfy's own frontend is a useful model here. All landing copy sits in frontend/src/i18n/translations.ts, and the prerendered landing shell is separate from the app shell. Copy and meta edits stay away from app routes, which is exactly why they're safe to automate. If your marketing strings are scattered across twelve components, the first PR should probably be the one that centralizes them.

How do you know whether AI assistants can read your product at all?

Check the raw fetch, not the browser. Your site loads fine for you and returns nothing useful to a crawler that doesn't run JavaScript or gets stopped at the edge.

Viewfy ran a scan of 383 Show HN products with scripts/tier1_scan.py. Result: 27% were unreadable to AI crawlers, and 17% were blocked from Claude specifically. That's roughly one in four launched products invisible to the tools buyers now ask for recommendations. Not one in four bad products. One in four products with a config problem nobody was told about.

The fix is usually boring: a prerendered shell, an llms.txt, a CDN rule that stops treating a known crawler as a bot. Boring fixes are exactly what a PR is for.

They fit when the post comes from the same source as the blog and lands without a scheduling ritual. Viewfy posts on X and Threads alongside the daily blog, so one piece of thinking covers both surfaces.

This is the split people miss when comparing tools. A scheduler assumes you already wrote the thing. Compare Viewfy vs Buffer or Viewfy vs Hootsuite and the queue is not the difference, the drafting is. Same story in Viewfy vs Later: scheduling social is one lane, SEO plus AI visibility plus content is the rest of the road.

One rule survives all of it. If the reply only works as a pitch, don't send it.

What are the stable facts about how Viewfy delivers?

Surface	Output	Where it lands	Review needed
Blog	One post per day	Your site	Editorial only
SEO fixes	Diff on existing files	Pull request on your repo	Code review
AI visibility fixes	Crawler and prerender config	Pull request on your repo	Code review
Social	Posts on X and Threads	Your accounts	Editorial only
First post	Free, no card	Your site	Yours to keep

How should you judge any growth tool's own numbers?

By whether the number is generated or restated. Viewfy's proof strip pulls merged PR counts live from the database and hides itself when the count is zero, because a hardcoded past number is a lie with a timestamp on it.

Apply that test outward. If a vendor quotes a traffic lift, ask which account, which window, and whether the figure regenerates. Viewfy's Show HN stats have the same constraint: the docs require regenerating them together through the scan script, or the page starts drifting from reality.

Also worth reading before you buy anything: the best Viewfy alternatives for startup growth in 2026 covers where a single agent is the wrong shape.

When is a human agency still the better call?

When the work is judgment-heavy, relationship-heavy, or brand-defining. Positioning fights, partner deals, a launch with real budget behind it, none of that compresses into a diff.

Automation wins the repetitive lane: daily publishing, crawler hygiene, meta and link maintenance, the posts you'd otherwise skip during a shipping week. We broke down the split in AI growth agent for founders vs an agency. Short version: agency for the decisions, agent for the throughput.

What's the fastest way to test this on your own repo?

Drop a URL and read the first output. If the draft still helps after you delete the Viewfy line, it's real content. If the PR is a clean diff you'd merge from a teammate, it's real marketing automation for developers.

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