Why SEO fixes belong in pull requests, not injected scripts

By Published 5 min read

Short answer

SEO fixes belong in pull requests because a fix in your code is in the HTML crawlers receive, goes through review, stays if you stop using the tool, and can be reverted with a commit. An injected script applies its fix at runtime, so whether it counts depends on which crawler runs your JavaScript, and the fix disappears when you remove the snippet. A script is still the practical choice when you cannot edit the site's source, need a change live without a deploy, or your site is already client-rendered.

There are two ways to get an SEO fix onto a website. You can change the code that produces the page, or you can add a script that rewrites the page after it loads. Both end with a better title tag. They are very different things to own.

What an injected script actually does

A script-injection SEO tool asks you to add one snippet to your site, usually through your layout or a tag manager. At page load, the snippet fetches a set of rules and edits the document in the browser: it sets a title, adds a meta description, appends structured data, rewrites an image's alt text. Nothing in your repository changes. The fix exists only at runtime.

That is genuinely convenient. It is also the source of every problem below.

Problem 1: crawlers do not all run your JavaScript

Search engines fetch the raw HTML first. Google can render JavaScript, but rendering is a separate, queued step that can take longer than the initial crawl. Other consumers of your page read what it ships: social link previews rely on the Open Graph meta tags in the page head, and the crawler documentation from OpenAI, Anthropic and Perplexity lists their bots without saying whether they run JavaScript. Check each vendor's current documentation, because this is changing.

If a fix only exists after JavaScript runs, then whether it counts depends on who is looking and when. A fix in the HTML you ship does not have that uncertainty.

Problem 2: no review, no diff

In a pull request, a change to your homepage title is a two-line diff that a teammate can read, question and approve. With an injected script, the change is a rule in someone else's dashboard that edits your page after your own build and your own tests have finished. Your CI never saw it. Your reviewer never saw it.

That matters most when the change is wrong. A title rewrite that drops your brand name, or structured data that contradicts the visible page, is the kind of mistake code review exists to catch.

Problem 3: the fix is rented

When you stop using a script-based tool, you remove the snippet and every fix disappears with it. Your titles, descriptions and schema go back to whatever the source code said before, which is the reason you needed the tool.

A pull request is the opposite. The change is in your repository, in your history, deployable by your pipeline. Cancelling the tool changes nothing about the site.

Problem 4: rolling back means detective work

If a pull request causes a problem, you revert the commit. If a runtime rule causes a problem, you first have to find out which rule changed which element, in a tool you may not have open. Version control gives you a timeline for free; a dashboard gives you whatever history it chose to keep.

When a script still makes sense

Be fair to the category. If you cannot edit the site's source, as with some hosted builders, then a script may be your only option. If you need a change live in minutes without a deploy, a script is faster than a build pipeline. And if your site is already client-rendered, the HTML-versus-JavaScript distinction matters less because there was never useful raw HTML to begin with.

Those are real constraints. They are also constraints most teams with a code repository do not have.

What Crawlmend does instead

Crawlmend crawls your site, reads Search Console and PageSpeed data, and proposes each fix as a diff against your repository. You see the file, the before and the after. Approve it and Crawlmend opens a draft pull request on a new branch. It never merges. Before opening it, Crawlmend applies the change to a throwaway clone and checks that it does not break your build; see how fixes are generated for the details and the limits of that check.

The goal is not to remove humans from SEO changes. It is to make the SEO change look like every other change your team already knows how to review: small, attributable, reversible.

A practical test

  • View source on a page you fixed. Is the fix in the raw HTML?
  • Ask who approved the change and where you can see the diff.
  • Imagine cancelling the tool tomorrow. What happens to your titles?
  • Imagine the fix was wrong. How long to find and undo it?

If those answers are uncomfortable, the fix probably belongs in a pull request. You can read the full comparison, or connect a repository and look at your first diff.