![]() |
Make more money by making sure your links are valid html
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 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 ©=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 §ion=2 to §ion=2. To avoid problems with both validators and browsers, always use & in place of & when writing URLs in HTML: Note that replacing & with & 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 "&". With HTML, the browser translates "&" to "&" so the Web server would only see "&" and not "&" in the query string of the request. -- |
You can see all entities here :)
|
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. :) |
Didn't Toby mention a couple months back that you shouldn't change the & to & in CCBill links since it'll muck up something at their end?
|
I'm not sure but I'll look for that thread.
The idea here is that the "&" 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 "&" in them by that time. Time to look for that thread. Maybe someone from CCBill can stop by to comment on this too. |
Quote:
Sorry for mistake |banghead| |
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) |
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, Code:
header("Location: http://www.ccbill.com?asdf&pa=1234"); 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. |
Quote:
Shouldn't ALL affiliate codes that have & in them be left as & and NOT be changed to &? |
Quote:
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. |
Quote:
Im keen to explore adding the "&" 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 "&" when using a php redirect? Good thread here, but kinda confusing to a non technophile like myself. |
Quote:
|
Quote:
|
Interesting discussion -- how can we validate our code? Should we use the w3.org?
|
Quote:
|
Thanks for the tip Simon. I think I'm going to make a few adjustments to the way I do things now. :D
|
All times are GMT -4. The time now is 01:43 AM. |
Powered by vBulletin® Version 3.8.1
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© Greenguy Marketing Inc