JavaScript-Inserted and onclick Links: Verify a Delivery

A link inserted by JavaScript is crawlable according to Google's documentation as long as it ends up as an a element with an href in the rendered page. A link that works through onclick alone, through a span, or through a javascript: address is outside the recommended pattern. To verify a delivery you have to look for the link in three places: the raw HTML the server sent, the page the browser built, and, where you own the property, the page Google rendered. The working rule: if you cannot see an a element with an href in the rendered page, do not accept the delivery; ask for a written correction.

"The link works" can mean two different things. It can mean that clicking it opens the right page, or that a search engine can extract it as a link. The first matters to visitors, the second to the signal you paid for. No Google page says that a crawlable link will bring rankings; the checks below only test whether the delivery is technically correct.

Three places a link can live

The raw HTML

View page source shows what the server sent, before any script ran. A statically written link appears here as an a element with an href. A link added later by a script may not appear here, and that alone is not a defect.

The page the browser built

Inspect shows the page after scripts have run. A script-inserted link should appear here as an a element. The documentation puts it plainly: links added dynamically are crawlable as long as they use the markup shown for normal links. If Inspect shows an a with a real href, the insertion method itself is not a problem.

The page Google rendered

For script-inserted anchor text, the Link best practices page suggests using the "URL Inspection Tool" to confirm the text is present in the rendered HTML. That tool works for properties you own in Search Console; you cannot run it on a publisher's domain. For a link you bought, Inspect plus a screen recording are your practical methods. For your own site, see the Search Console links report guide.

The onclick question

Forms the documentation lists as not recommended

The Link best practices (Opens in a new tab) page lists these as not recommended, while noting that Google may still try to parse them: an a element that navigates only through onclick, a span carrying an href, an a element with routerLink instead of href, and addresses that start with javascript:. Read both halves of that statement: not recommended, and not guaranteed.

Is onclick always a problem?

No. An a element with a valid href and an onclick handler is among the recommended examples. A tracking or navigation script can use onclick without harm. The question to ask is whether a real href sits beside it.

Why javascript: addresses fail the resolution test

The documentation says the URL in the a element must resolve into an actual web address Google can send requests to. The javascript:goTo('products') and javascript:window.location.href='/products' examples are not recommended. A buyer's test: copy the href value and paste it into a fresh tab. If your target page does not open, the value is not a real web address.

Script-inserted links done properly

The acceptable case

If the script inserts an a element with a real href and the rendered page shows it, the documentation raises no objection. Themes and page builders can create components this way, and that does not count against you. Inspect should show the a, the href and the anchor.

Three risks

The first is timing. A slow or failing publisher script can leave the link absent when you first open the page; wait a few seconds and inspect again. The second is conditions: a link that appears on desktop but not on a narrow screen. The documentation has no statement on this; it is an operational risk. The third is loss on update. A theme or plugin update can remove a script-inserted link. This is why a second check after delivery matters.

Compare two widths

Practical suggestion: inspect at both desktop and narrow widths. Browsers name their device emulation tools differently, but the question is constant: is there an a with an href in both? If only one, the delivery is conditional and the seller should be asked about it in writing.

Page-level robots rules

Even a perfectly written link sits on a page whose directives matter. Google's robots meta tag page (Opens in a new tab) defines nofollow as "do not follow the links on this page" and noindex as "do not show this page in search results". X-Robots-Tag can be sent in the HTTP header for any URL, and any rule usable in a robots meta tag can also be sent that way. The page also says these rules are discovered when the URL is crawled, and that if robots.txt blocks crawling the rules will not be found and will be ignored.

For a buyer this means checking the head of the publishing page and the response headers. If the page carries nofollow, every link on it falls under that directive. If it carries noindex, the page itself may not be shown in search results. The page gives no figure for ranking effects. It also does not state whether robots meta tags depend on rendering, so if the tag is inserted by script you cannot infer the result from the documentation; ask the publisher whether it sits in static HTML. The meaning of rel values is compared in dofollow, nofollow, sponsored and ugc compared.

A delivery-day protocol

The steps

1. Open the publishing page in a normal window and find the link; reload and wait a few seconds if it is missing.
2. Open page source and search for your address or anchor. If found, the link is static HTML.
3. If not found, open Inspect and search the rendered page. If found there, the link was added by script.
4. If neither view contains it, the link is not on the page. That is a missing delivery, not a markup dispute.
5. Read the tag: a, span or button.
6. Read the href and paste it into the address bar.
7. Look for a robots meta tag in the head and an X-Robots-Tag in the response headers.
8. Record the copied element, a screenshot and the date.

Searching with the find box beats scanning a long page by eye. Browser menus and shortcuts vary by version and language.

Checklist

• Exact URL of the publishing page and check date
• Link present in page source (yes or no)
• Link present in Inspect (yes or no)
• href value
• rel value
• Page-level robots meta tag or X-Robots-Tag
• Desktop and narrow screen result
• Screenshot and copied element
• Decision: accepted, awaiting correction, rejected

The status model in backlink package delivery tracking pairs well with this list. Whether the page later gets indexed is a separate question, answered in how to check that a backlink page is indexed.

Decision rule

Do you see an a with an href in the rendered page? If no, ask for a correction. If yes, does the href equal your target? If no, ask for a correction. If yes, does a page-level nofollow or noindex conflict with the order? If yes, ask the seller in writing. If no, save the record and accept.

Hidden and conditional links

Some components show content only after a user action: tabs, accordions, pop-ups, sliders. The sources read here have no statement on links inside them, so the following are practical suggestions rather than documented rules.

A link inside a closed tab may or may not exist in the rendered page, depending on whether the component loads content in advance or on click. Inspect twice, before and after opening it. If a and href appear both times the risk is lower; if only after opening, write that in the record and ask why the placement sits in that component.

If a link appears only after a cookie banner is accepted or after login, you may see it while a crawler does not. The documentation does not address this. Open the page in a private window, click nothing and confirm that the link is visible. If it is not, treat the delivery as conditional and ask for an explanation.

Templates can show different components on mobile and desktop. If your link exists on only one, record which one, and consider requiring both in the order.

Example scenario: a regional travel agency on a news portal

Example scenario: A regional travel agency buys a sponsored paragraph on a local news portal. The portal renders its partner section through a component. The delivery email contains the URL; page source contains no trace of the agency's address. The owner assumes the order was not delivered.

Inspect tells a different story: after the component's script runs, an a element appears with the right href and the agreed anchor. The delivery is acceptable on markup. The owner then reads the head and finds a nofollow robots meta tag set by the portal's template. She writes to the portal asking whether this is intended for sponsored sections and records the answer. For the next order she adds two lines: the link is delivered as a and href in the rendered page, and any page-level robots directive is disclosed before payment.

Writing the rejection

Skeleton

1. Order number and full URL of the publishing page.
2. What you saw: for example, "in the rendered page the link is a span element; there is no href".
3. What the order says: "delivered as an a element with an href".
4. The requested fix and a deadline.
5. Screenshot, copied element and check date.

If the seller says it works in the browser

Your answer: working in a browser and matching the recommended pattern are different things. The documentation lists an onclick-only a element as not recommended. If the order named a and href, the dispute ends at the clause. If it did not, add the clause to the next order. The service request form guide, put the scope in writing, shows how.

Monitoring after delivery

One check is not enough. Practical suggestion: recheck within a week and then monthly, asking the same three questions each time: markup, page directives, record. Write down what changed and compare against the first record.

Script-inserted links depend on a component rather than static HTML, so template or plugin updates can affect them more easily. That is a likelihood from how such components work, not a statement from the documentation. For the same reason, asking the publisher to write the link into static HTML is a reasonable request before ordering; if the seller declines, your rendered-page record matters even more.

Two-person checks for agencies

For client deliveries, separate the person who placed the order from the person who verifies it, so that "the link exists" and "the link is correct" need two approvals. The report to the client should name the verifier, the date and the views used (source, Inspect). A small business owner cannot split roles, but repeating the check the next day gives a similar effect: a second look gives another chance to catch what the first missed.

Five mistakes in delivery records

Keeping a record is itself a check, and a record can be kept badly. These five mistakes reduce its value:

1. Taking only a screenshot. A screenshot shows how the page looks, not its markup. Without the copied element it does not answer the a and href question.
2. Not saying which view you looked at. If the link is absent in page source but present in Inspect, the record must say which view it describes.
3. Leaving out the date. Templates change, and an undated record cannot narrow down when a change happened.
4. Not comparing with the order. A working link is not enough; the href must equal the ordered target.
5. Skipping page-level directives. The link can be right while a nofollow or noindex in the head contradicts the order.

A short form that combines the three checks prevents all five. Short forms get filled in; long ones get skipped.

Questions to put to the seller before ordering

Ask these before paying and write the answers into the order note:

• Will the link be written into static HTML, or added by a component or script?
• If it is added by script, will it appear as a and href in the rendered page?
• Does the page carry a robots directive such as nofollow or noindex?
• If the template changes after delivery, will the link structure be preserved?

The documentation has no answer to the fourth question; any duration or protection exists only if the seller agrees to it in writing. If the seller avoids answering, make your decision knowing the uncertainty will be settled after delivery.

Reading the status code with browser tools

For a delivery record it helps to note not only that the page appears but also which status code the main document returned. The network panel of the browser's developer tools shows it; menu names differ by browser and language. If the page returns 200 and the link stands as an a with an href, both facts go into the record. If the component holding the link loads only after interaction, write that too. A dated line per check, with address, status code, view used, a and href result, rel value, robots directive and decision, makes changes visible when the lines sit side by side, and it shortens any later exchange with the seller.

Anchor text and image links at delivery

The link best practices page says anchor text should sit between crawlable a elements and lists empty link text as a bad practice. A link can carry the right href and still hand Google nothing to use as anchor text if its content is empty.

Empty elements and the title attribute

The page notes that when an a element is empty, Google can fall back to the title attribute as anchor text. That does not make an empty link acceptable. Practical suggestion: ask for visible, descriptive link text in the delivery record.

Image links

For image links, Google uses the image's alt attribute as anchor text. The page shows an image link with descriptive alt text as a good example and one with empty alt text and empty link text as a bad one. If the publisher delivered your link as a banner, read what the alt attribute says.

Text inserted by script

For anchor text added with JavaScript, the page suggests checking the rendered HTML with the URL Inspection Tool. That tool works only on a property you own in Search Console, so on a publisher's site you are limited to the browser's element inspector, which shows what your browser built, not what Google saw.

Reading robots rules that overlap

The robots meta tag document covers several rules together. At delivery, check both the tag in the HTML head and the X-Robots-Tag value in the HTTP response headers.

• When rules conflict, the more restrictive one applies: nosnippet overrides max-snippet.
• If different crawlers receive different rules, Google applies the sum of the negative ones. Nofollow for all crawlers plus noindex for googlebot means noindex and nofollow for Googlebot.
• The none value equals noindex plus nofollow.
• The rules are found only when a URL is crawled, so a robots.txt block means meta and header rules are ignored.

One date-based rule worth searching for

The document says the unavailable_after rule stops a page from being shown after the given date and time, and that Googlebot then reduces its crawl rate. For a paid placement with a set duration, a date earlier than the placement period means the page may leave results sooner than you paid for. The document does not describe any effect on link value. Practical suggestion: search the head and the response headers for this rule, and raise any early date in writing.

Quick reference

Google's documentation can change, so check the current pages before relying on any detail.

Frequently Asked Questions

Does a JavaScript-inserted link count for Google?

According to the Link best practices page, links added dynamically are crawlable as long as they use the recommended a element with href markup. For script-inserted anchor text, the page suggests using the URL Inspection Tool to confirm the text is in the rendered HTML.

The link is not in view-source but I can see it on the page. What now?

View-source shows the raw HTML the server sent, and a script-inserted link may not be there. Use Inspect to look at the rendered page. If an a element with an href is there, the documentation raises no objection.

Is a link that works through onclick acceptable?

An onclick next to a valid href is among the recommended examples. An a element that navigates only through onclick is listed as not recommended; Google may try to parse it, but the documentation gives no guarantee.

Is an href that starts with javascript: a problem?

The documentation does not recommend javascript: addresses, although Google may try to resolve them. The address in the a element should resolve into an actual web address.

Does nofollow on the publishing page affect every link on it?

Google's robots meta tag page defines nofollow as an instruction not to follow the links on the page. That is why the head and the HTTP headers of the publishing page are worth checking.

Can I use the URL Inspection Tool on any site?

No. It works for properties you own in Search Console. On a publisher's domain you rely on Inspect, a screen recording and the copied a element.

What should a rejection request include?

Include the order number, the publishing URL, what you saw, what the order says, the fix you request, a deadline, and a screenshot with the copied element.

Conclusion

A link inserted by JavaScript is acceptable under Google's documentation when it ends up in the rendered page as an a element with a real href. Links that depend on onclick alone, a span or a javascript: address are outside the recommended pattern; Google may try to parse them, but the documentation promises nothing. Page source, Inspect and Google's rendering show different things, so your delivery record should say which view you used, and the page-level robots directives deserve their own check. None of this is a ranking promise.

Add the three checks (markup, page directives, record) to your delivery template and send a written correction request at the first failure. If you prefer a package whose scope and delivery terms are stated up front, see the backlink packages on Akua Adforce; the details are on the product page.