Make more money by making sure your links are valid html

[Simon]

I know that many webmasters don't bother validating their code. Not a good idea, for a variety of reasons. One of them is that unless you're validating your html code, you may never see any warnings to let you know that the sponsor links in your html pages may not be valid. And if they're not valid, it's possible that a surfer's browser won't read those links correctly, which could result in you not receiving credit for some of your sales.

The text below is from this page. It may help explain what I mean about sponsor links...

Ampersands (&'s) in URLs

A common error occurs when including a URL which contains an ampersand ("&"). Take a look at this example:

<!-- This is invalid! --> <a href="foo.cgi?chapter=1&section=2&copy=3&lang=en">...</a>

This example generates an error for "unknown entity section" because the "&" is assumed to begin an entity reference. Browsers often recover safely from this kind of error, but real problems do occur in some cases. In this example, many browsers correctly convert &copy=3 to ©=3, which may cause the link to fail. Since ⟨ is the HTML entity for the left-pointing angle bracket, some browsers also convert &lang=en to ?=en. And one old browser even finds the entity §, converting &section=2 to §ion=2.

To avoid problems with both validators and browsers, always use & in place of & when writing URLs in HTML:

<a href="foo.cgi?chapter=1&amp;section=2&amp;copy=3&amp;lang=en">...</a>

Note that replacing & with &amp; is only done when writing the URL in HTML, where "&" is a special character (along with "<" and ">"). When writing the same URL in a plain text email message or in the location bar of your browser, you would use "&" and not "&amp;". With HTML, the browser translates "&amp;" to "&" so the Web server would only see "&" and not "&amp;" in the query string of the request.

--

[j3sUS183]

You can see all entities here

[Simon]

To be clear.

Tags are something used in blog posts.

What we're talking about here is encoding character entity references and the things on the page you posted are called entities and not tags.

Too much confusion about things already. Best we call things by their real names.

[Useless]

Didn't Toby mention a couple months back that you shouldn't change the & to &amp; in CCBill links since it'll muck up something at their end?

[Simon]

I'm not sure but I'll look for that thread.

The idea here is that the "&amp;" only appears in the raw html code sent from the server and it is translated by the browser into the "&" that was there originally. So the link click sent to CCBill (or anywhere else) shouldn't have the "&amp;" in them by that time.

Time to look for that thread.

Maybe someone from CCBill can stop by to comment on this too.

[j3sUS183]

Originally Posted by Simon

To be clear.

Tags are something used in blog posts.

What we're talking about here is encoding character entity references and the things on the page you posted are called entities and not tags.

Too much confusion about things already. Best we call things by their real names.

Of course you're right

Sorry for mistake

[Simon]

Okay, found that thread...
http://www.greenguysboard.com/board/...ghlight=ccbill

I think we need to get a CCBill rep in here. Otherwise we're going to be talking about every link to CCBill *needing* to be coded as invalid html in order to get paid.

And if that's the case, then CCBill and all the affiliate programs using them need to get the word out to the webmasters who may be wasting their time writing syntactically valid html.

(j3sUS188 - no worries, I know you were trying to help)

[cd34]

The issue at that time was whether the link was coded in html (which does work) or done through a redirect script (which of course doesn't work)

If you code the html in the links, most browsers will de-entify prior to sending the request to ccbill, in which case you get credited. There were some strange browser versions that didn't de-entify properly which caused some issue. I would bet that less than 1% of the browsers don't properly handle entities in urls now.

However, if you are coding the link and sending it through a php redirect script,

<?php
header("Location: http://www.ccbill.com?asdf&amp;pa=1234");
?>

will not get translated properly on ccbill's side. Granted, the link is not in proper form, but, its so prevalent that I think ccbill (and any other affiliate program depending on an & or ? in the url) should properly try to de-entify the url before processing. Almost every traffic trading script will entify the url when it is placed in a database and redirect the surfer via an entified link.

I don't recall the exact syntax, but, you could always wrap the stuff that doesn't validate in CDATA blocks which would allow those urls with & to validate.

[Licker4U]

Originally Posted by Useless Warrior

Didn't Toby mention a couple months back that you shouldn't change the & to &amp; in CCBill links since it'll muck up something at their end?

The very first site I built I used Front Page and it automatically changed all "&'s" to &amp;. I was told not to use Front Page and hand code everything, which I did. I was told that changing the & to &amp; was only if you wanted the & to actually show up on a page. I have a LOT of affilitate links, not just to CCBill, that just have the & in the affiliate code.

Shouldn't ALL affiliate codes that have & in them be left as & and NOT be changed to &amp;?

[Simon]

Originally Posted by cd34

Almost every traffic trading script will entify the url when it is placed in a database and redirect the surfer via an entified link.

That's one more reason for sponsors not to use the standard CCBill link structure (or any structure that uses the '&' character in their links).

It's much better* to be able to link to a paysite using something like:

http://www.PaysiteName.com/?r=123456

There's no need to encode anything in that link address. The sponsor just needs some php code on the index page of 'PaysiteName.com' to grab the '123456' and stick it in an UNencoded "refer.ccbill.com/cgi-bin/..." address and send that along to CCBill to get the cookie set. CCBill sends the surfer back to the paysite immediately and it's like nothing special happened at all to the surfer.

The same thing applies on links to HFS and FHG. On those I like the idea of embedding the code somewhere inside the url instead of sticking it on the end, but either way, I think that getting rid of the '&' character in any and all links given to affiliates is something that all sponsors should do.


--
* When I say 'better' I mean from the standpoint of the affiliate webmaster. Obviously it might be financially attractive to a sponsor if some/many of the incoming signups didn't require any commissions to be paid out.

[msanchez]

Originally Posted by cd34

However, if you are coding the link and sending it through a php redirect script,

<?php
header("Location: http://www.ccbill.com?asdf&amp;pa=1234");
?>

will not get translated properly on ccbill's side.

I send alot of my ccbill links right through a php redirect as your example shows and I have never done anything but use the exact ccbill code and I get plenty of sales like that.

Im keen to explore adding the "&amp;" but hesitant because I dont want to break whats working.

Is it possible that some sales would still register with the default code but not as many as would register is using "&amp;" when using a php redirect?

Good thread here, but kinda confusing to a non technophile like myself.

[Useless]

Originally Posted by msanchez

Is it possible that some sales would still register with the default code but not as many as would register is using "&amp;" when using a php redirect?

With the php redirect, the web browser doesn't have the opportunity to de-entify the URL. It's like copying and pasting a URL right into the address bar. If you are using that linking method, there's no reason to worry about validation of the php redirect. There's no page to validate.

[msanchez]

With the php redirect, the web browser doesn't have the opportunity to de-entify the URL. It's like copying and pasting a URL right into the address bar. If you are using that linking method, there's no reason to worry about validation of the php redirect. There's no page to validate.

Thanks for the clarification UW.

[Wanderer]

Interesting discussion -- how can we validate our code? Should we use the w3.org?

[tickler]

Originally Posted by Useless Warrior

With the php redirect, the web browser doesn't have the opportunity to de-entify the URL. It's like copying and pasting a URL right into the address bar. If you are using that linking method, there's no reason to worry about validation of the php redirect. There's no page to validate.

You have to be careful with a few of the ad scripts though. They have a tendancy to insert the &amp sometimes. When setting things up, it's best to also go look at the source code to check the actual link. I found a PPC advertiser that works OK unless I go do maintenance on the link. The script then pops it to a &amp and I was wondering why the hits weren't counting at ccBill..

[virgohippy]

Thanks for the tip Simon. I think I'm going to make a few adjustments to the way I do things now.