If IndexNow is receiving a GitHub pull-request address instead of a blog URL, inspect the exact URL your workflow submits. A successful GitHub Actions run does not prove that the submitted address is a public page on your site. The right fix depends on how your site publishes content and how the workflow builds its URL list; changing the trigger alone may not solve the underlying problem.
What IndexNow is supposed to receive
IndexNow is for notifying search engines about URLs on your website that have been added, updated, or deleted. It is not for submitting a GitHub pull-request URL, a branch name, or a commit address. Each submitted URL should correspond to a public route on the site whose ownership has been verified for IndexNow.
As an Amazon Associate I earn from qualifying purchases.
Site ownership is verified by publishing an IndexNow key file. It can be placed at the root of the host or elsewhere on that host; if it is elsewhere, the request must identify the key location. Check that the submitted URL, host, key, and key location agree. See IndexNow’s official documentation for the protocol requirements and response codes.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Why a pull-request workflow can be confusing
GitHub Actions exposes pull-request metadata that identifies GitHub’s pull-request ref and commits—not the canonical URL of a blog post. For a pull_request workflow, GitHub documents GITHUB_REF as refs/pull/PULL_REQUEST_NUMBER/merge and GITHUB_SHA as the last merge commit on that ref. The PR head commit SHA is separately available as github.event.pull_request.head.sha. These values can help a workflow check out or compare code, but they are not website URLs.
#1 Best Overall
A pull_request trigger does not, by itself, make a workflow submit a GitHub URL to IndexNow. That depends on the workflow’s own URL-construction logic: for example, what values it places in the request’s url or urlList. GitHub documents the event behavior in Events that trigger workflows.
Trace the submitted URL before changing the trigger
- Find the IndexNow request. In the workflow and any action or script it invokes, locate where the request is assembled. Identify the exact value sent as
urlor each entry inurlList. - Log the outgoing values safely. Add a temporary diagnostic that prints the URLs being submitted, but redact the IndexNow key and other secrets. Inspect the actual request values rather than inferring them from a green workflow check or from the run’s commit information.
- Compare each value with the live site. Confirm that every URL uses the verified website host and the canonical public route for the affected page. A GitHub host, pull-request ref, branch, or commit identifier is not a substitute for that route.
- Check what event the run represents. Determine whether the workflow was building a pull-request preview, publishing production content, or running manually. The IndexNow notification should be connected to the site’s actual publication flow, not simply to whichever event happens to start a build.
- Trace URL generation back to content changes. Build the notification list from the site’s content or publication data so it contains the pages that actually changed. Do not treat a Git ref or commit SHA as the page URL.
- Test the resulting request and its response. Verify the host, URL, key, and key location, then interpret the response according to IndexNow’s documented status codes.
Choose a trigger that matches the publishing flow
GitHub supports push, pull_request, and workflow_dispatch triggers. Which one should send the notification depends on how a site moves from proposed content to a public page. A pull-request workflow may be useful for previews or checks; a production notification belongs at the point where the relevant public URL is published. For some architectures that may be after a push to the production branch; others need a different deployment event or explicit publication step. The trigger name alone does not establish that the right URL will be built.
GitHub environments can help separate deployment stages. An environment such as production can use branch restrictions, required approvals, custom protection rules, and limited access to environment secrets. These are available controls, not proof of what any particular workflow changed. GitHub describes them in Deploying with GitHub Actions.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteHandle updates, deletions, and batches deliberately
Do not submit every repository address merely because the protocol supports large requests. IndexNow allows up to 10,000 URLs in a JSON POST, according to its documentation; that is a maximum, not a recommended batch size. Submit only relevant changed website URLs, and make sure the workflow’s change-detection logic accounts for the site’s content model.
- New or updated posts: include the canonical public URL when it is published or updated.
- Deleted posts: determine whether the old public URL should be reported as deleted, and ensure the workflow can still identify that URL after the content file is removed.
- Renamed posts: account for both the old route and the new one where the site’s redirect or deletion behavior requires it.
- Multiple changes: send only the changed public URLs in the batch, rather than the repository’s files, PR addresses, or full URL inventory.
Keep a sitemap as the site’s complete URL inventory and for ongoing discovery. IndexNow is a way to notify search engines about changes; it does not replace the sitemap. IndexNow’s FAQ explains both the sitemap distinction and the fact that submission does not guarantee indexing.
What the IndexNow response does—and does not—tell you
A successful HTTP 200 means the search engine received the URL, not that it indexed the page. IndexNow’s official documentation states: “The HTTP 200 response code only indicates that the search engine has received your URL.” A 202 response means a submission was accepted while key validation is pending. Other documented responses include 400 for a malformed request, 403 for key problems, 422 for an invalid host, URL, or key combination, and 429 for excessive requests.
After correcting the workflow, validate the outgoing URLs and protocol response separately from search visibility. A received notification is one step in discovery; it is not evidence that a page has been indexed or will appear in search results.
Recommended Free Tools
What can be said about the incident-specific fix
The GitHub and IndexNow documentation establishes how pull-request refs work, what URLs IndexNow accepts, and which deployment controls are available. It does not identify a repository, workflow file, URL-building function, or patch for this particular incident. Without those details, there is no basis to claim that the fix was a specific code change—or simply switching from pull_request to push. The actual change should be described only after confirming the workflow’s trigger, URL-generation logic, change filtering, and production-publication condition.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
